Sconify: Lift-And-Shift Container Images
TL;DR
We show how to build a container image such that the service deployed by this image runs automagically inside of an Intel SGX enclave. This workflow uses a native image as input. Typically, the native image is generated by an existing CI/CD pipeline. We translate this native image into a confidential image such that all files are protected and the service runs inside of an enclave. This is a single-step transformation using the command sconify_image:
sconify_image --from="$NATIVE_IMAGE" --to="$CONFIDENTIAL_IMAGE" ...
Sconify Container Images
The general workflow to generate a confidential image is as follows. We add an extra stage that sconifies, i.e., converts a native image into a confidential container image to an existing CI/CD pipeline. For a node
-based application/service, this might look as follows:
The transformation is controlled via the command line arguments of sconify_image
. Typically, one would select the appropriate arguments when setting up the CI/CD pipeline. The image sconification should in most cases be completely automated and executed as part of the CI/CD pipeline. One might run the test stage after the sconification of the image.
Right now, we only support a commercial variant of sconify_image
which provides all feature required for production use.
During the sconification of a container image, one can also generate a SCONE policy and a helm chart:
The SCONE policy defines how to attest the service/application: when a service is started, SCONE verifies that the service runs the correct code inside of an Intel SGX enclave and the filesystem was not tampered with. To simplify the operations of confidential services, the container can be deployed in a Kubernetes cluster with the generated helm chart:
Protection Goals
By transforming a service into a confidential service, one can remove all admins as well as all the code running outside of the enclave from the trusted computing base. Note that SCONE will help to protect the files of an application and also the network traffic if needed, i.e., a service admin will only see encrypted files and will not know any application secrets. In other words, even if an admin is permitted to run a confidential service, it cannot see the files of the service nor can the admin see the memory content of the service during execution:
Next Steps
To learn about how to create confidential services, we recommend to read the following sections:
- example first, look at a simple example on how to sconify a Python container image - this includes all code to do so,
- file protection learn about the different file types and how to protect these types,
- sconify_image learn about the tool to create confidential container images, and
- advanced example shows how to set up a multi-party computations consisting of containers from different
To acquire more background information, you could then read about
- attestation and configuration to learn about the SCONE Configuration and Attestation Service, and
- encrypted volumes to learn how to defining a SCONE CAS policy which automatically encrypts Kubernetes volumes and controls access to the encryption key.