Skip to content

Kubernetes and SconeApps

In this section, we describe how we can build confidential applications with the help of SCONE. We can deploy these applications to a vanilla Kubernetes cluster. Therefore, we do not need to modify Kubernetes in any way. Instead, we maintain an SGX plugin to simplify the scheduling of confidential applications.

We assume that you are already familiar with basic Kubernetes concepts. We first introduce some confidential computing concepts, then we show how to install confidential applications. We also introduce an in-depth hello world tutorial.

Our recommended way to transform a service into a confidential service is to use a lift-and-shift (a.k.a. sconify) approach. Additionally, we maintain a set of already sconified services which we call SconeApps.

Sconify Workflow

SCONE Confidential Computing Concepts

SCONE CAS

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 actually serve these network ports. In the context of confidential computing, we need to protect all of these processes. We use the term native service to refer to a service that is not protected by SCONE.

  • confidential service: SCONE permits us to run each service's process inside of an SGX enclave. Hence, we refer to such services as confidential services. We refer to all other services 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, nor 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.

SCONE CAS

  • (transparently) encrypted volume: an confidential service can get access to transparently encrypted volumes. To Kubernetes, these volumes look like standard volumes. To the CC App, these volumes look like plain text files. The CC App possesses this view as SCONE decrypts/encrypts files inside of 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 such that we can establish secure channels between confidential services as well as containerized CC Apps.

SCONE CAS

  • 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 both confidential services running in the same pod as well as confidential services across pods.

  • server certs: SCONE can generate server certificates for services. These certificates are generated by an confidential service (SCONE CAS). Further, the server certificates can be injected into the filesystem of an 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 as well as 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.