Skip to content

Helm and Confidential Applications

Helm is the package manager for Kubernetes. It is our favorite way to deploy SCONE-based confidential applications to Kubernetes. Note that we do not need to trust Helm nor Kubernetes: SCONE & SGX can protect the confidentiality and the integrity of applications - even if Helm or Kubernetes would be compromised.

Our objective is that one can securely outsource the management of Kubernetes and services, like a database service, to external entity and still keep in control of one's applications and data.

One establishes trust with a confidential application via remote attestation. In the case of SCONE, each enclaved service is associated with a policy. Attestation ensures that the enclaved service conforms to this policy. The attestation is in most cases delegated to TLS. In this way, one can implement mutual attestation of enclaved services without the need to modify applications.

Prerequisites

If you need help installing Kubernetes clusters for confidential applications, just drop us an email.

sconeapps: Curated Confidential Applications

We support a large variety of confidential applications. One of the most convenient ways to deploy confidential applications to Kubernetes is to use Helm. We support this right now for commercial customers only: For the following steps you need to get access to the SCONE standard edition (email us).

sconeapps is a private Helm repository for which we need to grant you access. After you got access, you need to generate a GitHub token ( Click here to issue a GitHub token).

Use your token to add the sconeapps repository to Helm:

export GH_TOKEN=...
helm repo add sconeapps https://${GH_TOKEN}@raw.githubusercontent.com/scontain/sconeapps/master/
helm repo update

Docker Hub Credentials

The sconeapps images are stored in a private docker hub repo. Hence, to deploy these images, we need to grant you access and you need to pass your docker hub credentials to Kubernetes. To do so, you need to create a Kubernetes secret sconeapps containing these credentials.

You could first define your credentials which includes the generation of a access token:

export DOCKER_HUB_USERNAME=...
export DOCKER_HUB_ACCESS_TOKEN=...
export DOCKER_HUB_EMAIL=...

and then create a Kubernetes secret as follows:

kubectl create secret docker-registry sconeapps --docker-server=index.docker.io/v1/ --docker-username=$DOCKER_HUB_USERNAME --docker-password=$DOCKER_HUB_ACCESS_TOKEN --docker-email=$DOCKER_HUB_EMAIL

Our helm charts will refer to this secret by default. In case you already use a different secret name for your docker credentials, you can overwrite the name of the secret at the time you install any of the sconeapp charts.

Using Helm

See all charts available:

helm search repo sconeapps

Installing one chart:

helm install my-database sconeapps/mariadb-scone

This repository contains the following charts:

Chart Description
cas Deploy the SCONE Configuration and Attestation Service (CAS) to Kubernetes.
database Umbrella chart to deploy a scalable, confidential database consisting of MariaDB SCONE and MaxScale SCONE and HAProxy
las Deploy the SCONE Local Attestation Service (LAS) to all Kubernetes nodes;
mariadb-scone Deploy MariaDB SCONE, i.e., MariaDB running inside of SGX enclaves, to Kubernetes
maxscale Deploy MaxScale SCONE, i.e., Maxscale running inside of SGX enclaves and optionally, an HAProxy as Ingress
sgxdevplug Deploy our SGX Kubernetes plugin to Kubernetes; this is required by all other helm charts;
TEEMon Deploy TEEMon, our monitoring framework for confidential applications. It collects and visualizes performance metrics including SGX Metrics;
Visual Studio Code Deploy VisualStudio Code and the SCONE CrossCompiler to be able to edit and run your confidential applications inside of a Kubernetes cluster.

We support a large number of applications running inside of @(SGX enclaves). Just let us know what applications you need and we will add helm charts for these applications first.

Example

The database chart will deploy mariadb and maxscale charts together. The example below will deploy 6 instances of MariaDB SCONE: each one will act as a different shard, and also be attested by the provided CAS. MaxScale will generate a maxscale.cnf using the in-cluster DNS entries for each MariaDB instance. The last line enables an HAProxy Ingress exposing the MaxScale replicas to the external world.

export SCONE_CAS_ADDR=scone-cas.cf
helm install my-database sconeapps/database \
   --set global.mariadb.replicaCount=6 \ 
   --set mariadb-scone.scone.attestation.cas=$SCONE_CAS_ADDR \
   --set mariadb-scone.scone.attestation.config_id=database/db \
   --set maxscale.generateConfig=true \
   --set maxscale.haproxy-ingress.enabled=true

To check other examples and the complete set of options to further customize these charts, please refer to later sections of this chapter.