proposal: encrypted oci container images #175
Conversation
Signed-off-by: Furkan <furkan.turkal@trendyol.com>
|
|
||
| The [ocicrypt](https://github.com/containers/ocicrypt) library is the OCI image spec implementation of container image encryption. More details of the spec can be seen in the [OCI repository](https://github.com/opencontainers/image-spec/pull/775). The purpose of this library is to encode spec structures and consts in code, as well as provide a consistent implementation of image encryption across container runtimes and build tools. | ||
|
|
||
| Pipelines will push the _unencrypted_ docker images directly into registry. Harbor will know every Tribe's private keys. So, as soon as new image store request received, we encrypt the image layers using `ocicrypt`. Filesystem may also be encrypted, but it does not matter since any authorized person have necessary access to pull images. Even if someone gets the target image somehow, it should not work on container runtimes. `ctr` command have an ability to ask encryption password if image encrypted. See the [imgcrypt](https://github.com/containerd/imgcrypt) project. |
There was a problem hiding this comment.
This is kind of an interesting setup -- having the location where the encrypted images get stored also have access to the private key data required to encrypt/decrypt the images seems less than ideal. Maybe it would be a good idea to elaborate on your threat model a bit to explain what this would gain?
For example, if you're just looking for at-rest encryption, something like an encrypted filesystem underneath Harbor seems to me like it's probably a better answer (and one that doesn't require any changes to Harbor itself to support).
There was a problem hiding this comment.
having the location where the encrypted images get stored also have access to the private key data required to encrypt/decrypt the images seems less than ideal.
Oh, yes, I agree with you. I could not figure it out how it should be in effective way 🤔
Maybe it would be a good idea to elaborate on your threat model a bit to explain what this would gain?
Actually, the idea is coming from here: Anyone who has admin privileges to access the registry, (i.e., both network or hardware access), if somehow get the my super-secret sensitive image, container runtime should not able to run my image since its layers are encrypted.
something like an encrypted filesystem underneath Harbor seems to me like it's probably a better answer
Sound makes sense. Any related proposal for this?
There was a problem hiding this comment.
I had the same question: as the whole point of a zero trust container registry is that image encryption/decryption is happening on the client side.
In a most setups, object stores are commonly used that have options to encrypt the bucket with an HSM or even a client side encryption on the registry.
the only point where I would see TUF is to display some meta-information in the UI such as indicating the image is encrypted by whom and what key.
There was a problem hiding this comment.
Actually, the idea is coming from here: Anyone who has admin privileges to access the registry, (i.e., both network or hardware access), if somehow get the my super-secret sensitive image, container runtime should not able to run my image since its layers are encrypted.
[...]something like an encrypted filesystem underneath Harbor seems to me like it's probably a better answer
Sound makes sense. Any related proposal for this?
In my understanding of unencrypted filesystems, they won't help you with your threat model, since the admin of the registry will still have access. The encrypted filesystem only mitigates unauthorized (physical) attackers. In a running system they are (often) transparent.
Also you are speaking from network access, if someone has access to the network he can just capture the packets of incoming data and get the unencrypted "pushed" image. of course for "pulled" images (which should be quite more :P) there is some protection.
|
The Cosign and Harbor combination covers the proposal to sign OCI artifacts using the OCI way. With the OCI image/distribution specification reaching the RC2 stage, the introduction of the Distribution spec: https://github.com/opencontainers/distribution-spec/blob/main/spec.md |
|
After evaluation of your proposal, we have decided to close it at this time due to the current lack of interest from the community. However, this decision does not prevent the possibility of revisiting your proposal in the future, should the situation change. |
Signed-off-by: Furkan furkan.turkal@trendyol.com
Follow-up issue: goharbor/harbor#15489
I could not fill the implementation process since I do not know Harbor's project domain much. So, any contributions to my PR are welcomed. We can improve the proposal better according to your feedback.