Skip to content

SCONE CAS: Deploy and Attest

SCONE CAS is the configuration and attestation service that manages policies and attests services. We explain how to start SCONE CAS with the help of helm. Further, we show how to attest the SCONE CAS to ensure that it was properly deployed.

The easiest way to deploy SCONE CAS is to use the SCONE Operator.

Deploying SCONE CAS


The sconeapps/cas chart will deploy a SCONE CAS. If we do not need to set any special affinity options and we want to deploy the development CAS, you can just execute:

helm install cas sconeapps/cas

This starts SCONE CAS in the default Kubernetes namespace. As an alternative, you can deploy SCONE CAS with Kubeapps.

Configuration Options

You can learn about the configuration options by executing:

helm install cas sconeapps/cas --dry-run

One option to set is the image to be deployed. If you want to run in release mode, you need to specify a different image by first defining environment variable SCONE_CAS_IMAGE appropriately. You can do this as follows:

helm install cas sconeapps/cas --set image=$SCONE_CAS_IMAGE

By default, this helm chart uses the SGX Plugin. Hence, it sets the resource limits of cas as follows:

  limits: 1

In case you do not want to use the SGX plugin, you can remove the resource limit and explicitly mount the local SGX device into your container by setting:

  - name: dev-isgx
      path: /dev/isgx

  - name: dev-isgx
    path: /dev/isgx

You can check the status of this release, i.e., the instance that you just deployed, by executing:

helm status cas

Attesting SCONE CAS

Since we do not know if SCONE CAS was properly started, we need to attest SCONE CAS. Typically, the attestation will be performed by another confidential service. You can also perform the attestation manually. We assume that you trust your local computer that it properly executes the attestation.

You can attest your SCONE CAS as follows. First, forward the traffic from your local computer to the release that you just started:

kubectl port-forward  service/cas 8081:8081

Second, determine MRENCLAVE of the SCONE CAS image. Note for commercial customers, we provide a secure way to determine MRENCLAVE.

A generic way to determine MRENCLAVE is as follows. We set the environment variable IMAGE to the name of the SCONE CAS image. If you changed the SCONE CAS image, we assume that you set the environment variable SCONE_CAS_IMAGE accordingly (see above). We then compute MRENCLAVE of SCONE CAS - assuming that you trust your local computer:

export IMAGE=${}
export CAS_MRENCLAVE=$(docker pull $IMAGE > /dev/null ; docker run -i --rm -e "SCONE_HASH=1" $IMAGE cas)

You can view the result like this:


You can attest SCONE CAS on your local machine by executing the following command (set CLI_IMAGE to an image that contains the SCONE CLI):

export CLI_IMAGE=""
docker run -e SCONE_MODE=SIM  -it --rm $CLI_IMAGE scone cas attest -G --only_for_testing-debug  --only_for_testing-ignore-signer host.docker.internal $CAS_MRENCLAVE

It will print the following output if the SCONE CAS runs inside of an enclave:

CAS host.docker.internal at https://host.docker.internal:8081/ is trustworthy

and it will store the certificate of the SCONE CAS. This certificate can be used later to verify that we connect to the attested SCONE CAS.

For attesting a SCONE CAS in production mode, you should use hardware mode. We determine which SGX device to mount with the function determine_sgx_device.

docker run $MOUNT_SGXDEVICE -e SCONE_MODE=HW  -it --rm $CLI_IMAGE scone cas attest host.docker.internal $CAS_MRENCLAVE

You can also try to attest with a wrong CAS_MRENCLAVE (e.g. by incrementing by 1):

export CAS_MRENCLAVE=9a1553cd86fd3358fb4f5ac1c60eb8283185f6ae0e63de38f907dbaab7696795
docker run -e SCONE_MODE=SIM  -it --rm $BASE_IMAGE scone cas attest -G --only_for_testing-debug  --only_for_testing-ignore-signer host.docker.internal $CAS_MRENCLAVE

The output would look like this:

Error: Error during attestation of CAS
Caused by: Enclave hash does not match expectation: