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

Over time, we will add more information explaining how to reduce the complexity of building, deploying and operating confidential applications deployed to Kubernetes.

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 cannot be read by any other process nor by the operating system or the hypervisor or any user.

  • 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 as well as the memory of the processes - unless the processes run in enclaves in release mode.

  • containerized CC App: an application consisting of enclaved services. The enclaved services cannot be inspected by users. However, the file system can still be inspected unless we encrypt the file system. SCONE can encrypt files in a way that is transparent to an enclaved service.


  • (transparently) encrypted volume: an enclaved service can get access to transparently encrypted volumes. To Kubernetes, these look like standard volumes. However, users that log into a container will only see encrypted files. To an authorized enclaved service, the files look like plain files because SCONE transparently decrypts/encrypts the files inside of the enclave.

  • 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 code, they will be able to establish a TLS connection.