Confidential Containers and Encrypted Container Images

Current state and challenges

There are many use cases that necessitate the need for encrypted container images when working with confidential containers.

This article summarizes what we are doing under the Confidential-Containers (CoCo) project to provide this functionality and current challenges.

Before we dive into the details, let’s spend some time understanding the encryption/decryption process for container images.

A symmetric key is used for encryption and decryption of the image. This symmetric key is wrapped using a public key, commonly referred to as Key Encryption Key (KEK) to enable secure transmission.

The following picture from Brandon’s article helps to understand the process. If you are new to container image encryption, I would recommend reading his article for more details

Src: https://medium.com/@lumjjb/encrypting-container-images-with-containerd-imgcrypt-3c07f8e8e8d4

As of this writing, the skopeo tool has support for container image encryption and decryption.

Skopeo uses the ocicrypt library to work with encrypted container images.

Container Image Encryption & Decryption in the CoCo project

The following picture provides a high-level view of the different components

In the CoCo project using VM Trusted Execution Environment (based on Kata runtime), the Attestation Agent (AA ) implements the required support for obtaining the Key Encryption Key (KEK) from a Key Broker Service (KBS).

The container image encryption and decryption workflow are summarized below.

Image Encryption

1. Select base container image
2. Add secret data to the image
3. Encrypt the image
4. Push to container registry

For encrypting the container image one can use skopeo.

However, one of the key challenges w.r.to encrypted image creation is integration in a DevOps pipeline.

A typical DevOps pipeline with confidential container image build step will look like below:

Should we create a reusable tekton task? Or should we look at the custom resource pattern managed by a Kubernetes operator? Or is there a better alternative?

If you have ideas and suggestions please feel free to add your comments to the following Github issue — https://github.com/confidential-containers/operator/issues/20

Image Decryption by Kata

1. Create Kata POD
2. Download the container from the registry
3. Decrypt the container image
4. Execute

The container image download and decryption are performed at runtime by the kata-agent.

You can read the detailed description of the design in the following doc — https://github.com/confidential-containers/image-rs/blob/main/docs/ccv1_image_security_design.md

As you can make out, this is just the start of the journey to help users realize the benefit of confidential computing for their container workloads using open technologies.

Please reach out via GitHub — https://github.com/confidential-containers or slack https://katacontainers.slack.com