search

confidential-containers / trustee

Attestation and Secret Delivery Components
Apache License 2.0
64 stars 83 forks source link

Expose init_data to policy #370

Open fitzthum opened 6 months ago

fitzthum commented 6 months ago

Now that the init_data spec is merged, we should think about how we will evaluate the init data with Trustee.

Currently we don't really expose the init_data to either the attestation policy or the resource policy in the KBS. We had talked about extending the claims map of each verifier to include init_data, but that hasn't really happened. Maybe we should instead directly provide the init_data to opa engine in addition to the claims map? Should we do this for both the AA and KBS?

Xynnn007 commented 6 months ago

That's good points and I agree to provide them into OPA. Overall I think KBS is the right place to check plaintext of initdata and potential runtime data rather than AS.

Let's see the whole lifetime of initdata and see what we should do Stage Comments What we need to enhence
Injected to guest and checked against tee field - Kata side
deliver from guest to trustee Handling in KBS and deliver upon KBS protocol is a better way. We might change the use of evidence field in Attestation or add a new parameter to deliver plaintext initdata. https://github.com/confidential-containers/confidential-containers/issues/176 has similiar requests. This hints that AA should have ability to get the whole plaintext of initdata, which would be achieved either by changing the rpc CheckInitData to carry while initdata or potentially use launch cmdline kbs protocol & kbs-types & AA & kbs_protocol crate
check claims we need to have an uniform of initdata. This may introduce some serialization and deserialization operations to convert Toml to Json and then put it into regorus engine. The check work should be delayed after attestation with AS succeeds kbs
fitzthum commented 6 months ago

Yeah, I think we'll need to extend CheckInitData in the AA to get the plaintext in the first place. The AA should probably store the plaintext somewhere until it is time for attestation.

We could potentially use one of the extra-params fields in the KBS protocol for the initdata, but unfortunately the attestation message doesn't have that field. I guess we could pass it as part of the request but that seems kind of weird.

Once we're into the KBS, we should double check that all the verifiers are actually validating the initdata and then just pass it into the Regorus engine.