New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: encrypted oci container images #175
Open
Dentrax
wants to merge
1
commit into
goharbor:main
Choose a base branch
from
Dentrax:proposal/encrypted-oci-container-images
base: main
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,63 @@ | ||
# Proposal: `Support Encrypted OCI Container images: TUF + ocicrypt` | ||
|
||
Author: `Furkan Türkal / @Dentrax`, `Batuhan Apaydın / @developer-guy` | ||
|
||
Discussion: [goharbor/harbor#15489](https://github.com/goharbor/harbor/issues/15489) | ||
|
||
## Abstract | ||
|
||
The proposal introduces a container layer encryption for unencrypted images that pushing into the registry. | ||
|
||
## Background | ||
|
||
IT companies may have sensitive images. Encrypted OCI Container images as a way to protect the confidentiality of container workloads, as well as how they can be used in an enterprise setting to help you achieve workload compliance. These provide a good overview of how to protect workloads in a high assurance environment. | ||
|
||
See the [motivation of the work](https://developer.ibm.com/articles/enabling-advanced-key-usage-and-management-in-encrypted-container-images//), for more information. | ||
|
||
![High Level Overview](images/encrypted_oci_container_images/high_level_overview.png) | ||
|
||
## User Stories | ||
|
||
### Story 1 | ||
As a project developer, I want to be able to keep my container image in encrypted state even though I do not encrypt in the CI/CD pipeline. | ||
|
||
### Story 2 | ||
As a registry administrator, I should not be able to run the container images even I have pull access from the registry. | ||
|
||
## Proposal | ||
|
||
[TUF](https://github.com/theupdateframework/tuf) was designed with the premise that all software repositories will be compromised at a certain stage, therefore it incorporates separation of signing duties techniques that make possible to minimize the impact of a stolen private key in the environment. | ||
|
||
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. | ||
|
||
### Overview | ||
|
||
![Overall Architecture](images/encrypted_oci_container_images/overall_architecture.png) | ||
|
||
## Rationale | ||
|
||
**This is not a concern of Harbor** | ||
|
||
I am not so sure if this problem is really a concern of Harbor. This is why I'm throwing this issue. We can discuss and brainstorm the idea. | ||
|
||
We can encrypt our images in the CI/CD pipeline just before the push into container registry. And we can easily decrypt the images before deploying to cluster. | ||
|
||
And we should find a way out about how to decrypt these securely after pull the image. | ||
|
||
**Encrypting FS for storage instead of images** | ||
|
||
Projects like [fscrypt](https://github.com/google/fscrypt), [encfs](https://github.com/vgough/encfs), etc. could take care of. But it does not solve the problem of what we want to achieve for. Images still in unencrypted state. | ||
|
||
## Compatibility | ||
|
||
To be discussed | ||
|
||
## Implementation | ||
|
||
To be discussed | ||
|
||
## Open issues (if applicable) | ||
|
||
No |
Binary file added
BIN
+29.6 KB
proposals/images/encrypted_oci_container_images/high_level_overview.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added
BIN
+415 KB
proposals/images/encrypted_oci_container_images/overall_architecture.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, yes, I agree with you. I could not figure it out how it should be in effective way 🤔
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.
Sound makes sense. Any related proposal for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.