search

confidential-containers / trustee

Attestation and Secret Delivery Components
Apache License 2.0
65 stars 88 forks source link

Verifier bails instead of automatically fetching certificate from KDS #456

Open AdithyaKrishnan opened 3 months ago

AdithyaKrishnan commented 3 months ago

The mod.rs code in verifier currently prints a statement that it Could not find either VCEK or VLEK in cert chain instead of automatically fetching it from the KDS

mkulke commented 2 months ago

The mod.rs code in verifier currently prints a statement that it Could not find either VCEK or VLEK in cert chain instead of automatically fetching it from the KDS

Afaik KDS has a rate-limit, that would made it unreliable to use it by default. The VCEK/VLEK should be in the SNP-attester's evidence?

Doctor-love commented 2 months ago

Afaik KDS has a rate-limit, that would made it unreliable to use it by default. The VCEK/VLEK should be in the SNP-attester's evidence?

If I understand you correctly, the "extended attestation workflow" as described in this issue comment is required in the current implementation of the verifier? Or is there some other way this is meant to work?

mkulke commented 2 months ago

I think that's how it's supposed to work. The VCEK could be cached in multiple places (like a cloud's IMDS), but the public KDS service is occasionally not available, so I'd be cautious to build an architecture around it. We could still have a local memory cache on trustee for VCEKs maybe.

fitzthum commented 2 months ago

Apparently the latest upstream host patches no longer support setting the extended report (which the verifier currently requires), so we should make sure we implement some kind of fallback. If the AS reaches out to the KDS, it should cache the responses to avoid doing it too often.