Kubernetes provides several layers of isolation for containerized applications, but traditional containers still share the host operating system kernel. This creates a security concern for workloads that process sensitive information. Even when application containers are isolated from one another, privileged host software, administrators, or compromised infrastructure components may have access to workload memory and data.
Confidential Containers address this concern by using hardware-backed Trusted Execution Environments (TEEs) to protect workloads while they are running. Instead of relying only on conventional container isolation, a workload can execute inside a confidential virtual machine whose memory is protected by supported processor technology.
The CNCF Confidential Containers project brings this capability into Kubernetes through components such as Kata Containers, the Confidential Containers Operator, and Trustee.
This approach is useful for applications processing financial records, customer information, healthcare data, encryption keys, and other sensitive workloads. However, deploying confidential containers requires more than changing a Kubernetes runtime setting. Hardware support, image protection, remote attestation, secret management, and operational policies must work together.
What Are Confidential Containers?
Confidential Containers extend container isolation using confidential computing technology.
In a conventional Kubernetes deployment, a container runs through a container runtime such as containerd. Containers have isolated namespaces and resource controls, but they share the host kernel.
This means a sufficiently privileged host administrator or compromised host kernel may be able to inspect workload memory or interfere with execution.
Confidential Containers introduce a hardware-enforced isolation boundary around the workload. With the VM-based architecture, each confidential workload runs inside a virtual machine protected by a supported TEE.
Depending on the hardware platform, this can use technologies such as:
- AMD SEV-SNP.
- Intel TDX.
- Other supported confidential computing platforms.
The host remains responsible for scheduling and managing the Kubernetes workload, but the confidential computing hardware helps protect the guest's memory and execution state.
This is particularly important in multi-tenant environments where organizations need stronger separation between infrastructure operators and application data.
Confidential Containers do not eliminate every security risk. Application vulnerabilities, compromised dependencies, incorrect authorization, and exposed application endpoints remain relevant. The technology protects a specific boundary: the confidentiality and integrity of workload execution against certain infrastructure-level threats.
Understand the Architecture
The Confidential Containers architecture combines Kubernetes components with additional guest-side and attestation services.
The main components include:
| Component | Responsibility |
|---|
| Kubernetes | Schedules and manages application workloads |
| Confidential Containers Operator | Installs and configures confidential container components |
| Kata Containers | Provides the runtime and guest virtual machine |
| Kata Agent | Manages containers inside the guest |
| Attestation Agent | Collects hardware evidence from the guest |
| Confidential Data Hub | Handles confidential workload operations and secret access |
| Trustee | Verifies attestation and controls secret release |
A typical deployment follows this sequence:
- Kubernetes schedules a pod using a confidential runtime class.
- The runtime starts the protected guest environment.
- The guest establishes its identity through hardware-backed attestation.
- Trustee evaluates the attestation evidence.
- If the workload satisfies the configured policy, Trustee releases authorized resources or secrets.
- The guest retrieves and decrypts protected container images when required.
- The application starts inside the confidential environment.
The key point is that the application does not need to be redesigned into a different programming model simply to use VM-based confidential containers. Kubernetes continues to manage the pod through its familiar API.
However, the guest environment and hardware requirements introduce additional operational considerations.
Prepare the Kubernetes Environment
Before deploying a confidential workload, verify that the Kubernetes environment supports the required runtime and hardware configuration.
The requirements depend on the selected platform and deployment model.
For a hardware-backed deployment, check:
- A supported confidential computing processor.
- Firmware and platform configuration required by the TEE.
- A compatible Linux kernel and virtualization stack.
- KVM support where required.
- A compatible container runtime.
- Supported Kata Containers and Confidential Containers components.
- Access to the required attestation services.
The Confidential Containers Operator simplifies installation by managing the components needed by the cluster.
After installing the operator, verify that the expected runtime classes are available:
kubectl get runtimeclass
The exact runtime class names depend on the installed platform and configuration.
For example, a runtime class named kata may be available for a generic evaluation environment. A hardware-backed deployment may expose a platform-specific runtime class.
Do not assume that a generic runtime class provides hardware-backed confidentiality. Some configurations are intended for functional testing without confidential hardware.
This distinction matters when validating security requirements. A workload running successfully inside a test VM does not prove that its memory is protected by a hardware TEE.
Deploy a Basic Confidential Workload
Once the operator and runtime are configured, a Kubernetes pod can request the confidential runtime through runtimeClassName.
Consider a simple NGINX workload:
apiVersion: v1
kind: Pod
metadata:
name: confidential-nginx
labels:
app: confidential-nginx
spec:
runtimeClassName: kata
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80
Save the configuration as confidential-nginx.yaml and deploy it:
kubectl apply -f confidential-nginx.yaml
Check the pod:
kubectl get pods
Inspect the runtime information:
kubectl describe pod confidential-nginx
The runtimeClassName tells Kubernetes which configured runtime should handle the workload.
The image version in this example is illustrative. Production deployments should use an approved image version, preferably pinned by digest, and follow the organization's image security policy.
A basic deployment is useful for validating the Kubernetes integration. It does not yet establish a complete production security model. In particular, an unsigned or unencrypted image and a workload that does not request protected secrets do not demonstrate the full attestation and secret-release process.
Protect Container Images and Secrets
Protecting workload memory is only one part of confidential computing.
Container images can contain proprietary application code, configuration files, and other sensitive material. Secrets such as database passwords and encryption keys also need protection.
Confidential Containers supports workflows for signed and encrypted container images.
Image signing helps verify the origin and integrity of an image. Encryption protects image contents while they are stored and transferred. The guest can retrieve the necessary decryption material after successful attestation.
A simplified workflow looks like this:
- Build the application image.
- Sign the image using the organization's image-signing process.
- Encrypt the image using a supported image-encryption workflow.
- Publish the protected image to a container registry.
- Configure the confidential workload to retrieve the required decryption resources.
- Allow the guest to decrypt and use the image after the attestation process succeeds.
The signing and encryption steps solve different problems. Signing verifies image integrity and authenticity, while encryption protects the image contents from unauthorized access.
Both can be important for workloads containing proprietary code or sensitive configuration.
Use Trustee for Remote Attestation
Remote attestation is one of the most important parts of a confidential workload deployment.
A TEE produces hardware evidence describing the protected environment. This evidence can include measurements and platform information that help establish whether the guest is running in an acceptable state.
Trustee provides services for evaluating this evidence and controlling access to protected resources.
Its main components are:
- Key Broker Service (KBS): Coordinates attestation and resource requests.
- Attestation Service (AS): Validates hardware evidence.
- Reference Value Provider Service (RVPS): Manages reference values used during verification.
The guest's Attestation Agent collects evidence and communicates with the KBS. The KBS works with the Attestation Service to evaluate the evidence before authorizing access to resources.
This prevents a workload from receiving sensitive keys simply because it successfully started as a Kubernetes pod.
The resource-release decision should depend on the security state of the guest and the configured policies.
Configure Secret Release Policies
A confidential workload may need database credentials, encryption keys, or other protected resources.
Trustee uses resource policies to determine whether a particular workload can retrieve a resource.
For example, an organization may require that a database encryption key is released only to a workload running on an approved TDX or SEV-SNP platform.
A policy can inspect attestation claims and decide whether the request is authorized.
The following Rego example illustrates a basic allow-or-deny policy structure:
package policy
import rego.v1
default allow := false
allow if {
input["submods"]["cpu0"]["ear.status"] == "affirming"
}
This is an illustrative policy fragment, not a complete production policy. Actual claim paths and expected values depend on the attestation token and platform configuration.
A production policy should validate more than a single status field. It may need to check:
- The expected hardware platform.
- Accepted firmware and security measurements.
- The workload's initialization data.
- The approved Kata Agent policy.
- The requested resource.
- The identity and authorization context of the workload.
Trustee also distinguishes resource policies from attestation service policies. Resource policies control which resources are released, while attestation service policies determine how hardware evidence is evaluated.
Keeping these responsibilities separate makes the security model easier to maintain.
Understand Kubernetes Security Boundaries
Confidential Containers change some traditional assumptions about Kubernetes security.
In a normal cluster, administrators may have broad access to the host and container runtime. With confidential computing, the host outside the TEE is treated as untrusted for the protected workload's memory and execution state.
This does not mean Kubernetes administrators lose every operational capability. They can still manage pods, scheduling, and infrastructure. However, operations that cross the guest's trust boundary require additional controls.
For example, unrestricted kubectl exec access may undermine the intended workload security model.
Kata Agent policies can restrict operations performed inside the confidential guest. An organization may use these policies to control container creation, process execution, or access to specific images.
The policies can be cryptographically linked to the attestation process through measured initialization data. Trustee can then verify that the expected policy was applied before releasing secrets.
This is an important design consideration: a confidential VM alone is not a complete security policy.
Production Considerations
Running confidential workloads in production requires additional planning.
Hardware and platform compatibility
Confirm that the selected cloud provider or on-premises platform supports the required TEE technology. Hardware availability, firmware configuration, and supported runtime versions can vary.
Performance and resource allocation
Confidential virtual machines introduce additional resource overhead. Measure startup time, memory consumption, CPU utilization, and application latency under realistic workloads.
Image and secret lifecycle
Establish processes for rotating encryption keys, revoking compromised resources, updating signed images, and reviewing attestation policies.
Monitoring and troubleshooting
Collect Kubernetes events, guest logs, runtime health information, and attestation service logs. Ensure that the monitoring design does not expose sensitive workload data outside the intended trust boundary.
Recovery and availability
Plan for attestation service outages, unavailable key brokers, expired credentials, and hardware failures. A workload that cannot obtain its required secrets should fail safely rather than silently falling back to an unprotected execution mode.
Common Deployment Problems
| Problem | Possible cause | What to investigate |
|---|
| Pod remains in Pending state | Runtime class or node configuration is unavailable | Check runtime classes, node capacity, and scheduling events |
| Confidential runtime fails to start | Incompatible virtualization or hardware configuration | Verify the platform prerequisites and runtime logs |
| Attestation is rejected | Evidence does not satisfy the configured policy | Inspect attestation claims and reference values |
| Secret retrieval fails | KBS policy denies the request or the resource is missing | Check the resource URI, policy, and KBS logs |
| Encrypted image cannot be started | Decryption resource is unavailable or image configuration is incorrect | Verify image encryption and key provisioning |
| Workload starts without expected protection | A generic or non-confidential runtime was selected | Verify the actual runtime and hardware-backed attestation |
A useful troubleshooting approach is to separate failures into three areas: Kubernetes scheduling, guest initialization, and attestation or secret provisioning. This makes it easier to identify which component is responsible.
Conclusion
Confidential Containers extend Kubernetes workload isolation using hardware-backed confidential computing. They provide a way to protect sensitive application execution while retaining the familiar Kubernetes deployment model.
The Confidential Containers Operator, Kata Containers, and Trustee work together to establish the runtime environment, verify workload integrity, and control access to protected resources.
For production adoption, teams should go beyond deploying a pod with a confidential runtime class. They need to validate hardware-backed attestation, image signing and encryption, secret-release policies, operational restrictions, and recovery procedures.
The strongest deployments treat confidential computing as a complete trust model rather than a single Kubernetes configuration option.
Join the conversation! Your thoughts help the community grow.