Skip to content

Kubernetes and SCONE Basics

In this section, we describe how one can build confidential applications with the help of SCONE. These applications can be deployed to a vanilla Kubernetes cluster. This means that one does not need to modify Kubernetes in any way. Instead, we maintain a 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, show how to install confidential applications and 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 the concept of exposing an application as a network service at one or more network ports. The network ports are actually served by one or more processes. In the context of confidential computing, all of these processes would need to be protected. To refer to a service that is not protected by SCONE, we use the term native service.

  • enclaved service: SCONE permits to run each process of a service inside of an SGX enclave. Hence, we call these enclaved services. We call all other services native services. If such an enclave is in release mode, its memory is encrypted by the CPU and cannot be read by any other process nor by the operating system or the hypervisor or any user. This is sometimes called runtime encryption.

  • container: a container is a mechanism to deploy services. In most cases, this will be a Docker container. Note that a container can be entered by users and the users can inspect all files in the container. Also, a root user can inspect the memory of any process - unless the processes run in enclaves in release mode. In this case, a root user sees at most encrypted pages.

  • containerized CC App: an application consisting of enclaved services. The enclaved services cannot be inspected by users. We also require that the content of the files of a CC App cannot be read by any other App or the system. 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 look like standard volumes.TO the CC App these look like plain text files since 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 is a SCONE concept. It is a pod that contains only enclaved services and all 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 secure channels can be established between enclaved services as well as between containerized CC Apps.


  • TLS: SCONE can enforce that all enclaved services of a containerized CC App communicate with each other via TLS. This is the case 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) and can be injected into the filesystem of an enclaved service: they are only visible to the enclaved service, 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 policy-controlled CA (as part of the SCONE CAS). In this way, one 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. In this way, one can perform a mutual attestation via TLS: only if both communication partners run inside of enclaves, were properly initialized, have encrypted volumes that were not tempered with and run an untempered binary, they will be able to establish a TLS connection.