Skip to content

_index.adoc

Latest commit

 

History

History
83 lines (59 loc) · 6.85 KB

_index.adoc

File metadata and controls

83 lines (59 loc) · 6.85 KB
title Confidential Containers pattern
date 2024-10-03
tier sandbox
summary This pattern helps you get started with deploying confidential containers in OpenShift Container Platform.
rh_products
Red Hat OpenShift Container Platform
Red Hat Advanced Cluster Management
Red Hat OpenShift Sandbox Containers
industries
General
aliases /coco-pattern/
pattern_logo coco-logo.png
links
github install bugs feedback
coco-pattern-getting-started
Table of Contents

About the Confidential Containers pattern

Confidential computing is a technology for securing data in use. It uses a Trusted Execution Environment (TEE) provided within the hardware of the processor to prevent access from others who have access to the system, including cluster administrators and hypervisor operators. Confidential containers is a project to standardize the consumption of confidential computing by making the security boundary for confidential computing a Kubernetes pod. Kata containers is used to establish the boundary via a shim VM.

A core goal of confidential computing is to use this technology to isolate the workload from both Kubernetes and hypervisor administrators. In practice this means that even a kubeadmin user cannot exec into a running confidential container or inspect its memory.

Schematic describing the isolation of confidential containers from the hosting system

This pattern uses Red Hat OpenShift sandbox containers to deploy and configure confidential containers on Microsoft Azure. On Azure, confidential containers run as "peer pods" — VMs from the Standard_DCas_v5 family provisioned directly on the Azure hypervisor rather than nested inside OpenShift worker nodes.

It deploys three copies of 'Hello OpenShift' to demonstrate some of the security boundaries enforced with confidential containers, along with a kbs-access application that verifies end-to-end secret delivery from the Key Broker Service.

Requirements

  • An Azure account with the required access rights, including quota for Standard_DCas_v5 confidential VMs

  • An OpenShift 4.17+ cluster within the Azure environment

  • Tools: podman, yq, jq, skopeo

  • An OpenShift pull secret at ~/pull-secret.json

Security considerations

This pattern is a demonstration only and contains configuration that is not best practice

  • The pattern supports both single-cluster (simple clusterGroup) and multi-cluster (trusted-hub + spoke) topologies. The default is single-cluster, which breaks the RACI separation expected in a remote attestation architecture. In the single-cluster topology, the Key Broker Service and the workloads it protects run on the same cluster, meaning a compromised cluster could affect both. The multi-cluster topology addresses this by separating the trusted zone (Trustee, Vault, ACM on the hub) from the untrusted workload zone (spoke). The RATS architecture mandates that the Key Broker Service (e.g. Trustee) is in a trusted security zone.

  • The Attestation Service has wide open security policies. The default insecure policy accepts all images without signature verification. For production use, configure the signed policy in values-secret.yaml.template and provide cosign public keys.

Future work

  • Deploying to alternative environments supporting confidential computing including bare metal x86 clusters; IBM Cloud; IBM Z

  • Finishing the sample AI application for confidential inference with protected GPUs

  • Supporting air-gapped deployments

Architecture

Confidential Containers typically has two environments. A trusted zone, and an untrusted zone. In the trusted zone, the Key Broker Service (Trustee), attestation service, and secrets management (Vault) are deployed. In the untrusted zone, the sandboxed containers operator provisions confidential VMs and runs workloads.

The pattern supports both single-cluster and multi-cluster topologies. In the single-cluster topology (simple clusterGroup), all components are converged on one cluster. In the multi-cluster topology, the trusted-hub clusterGroup runs on the hub cluster and the spoke clusterGroup runs on one or more managed clusters imported via ACM. See Getting started for deployment options.

Schematic describing the high level architecture of confidential containers

Key components

  • Red Hat Build of Trustee 1.0: The Key Broker Service (KBS) and attestation service. Trustee verifies that workloads are running in a genuine TEE before releasing secrets. Certificates for Trustee are managed by cert-manager using self-signed CAs.

  • HashiCorp Vault: Secrets backend for the Validated Patterns framework. Stores KBS keys, attestation policies, and PCR measurements.

  • OpenShift Sandboxed Containers 1.11: Deploys and manages peer-pod VMs for confidential workloads. Operator subscriptions are pinned to specific CSV versions with manual install plan approval to ensure version consistency.

  • Red Hat Advanced Cluster Management (ACM): Manages the spoke cluster in multi-cluster deployments. Policies and applications are deployed to the spoke via ACM’s application lifecycle management.