Skip to content

Sconify Container Image (Standard Edition)

Prerequisites

Please read section Sconify to understand the general sconification workflow first.

sconify_image is a command line tool within a SCONE image that enables the sconification of native images without detailed knowledge of the SCONE framework. sconify_image transforms a native container image to an encrypted SCONE-enabled image in one step. We call this transformation sconification. These SCONE-enabled images execute their service within an SGX enclave using the SCONE runtime. In particular, the features of sconify_image are:

  • sconification of the native image binary such that the execution of the sconified binary is performed within an SGX enclave
  • encryption and integrity protection of native image files: giving access to the sconified binary only after it is attested by the SCONE platform
  • creation of a SCONE policy using sensible defaults (e.g., including native image environment variables and working directory), and with options to customize to use additional features of the SCONE policy language (e.g., SCONE shared volumes, shared secrets, injected files) - ensuring only the sconified binary can access the secured resources, and
  • usage of all these features with only a single command - enabling an easy integration into existing CI/CD workflows.

We continue by demonstrating the usage of Sconify Image by sconifying a Python Flask REST API image. We thereby show the two main methods of image sconification with:

  1. SCONE File Protection
  2. SCONE Binary File System

Furthermore, we show how sconify_image facilitates easy modification of the SCONE policy. Finally, we give a detailed technical description of all command line options that the tool supports.

sconify_image currently supports musl LibC and GLibC container images

This 1-step conversion supports native images based on Alpine Linux and debian-based images. Debian-based image support is still experimental.

Debian-based image support

SCONE GLibC support is only compatible with PIE (Position Independent Executable)-compiled binaries. Please ensure your binary is PIE-enabled, e.g., with file <binary>.

Sconify Image Processing TIme

The current version (SCONE5.5) of the binary-fs, sconify_image requires a significant amount of computational and memory resources: sconify_image may take several minutes to sconify an image. The next SCONE release will contain a new the binary-fs that will use only seconds instead of minutes.

Sconify Image Workflow

SCONE File Protection

Suppose we have a simple Python Flask REST API service which we wish to sconify. We present the general workflow of the sconification process using SCONE File Protection:

Sconify Image Workflow

As shown, Sconify Image sconifies the native binary, and copies the sconified binary to the encrypted image. Further, Sconify Image encrypts the service's code and data files, and copies these encrypted files to the encrypted image as well. During the sconification of the image, Sconify Image creates a security policy containing metadata to decrypt the encrypted files and to check the files integrity. This policy also contains additional information, e.g., the native images environment and working directory. Sconify Image uploads this policy to an attested SCONE CAS. After Sconify Image finishes this process, we can run a confidential container from the encrypted image. Upon execution, the SCONE CAS attests the service to ensure its trustworthiness. After a successful attestation, the CAS sends the service the secrets specified in the policy, which enable the service to execute as expected.

We continue by showing a possible implementation of this workflow. The Dockerfile of the Flask service may look as follows:

FROM alpine:3.10
ENV LANG C.UTF-8
COPY rest_api.py /app/rest_api.py
COPY flask.key /tls/flask.key
COPY flask.crt /tls/flask.crt
COPY requirements.txt /app/requirements.txt
RUN apk add --no-cache openssl ca-certificates pkgconfig wget python3 python3-dev \
    && ln -s /usr/bin/pip3 /usr/local/bin/pip \
    && ln -s /usr/bin/pip3 /usr/bin/pip \
    && pip3 install -r /app/requirements.txt
CMD python3 -B /app/rest_api.py

To then use Sconify Image, we must select resources relevant for sconification. We see that the program code is in /app, and the data files that the service uses are in /tls. Further, our service runs in Python. Upon inspection, e.g., with $(which python3), we find that our binary is located at /usr/bin/python3.7. We specify this information: 

PROTECT_DIR_1="/app"
PROTECT_DIR_2="/tls"
BINARY="/usr/bin/python3.7"

Let us assume that the native image is named my-repo/my-native-flask. Further, we specify the name for the finished encrypted image for later use: my-repo/my-encrypted-flask. 

NATIVE_IMAGE="my-repo/my-native-flask"
ENCRYPTED_IMAGE="my-repo/my-encrypted-flask"

Push encrypted images automatically

To push the encrypted image automatically, set --push-image. Please make sure to name your image appropriately (e.g., ENCRYPTED_IMAGE="registry/repo/tag") and to provide the correct Docker credentials to the Sconify Image container, so that it can push to the specified repository. You can do so by mounting a Docker credential file inside of the Sconify Image container through a volume: -v $HOME/.docker/config.json:/root/.docker/config.json.

We also decide on information for using the SCONE infrastructure. We select a CAS to upload our policy, in this case the public CAS 5-2-0.scone-cas.cf. We additionally specify the name of a LAS. Further, we set a name for the session we wish to upload: my-flask-session, as well as a name for the flask service within the session: my-flask-service. And finally, we set a namespace CAS namespace to bundle this session with further sessions we may create in our workflow: my-workflow-namespace-$RANDOM. 

CAS_ADDR="5-2-0.scone-cas.cf"
LAS_ADDR="localhost:18766"
SERVICE="my-flask-service"
SESSION="my-flask-session"
NAMESPACE="my-workflow-namespace-$RANDOM"

We now require the SCONE environment variables with which we run our service: 

SCONE_HEAP="1G"
SCONE_STACK="4M"
SCONE_ALLOW_DLOPEN="2"

Finally, to attest the CAS and upload a policy, we need access to the SGX device. Hence, we determine the SGX device (see determining SGX device). The SGX device allows Sconify Image to attest the SCONE CAS. 

determine_sgx_device
Typically, we use the SCONE CLI to attest the CAS and upload sessions. Yet, Sconify Image executes these tasks automatically.

With all this information, we can run the Sconify Image tool: 

docker run --rm --device="$SGXDEVICE" \
    -v /var/run/docker.sock:/var/run/docker.sock \
    registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image \
    sconify_image --from="$NATIVE_IMAGE" --to="$ENCRYPTED_IMAGE" --cas-debug \
    --dir="$PROTECT_DIR_1" --dir="$PROTECT_DIR_2" \ # includes all subdirs as well
    --binary="$BINARY" \
    --cas="$CAS_ADDR" --las="$LAS_ADDR" \
    --service-name="$SERVICE" --name="$SESSION" --namespace="$NAMESPACE" \
    --create-namespace \
    --heap="$SCONE_HEAP" --stack="$SCONE_STACK" --dlopen="$SCONE_ALLOW_DLOPEN"

Running in Production Mode

For production, we must remove --cas-debug to ensure the CAS runs in production mode, and sign the binary with a production key: --scone-signer=PRIVATE_KEY_PATH

Upon successful execution, the tool then returns the name of the session ("$NAMESPACE/$SESSION"), and the encrypted image under the name "$ENCRYPTED_IMAGE" will have been created. The encrypted image also contains the CAS_ADDR and LAS_ADDR, as well as the SCONE_CONFIG_ID. As such, we can then simply run the service, and it will utilize existing SCONE infrastructure without the need for further specification: 

docker run --rm --device="$SGXDEVICE" $ENCRYPTED_IMAGE

SCONE Binary File System

Using the SCONE Binary File System (binary-fs), we can embed the service's files into the binary. This embedding extends the protection of the SGX enclave to the binary-fs. Further, the enclave's measurement (MRENCLAVE) then reflects the file system state. As such, the usage of binary-fs changes the process of Sconify Image sconification. The updated process is as follows:

Sconify Image Workflow Binary FS

As pictured, we must specify all files the service may access. This includes service libraries. As we use Python, Sconify Image includes the Python library be default. Thus, we must only make minimal changes to the command from before. To enable the binary-fs sconifcation mode, we must set --binary-fs. To specify directories to include in the binary-fs, we select them using --fs-dir. This option recursively includes all subdirectories as well. We can select individual files to include as well with --fs-file. We may require access to files containing system specific data, which are not avaible at the time of binary-fs creation. These files may include networking files, such as /etc/resolv.conf or /etc/hosts. To access such files which reside outside of the binary-fs on the host, we may use the --host-path option. Note that files included with this option are not protected. The modified Sconify Image command could look as follows:

docker run --rm --device="$SGXDEVICE" \
    -v /var/run/docker.sock:/var/run/docker.sock \
    registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image \
    sconify_image --from="$NATIVE_IMAGE" --to="$ENCRYPTED_IMAGE" --cas-debug \
    --fs-dir="$PROTECT_DIR_1" --fs-dir="$PROTECT_DIR_2" --binary="$BINARY" \
    --cas="$CAS_ADDR" --las="$LAS_ADDR" \
    --host-path="/etc/resolv.conf" --host-path="/etc/hosts" \
    --service-name="$SERVICE" --name="$SESSION" --namespace="$NAMESPACE" \
    --create-namespace \
    --heap="$SCONE_HEAP" --stack="$SCONE_STACK" --dlopen="$SCONE_ALLOW_DLOPEN" \
    --binary-fs

Service Library Inclusion

For supported services, we include service libraries into the binary file system by default. To view supported service, run docker run --rm registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image sconify_image --help

Binary-FS only compatible with PIE compiled binaries

Only binaries compiled with the -pie are compatible with binary-fs. To check if a binary is PIE-enabled, execute: file <binary> and check if the output contains pie executable.

In both Sconification variations, Sconify Image copies shared object dependencies of the binary into the encrypted image by default. Otherwise, the image container cannot execute the binary, as the shared object dependencies can not be loaded if they do not exist in the container's host file system. With binary-fs, the shared object dependencies loaded by the binary do not have to be included in the binary-fs. To include dependencies into the host file system of the encrypted image, we can use the --plain options.

Acquiring Policy Access

Before uploading a session to the SCONE CAS, Sconify Image generates a private key. Sconify Image then generates a corresponding public key. While uploading the session to the SCONE CAS, Sconify Image sends the CAS this public key. Sconify Image can then use this public / private key pair to identify itself to the CAS. The CAS binds the public key to Sconify Image's session, such that only holders of the corresponding private key may read and update the session. We may wish to read and update our session after Sconify Image is finished with the sconification process. Thus, we can retrieve Sconify Image's private key. We achieve this extraction by using a docker volume when running Sconify Image. We thereby mount the volume to the directory where Sconify Image stores, among other CAS relevant information, the private key (~/.cas/config.json): 

docker run --rm --device="$SGXDEVICE" \
    -v $PWD/private-sconify-image-key:/root/.cas \ # PRIVATE KEY VOLUME
    -v /var/run/docker.sock:/var/run/docker.sock \
    registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image \
    sconify_image ...
We can then use the config.json in other containers to read and update the session: 
docker run --rm --device="$SGXDEVICE" \
  -v $PWD/private-sconify-image-key:/root/.cas my-scone-image

Acquire Sconify Image Resources

During the sconification process, Sconify Image generates the encrypted image's Dockerfile and session. To collect these resources, we add a volume to Sconify Image. Sconify Image stores resources in /build-resources: 

docker run --rm --device="$SGXDEVICE" \
    -v $PWD/sconify-image-resources:/build-resources \ # RESOURCE COLLECTION VOLUME
    -v /var/run/docker.sock:/var/run/docker.sock \
    registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image \
    sconify_image ...
With these resources, we may rebuild the image ourselves. These resources are invaluable for debugging images created by Sconify Image.

CI/CD Workflow

In a typical workflow, one would perform the sconification of an image as part of the CI/CD pipeline: One would test the native image first, sconify the image and test the sconified image again. After a successful test, the binary would be pushed to a container image repository.

Advanced Sconifcation Options

Disable Default Sconification Behavior

By default, Sconify Image adds a symlink for supported services to the Dockerfile. To illustrate, if the binary to sconify is a Python 3 binary, such as /usr/bin/python3.7, Sconify Image will add a symlink: ln -s /usr/bin/python3.7 /usr/bin/python3. To disable this behavior, the option --disable-binary-symlink-detection may be specified.

Disable Copying of Shared Object Dependencies

Binaries require shared object dependencies to be executed. We can view these dependencies with: 

ldd <path-to-binary>
As we copy the binary to a different image than the native image, some shared object dependencies may not be present. As such, the binary may not be executable. To prevent this, Sconify Image, by default, copies all shared object dependencies of the binary from the native image to the encrypted image. To disable this behavior, we can use the --disable-copy-shared-object-dependencies option. As mentioned, this option may cause the binary to not be executable. To still enable that the binary is executable, shared object dependencies not available in the BASE_IMAGE must be specified with --plain-file.

Disable Copying of Service Libraries

Some services require certain service libraries to function. To illustrate, Python 3 usually requires a service library, e.g. /usr/lib/python3.7. Without the service library, the execution of the service may fail. As such, for supported services, Sconify Image attempts to find the service libraries within the native image and copy them to the encrypted image. For fspf sconification, the service libraries are plainly copied to the encypted image. In binary-fs sconification, Sconify Image includes the service libraries in the binary file system. To disable this behavior, e.g., to protect the service library with fspf, we use the option --disable-copy-service-libraries.

Disable Binary File System Defaults

Some services require shared object files that are not direct dependencies of the service during execution. To ensure that such services do not fail during execution when using binary-fs, Sconify Image includes all shared object files of the native image into the binary file system. This inclusion strongly increases the sconfication duration. To disable this behavior, we may use the --disable-binary-fs-defaults option.

Disable Replacement of Unsconifiable Binaries

Certain binaries cannot be sconified as is. They must be entirely recompiled with the SCONE libraries. Otherwise, the execution of such binaries results in hard-to-debug errors. Sconify Image detects such unsconifiable binaries, and replaces them with pre-compiled sconified binaries from SCONE images. To check which binaries Sconify Image replaces, try: sconify_image --help, in the desciption of the option --disable-replace-unsconifiable-binaries. We can use this option, --disable-replace-unsconifiable-binaries, to disable this behavior.

Policy Extension Options

Sconify Image enables easy extension of the security policy created in the sconification process. Currently, Sconify Image supports following security policy extensions:

Command

By default, Sconify Image sets the command in the security policy as the command in the native image. The container image executes this command upon a successful attestation by the CAS. To set a custom command, we can use --command=SESSION_CMD.

Environment Variables

By default, Sconify Image copies all environment variables from the native image to the security policy. Hence, Sconify Image protects the native environment variables. We can disable this default with --disable-copy-envvars. To specify additional environment variables for the security policy, we can use --env="KEY=VALUE".

Working Directory

By default, Sconify Image copies the working directory of the native image into the security policy. As such, upon execution, the working directory of the service will be the working directory set in the native image. The working directory's inclusion into the policy also protects it from external entities.

Volumes

With the option --volume=NAME:PATH:[[FROM_SESSION]:[TO_SESSION]], we can easily create and access SCONE volumes. We set the volume name with NAME and the mount path into the encrypted image with PATH. To simply create a volume: 

--volume="my_vol:/vol/simple-vol"

Optionally, volumes can be either imported or exported from or to other sessions, using FROM_SESSION and TO_SESSION, respectively. To import a volume my_in_vol from session import-session, we can use: 

--volume="my_in_vol:/vol/in-vol:import-session:"
To export the volume my_out_vol to session export-session, we can use: 
--volume="my_out_vol:/vol/out-vol/::export-session"
Exporting to multiple sessions is also possible: 
--volume="my_many_out_vol:/vol/many-out-vol::policy-1:policy-2:policy-3"

Disable Default Session Creation Behavior

Disable Copying of Environment Variables

As environment variables specified in the native image are typically used by the contained service, Sconify Image by default copies all existing environment variables of the native image to the session. As such, SCONE protects these environment variables, and only attested services may access them. To disable this behavior, we may use the --disable-copy-envvars option.

Automatic Helm Chart Generation

Helm allows developers and operators to define their application deployment to a Kubernetes cluster in a Helm chart, which is a collection of templates that are rendered into custom, valid manifests accepted by Kubernetes. Helm charts provide a sensible way of distributing and managing the lifecycle of applications that run on Kubernetes.

Sconify Image generates charts that inherit default values from the sconification process, such as the service name, the CAS address, the appropriate SCONE config ID, the encrypted image name and so on. Chart generation is enabled through the parameter --k8s-helm-workload-type=[deployment|job|statefulset|daemonset], which specifies how your application should be deployed to Kubernetes. A bit more about each workload type:

  • Deployment: the most common, intended for stateless workloads that run indefinitely (e.g., NGINX).
  • StatefulSet: intended for stateful workloads that run indefinitely (e.g., MariaDB).
  • Job: intended for workloads that run to completion (e.g., batch processors, ML pipelines).
  • DaemonSet: intended to run with exactly one replica per node in the cluster (e.g., node agents, device plugins).

Extending the previous Flask service example, which should run as a Kubernetes Deployment, we set:

export WORKLOAD_TYPE="deployment"

Generated charts are by default saved to /sconify-helm, so we add a volume to save the charts locally: -v $PWD/charts:/sconify-helm. The charts will be saved to a local directory called charts. The output directory can be configured through --k8s-helm-output-dir=$DIR option.

Finally, since the Kubernetes cluster needs to pull the sconified image before running it, we add --push-image and mount Docker credentials inside the container -v $HOME/.docker/config.json:/root/.docker/config.json , so sconify_images can push the images automatically. You can also push the images yourself after the sconification process is done.

docker run --rm --device="$SGXDEVICE" \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v $HOME/.docker/config.json:/root/.docker/config.json \
    -v $PWD/charts:/sconify-helm \
    registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image \
    sconify_image --from="$NATIVE_IMAGE" --to="$ENCRYPTED_IMAGE" --cas-debug \
    --dir="$PROTECT_DIR_1" --dir="$PROTECT_DIR_2" --binary="$BINARY" \
    --cas="$CAS_ADDR" --las="$LAS_ADDR" \
    --service-name="$SERVICE" --name="$SESSION" --namespace="$NAMESPACE" \
    --create-namespace \
    --heap="$SCONE_HEAP" --stack="$SCONE_STACK" --dlopen="$SCONE_ALLOW_DLOPEN" \
    --push-image \
    --k8s-helm-workload-type="$WORKLOAD_TYPE"

After the sconification process is finished, the generated chart can be installed as follows (using the defaults inherited from sconify_image):

helm install my-flask-api charts/$SERVICE

You can customize parameter values via --set option in helm install. For example, to deploy the Flask service with 5 replicas, and specifying an imagePullSecret so that Kubernetes can pull images from a private registry:

helm install my-flask-api charts/$SERVICE --set replicaCount=5 --set imagePullSecrets[0].name=my-secret

Charts generated by Sconify Image also include documentation. Refer to the documentation to see the full list of parameters accepted by the chart.

Kubernetes Naming Constraints

Due to Kubernetes naming constraints, some names in the chart might be slightly changed to be DNS-1123-compliant.

Volumes

If you configure encrypted volumes (through --volume option in sconify_image), they will also be translated to the Helm chart. Sconify Image will create templates for a Kubernetes volume and a volumeMount to bind it to your container. They will have the same mountpoint as specified in sconification, but might have a slightly different name because of Kubernetes naming constraints.

Each volume can be independently configured with respect to its persistence in Kubernetes. It's possible to disable persistence (using an emptyDir: {} volume), or to have PersistentVolumes attached to your application, either manually (by specifying an existing PersistentVolumeClaim) or dynamically, by setting Storage Classes.

Signing Options

Scone Signer

Sconify Image can also sign binaries of images during sconification, using the scone signer. Only signed binaries may run in production mode. Signing binaries requires an Intel verified private key. To use the scone signer, add the option --scone-signer=PRIVATE_KEY_PATH, whereby the PRIVATE_KEY_PATH is the patch to the private key accessible by the container. We give the container access with a volume. A corresponding command can look as follows: 

docker run --rm --device="$SGXDEVICE" \
    -v $PWD/my-private-key.pem:/my-private-key.pem \ # SUPPLY CONTAINER THE KEY
    -v /var/run/docker.sock:/var/run/docker.sock \
    registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image \
    sconify_image ... --scone-signer=/my-private-key.pem

We squash the image after building, such that the Docker build history does not expose information of the key. The key itself is never COPYed into the image. We use it with the DOCKER_BUILDKIT --secret option.

Session Upload Options

Identity

Sconify Image can also use identity files to create and access namespaces and sessions. An identity file must contain a PEM-encoded PKCS#8 private key followed by a X.509v3 certificate. These identity files serve as access control.

We can either generate an identity file with: 

openssl genpkey -out identity-private-key.pem -algorithm EC -pkeyopt ec_paramgen_curve:P-256
openssl req -x509 -key "identity-private-key.pem" -out "identity.crt.pem" -days 31 -nodes -sha256 -subj "/CN=Generated Test Certificate" -reqexts SAN -extensions SAN -config <(cat /etc/ssl/openssl.cnf <(printf '[SAN]\nsubjectAltName=DNS:www.scontain.com,DNS:localhost'))
cat identity-private-key.pem > identity.pem
cat identity.crt.pem >> identity.pem

Or we can extract it from a scone client which already uploaded a session, to acquire its identity and access rights: 

# within client container
printf '%b' "$(cat $HOME/.cas/config.json | jq .identity)" > identity.pem

We can then use this identity file in Sconify Image, to upload our session to e.g. a preexisting namespace, created by another client. We use the --identity=FILE option for this: 

docker run --rm --device="$SGXDEVICE" \
    -v $PWD/identity.pem:/identity.pem \ # SUPPLY THE IDENTITY TO CONTAINER
    -v /var/run/docker.sock:/var/run/docker.sock \
    registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image \
    sconify_image ... --identity=identity.pem

Disable Default Session Upload Behavior

Disable Session Upload

By default, Sconify Image uploads the session it generates. To disable any session uploading and CAS attestation, we can use the option --disable-session-upload. Sconify Image thereby still generates a session in /build-resources, yet does not upload it to any CAS. As such, Sconify Image does not require a CAS or LAS connection in this mode.

Disable Attestation

By default, Sconify Image attempts to attest the CAS that it will upload the session to. For attestation, it requires the Intel SGX Device. To upload sessions to the CAS without attestation and without requiring an SGX device, we can use the option --disable-attestation. This option is not secure.

Disable Session Security Attestation

By default, sessions uploaded by Sconify Image requires the service that wishes to utilize them to be attested by the CAS. This attestation requires the presence of a LAS. To enable a session to be usable by any service, we can disable the services attesation with --disable-session-security-attestation. This option is not secure, as it allows the session to be used by any service. This usability may expose secrets and secure configuration.

All Supported Options

  -h, --help               display this help and exit

REQUIRED:
  --from=NATIVE_IMAGE      name of the native image (which this script encrypts)
  --to=TO_IMAGE            name of encrypted image (image output of this script)
  --binary=BINARY          binary of the native image (which is to be sconified)

OPTIONAL:
  --name=SESSION           name of the CAS policy session (default: TO_IMAGE \ '/')
  --base=BASE_IMAGE        set the base image used to generate the encrypted
                             image (default=alpine:3.10)
  --command=SESSION_CMD    set the command in the session to be securely
                             executed, e.g.,
                             '/my-app/my-binary /my-app/secret-foo.txt'.
                             (default: ENTRYPOINT + CMD of native image)
  --env="KEY=VALUE"    set additional env variables to include in the
                             session, in addition to env vars from native image
  --cli=CLI_IMAGE          set the SCONE CLI image (default=registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image)
  --service-name=SERVICE_NAME      set the name of the service within the
                              SESSION (default: service). Is used for
                              SCONE_CONFIG_ID=SESSION/service
  --dir=DIRECTORY          add directory to encrypt; add one option per
                             directory. Will be added to the BASE_IMAGE file
                             system. NOT compatible with '--trace' and
                             '--binary-fs'
  --plain=DIRECTORY        copy directories that are not encrypted to the
                             TO_IMAGE file system
  --plain-file=FILE        copy files that are not encrypted to the TO_IMAGE
                             file system
  --volume=NAME:PATH[:[FROM_SESSION][:TO_SESSION_1]:...[:TO_SESSION_N]]
                           set a volume with name NAME at path PATH in the
                             session
                             (see sconedocs.github.io/CAS_session_lang_0_3/#volumes).
                             Optionally EITHER import volume from FROM_SESSION
                             OR export to TO_SESSION. Multiple export volumes
                             may be specified. If FROM_SESSION empty, only
                             TO_SESSSION will be used (e.g. name:path::to_session)
  --cas=CAS_ADDR           set the name of the CAS_ADDR (default=5-2-0.scone-cas.cf)
  --cas-debug              permit CAS to be in debug mode
  --las=LAS_ADDR           set the name of the LAS service (default=localhost:18766)
  --trace=TRACE_FILE       use tracefile to create encrypted files
  --template=TEMPLATE_FILE file containing policy template
                             (default=/src/session-template.yml)
  --session=SESSION_FILE   file that will contain the session
                             (default=/build-resources/session.yml)
  --secrets=FILE           policy section that defines secrets
                             (see sconedocs.github.io/CAS_session_lang_0_3/#secrets)
                             MUST BE MAPPED TO CONTAINER WITH VOLUME (-v).
  --injectedfiles=FILE     policy section that defines the injected files
                             (see sconedocs.github.io/CAS_session_lang_0_3/#secret-injection-files)
                             MUST BE MAPPED TO CONTAINER WITH VOLUME (-v).

  --namespace=NAMESPACE    namespace of this session (default=RANDOM)
  --create-namespace       create namespace (instead of using existing namespace)
  --identity=FILE          Identity file to use during session creation.
                             If omitted, the automatically generated CLI identity
                             will be used. An identity file must contain a PEM-encoded
                             PKCS#8 private key. MUST BE MAPPED TO CONTAINER WITH
                             VOLUME (-v).
  --push-image             push the sconified Docker image ('--to').
                             Please note that a valid Docker credentials file MUST be provided in its
                             default location (~/.docker/config.json). For example, you can mount it to
                             the sconify container with a volume (-v):
                                -v $HOME/.docker/config.json:/root/.docker/config.json
                             This parameter will not have any effect if --docker-trust-sign is also set.

ADVANCED:
DISABLE DEFAULTS:
  --disable-binary-symlink-detection   for supported services, disables the
                             automatic addition of a symlink to the BINARY in
                             the TO_IMAGE
  --disable-copy-shared-object-dependencies    disables default inclusion of
                             shared object dependencies of the BINARY on the
                             TO_IMAGE host file system
  --disable-copy-service-libraries for supported services, copy the service
                             libraries to the TO_IMAGE
  --disable-copy-envvars   disables default inclusion of NATIVE_IMAGE
                             environment variables in session
  --disable-session-upload disable session uploading and CAS attestation
  --disable-attestation    disables SCONE CAS attestation. Enables session
                             uploading without using Intel SGX. IS INSECURE.
  --disable-session-security-attestation disables attestation of the session.
                             Allows anyone to use the session; MRENCLAVE is NOT
                             verified. NO SERVICE AUTHENTICATION IS PERFORMED UPON
                             SESSION USAGE.
                             (see sconedocs.github.io/CAS_session_lang_0_3/#disabling-attestation)

BINARY FILE SYSTEM (binary fs):
  --binary-fs              use the SCONE binary file system to embed the file
                             system into the binary; ONLY SUPPORTS PIE COMPILED
                             BINARIES (see sconedocs.github.io/binary_fs/)
  --fs-dir=DIRECTORY       add a directory to the binary-fs; one option per dir
  --fs-file=FILE           specify certain files to include in the binary fs.
                             Useful if including the file's directory makes the
                             binary fs too large.
  --crosscompiler=CROSSCOMPILER_IMAGE    scone crosscompiler image for compiling
                             binary-fs of executable. Only used when binary-fs
                             is enabled.
                             (default=registry.scontain.com:5050/sconecuratedimages/sconecli:sconify-image)
  --disable-binary-fs-defaults     disables default inclusion of shared object
                             libraries and service related libraries in the binary fs

SIGNING:
  --scone-signer=PRIVATE_KEY_PATH  sign the binary for production mode
                             (uses other arguments from environment).
                             (see sconedocs.github.io/scone-signer/)
                             MUST BE MAPPED TO CONTAINER WITH VOLUME (-v).
  --docker-trust-sign=PRIVATE_KEY_PASSPHRASE   sign the image with docker trust
                             signer (requires docker trust private key on
                             platform and corresponding public key to be added
                             to target repo of TO_IMAGE). WILL EXECUTE A DOCKER PUSH.

KUBERNETES:
  --k8s-helm-workload-type=[deployment|statefulset|daemonset|job] generate a Helm chart to deploy
                                      the sconified application to a Kubernetes cluster as the specified
                                      resource.
  --k8s-helm-output-dir=DIRECTORY   save generated charts to DIRECTORY.
                                      (default=/sconify-helm)

SCONE ENV VARS:
  --heap=INT               heap size (default=1G)[SCONE_HEAP]
  --stack=INT              stack size (default=1M) [SCONE_STACK]
  --dlopen=[0|1|2]         dlopen: 0 - disable,
                             1 - enable and require authentication (default),
                             2 - debug only [SCONE_ALLOW_DLOPEN]
  --fork=[0|1]             enable fork (default=0) [SCONE_FORK]

DEBUG:
  -x, --debug              enables 'set -x' (commands are printed)
  -v, --verbose            prints created build artifacts (Dockerfile, session)
  --no-color               disable colored output (useful for execution in scripts)