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

Defer multitenant key model to image auth discussion

Browse Source 
Signed-off-by: Brandon Lum <lumjjb@gmail.com>
This commit is contained in:
Brandon Lum 2020-01-08 10:18:51 +00:00
parent c43a7588f6
commit 8df431fc31
3 changed files with 2 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
docs/encryption.md
View File

@ -9,12 +9,11 @@ Encrypted container images are OCI images which contain encrypted blobs. An exam
## Key Models ## Key Models
Encryption ties trust to an entity based on the model in which a key is associated with it. We call this the key model. There are two currently supported key models in which encrypted containers can be used. These is based on two main usecases. 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).
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). 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).
2. "multitenant" Key Model - In this model, the trust of encryption is tied to the cluster or users within a cluster. This allows multi-tenancy of users, and is useful in the case where multiple users of kubernetes each want to bring their own encrypted images. This is based on the [KEP that introduces `ImageDecryptSecrets`](https://github.com/kubernetes/enhancements/pull/1066/).
## Configuring image encryption "node" key model ## Configuring image encryption "node" key model
@ -44,28 +43,3 @@ model to that of "node". In addition, the decryption `stream_processors` are con
configured to specify where decryption keys are located locally in the node. configured to specify where decryption keys are located locally in the node.
After modify this config, you need restart the `containerd` service. After modify this config, you need restart the `containerd` service.
## Configuring image encryption "multitenant" key model
```toml
[plugins.cri.image_encryption]
key_model = "multitenant"
[stream_processors]
[stream_processors."io.containerd.ocicrypt.decoder.v1.tar.gzip"]
accepts = ["application/vnd.oci.image.layer.v1.tar+gzip+encrypted"]
returns = "application/vnd.oci.image.layer.v1.tar+gzip"
path = "/usr/local/bin/ctd-decoder"
[stream_processors."io.containerd.ocicrypt.decoder.v1.tar"]
accepts = ["application/vnd.oci.image.layer.v1.tar+encrypted"]
returns = "application/vnd.oci.image.layer.v1.tar"
path = "/usr/local/bin/ctd-decoder"
```
To use the multitenant key model, the field should be set to `key_mode = "multitenant"`.
We note that "multitenant" key modle requires a kubernetes version that supports the `ImageDecryptSecrets`
feature. The `stream_processors` need to be configured to handle decryption as specified in [containerd/imgcrypt project](https://github.com/containerd/imgcrypt). Since keys are passed through
kubernetes, there is no need to specify a way in which the decoder needs to locally obtain keys.
After modify this config, you need restart the `containerd` service.

3
pkg/config/config.go
View File

@ -243,9 +243,6 @@ const (
RuntimeUntrusted = "untrusted" RuntimeUntrusted = "untrusted"
// RuntimeDefault is the implicit runtime defined for ContainerdConfig.DefaultRuntime // RuntimeDefault is the implicit runtime defined for ContainerdConfig.DefaultRuntime
RuntimeDefault = "default" RuntimeDefault = "default"
// EncryptionKeyModelMultitenant is the key model where keys are obtained from
// kubernetes ImageDecryptSecrets
EncryptionKeyModelMultitenant = "multitenant"
// EncryptionKeyModelNode is the key model where key for encrypted images reside // EncryptionKeyModelNode is the key model where key for encrypted images reside
// on the worker nodes // on the worker nodes
EncryptionKeyModelNode = "node" EncryptionKeyModelNode = "node"

1
pkg/server/container_create.go
View File

@ -165,7 +165,6 @@ func (c *criService) CreateContainer(ctx context.Context, r *runtime.CreateConta
// rootfs readonly (requested by spec.Root.Readonly). // rootfs readonly (requested by spec.Root.Readonly).
customopts.WithNewSnapshot(id, containerdImage), customopts.WithNewSnapshot(id, containerdImage),
} }
if len(volumeMounts) > 0 { if len(volumeMounts) > 0 {
mountMap := make(map[string]string) mountMap := make(map[string]string)
for _, v := range volumeMounts { for _, v := range volumeMounts {