search

confidential-containers / guest-components

Confidential Containers Guest Tools and Components
Apache License 2.0
83 stars 95 forks source link

Add runtime attestation support in image rs #636

Open arronwy opened 3 months ago

mkulke commented 3 months ago

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

fitzthum commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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: https://github.com/confidential-containers/confidential-containers/issues/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 commented 3 months ago

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 commented 3 months ago

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.