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.

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

Add runtime attestation support in image rs #636

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

arronwy
Copy link
Member

@arronwy arronwy commented Jul 31, 2024

No description provided.

arronwy added 3 commits July 30, 2024 13:50
Extend image full name with digest to measurement register.

Signed-off-by: Wang, Arron <[email protected]>
runtime-attestation feature is not enabled by default,
but need enable in CI tests.

Signed-off-by: Wang, Arron <[email protected]>
Copy link
Member

@Xynnn007 Xynnn007 left a comment

Choose a reason for hiding this comment

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

Cool! It is nice to see that we can support such feature in image-pulling.

I think we might need to make a spec for event/domain/operations for CoCo. In this PR, image-rs pull_image xxx is used. An possible ideal format would be github.com/confidential-containers imagePulling xxx in my mind.

Secondly, once we have move image pulling things into CDH, I suggest that the event record calling things be also moved to CDH. Thus a successfully image-pull event responsed in CDH will call AA to record. This would help to prevent image-rs -- as an underlying dependency to leverage RPC client to connect to AA again, though image-rs is doing so now by fetching keys from CDH.

wdyt?

cc @fitzthum @mkulke

@mkulke
Copy link
Contributor

mkulke commented Jul 31, 2024

I'd agree with @Xynnn007 on both points (eventlog spec and avoiding another AA rpc client)

@fitzthum
Copy link
Member

We're starting to have a few different options for verifying images (this, signatures, policy). That's fine, but we should document them all with some comparisons at some point.

@arronwy
Copy link
Member Author

arronwy commented Aug 1, 2024

We're starting to have a few different options for verifying images (this, signatures, policy). That's fine, but we should document them all with some comparisons at some point.

Yes, Agree, I can add this in current image-rs security document, currently the integrity of image pull inside by TEE is covered by signature or runtime attestation, image shared by host is covered by policy

@arronwy
Copy link
Member Author

arronwy commented Aug 1, 2024

Cool! It is nice to see that we can support such feature in image-pulling.

I think we might need to make a spec for event/domain/operations for CoCo. In this PR, image-rs pull_image xxx is used. An possible ideal format would be github.com/confidential-containers imagePulling xxx in my mind.

Yes, agree, I create a issue to propose create a unified link for CoCo specific data format: confidential-containers/confidential-containers#225

Secondly, once we have move image pulling things into CDH, I suggest that the event record calling things be also moved to CDH. Thus a successfully image-pull event responsed in CDH will call AA to record. This would help to prevent image-rs -- as an underlying dependency to leverage RPC client to connect to AA again, though image-rs is doing so now by fetching keys from CDH.

Yes, agree, after image pulling is integrated into CDH and kata-agent also switch to use CDH to pull image, I'll switch to move this part to CDH.

@mythi
Copy link
Contributor

mythi commented Aug 1, 2024

Is runtime-attestation a good choice for the name here? It sounds like an overloaded term and may cause misunderstandings (it can also mean repeated attestations during the pod runtime).

@mkulke
Copy link
Contributor

mkulke commented Aug 2, 2024

Is runtime-attestation a good choice for the name here? It sounds like an overloaded term and may cause misunderstandings (it can also mean repeated attestations during the pod runtime).

good point. I think it makes sense if you look at it as extension to a vm launch-measurement, but from a container perspective the image pull phase is not runtime strictly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants