Determine the hash value of a policy
We have seen in the last assignment, that each policy (a.k.a. session) has a hash value. This hash value is returned when one creates or updates a policy. We will see that one needs the hash value to update a policy. Sometimes one might forget to store the hash value, or due to an error, the hash value is lost, or somebody else has changed the policy.
The reason that one has to declare a
predecessor in a policy is to be able to track and synchronize changes of a policy. With the help of the predecessor field, one can determine a linear history of all previous policies with the same name. This is important in case one wants to check if other policies had been granted access to a secret in the past or which
MRENCLAVEs had access to secrets. Via the CAS REST API, one can then query the past policies - if one has read access to the policies.
predecessor field is also used to synchronize updates to a policy. If multiple entities might concurrently update a policy, the
predecessor field can be used to ensure that no other entity has modified the policy in the meantime. A typical workflow is as follows:
- read the current policy,
- determine the hash of the current policy, say, it is
- modify the policy and define
- update the policy
If another entity has modified the policy between step 1. and step 4., the hash will change and hence, the
predecessor will change. In this case, the update of the policy will fail. The writer has to retry steps 1 to 4.
Write a script in your favorite scripting language that performs the following steps:
- Retrieve the namespace policy that you created in the last assignment
- Compute the hash of this policy using
scone session verify.
- Write out an updated state file
state.envthat contains the name of the namespace and its current hash of the policy.
Verify that you computed the correct hash value by reading a policy using the policy name and the hash of the policy. In this case, the policy name is the name of your namespace. The hash is the value that you retrieved in task 1.
To compute the hash of an existing policy, we can first retrieve the policy using
scone session read and store this in a file. We pass this file to
scone session verify. The command
scone session verify computes the hash value of the given policy file.
To retrieve a session via the SCONE CAS REST API, you need a client certificate that permits you read access to the session. Using the standard
curl tool, one can specify a client certificate with the option
--cert <FILE>. Since we created the session with
scone CLI, by default only the key pair of the
scone CLI can be used to retrieve the session content. In case, the
scone CLI itself is not protected, we can extract the CLI as follows:
- Read the
sconeconfiguration file stored in
- Extract the value of the key
identity. You might want to use a tool like
jqto extract the value of this key.
To retrieve the policy from CAS, we need the certificate of the CAS instance and a client certificate. We can retrieve this certificate using
scone cas show-certificate as we have already seen in assignment 1.
The URL that we need to retrieve the session is as follows:
$NS contains the name of the policy and
$COMPUTED_NAMESPACE_HASH its hash.
A solution for this task for
bash is available in assignment 3](https://github.com/scontain/Exercise/tree/main/Exercise3).
- Please have a look at the troubleshooting hints from the previous assignments. If you experience any additional issues, please let us know via email. We will add the issue and a proposed solution to this troubleshooting section.