Trustee: Remote Attestation and Secret Management

Trustee is the CNCF Confidential Containers remote attestation and secret-management solution for confidential containers and confidential virtual machines (CVMs). It verifies attestation evidence and releases keys, credentials, or other protected resources only to workloads that satisfy policy.

Trustee implements the Relying Party and Verifier roles from the IETF RATS architecture, and consists of three sub-components:

Guest-components is the repository implementing the Attester role from the IETF RATS architecture and consists of the Attestation Agent (AA) component. The AA (attestation-agent) runs inside the TEE (CVM) and is responsible for sending the evidence (claims) from the TEE to prove the trustworthiness of the environment.

There are also few other helper components inside the TEE:

• Confidential Data Hub (CDH): The CDH (confidential-data-hub) facilitates secure key retrieval for kata-agent and applications. It also provides additional services, such as secure mount for external storage or key management client services to retrieve keys directly from external Key Management Services. The secure mount service enables mounting of encrypted storage inside the TEE. The CDH APIs are exposed to the applications via a local API Server.

• API Server: The API Server (api-server-rest) is a local API server that exposes the CDH APIs to the applications.

• Container image library: The container image library (image-rs) provides the functionality to handle container image lifecycle inside the TEE (CVM).

Architecture¶

The CVM’s Attestation Agent (AA) sends attestation evidence to the KBS. The KBS forwards it to the AS for verification against the RVPS. Upon a positive result, the KBS releases the requested resource (e.g., a decryption key) from the KMS backend.

End-to-End Flow¶

A CVM attests to request a resource. The KBS appraises the attestation result before releasing a key or secret. Trustee can also delegate verification to external services (Intel Trust Authority, NVIDIA NRAS, etc.) and integrate with KMS, Vault, HSM, or Kubernetes Secrets as key backends.

CoCo Attestation¶

CoCo performs lazy attestation — Attestation is triggered on-demand. For example during pod creation to retrieve container image signature policy and key, or image decryption key. It could also be triggered post pod creation when the workload requests a secret.

Two attestation models are supported:

Background Check Model — the default CoCo mode. The CVM sends evidence directly to Trustee; Trustee verifies and releases the secret.

Passport Check Model — the CVM obtains a reusable attestation token from the Verifier and presents it to one or more Relying Parties directly. Useful when many services need to verify the same CVM.

Transport Security¶

Communication between the CVM and Trustee is protected at multiple layers. Trustee serves over HTTPS by default, with TLS certificates typically managed by cert-manager. The CVM pins the KBS certificate in its initdata configuration, so the Attestation Agent will only connect to the intended KBS instance. Because the initdata is measured into the TEE’s launch measurement, any tampering with the pinned certificate changes the measurement and causes attestation to fail. This binds transport security to the attestation chain. As an additional safeguard, the Attestation Agent generates an ephemeral key pair inside the CVM and includes the public key in the attestation evidence as runtime data. The TEE hardware signs over this runtime data, binding the ephemeral key to the attestation report. Secrets released by the KBS are encrypted using this ephemeral public key, so even if the TLS channel were compromised, only the attested CVM holding the corresponding private key can decrypt the response.

Workload APIs¶

Inside the pod, the Confidential Data Hub (CDH) exposes a local HTTP endpoint for secret retrieval. All requests trigger attestation if not already performed, and return the secret only on success.

Secret Resource Release API¶

The secret resource release API endpoint is available at http://127.0.0.1:8006/cdh/resource/ inside the pod.

The secret resource must be referenceable under the following path: {repository}/{type}/{tag}

Example — retrieve a decryption key stored in KBS under default/enckey/key.pem:

curl http://127.0.0.1:8006/cdh/resource/default/enckey/key.pem

Sealed Secrets¶

A sealed secret is a Kubernetes Secret whose value is encrypted and can only be decrypted inside a TEE after successful attestation. The encrypted form is stored in etcd — the actual plaintext never exists outside the TEE.

Flow:

1. User creates a sealed secret config pointing to a KBS resource

2. The config is encoded as a sealed secret value and stored as a K8s Secret — etcd holds only the encrypted form

3. When the pod runs inside the TEE, CDH attests to Trustee and retrieves the real secret

4. The plaintext value is injected into the container as an env var or volume mount

Mapping to RATS Standard¶