SCONE and Kubernetes

In this section, we describe how we can build cloud-confidential applications with the help of SCONE. We can deploy these applications to a vanilla Kubernetes cluster.

Our main objective is to support confidential applications on managed Kubernetes clusters, i.e.,

• an external provider can operate the cluster,
• neither this provider nor the Kubernetes cluster is trusted, i.e., it is NOT part of the trusted computing base,
• SCONE can protect the data, the code (e.g., Python code), and the application's secrets, so neither the provider nor Kubernetes can access these.
• there is no need to modify Kubernetes or the operating system.

Getting Started

• Running a modern Linux kernel is sufficient to get access to SGX, i.e., there is no need to install any additional drivers:

  • Kernels starting 5.11 when running bare metal,
  • Kernels starting 5.13 KVM support SGX inside of virtual machines, and
  • Kernels starting 6.0 support EDMM (Enclave Dynamic Memory Management).

• SCONE supports Intel SGX for transparent Kubernetes support: We require that the cloud provider enables Intel SGX in the virtual machines that execute the Kubernetes nodes. If you need to use AMD SEV, please send us an email.

• Installing SCONE components: We recommend using the SCONE Kubernetes operator for a production setup: this will automate most of the SCONE components' lifecycle.

  Alternatively, you can install the components using helm:

  • helm install sgxdevplugin sconeapps/sgxdevplugin

    Our SGX plugin gives containers access to SGX on all Kubernode with SGX-enabled CPU.

  • helm install las sconeapps/las

    Install the local attestation service on all Kubernetes nodes with an SGX-enabled CPU.

  • helm install cas sconeapps/cas --set image=$SCONE_CAS_IMAGE (optional)

    Installs the SCONE Configuration and Attestation service. Alternatively, use a public cas like scone-cas.cf.

Workflow

We assume that you are already familiar with basic Kubernetes concepts. We first introduce some confidential computing concepts and then show how to install confidential applications.

Our recommended way to transform a service into a confidential service

• to use sconctl for cloud-confidential applications that you build,
• to use a lift-and-shift (a.k.a. sconify) approach for converting native services into confidential services, and
• use already sconified services - which we call SconeApps - in the context of your cloud-confidential applications.

We also present a low-level hello world tutorial in case you want to learn more about implementation aspects.

SCONE Confidential Computing Concepts

When developing a CC application, we need to consider the following concepts:

• (native) service: in Kubernetes, a service is an abstract way of exposing an application as a network service at one or more network ports. Multiple processes may serve these network ports. In confidential computing, we need to protect all of these processes. We use the term native service to refer to a service not covered by SCONE.

• confidential service: SCONE permits us to run each service's process inside an SGX enclave. Hence, we refer to such services as confidential services. We refer to all other services as native services. If such an enclave is in release mode, the CPU encrypts the enclave's memory. Therefore, this memory cannot be read by any other process, the operating system, the hypervisor, or any user. We refer to this encryption as runtime encryption.

• container: a container is a mechanism to deploy services. In most cases, this container will be a Docker container. Note that users can enter a container and inspect all files within it. Further, a root user can inspect any process's memory - unless this process runs in an enclave in release mode. In this case, a root user sees, at most, encrypted pages.

• containerized CC App: a containerized CC App is an application consisting of confidential services. Users cannot inspect these confidential services. Further, we require that neither any other app nor the system can read the contents of the files of a CC App. Note that enclaves do not protect files. Also, we cannot depend on the operating system to encrypt files since an adversary might already be in control of the OS.

• (transparently) encrypted volume: a confidential service can get access to transparently encrypted volumes. To Kubernetes, these volumes look like standard volumes. These volumes look like plain text files to the CC App. The CC App possesses this view as SCONE decrypts/encrypts files inside the application's enclave. A user that logs into a container will only see encrypted files.

• pod: a pod is a Kubernetes concept. It is the minimal deployable unit consisting of one or more containers executed on the same node. A pod can consist of confidential as well as native services.

• CC pod: a CC pod is a SCONE concept. It is a pod that contains only confidential services. Further, all of its volumes are encrypted. Also, all communication between confidential services is encrypted.

• IP address: a pod has an IP address. The network communication can be inspected unless it is encrypted. We explain below how SCONE helps to provide confidential services with certificates so that we can establish secure channels between confidential services and containerized CC Apps.

• TLS: SCONE can enforce all confidential services of a containerized CC App to communicate with each other via TLS. SCONE can enforce this secure communication for confidential services running in the same pod and confidential services across pods.

• server certs: SCONE can generate server certificates for services. These certificates are generated by a confidential service (SCONE CAS). Further, the server certificates can be injected into the filesystem of a confidential service. The server certificates are only visible to this confidential service receiving the injection, i.e., they do not exist outside its enclave.

• client certs: SCONE can also generate client certificates. SCONE CAS can provide a containerized CC app with a policy-controlled CA (as part of the SCONE CAS). Using the CA of the SCONE CAS, we can enforce access control to services. Only services with the appropriate client certificate are permitted to access a service.

• CA certs: SCONE can inject the CA certificates for the clients and the services. Using this injection, clients and services can perform a mutual attestation via TLS. The communication partners may only establish a TLS connection if they both run inside of enclaves, were properly initialized, have encrypted volumes that were not tampered with, and run an untampered binary.