Imagine you run a restaurant where the kitchen staff can prepare your food perfectly, but they can never see the recipe, taste the ingredients, or peek at what the other tables ordered. That is essentially what Confidential Containers does for your workloads in Kubernetes. It creates a sealed environment where containers run inside hardware-isolated enclaves, meaning the host machine, the cloud provider, and even the cluster administrator cannot peek inside.
The problem it solves is real: when you run workloads in the cloud, you are trusting the infrastructure provider with your data. For regulated industries like finance, healthcare, and government, that trust is not always available. Confidential Containers uses hardware-level isolation technologies like Intel TDX, AMD SEV-SNP, and IBM Secure Execution to create encrypted memory regions where containers run without the host being able to read their memory.
Platform engineers and security teams in organizations handling sensitive data use Confidential Containers when they need to run workloads on infrastructure they do not fully control. It is a CNCF sandbox project that integrates with Kubernetes to make confidential computing feel as close to “just another runtime class” as possible.
So why should you care about v0.22.0 specifically? Because this release brings a Helm chart for Trustee (the attestation broker that holds the keys to your encrypted containers), support for Redis and AWS Secrets Manager as storage backends, and a brand-new JWKS endpoint for standardized token verification. Plus a breaking change in admin authentication that will require action if you are upgrading. Let us get into it.
What Is New
Trustee Gets a Helm Chart
If you have ever tried to deploy Trustee manually, you know it involved a lot of YAML wrangling. Trustee is the Key Broker Service that mediates between the encrypted container and the attestation infrastructure, releasing decryption keys only after the container proves it is running in a genuine hardware enclave.
With v0.22.0, Trustee now ships with an official Helm chart that handles deployment, configuration, and even IBM SE material mounting via PV/PVC. This is the kind of improvement that does not sound glamorous until you realize it takes a multi-day deployment exercise and condenses it into a single helm install command.
helm install trustee ./trustee-helm-chart \
--set as.enabled=true \
--set kbs.enabled=true \
--set rvps.enabled=trueThe Helm chart also includes end-to-end test support with sample attesters and TDX configurations, and there is a CI dashboard for monitoring deployments. See PR #1150 for the chart itself, PR #1447 for the e2e test framework, and PR #1458 for TDX e2e support.
New Storage Backends: Redis, Valkey, AWS Secrets Manager, and GCP Secret Manager
Trustee needs a place to store its secrets, policies, and reference values. Previously, your options were limited to a local JSON file, which is fine for testing but less ideal when you are running production-grade confidential computing infrastructure.
This release adds three new storage options. A Redis/Valkey key-value backend for high-performance distributed storage. An AWS Secrets Manager resource backend for organizations already invested in AWS. And a GCP Secret Manager backend for the Google Cloud crowd. You can now pick the storage that fits your infrastructure instead of working around the limitations of a filesystem.
# Trustee configuration with Redis backend
[secret_storage]
type = "redis"
addr = "redis://127.0.0.1:6379"
# Or AWS Secrets Manager
[resource_storage]
type = "aws_sm"
region = "us-east-1"This matters because in a production confidential computing setup, where you store your attestation secrets is a security-critical decision. Having Redis, AWS, and GCP options means you can align your Trustee storage with your existing secret management strategy. See PR #1332 for Redis, PR #1374 for AWS Secrets Manager, and PR #1469 for GCP Secret Manager.
Standardized Token Verification via JWKS
Attestation tokens are how a Trusted Execution Environment proves to the outside world that it is legitimate. But verifying those tokens requires knowing the signing key, and distributing signing keys securely is exactly the kind of problem that leads to security headaches.
v0.22.0 introduces a well-known JWKS endpoint at /.well-known/jwks.json that exposes the Attestation Service’s public signing keys. This means any downstream verifier can discover and validate attestation tokens using standard JWT/JWKS libraries, the same way OAuth works. The release also adds an issuer claim to attestation tokens, making them self-describing.
# Fetch signing keys
curl https://trustee.example.com/.well-known/jwks.json
# Response:
{"keys": [{"kty": "EC", "crv": "P-256", "x": "...", "y": "..."}]}
# Verify attestation token with standard JWT library
jwt.verify(token, jwks_keys, algorithms=["ES256"])This is a meaningful step toward interoperability. Instead of building custom verification logic for each attestation provider, you can use off-the-shelf JWT tooling. See PR #1428 for the JWKS endpoint and PR #1434 for trusted JWKS resolution via OpenID discovery.
Breaking Change: Admin Authentication Overhaul
This one requires action. The admin authentication framework in Trustee has been completely reworked. Previously, the KBS client authenticated admin operations using an admin private key. Now it uses an admin token instead.
If you are upgrading from a previous version, your existing admin private key configuration will not work. You need to generate and configure admin tokens before deploying v0.22.0.
The change modularizes the entire admin authentication and authorization system, making it extensible for future authentication methods beyond the current token-based approach. See PR #1239 for the implementation.
Deprecations and Removals
This release cleans house. Several components that had been on borrowed time have been removed:
- Docker CAA provider is gone. If you were using Docker as your container runtime in the CoCo attestation agent, you need to switch.
- Fedora-based mkosi-built podvm images and packer-built podvm images have been removed. The project has consolidated on a single image build process.
- CSI wrapper component has been removed, simplifying the storage interface.
- In-toto reference value extractor has been dropped from RVPS.
- Simple token support was already deprecated since v0.16.0, and the deprecation warning itself has now been removed. Simple tokens are truly gone.
Security Note
This release resolves GHSA-82j2-j2ch-gfr8, a vulnerability in rustls-webpki, by updating the dependency. The fix was applied in PR #1474. Additionally, JWE key material is now zeroized on drop (PR #1345), ensuring sensitive cryptographic material does not linger in memory longer than necessary.
Hardware Support
v0.22.0 continues to support and test on three major platforms: Intel TDX, AMD SEV-SNP, and IBM Secure Execution for Linux. Notably, NVIDIA GPU attestation is now tested on a stack featuring AMD EPYC 9274F with NVIDIA GH100 GPUs, running Ubuntu 26.04 and Kubernetes v1.34.1. The Intel verifier also gained support for air-gapped verification (PR #1368), dropping the dependency on the QCNL library for environments without internet access.
Under the Hood
This release is based on Kata Containers 4.0.0, which adopts the Rust shim as the default for many runtime classes. Confidential Containers still uses the Go shim for now, but the transition is on the roadmap. Trustee and guest components use KBS protocol v0.4.0 and are built with Rust 1.90.0.
The Bottom Line
Confidential Containers v0.22.0 is the release where Trustee grows up: Helm charts, enterprise storage backends, standard JWKS token verification, and a modular auth system make this feel less like a research project and more like something you could actually run in production.
