Kubernetes and Zero Trust: Enhancing Security with CNCF Confidential Containers

Zero Trust is a security strategy based on the following key principles:

👉 Verify explicitly → Always check and confirm identity using all available data.
👉 Use least privilege access → Give only the minimum access needed, using adaptive policies and ensuring data protection.
👉 Assume breach → Act as if a breach has already happened. Limit the damage by restricting access, encrypting data, and using analytics to detect threats.

CNCF Confidential Containers (CoCo) project facilitates implementing a zero-trust security strategy for any Kubernetes cluster through the following:

1. Runtime encryption that safeguards applications from infrastructure-based attacks: It enables executing workloads within isolated Trusted Execution Environments (TEEs) that provide runtime memory encryption. Running the workload in TEEs ensures that sensitive data remains secure even if the underlying infrastructure is compromised (assumes breach). For example, a database within the TEE stays encrypted and inaccessible, even with root access to the host operating system.
2. Remote attestation that verifies the environment before running workloads and allowing data access: Remote attestation helps implement the “verify explicitly” and “assumes breach” principles by facilitating hardware-based attestation that allows remote verification of the TEE, the workloads and the software stack running the workloads to prove their integrity. This approach ensures that only verified workloads running in an untampered environment can access sensitive data.
3. Policies: Policies are an explicit list of allowed and denied operations inside the TEEs. Even the cluster administrator doesn’t have access to the confidential containers (least privileged access).

Technically, this means focusing on the following key security measures:

1. Verifying the Trusted Execution Environment (TEE) before running the workload — Ensuring that the TEE and its software stack are valid, untampered, and attested before running workloads.
2. Retrieving Data Securely inside the Trusted Execution Environment (TEE)— Ensuring secrets and sensitive data are only accessible inside the trusted execution environment and never exposed elsewhere, even to the cluster or host administrator.
3. Providing explicit allowed and denied list of operations for the Trusted Execution Environment (TEE).

CNCF CoCo provides two features to facilitate the above security measures, enabling you to implement a zero-trust strategy for your Kubernetes deployments.

1. Secret Resource Release API endpoint
2. Policies

Secret Resource Release API endpoint

One of the core features of CNCF CoCo is the ability to securely retrieve secrets inside the TEE after proving its trustworthiness.

CoCo provides a Secret Resource Release API endpoint, allowing processes inside a CoCo-enabled workload pod to retrieve secret resources.

The API is available at the following endpoint:

http://127.0.0.1:8006/cdh/resource/

An application inside the pod (deployed inside the TEE) calling this API endpoint triggers the remote attestation procedure with the external Key Broker Service (KBS). On successful remote attestation, KBS releases the secret resources to the application.

For example, if KBS stores a secret key under default/enckey/key.pem, applications running inside the pod can retrieve it with:

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

The following diagram shows the components involved.

Author created

Please refer to my earlier blog for an in-depth explanation of the attestation and secret resource retrieval process.

How your confidential containers can securely retrieve secrets?

As mentioned, a key aspect is that the application receives the secret resource only after successful remote attestation. In other words, the secret is released only to a verified TEE environment.

As a user, you can employ this fact to verify the trustworthiness of the TEE and the related software stack. Let’s see an example.

Create a dedicated resource in KBS to verify the environment’s attestation status.

For example, let’s say you created a KBS resource named trustee-attestation-status/status with value attested .

Then if you want to verify that the deployed pod is indeed running inside a trustworthy TEE environment, you can run the following command by exec-ing into the pod.

curl -s http://127.0.0.1:8006/cdh/resource/default/trustee-attestation-status/status

On successful attestation, value of attested will be returned, proving that the pod is indeed running in a trusted TEE environment.

However, there is a catch. The cluster admin is untrusted. And ifexec-ing into a pod is allowed, then the cluster admin can retrieve any secret from the CoCo pod and the whole premise of protecting the secrets from the cluster admin falls apart. Any Kubernetes API operation (either via CLI or programmatically) is subject to tampering by the cluster admin.

The CoCo folks did think about this :-). Hence, they introduced the policy feature that you must use to prevent weakening the zero-trust strategy.

Policies

Simply put, policies are explicit allowed and denied list of operations allowed inside the TEE.

Please read about policies in my earlier blog.

Enforcing Security in Confidential Containers with Kata Agent Policies

You must use the policy to explicitly allow “exec” of specific commands, container image hashes to use and allowed pod spec mutations. Further, you should, at a minimum, use a signed image to avoid cluster admin tampering with the image. Before starting the pod, the CoCo runtime verifies the signature inside the TEE environment, preventing running of malicious tampered images.

Remember that cluster admin is untrusted when using CoCo, and any mutations to the pod specification, if not verified within the CoCo environment, compromise the zero-trust strategy.

I hope this blog provides some pointers when planning a zero-trust security strategy for your Kubernetes clusters.