Optimized the logic for token issuance and verification. #139
Conversation
jialez0
force-pushed
the
token
branch
21 times, most recently
from
ac2af79
to
f04d4ef
Compare
There was a problem hiding this comment.
Haven't had time to look at the code yet. Just a few comments.
One thing overall is that I would like us to settle on some more formal definitions of background check vs passport and how it relates to our project specifically.
I think we've been making a slightly different distinction between two modes. Currently we have one mode where the HW evidence is only the initial launch measurement. This is the 2-stage attestation. MSFT have proposed another mode where we measure the policy and bind the hw measurement to the workload. In some ways these two modes map onto background check vs passport, but not quite.
When we use a two-stage attestation, the hw evidence alone does not define the workload. Currently we use the RATS background check model for this. The KBS asks the AS to validate the hw evidence, and then the KBS injects secrets into the guest that define the workload identity.
What we've noticed lately is that it would be useful to be able to provide a workload with some kind of "passport" that reflects the workload claims. In the two-stage approach we can't use the HW evidence as a passport, because it only includes the launch measurement. Instead, this passport would have to come from the KBS, which knows the full set of workload claims. Even though we've referred to this as a passport, it wouldn't work with the RATS passport model, because we need to get it from the KBS, not from the AS (assuming the launch measurement is truly generic).
On the other hand, if we use the policy-based approach with the host data, the launch measurement would now reflect the entire workload. Here we would already have a "passport" even if we never connect to a verifier. This evidence could be sent to an enlightened KMS directly to retrieve secrets. Maybe we shouldn't refer to this as a passport, but as a workload certificate (or something).
So we have different meanings of the passport/background check idea. In the RATS model one of the crucial differences is whether or not you connect directly to the AS. For CoCo we probably care more about what exactly the evidence measures. We've also just introduced a distinction between tokens and evidence. I think we need to make it much more clear what the relationship between all these things is.
|
|
||
| By default, KBS relies on the [Confidential Containers Attestation-Service (AS)](https://github.com/confidential-containers/attestation-service) | ||
| to verify the TEE Evidence. | ||
| ## Background Check Mode |
There was a problem hiding this comment.
Here we use "mode" to distinguish from "model". "mode" are a specific usage of KBS, and "model" are abstract architectures defined by RATS.
|
@jialez0 Yes, I understand the model and I think that it will work. I think it's also a fine place to start, but I'm not sure it's going to be optimal in the long term. One thing to think about is that this model requires resource policy to be platform specific. I'm not sure this is ideal. I suggested an alternate model where the output of the AS policy validation would be the input to the KBS policy validation. In this model the AS could evaluate the claims and return not just true/false, but a wide range out outputs. For instance the AS could return level1, level2, level3 etc. to reflect different levels of strictness. Then the KBS policy could require a certain level for a certain secret. In this approach the resource policy is decoupled from the platform. The AS could define level2 for many several different platforms. I think this would really simplify coming up with resource policies, especially for resources that are deployed on multiple platforms. That said, I think the use case you mention is valid and should be supported. I think we could easily allow both if we just include the output of the AS validation as part of the token along with the claims. Then if people want to write a KBS policy that parses all the claims again they can, but they can also just use the output from the AS. Does that seem reasonable? |
@fitzthum Okay, I think this is reasonable, and I will implement it in this PR and AS PR. |
jialez0
force-pushed
the
token
branch
16 times, most recently
from
e843eac
to
5744358
Compare
Signed-off-by: Jiale Zhang <zhangjiale@linux.alibaba.com>
Signed-off-by: Jiale Zhang <zhangjiale@linux.alibaba.com>
Add two new features: `as` and `resource` oo enable KBS to clearly support two different deployment modes under the RATS architecture: 1. Background Check mode: - Deploy a KBS service that integrates AS to verify Evidence and distribute resources after verification is successful 2. Passport mode - Deploy a KBS service that does not integrate AS and only relies on verifying tokens to distribute resources - Deploy a service that does not distribute resources but is only responsible for verifying Evidence and issuing tokens (we can call it Attestation Broker Service installed) RATS architecture: https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/ Signed-off-by: Jiale Zhang <zhangjiale@linux.alibaba.com>
Added optional feature to KBS: integrated policy engine to determine whether requesters have access rights to specific resource data based on attestation results claims. The default implementation of the policy engine is the Open Policy Agent, which provides a unified interface to support more types of policy engines. Signed-off-by: Jiale Zhang <zhangjiale@linux.alibaba.com>
1. Change the version of `kbs_protocol` dependency. 2. Add argument to set custom TEE private key. 3. Support get resource with attestation token to adapt passport mode. Signed-off-by: Jiale Zhang <zhangjiale@linux.alibaba.com>
1. Optimize Makefile: replace messy object names with compile parameters 2. Update kbs-config.json and as-config.json 3. Update Dockerfiles Signed-off-by: Jiale Zhang <zhangjiale@linux.alibaba.com>
1. Update README.md to explain the two deploy mode (background-check and passport) 2. Update `kbs_attestation_protocol.md` and `kbs.yaml` to adapt the new APIs and structures 3. Add a Quick Start guide Signed-off-by: Jiale Zhang <zhangjiale@linux.alibaba.com>
Signed-off-by: Jiale Zhang <zhangjiale@linux.alibaba.com>
kbs_protocolin Refactor kbs client guest-components#304)@Xynnn007 @sameo @bpradipt @mkulke @mythi If you have any comments on these modifications, please let me know.