search

confidential-containers / trustee

Attestation and Secret Delivery Components
Apache License 2.0
56 stars 81 forks source link

KBS does not support multiple attestation policies #282

Open fitzthum opened 8 months ago

fitzthum commented 8 months ago

This issue is for discussion rather than any immediate fix.

Recently we updated the AS API to allow callers to specify the ids of the policies that are evaluated. We don't make use of this in our KBS should we? Perhaps we could allow the client to select which policies to evaluate?

Xynnn007 commented 7 months ago

Nice point. Here are some ideas from my side.

  1. Add a configuration for KBS to set the policy id for all requests. This is not flexible but fits in single-tenant architecture/dedicated instance where each deployment will use its own single KBS.
  2. As the requester of the KBS is actually running in TEE like AA, it is a good choice to determined by it. My idea is to have KBS-client lib added another parameter, the instance id. This instance id works like the pod id we have talking all time and will be delivered to KBS when doing RCAR. This id, as one of the launch parameters of AA, would be protected integritily by initdata mechanism. Before launch KBS, the KBS should have a configuration that defines which instance id will be mapped to which AS policy. This is like an AA unknown to KBS sending a handshake request and claiming to be a certain instance. KBS will get in touch with AS to verify based on the verification policy that this instance should pass.
fitzthum commented 7 months ago

Add a configuration for KBS to set the policy id for all requests. This is not flexible but fits in single-tenant architecture/dedicated instance where each deployment will use its own single KBS.

Yes, I think this could be as simple as making the default config(s) a configurable parameter and having it always be included in the list of policy ids.

This instance id works like the pod id we have talking all time and will be delivered to KBS when doing RCAR.

I think this makes sense. One thing to note is that this ID doesn't need to be unique. With this approach we could support a client that wants to have a unique ID for every guest but we could also support a client that wants to identify instances more generally i.e. by having different classes of instance.

Anyway, since we can set multiple policy ids, we can do both approaches.