Add runtime attestation support in image rs

[arronwy]

No description provided.

[Xynnn007]

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]

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

[fitzthum]

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]

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]

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]

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]

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.

[Xynnn007]

I am working on making a RFC of coco eventlog under trustee repo

[mythi]

I am working on making a RFC of coco eventlog under trustee repo

do you mean a document of what the measured events or something else?

[Xynnn007]

I am working on making a RFC of coco eventlog under trustee repo

do you mean a document of what the measured events or something else?

yes. an eventlog spec mentioned in #636 (review)