Encryption of layers

[wjbrf]

What is the version of your ORAS CLI

latest

What would you like to be added?

Has there been any efforts to add support for encrypted layers to ORAS?

There is some support for encrypted containers within containerd and skopeo. There appears to be some semblance of an encryption spec for OCI containers.

I'm not considering encryption at rest, I'm looking at encryption within the layers of the image itself.

The use case I'm looking at is to enable encryption and decryption at the time when files are pushed or pulled. The encryption key would be specified as an argument.

Why is this needed for ORAS?

Encryption of OCI artifacts may be handled more seamlessly using ORAS. Opposed to encrypting files before including in an artifact or using tools like skopeo to handle encryption.

Are you willing to submit PRs to contribute to this feature?

• Yes, I am willing to implement it.

[FeynmanZhou]

Hi @wjbrf ,

Would you mind clarifying more about your scenarios of layer encryption? How will this benefit your use cases?
Can you share more reference and context about how containerd and skopeo's support on this?

[crepererum]

I know I wasn't asked, but since I'm interested in this feature two, I take the liberty to try to answer the open questions.

Would you mind clarifying more about your scenarios of layer encryption? How will this benefit your use cases?

Answering for my personal use case: My website/blog uses a static site generator. In CI, I would like to build the website (i.e. output all the HTML, CSS, images etc.) and package it into an OCI artifact. That artifact then should be pushed to some registry, and from there fetched into the server that just presents it, e.g. using Caddy. On the server side, podmand quadlets will be used. Now in vein of increasing AI scraping, I would like to shield my work at least somewhat, e.g. using Anubis on the server side. The artifact however is still an open book though. I COULD host my own private registry, but it would be nice if I could just use existing infrastructure (also to decouple the CI from the actual hosting server) and just encrypt the data, i.e. make the OCI artifact opaque.

My -- somewhat uneducated -- guess is that other users may have similar use cases, where they "park" data in form of OCI artifacts somewhere but don't want the registry provider to read/scan everything. Note that I would suggest to NOT use the encryption to hide API secrets/keys though (use the the container runtime secret feature for that).

Can you share more reference and context about how containerd and skopeo's support on this?

For the "producer" end, see --encryption-key and --encrypt-layer in the skopeo copy docs.

On the "consumer" end, here's podman's docs (I know you've asked for containerd but I just used to have the podman stuff at hand): https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html#artifact-units-artifact.

[wjbrf]

Hi @FeynmanZhou

The goal would to be able to encrypt assets within the OCI artifact ecosystem. This would be without requiring another tool to encrypt OCI assets and without encrypting files before including in OCI artifacts. Ideally ORAS itself would add encryption and decryption features. Tools using ORAS would then be able to benefit from an base-line encryption implementation.

My use case is to encrypt assets as a form of end-to-end access control and confidential storage/transport. This could include sensitive artifacts such as configurations, secrets, keys, or any other assets where confidentiality is desired.

It would be up to system users to determine risk. Currently encryption as a feature within ORAS doesn't exist, requiring workarounds or custom development to even consider using OCI artifacts where confidentiality is required.

To compare with other implementations: Skopeo has flags to encrypt and decrypt containers. Example for encryption: skopeo copy --encryption-key jwe:./mypubkey.pem oci:local_nginx:latest oci:nginx_encrypted:latest Example for decryption: skopeo copy --decryption-key ./mykey.pem oci:nginx_encrypted:latest oci:nginx_decrypted:latest

One reference implementation to consider would be imgcypt: https://github.com/containerd/imgcrypt which is a sub-project of containerd.

Containerd is usings imgcrypt.
https://github.com/containerd/containerd/blob/main/docs/cri/decryption.md
containerd supports decrypting containers at runtime. Application containers are encrypted up until when they are executed by the container runtime. I believe the term streaming decryption is used.

Layers for encrypted application containers have the labels "application/vnd.oci.image.layer.v1.tar+gzip+encrypted". For OCI Artifacts a comparable label would be needed.

example config for containerd which shows some options regarding the layer labels.

[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"

Another comparison would be how zip files support encryption. The package format itself supports encryption so the files don't need to encrypted individually.

Desired feature within ORAS:

• ORAS cli to support encryption and decryption flags to transparently encrypt and decrypt assets.
• ORAS library support for encrypting and decrypting OCI artifacts with the option of extensibility if required.

Ideally tools built on top of ORAS would then consider supporting encryption. Especially if there is a base implementation.

I have come into a couple scenarios requiring encryption for OCI Artifact containers and haven't come up with a solution that doesn't require custom development.