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.
using cue
policy:
type: cuedata: | predicateType: "https://cosign.sigstore.dev/attestation/v1" predicate: "foobar e2e test"
or rego
policy:
type: regodata: | package sigstore default isCompliant = false isCompliant { input.predicateType == "https://cosign.sigstore.dev/attestation/v1" input.predicate == "foobar e2e test" }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.
### Tasks
- [x] Propose policy API (protos)
- [ ] https://github.com/chainloop-dev/chainloop/issues/1107
- [ ] https://github.com/chainloop-dev/chainloop/issues/1108
- [ ] https://github.com/chainloop-dev/chainloop/issues/1110
- [ ] https://github.com/chainloop-dev/chainloop/issues/1111
- [ ] https://github.com/chainloop-dev/chainloop/issues/1112
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
regoor potentiallycuepolicies 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 pushcommand 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
cueor 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.