Skip to content
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.

Sign up for GitHub

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

Jump to bottom

proposal: encrypted oci container images #175

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

proposal: encrypted oci container images #175

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
63 changes: 63 additions & 0 deletions proposals/encrypted_OCI_container_images.md
View file
Open in desktop
@@ -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.
Copy link
Member

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).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


### 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 proposals/images/encrypted_oci_container_images/high_level_overview.png
View file
Open in desktop
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added proposals/images/encrypted_oci_container_images/overall_architecture.png
View file
Open in desktop
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.