Introduction

Using the SCONE platform, one can protect data (like PII and training data), and code (like Python programs)

at rest (i.e., on disk),
in flight (i.e., on the network), and
in use (i.e., in the main memory).

SCONE protects the confidentiality and integrity of the data and the code without needing to modify or recompile the application.

One novel aspect of confidential computing is that applications can be protected against privileged software like the operating system and the hypervisor. To certify that the data and code of a native application are adequately protected, we need to ensure that all software and hardware components are sufficiently protected. SCONE isolates each service individually. This reduces not only the attack's surface but also the effort to certify that an application is properly protected. The isolation enables us to securely outsource the management of components like the operating system and Kubernetes to a cloud/service provider. SCONE decouples the integrity and confidentiality of data and code from all other software components and from the entity that manages the software and hardware stack.

It is well known that many vulnerabilities are caused by using out-of-date software/hardware/firmware components. A second novel aspect of confidential computing is that one can attest all components that we need to ensure the confidentiality and integrity of our application. These components include the CPU, its firmware and the application code and its data itself. The attestation ensures that these components are up-to-date and no vulnerabilities are known for these components. In other words, one can establish trust in all components that are required to execute the application. In SCONE, this attestation is done transparently at each program start.

Development

Using SCONE, one can transform - a.k.a. sconify - an existing application into a confidential application without needing to modify the application. Moreover, one can integrate this process into existing development and deployment workflows.

Development Workflow

An application consists of one or more containers. Typically, a container hosts one service. A container is deployed with the help of a container image. Typically, a container image is created as part of a CI/CD pipeline. One can transform a container image into a confidential container image with the help of container image sconify_image. This sconification is typically triggered as part of the CI/CD pipeline. During development, one might sconify container images using a Linux, a Mac or a Windows machine. There is no need for a TEE environment.

Deployment At Development Workflow

During development, one will deploy confidential container images on a Kubernetes Cluster like AKS for testing. A confidential container image is deployed in the same way as a native Kubernetes image: one can use kubectl (e.g., hello world example) or via helm (e.g., hello world example). One needs, however, to deploy some extra services. We need to deploy the SCONE SGX Plugin and a local attest service on each node (see deploying LAS). To Kubernetes, a confidential container is handled in the same way as a native container.

Production

For running services in production mode, we would setup up services in a production Kubernetes cluster first. Second, one would automatically deploy and update confidential services.

Setup Workflow

In a production Kubernetes cluster, in addition to the SCONE SGX Plugin and a local attest service (see deploying LAS), we need a production-mode CAS. Installation of the services is performed with helm charts. The encrypted CAS database must be stored in a persistent Kubernetes volume. CAS can be deployed using a primary/backup system: When the current primary crashes, a backup CAS will be started and will take over the CAS service.

Production Deployment Workflow

In a production cluster, we want to automatically update services as soon as they have been updated. There are several tools that automate this workflow: they check if the image on a registry has been updated and then redeploy the service. In some cases, one even has a nice GUI that visualizes the current state. In a later post, we will introduce one of these tools. Since the attestation of SCONE-based service is performed transparently, we can deploy and update services using standard tooling.