Error requesting resources from different KBS': The resource KBS host differs from KBS URL one

[katexochen]

When requesting two resources from different KBS through the API of the AA, the second request will fail with:

AA-KBC get resource failed: The resource KBS host 10.0.100.1:8080 differs from the KBS URL one 10.0.100.100:8080

Can anyone explain to me why we're not just using the KbsUri from the request? https://github.com/confidential-containers/attestation-agent/blob/aa1d3c510350cd2f2668aca374abba19e2b73b3f/kbc/src/cc_kbc/mod.rs#L76-L104

[fitzthum]

We could potentially adjust the error handling a bit here, but there is currently a fundamental limitation regarding multiple KBSes.

CoCo uses generic guest evidence. The root of trust of a CoCo workload is the KBS, which verifies the generic evidence and provides identifying secrets, thus extending the TCB to the guest. Extending the TCB to a second KBS raises a number of subtle challenges, that we currently have no mechanisms to solve.

If you would like to request resources from multiple sources today, it's best to use a hierarchical approach. For example, the guest can request an attestation token from the KBS, that can be used to connect to a secondary KMS (which trusts the KBS).

Does that make sense? Do you have a usecase where multiple KBSes is a requirement?

[katexochen]

Sorry, my description is lacking some detail. I don't require a second KBS entity, but the KBS I run is a pod and has an ephemeral IP, so it might happen that the KBS is restarted during the lifetime of the AA and is then reachable under another IP.

Would it be a security problem to enable using a domain name for this? At least when running the KBS inside of a cluster, the distribution of IPs is done by non-TCB code, and the IP of the KBS shouldn't be used as identity anyway, right?

[fitzthum]

Hmmm. In theory connecting to the same KBS at a different IP is fine, but if the KBS is restarting then it isn't really the same one. If the restarted KBS doesn't have the session info from the original one, the KBC will need to re-attest and setup a new secure channel. That's going to cause a couple of problems. Practically speaking not all KBCs are going to support doing multiple attestations. More importantly the second attestation will give an incomplete view of the TCB given that containers could already be running inside the guest.

Using a domain name instead of an IP for the KBS URI is fine. As you say we don't trust the IP. I'm not entirely sure if using a domain will work out of the box, but it is a valid use case.

[mkulke]

In the current revision of attestation-agent I do not find this restriction anymore, has it been lifted since?

it was removed in this commit

[fitzthum]

Yes, in that PR @Xynnn007 moved the formulation of the URL from the KBC to the KBS Client. Now it is created here. There is no longer an error message but we still use the KBS URI from the AA configuration, ignoring what is set in the resource URI. This is correct imo.