Skip to content

Kubernetes and SCONE Basics

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, and we continue with an in-depth hello world tutorial.

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 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.

  • enclaved service: SCONE permits us to run each service's process inside of an SGX enclave. Hence, we refer to such services as enclaved 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 enclaved services. Users cannot inspect these enclaved 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: an enclaved 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 enclaved as well as native services.

  • CC pod: a CC pod is a SCONE concept. It is a pod that contains only enclaved services. Further, all of its volumes are encrypted. Also, all communication between enclaved 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 enclaved services with certificates such that we can establish secure channels between enclaved services as well as containerized CC Apps.


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

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