podman pull: support decrypting images

[ningmingxiao]

No description provided.

[mheon]

Can you clarify what you're asking? What's the specific Skopeo command you're asking about?

[ningmingxiao]

I want podman can auto decrypt an encrypted image,when use podman run with an encrypted image.

[rhatdan]

Could you show an example of what is going wrong?

[vrothberg]

Skopeo has flags for {de,en}crypting images (e.g.,--encrypt-layer). Those are currently marked as experimental in Skopeo. @lumjjb @mtrmac what do you think on adding support for that in Podman as well?

[rhatdan]

I would think Podman should just handle it when pulling an image, I would figure if I pull an encrypted image, I would be prompted for the decryption key, and then store the image in containers storage.

Adding a --encrypt flag to podman push, would seem to be a nice enhancement.

[vrothberg]

containers/common/libimage already supports that, so it would be a Podman-only change. I do not know whether we want to limit support to the local client or if want to extend it to remote client as well.

[vrothberg]

@baude PTAL

[rhatdan]

In a perfect world, I would do both, but sending the decryption key in a protocol, might be a bit risky.

[vrothberg]

We're sending credentials over the wire as well - I think we assume the connection is secure. If users opt-out from a secure connection, they probably know what they are doing.

[lumjjb]

I'm not sure how this plays into the architecture, but we did a daemon based configuration, with a set of keys for cri-o, not sure how it would map for podman

[rhatdan]

The podman service should be able to use that configuration or one similar.

The question would be, should a user be prompted for a decryption key, or do they need to prepopulate the keys using some other tool into a configuration directory.

[vrothberg]

I think we can start with providing keys on the CLI via flags as done in Skopeo. If there's a need for a permanent configuration, we can look into something similar to the CRI-O configuration.

[mtrmac]

For pull, this is just a matter of exposing the options to supply keys.

The current code does not actually allow interactively prompting for keys; software could always read the manifest to see if it contains encrypted layers, and prompt before actually starting a pull, or maybe we could build some interactive callbacks.

But I’m not immediately sold on the interactivity — AFAIK keys are typically not passphrases, so the users would be entering … paths to local files? Possibly using some algorithm prefix syntax or PKCS#11 hardware identification? I vaguely recall containers/ocicrypt is actually a protocol switch over 5 or so very different encryption mechanisms… My intuitive impression with absolutely no data is that using a decryption key would almost never be a one-time operation that warrants interactivity: The key would be provisioned on the relevant computer and then used repeatedly over time. That strongly suggests “non-interactive, possibly only automated” to me.

---

I’d expect push to work just as easily — one thing to check is pushing a Docker-formatted image (because encryption would require conversion to OCI). Reading the code, I think that is supposed to work already, but it would be worth at least a smoke-test.

[mtrmac]

In a perfect world, I would do both, but sending the decryption key in a protocol, might be a bit risky.

Read https://github.com/containers/ocicrypt/blob/main/docs/keyprovider.md#encrpytingdecrypting-examples — the key providing mechanisms are not really designed to be handed off to a different machine.

It’s an interesting thought to take advantage of that, and have the remote server actually provide a specialized “Podman client” key provider; then the remote client would start some kind of “decryption server” that allows using keys remotely, using the actual users’ configuration, and ask the remote server to connect back to the “decryption server” to perform operations. That would allow supporting arbitrary ocicrypt configurations (if that matters), and the actual encryption keys could never leave the client (including possibly being hardware-protected).

But that seems like quite a lot of work for a niche feature. I’d start with just not supporting this on remote. (FWIW signing does not currently support remote either, at least simple signing runs into similar GPG configuration complexity issues, and sigstore will eventually get complex with Fulcio-required interactivity.)

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@ashley-cui PTAL

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[vrothberg]

I think we can close given #16329 added support for it.

[mtrmac]

Yes, let’s.