Overview

We would like to propose a new media type for encrypted layers of a container image. This addition would facilitate the ecosystem for encrypted container images. This allows users with stricter trust requirements to be able ensure end-to-end encryption from build to runtime. In addition, it allows users to use a centralized managed repository (i.e. Docker Hub) without any risk of their images being compromised.

Outdated Design Doc (Look at PR for updated):
https://docs.google.com/document/d/146Eaj7_r1B0Q_2KylVHbXhxcuogsnlSbqjwGTORB8iw/edit?usp=sharing

Link to presentations:
Dockercon US 2019: https://www.youtube.com/watch?v=9LyPUy4XYbs&list=PLkA60AVN3hh-XtoZ8zoZir6wnpaVXGUgk&index=28
Kubecon CN 2019: https://www.youtube.com/watch?v=bzHPnlSfM_8

Tracking implementations:

containerd
https://github.com/containerd/cri/blob/master/docs/decryption.md
https://github.com/containerd/imgcrypt

crio
https://github.com/cri-o/cri-o/blob/master/tutorials/decryption.md

buildah
containers/buildah#2271

skopeo
containers/skopeo#732

Call for Contribution:

• Quay
• podman
• Kaniko
• Docker CLI

Links:

Details of updated changes can be viewed in the PR.
Implementation of those changes can be viewed in this PR.

Proposal written and discussed by:
Brandon Lum (@lumjjb), Dimitrios Pendarakis, Hani Jamjoom (@jamjoom), James Bottomley (@jejb), Phil Estes (@estesp), Stefan Berger (@stefanberger), Alaa Youssef within IBM.

This is a follow-up from a discussion with @stevvooe , and @dmcgowan at DockerCon.

Goals

In coming up with a proposal, we considered the following:

• Application creators should not need to worry about details of encryption. Flows in the DevOps process and the runtime orchestration would be responsible for facilitating encryption.
• Re-usability of layer de-duplication among container images
• Encryption should be end-to-end, from the build step to when the container needs to be run on the worker machine. (i.e. registry owner should not be able to view the encrypted contents).
• Encrypted images created can be for multiple trusted entities, and key management is responsible for managing that trust.
• Specification should be easily integrated to generic with and across key management systems.
• Secondary experimental goal: Allow more granular control of security, to provide possibility of desegregation and more fine-grained security controls. (i.e. base OS, middleware, application can be encrypted separately).

Proposed Changes

Details of updated changes can be viewed in the PR.
Implementation of those changes can be viewed in this PR.

In the creation of a container runtime bundle from the encrypted images, the runtime would perform an additional step of performing the decryption based on the information given in the annotations.

Additional Details

We include some of the interesting discussions we have about the proposal.

Encryption Standard

The encryption/decryption will be done will be according to OpenPGP standard as according to RFC4800.

• The layer data will consists of Symmetrically Encrypted Data Packet as in RFC4880 Section 5.7
• The wrapped keys (org.opencontainers.image.pgp.keys) will be an array of Public-Key Encrypted Session Key Packets as in RFC4880 Section 5.1
• Decryption will be done by processing the wrapped key packets followed by the encrypted data packets.

Key Management

The purpose of Key Management is to assist in performing distribution, storage and use of keys. We note that this is important to be able to ensure that container runtimes are able to obtain the keys for decryption, and for encrypted container image creators to pass keys to their kubernetes/docker runtimes. However, we note that Key Management in itself can be seen as a separate component that assists the use of Encrypted Container Images. Therefore, we treat the process of Key Management as separate from the design of the Encrypted Container Images itself.

We note however, that Key Management is important in ensuring technology adoption. We discuss Key Management briefly. We have two models of key management that we consider, they are not exclusive and can probably be used in tandem.

Own Key Management

Key management is handled by the operator of the cloud, and plugins are provided to allow interfacing with existing Key Management Solutions. In this case, the Key Management Solution (i.e. Vault, Azure Vault, IBM KeyProtect, etc.) need to be trusted by the company (run by themselves or by a trusted service).

An example:

Company A has an existing internal Vault service. To build an image, the build machine or developer generates a symmetric key through Vault to perform encryption of the image. This symmetric key is then stored in the Vault service via an Encrypted Container Image Vault plugin. To run the image, the administrator configures it's kubernetes cluster with a Vault token to use the internal vault service via a Encrypted Container Image Vault plugin.

Fully Centralized Untrusted Key Distribution

Key management is handled by users and container runtimes interacting with an untrusted Key Distribution server (alongside container image registry). Private keys are still managed individually by users but no additional external party's trust is required (if server is compromised, no keys are lost). In addition, it provides a central location for users to manage. The trust model is similar to that of Docker Notary server.

An example:

To build an image, the build machine or developer generates a symmetric key and performs the encryption of the image. The symmetric key is then wrapped with the public key of the entities/receipients that it allows access to and registered with the server.

We spin up a new cluster (that operates uses a docker ID of orgcluster). The kubernetes cluster runtime downloads an encrypted image and identifies it does not have the necessary keys to decrypt the image. The runtime sends a request for the key for the layer to the FCUKD server. The approver (image owner or delegate) gets a notification of the request, and verifies, approves and submits a wrapped key to the system. Thereafter, the requestor (cluster) can download unwrap and use the symmetric key to decrypt the container image. The approval process may be automated through an Access Control Lists set by the key owner.

We note that it is possible to provide the symmetric key to the Fully Centralized Untrusted Key Distribution system and perform auto-approvals, but it is highly discouraged since it weakens the security of the system.