-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EAR Support #516
base: main
Are you sure you want to change the base?
EAR Support #516
Commits on Sep 25, 2024
-
policy: make policy error more general
Since we reference this error enum from mod.rs, it should not be rego-specific. The error variants are not specific to OPA, so lift them into mod.rs. Now, someone writing an alternative policy engine can use the same errors. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for 40f9b6f - Browse repository at this point
Copy the full SHA 40f9b6fView commit details
Commits on Oct 2, 2024
-
token: implement EAR token generation
This commit allows the AS to issue EAR tokens with the help of the rust-ear crate. EAR tokens require particular claims. This creates a binding between the AS policy and the EAR token. Specifically, the policy engine must return an EAR appraisal. The policy engine is still generic. Multiple policy engines could be implemented as long as they create an appraisal. Token generation is no longer generic. Since the policy engine, will always return an appraisal, we must generate an EAR token. This commit removes the simple token issuer and replaces the TokenProvider trait with a struct. The KBS will still be able to validate many different tokens, but this commit changes the AS to only issue EAR tokens. There are a few other changes, including that the policy engine no longer takes multiple policies. For now, we only evaluate the first policy in the policy list, but future commits will change this convention so that we only ever think about one policy for the attestation service (until we introduce support for validating multiple devices at once). This commit also removes the flattening of the tcb claims. With the EAR tokens, we store the TEE pubkey the tcb claims. If these claims are flattened, we will need to do some extra work to deserialize the key. The TCB claims are currently flattened so that we can use the key names as the input to the RVPS. This commit breaks this functionality, but a future commit will change the way the RVPS works to accomodate. There isn't a direct pairing between claim names and reference values, so there is no reason to keep flattening all the claims, especially because the flattening code has some corner cases that it does not support. This commit also adds the init_data_claims and runtime_data_claims to the tcb claims as long as the corresponding claims about the hashes are already there. This will allow the init_data to travel with the token, which will be convenient except if the init_data is too big. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for d803715 - Browse repository at this point
Copy the full SHA d803715View commit details
Commits on Oct 3, 2024
-
token: allow KBS to validate EAR tokens
For EAR tokens we require the public key to be set. There is no option to deserialize a token without validating the signature. The EAR verifier returns the submods as JSON. This means that some information, such as the verifier id is not propogated. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for 34567b1 - Browse repository at this point
Copy the full SHA 34567b1View commit details -
docker-compose: add attestation token keypair
A keypair is required to sign and validate the attestation token. In the past this was optional, but now it is not. Update the docker-compose manifest and configs to pass in this new keypair and update the docs to tell people how to generate it. This does complicate the user experience, but things are not secure without it. That said, we may be able to implement this automatically in a future PR. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for 37916b5 - Browse repository at this point
Copy the full SHA 37916b5View commit details -
tests: add token keypair to docker e2e test
Now we need to provision a keypair for signing and validatig the attestation tokens. Add this keypair to the docker e2e test Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for ccd4bf3 - Browse repository at this point
Copy the full SHA ccd4bf3View commit details -
tests: remove unnecessary env var
The sample attester is enabled by default. Remove setting the environment variable that used to enable it. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for a60486f - Browse repository at this point
Copy the full SHA a60486fView commit details
Commits on Oct 4, 2024
-
k8s: add token signing keypair to k8s deployments
We now require a keypair for signing/validating the attestation token. Add this keypair to our k8s deployment tooling. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for a58fb80 - Browse repository at this point
Copy the full SHA a58fb80View commit details -
tests: update e2e Makefile test
We now require a keypair to sign/validate the attestation token. Add this keypair to the e2e test. Interestingly, we were using a keypair for validating the old CoCo token in this test, but only for the passport mode. Even in background check mode, this keypair is required or the token won't be validated at all. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for 1569368 - Browse repository at this point
Copy the full SHA 1569368View commit details -
rvps: change interface to get all reference values
Previously we expected the caller of the RVPS to provide a name for the reference value that they wanted. In the AS we were flattening the TCB claims to get this name. Ultimately, the names of the TCB claims do not map directly onto the names of the required reference values. This changes the interface to have the RVPS determine which reference values to send. At the moment, it simply sends all of them. This allows the reference values that are used to mostly be set within the policy itself, which is probably a good idea. In the future, the RVPS should be improved to include a context abtraction that allows groups of reference values to be provided to the AS. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for 881aa70 - Browse repository at this point
Copy the full SHA 881aa70View commit details -
protocols: change policy_ids to policy_id
When generating EAR tokens, it seems best to only use one policy at a time (per-submod). In the commit that introduces EAR token generation in the AS, we simply ignore all policies in the policy_ids list except the first one. Here, we change the interface so that only one policy can be provided in an attestation request The KBS always sets one policy ("default"), anyway. In the future, we should figure out how to set this policy id more dynamically. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for 2f146a4 - Browse repository at this point
Copy the full SHA 2f146a4View commit details
Commits on Oct 5, 2024
-
THe skeleton for a policy that can be used to validate the TCB claims of all platforms in the context of confidential containers. Only sample and snp are supported currently, but this should give a good idea of how to extend the policy to other platforms. There are a few tweaks we can make later, such as supporting `>` or `<` comparisons. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for 1bc8011 - Browse repository at this point
Copy the full SHA 1bc8011View commit details -
docs: update docs and examples for EAR tokens
Update the attestestion service policy docs to describe the requirements for policies that will generate EAR tokens. Also update various example and default policies. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for e3fa251 - Browse repository at this point
Copy the full SHA e3fa251View commit details
Commits on Oct 23, 2024
-
policy: decouple policy claims from policy engine
If we want to support multiple types of tokens, we'll need to decouple the claims that are evaluated in the policy from the poliicy engine. This allows the token broker to specify a set of rules that the policy engine will evaluate. Then, the token broker will get the unprocessed output from the policy engine and do what it needs to. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for 98281a0 - Browse repository at this point
Copy the full SHA 98281a0View commit details -
token: support simple tokens and EAR tokens
Add back the support for the EAR token. This commit is still rough. Signed-off-by: Tobin Feldman-Fitzthum <tobin@ibm.com>
Configuration menu - View commit details
-
Copy full SHA for a13579f - Browse repository at this point
Copy the full SHA a13579fView commit details