Add the design document by arronwy · Pull Request #1 · confidential-containers/guest-components

arronwy · 2021-11-11T13:34:21Z

Co-authored-by: Liu Jiang gerry@linux.alibaba.com
Signed-off-by: Arron Wang arron.wang@intel.com

stevenhorsman · 2021-11-11T14:00:09Z

I think this looks like a great start. One thing I expected, but didn't spot (it might be included as part of the OCI spec) was the support for pulling images from authenticated registries via username:password / API key as I think that is one of the core features.

jiangliu · 2021-11-12T01:26:31Z

I think this looks like a great start. One thing I expected, but didn't spot (it might be included as part of the OCI spec) was the support for pulling images from authenticated registries via username:password / API key as I think that is one of the core features.

Thanks for review, pulling images with authentication should be covered by OCI distribution spec:)

fitzthum

I made a few minor comments mainly about future things. I think the doc looks good.

fitzthum · 2021-11-15T15:33:38Z

+The `image-rs` crate supports both encrypted and unencrypted container images since
+[Encrypted Container Image](https://github.com/opencontainers/artifacts/pull/15)
+is mandatory for many confidential container usage scenarios. It also supports image signature verification to ensure
+integrity.


There are some interesting policy questions here. I think from a security perspective we only want to support unencrypted containers that are verified, but should we really enforce this? How strict do we want to be and which entity should be in charge of setting the policy?

That depends on the threaten model of confidential containers. It should be configurable which types of images are supported:

encrypted with signature, mandatory

encrypted without signature, mandatory

unencrypted with signature, configurable and should be enabled

unencrypted without signature, configurable and may be disabled.

Yeah I think it's really just number 4 that we need to be very careful with. From a security perspective we shouldn't allow unencrypted and unsigned containers at all, but from a usability perspective those are exactly the container images that most people are probably using now.

Keep in mind that this potentially applies not just to containers, but to the individual layers of a container. As in we will definitely want to support container images where some layers are encrypted and others aren't. If we verify the signature of the entire image this should be safe. I'm not sure if there is any reason to have per-layer signatures.

Thanks @fitzthum , security policy part are updated, pls review.

fitzthum · 2021-11-15T15:38:52Z

+
+### Non-Goals
+ * Image push, content discovery/management operations for remote registries
+ * Image encryption and signing


I agree that everything involving provisioning an image is a non-goal that would bloat image-rs but let's make sure that we provide good documentation about how a user can setup images using other tools. image-rs isn't very useful if people can't easily upload encrypted/signed images.

So maybe a "Howto" doc helps here:)

ooi, is it not in scope as there are already existing tools to encrypt+sign or is that we don't want to bloat the binary? If it's the latter, we can simply build two binaries from the same source (one to encrypt/sign the other to decrypt/check) to avoid any packaging bloat.

If this project supported encrypting/signing, that would make writing unit tests easier. But at an integration level, the CI should encrypt with other tooling too! ;)

This project will leverage ocicrypt-rs to do decryption and image signing verification, and we may focuse integration test for compatiable with existing container build tools like skopeo

We hope to focus on the most valuable features at the first stage:)
Let's get something usable then we could extend it on demand:)

I agree with @arronwy and @jiangliu here, image distribution and building should be kept out of scope for now and that should be very clear.

To make it even clearer, we could indeed describe how to do those steps with other tools and libraries.

Yes, we added the document for generate test data in another PR which will describe how to do those steps, and will link them when related PR are merged.

jiangliu · 2021-11-16T04:07:20Z

I think this looks like a great start. One thing I expected, but didn't spot (it might be included as part of the OCI spec) was the support for pulling images from authenticated registries via username:password / API key as I think that is one of the core features.

How about this?
"Support pulling OCI/docker v2 images from registries with or without authentication."

dubek · 2021-11-16T10:19:45Z

+if needed. After image is unpacked, the image format module will handle
+the format conversion between oci v1 and docker v2.


Is local caching relevant at all?
Or is it the case that after everything is decrypted and unpacked the original blobs will be destroyed?

To be honest, we are not very clear about this yet:(
For most cases, we do not care about local caching. But not sure whether it will be needed for image data sharing.

Caching might be good if you have more than one of the same container inside a pod. We definitely don't want to download a container more than once if it can be avoided.

If caching is to be supported, is additional security needed for it? And how is it managed?

We should support the case where an image is shared by multiple containers within a pod.
On the other handle, it's challenge to share container images among pods, even not support by current hardware yet.
So let's leave the hard part to the future.

Yes, to be clear: We're talking about caching inside the guest.

Yes, will add this info.

jodh-intel

Thanks @arronwy. A few comments...

jodh-intel · 2021-11-29T11:03:00Z

+ 1. encrypted with signature, mandatory
+ 2. encrypted without signature, mandatory
+ 3. unencrypted with signature, configurable and should be enabled
+ 4. unencrypted without signature, configurable and may be disabled


This might be quicker to understand if it was formatted as a table.

Image type Image Signature? Layer encryption? ...

Also, is this scenario supported: a signed image that contains encrypted layers and unencrypted layers? (I think this should be stated clearly, maybe using the table above).

tbh, I'm wondering if we need an additional term since "encrypted image" doesn't specify if the image is signed. How about:

secured image: a signed image with all its levels encrypted.

Other questions:

What forms of signature are supported?

What forms of encryption are supported?

Can an image contain multiple encrypted layers where each layer uses a different encryption scheme?

What happens if an image layer fails to decrypt? Presumably, it is "invalid", but this should be stated.

What happens if a signing key is revoked or expired? Again, I think this should be stated explicitly.

Shouldn't "the whole system" require secure NTP (NTS) to stop the possibility of the host changing its clock which could affect the ability (or the validity) of signature verification? Plus Secure DNS (DoH or DoT)?

For image encryption opencontainers/artifacts#15 this PR describe the details on encrypted mediatype definitions for oci image spec.
For image signning, we still don't have detail definition yet, it is next step work for CC and upstream also have a POC: kata-containers/kata-containers#3023 and issue in attestation agent to support image signning verification: https://github.com/confidential-containers/attestation-agent/issues/24

jodh-intel · 2021-11-29T11:41:11Z

+
+### Non-Goals
+ * Image push, content discovery/management operations for remote registries
+ * Image encryption and signing


ooi, is it not in scope as there are already existing tools to encrypt+sign or is that we don't want to bloat the binary? If it's the latter, we can simply build two binaries from the same source (one to encrypt/sign the other to decrypt/check) to avoid any packaging bloat.

If this project supported encrypting/signing, that would make writing unit tests easier. But at an integration level, the CI should encrypt with other tooling too! ;)

jodh-intel · 2021-11-29T11:44:04Z

+if needed. After image is unpacked, the image format module will handle
+the format conversion between oci v1 and docker v2.


If caching is to be supported, is additional security needed for it? And how is it managed?

bpradipt · 2022-01-31T04:44:26Z

@arronwy gerry@linux.alibaba.com can this be closed as the initial design doc is already merged via #3 ?

jiangliu · 2022-02-09T09:55:17Z

@arronwy gerry@linux.alibaba.com can this be closed as the initial design doc is already merged via #253 ?

It's a different doc:)
This one should also be merged.

sameo · 2022-02-09T14:21:25Z

+
+### Non-Goals
+ * Image push, content discovery/management operations for remote registries
+ * Image encryption and signing


I agree with @arronwy and @jiangliu here, image distribution and building should be kept out of scope for now and that should be very clear.

To make it even clearer, we could indeed describe how to do those steps with other tools and libraries.

sameo · 2022-02-09T14:25:54Z

+if needed. After image is unpacked, the image format module will handle
+the format conversion between oci v1 and docker v2.


Yes, to be clear: We're talking about caching inside the guest.

sameo · 2022-02-09T14:26:27Z

+After container image is downloaded, `image-rs` will talk with remote
+attestation service to verify the image signature and decrypt the image
+if needed. After image is unpacked, the image format module will handle
+the format conversion between oci v1 and docker v2.


Why do we need to convert between oci v1 and docker v2?

Co-authored-by: Liu Jiang <gerry@linux.alibaba.com> Signed-off-by: Arron Wang <arron.wang@intel.com>

sameo · 2022-02-10T08:57:23Z

@fitzthum @jodh-intel Are you ok with that PR?

jodh-intel

Thanks @arronwy and @jiangliu.

lgtm

Document: Add KBS attestation protocol design doc

1.A Crate that implements the Attestation Service core functionality.. Fixes: #1 Signed-off-by: zhouliang121 <liang.a.zhou@linux.alibaba.com>

When creating ephemeral storages, place the LUKS headers in guest memory rather than onto the storage device itself. For this, create LUKS header files in the CDH storage directory, and call into CryptInit::init_with_data_device instead of into CryptInit::init. The code path in which existing, encrypted storages are utilized remains untouched. Signed-off-by: Manuel Huber <manuelh@nvidia.com> to-squash: address comments confidential-containers#1 to-squash: address comments confidential-containers#2 to-squash: address comments confidential-containers#3

fitzthum reviewed Nov 15, 2021

View reviewed changes

dubek reviewed Nov 16, 2021

View reviewed changes

jiangliu approved these changes Nov 29, 2021

View reviewed changes

jodh-intel reviewed Nov 29, 2021

View reviewed changes

arronwy mentioned this pull request Dec 2, 2021

[RFC] image-rs devel plan #2

Closed

21 tasks

sameo reviewed Feb 9, 2022

View reviewed changes

Add the design document

d997daa

Co-authored-by: Liu Jiang <gerry@linux.alibaba.com> Signed-off-by: Arron Wang <arron.wang@intel.com>

sameo approved these changes Feb 10, 2022

View reviewed changes

jodh-intel approved these changes Feb 10, 2022

View reviewed changes

fitzthum approved these changes Feb 10, 2022

View reviewed changes

sameo merged commit 8106e1a into confidential-containers:main Feb 10, 2022

eldios added a commit to switchboard-xyz/guest-components that referenced this pull request Jan 27, 2025

devired_key: cleaning pass confidential-containers#1

cf100b1

eldios added a commit to switchboard-xyz/guest-components that referenced this pull request Feb 5, 2025

devired_key: cleaning pass confidential-containers#1

6916687

bpradipt referenced this pull request in bpradipt/guest-components Apr 10, 2025

Merge pull request #1 from jialez0/main

a5258c7

Document: Add KBS attestation protocol design doc

bpradipt referenced this pull request in bpradipt/guest-components Apr 10, 2025

AS: The initial implementation

9a4ef93

1.A Crate that implements the Attestation Service core functionality.. Fixes: #1 Signed-off-by: zhouliang121 <liang.a.zhou@linux.alibaba.com>

manuelh-dev added a commit to manuelh-dev/guest-components that referenced this pull request Feb 10, 2026

feedback confidential-containers#1 (to squash)

d82d534

manuelh-dev added a commit to manuelh-dev/guest-components that referenced this pull request Feb 10, 2026

feedback confidential-containers#1 (to squash)

83d8100

manuelh-dev added a commit to manuelh-dev/guest-components that referenced this pull request Feb 11, 2026

feedback confidential-containers#1 (to squash)

bdc6c37

manuelh-dev added a commit to manuelh-dev/guest-components that referenced this pull request Feb 18, 2026

to-squash: address comments confidential-containers#1

8993486

		if needed. After image is unpacked, the image format module will handle
		the format conversion between oci v1 and docker v2.

Conversation

arronwy commented Nov 11, 2021

Uh oh!

stevenhorsman commented Nov 11, 2021

Uh oh!

jiangliu commented Nov 12, 2021

Uh oh!

fitzthum left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jiangliu commented Nov 16, 2021

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jodh-intel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bpradipt commented Jan 31, 2022

Uh oh!

jiangliu commented Feb 9, 2022

Uh oh!

Uh oh!

Uh oh!

Uh oh!