Require resources to come from the same source

[fitzthum]

I think we have a somewhat subtle security issue.

Today, the kbs_name and kbs_uri is part of the get_resource or get_secret request. This means that hypothetically the attestation agent could use one KBS to fulfill a get_secret request and another kbs to fulfill the get_resource request.

This is potentially dangerous because of how difficult it is to confirm the identity of the KBS. There is no way to store the public key of the KBS in generic guest image. Instead, we can validate that we are talking to the correct KBS only by receiving secrets that only a valid KBS would have access to. This only works for secrets, however. Signatures do not have the same properties. We can only trust that a signature is legit if it came from the same KBS that sent over a privileged secret.

So it's a little bit suspicious if we allow resources and secrets to come from different sources. That breaks that guarantee that we are talking to the same KBS. Currently ocicrypt-rs is the one that makes the requests and ocicrypt-rs will always use the same KBS so I don't think there is any immediate issue. That said, maybe we should think about changing the AA API to not support different KBC/KBS per request. Rather there could be one global setting for it. This would also simplify ocicrypt-rs because it wouldn't need to worry about which KBC/KBS to use.

[jialez0]

It should be reminded that this change will involve three components besides AA: kata-agent, image-rs, and ocicryt-rs:

1. We need to modify the logic of starting AA in kata-agent, so that the KBC and KBS URI configurations can be passed in the AA startup phase?

2. We need to modify all the callers of AA (image-rs, ocicrypt-rs), and modify the parameters passed when calling the API of AA?

[fitzthum]

Yeah honestly might not be worth the changes since there is currently no issue, but I thought it was worth documenting this somewhere before I forgot.

[Xynnn007]

This is potentially dangerous because of how difficult it is to confirm the identity of the KBS. There is no way to store the public key of the KBS in generic guest image. Instead, we can validate that we are talking to the correct KBS only by receiving secrets that only a valid KBS would have access to. This only works for secrets, however. Signatures do not have the same properties. We can only trust that a signature is legit if it came from the same KBS that sent over a privileged secret.

Identity of KBS could also be covered by the problem identity of TEE, which we are working on a proposal. Maybe we can talk about that after the coming happy holiday :).

That breaks that guarantee that we are talking to the same KBS.

Support that AA talk to different KBS sounds not a bad idea for me, only if we can ensure all the identities of the KBSes AA is talking to.

Currently ocicrypt-rs is the one that makes the requests and ocicrypt-rs will always use the same KBS so I don't think there is any immediate issue.

In fact ocicrypt-rs always use the same AA, like the config shows

{
    "key-providers": {
        "attestation-agent": {
            "grpc": "127.0.0.1:50000"
        }
    }
}

I'm sorry, but I hate to keep selling, https://github.com/confidential-containers/documentation/issues/85 proposal may help AA to identify which KBC is going to used, although it is greatly still to be improved. Even if we now kata-agent uses one fixed KBC and KBS, I hope that in future AA and kata-cc should not care about one KBS to provide more extensibility. (Maybe in the future there is a weird user intending to use multiple KBSes?)