👮Attestation

Confidential Container Attestation Workflow

Once the example configuration of vault engines for TLS and custom secrets provisioning is applied, starting an enclaved application becomes a straightforward process involving just three steps in the premain to prepare the environment and the filesystem.

Each application possesses a unique name, such as enclaive-redis-sgx, and generates an attestation for its self-signed certificate, which exclusively serves client authentication to the vault server.

The plugin searches for the required measurement using the provided application name when an authentication request is received. After confirming the quote's authenticity, the attested measurement and the user-supplied report data are compared against the expected measurement and the hash of the client certificate used in the request.

If all the checks pass, the client is granted a temporary token that allows access to a KVv2 secret associated with its attested name. Additionally, the client receives certificate issuance for its name subdomain within the cluster service domain.

To maintain the confidentiality of the access token, the client engages in peer certificate pinning following the authentication process. Since this logic is also included in the measurement, the coordinator can provide attestation that the application will not inadvertently expose this secret.