Currently, no verification is done when an attestation is received in the control plane. Creation and validation checks are done in the client side, but not on the server side.
We should allow operators to attach rego or potentially cue policies to their contracts and these should get evaluated during the reception of the attestation.
We created a task #35 which will get superseded by this functionality since 35 is in fact a policy check that some materials exist and that the runner type is correct.
re: implementation
We can start with making this check an enforcement, meaning that if the policy check fails the att push command will too since the check for the first version could be sync.
We could implement this check as a fan-out integration. Create it by default in your org and automatically attach it to each of your workflows.
About the policy format.
We should probably aim towards Open Policy Agent (OPA) and leverage (conftest) logic. We should take a look at policy-controller way of doing this
On the UX side of things we could allow attaching a policy to our contract today.
example from policy-controller that could map our current contract too.
Note: If we go ahead with the implementation based on an integration. We would need to extend the integrations model to read from its result and apply it to the workflow runs. Currently they are just fire and forget.
Currently, no verification is done when an attestation is received in the control plane. Creation and validation checks are done in the client side, but not on the server side.
We should allow operators to attach
rego
or potentiallycue
policies to their contracts and these should get evaluated during the reception of the attestation.We created a task #35 which will get superseded by this functionality since 35 is in fact a policy check that some materials exist and that the runner type is correct.
re: implementation
att push
command will too since the check for the first version could be sync.About the policy format.
We should probably aim towards Open Policy Agent (OPA) and leverage (conftest) logic. We should take a look at policy-controller way of doing this
On the UX side of things we could allow attaching a policy to our contract today.
example from policy-controller that could map our current contract too.
using
cue
or rego
Note: If we go ahead with the implementation based on an integration. We would need to extend the integrations model to read from its result and apply it to the workflow runs. Currently they are just fire and forget.