github/containerd
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

Updated doc based on changes requested

Browse Source 
Signed-off-by: Brandon Lum <lumjjb@gmail.com>
This commit is contained in:
Brandon Lum 2020-02-24 16:55:29 +00:00
parent ffcef9dc32
commit c5209cd679
2 changed files with 20 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/config.md
View File

@ -201,6 +201,14 @@ version = 2
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://registry-1.docker.io", ]
# 'plugins."io.containerd.grpc.v1.cri".image_decryption' contains config related
# to the handling decryption of encrypted container images.
[plugins."io.containerd.grpc.v1.cri".image_decryption]
# key_model sets how the trust model of where keys should reside for the
# decryption of encrypted container images. The default is "node".
# The docs/encryption.md file provides further information of key models.
key_model = "node"
```
## Untrusted Workload

26
docs/encryption.md
View File

@ -1,27 +1,26 @@
# Configure Image Encryption
This document describes the method to configure image encryption for `containerd` for use with the `cri` plugin.
## Encrypted Container Images
Encrypted container images are OCI images which contain encrypted blobs. An example of how these encrypted images can be created through the use of [containerd/imgcrypt project](https://github.com/containerd/imgcrypt). In order for the containerd runtime to be able to decrypt these images, the `cri` has to pass the correct options in its calls to containerd. This includes material such as keys and encryption metadata required by the runtime.
Encrypted container images are OCI images which contain encrypted blobs. These encrypted images can be created through the use of [containerd/imgcrypt project](https://github.com/containerd/imgcrypt). To decrypt these images, the `containerd` runtime uses information passed from the `cri` such as keys, options and encryption metadata.
## Key Models
## The "node" Key Model
Encryption ties trust to an entity based on the model in which a key is associated with it. We call this the key model. One such usecase is when we want to tie the trust of a key to the node in a cluster. In this case, we call it the "node" or "host" Key Model. Future work will include more key models to facilitate other trust associations (i.e. for multi-tenancy).
Encryption ties trust to an entity based on the model in which a key is associated with it. We call this the key model. One such usecase is when we want to tie the trust of a key to the node in a cluster. In this case, we call it the "node" Key Model. Future work will include more key models to facilitate other trust associations (i.e. for multi-tenancy).
### "node" Key Model Usecase
In this model encryption is tied to worker nodes. The usecase here revolves around the idea that an image should be decryptable only on trusted host. Using this model, various node based technologies which help bootstrap trust in worker nodes and perform secure key distribution (i.e. TPM, host attestation, secure/measured boot). In this scenario, runtimes are capable of fetching the necessary decryption keys. An example of this is using the [`--decryption-keys-path` flag in imgcrypt](https://github.com/containerd/imgcrypt).
1. "node" Key Model - In this model encryption is tied to workers. The usecase here revolves around the idea that an image should be only decryptable only on trusted host. Although the granularity of access is more relaxed (per node), it is beneficial because there various node based technologies which help bootstrap trust in worker nodes and perform secure key distribution (i.e. TPM, host attestation, secure/measured boot). In this scenario, runtimes are capable of fetching the necessary decryption keys. An example of this is using the [`--decryption-keys-path` flag in imgcrypt](https://github.com/containerd/imgcrypt).
### Configuring image decryption for "node" key model
The default configuration does not handle decrypting encrypted container images.
## Configuring image encryption "node" key model
An example for configuring the "node" key model for container image decryption is as follows:
The default configuration does not handle encrypted image.
In order to set up image encryption, create/modify `/etc/containerd/config.toml` as follows:
```toml
[plugins.cri.image_encryption]
[plugins.cri.image_decryption]
key_model = "node"
[stream_processors]
@ -37,9 +36,8 @@ In order to set up image encryption, create/modify `/etc/containerd/config.toml`
args = ["--decryption-keys-path", "/keys"]
```
This will enable support of `cri` for handling encrypted images. The configuration here sets the key
model to that of "node". In addition, the decryption `stream_processors` are configured as specified in
[containerd/imgcrypt project](https://github.com/containerd/imgcrypt), and have an additional field `--decryption-keys-path`
configured to specify where decryption keys are located locally in the node.
In this example, container image decryption is set to use the "node" key model. In addition, the decryption `stream_processors` are configured as specified in [containerd/imgcrypt project](https://github.com/containerd/imgcrypt), with the additional field `--decryption-keys-path` configured to specify where decryption keys are located locally in the node.
After modify this config, you need restart the `containerd` service.