support a way to explicitly disable policies in a group

[migmartri]

Currently, when you reference a policy group, all the policies inside are created. My proposal is to have an attribute in the attachment of the policy groups in the contract that allows you to explicitly disable policies you want to skip.

For example, having this contract that runs all the policies in the quality group

apiVersion: chainloop.dev/v1
kind: Contract
metadata:
  name: example-contract
spec:
  policyGroups:
    - ref: file://groups/sbom-quality-group.yaml
      with:
        bannedComponents: log4j@2.14.1

We could have

apiVersion: chainloop.dev/v1
kind: Contract
metadata:
  name: example-contract
spec:
  policyGroups:
    - ref: file://groups/sbom-quality-group.yaml
      with:
        bannedComponents: log4j@2.14.1
        bannedLicenses: AGPL-1.0-only, AGPL-1.0-or-later, AGPL-3.0-only, AGPL-3.0-or-later
      skip:
        - sbom-present
        - my-other-policy

[migmartri]

From a user

I would suggest the other way - by default, all policies run but there should be an option to disable some of them

if i enable a policy group, it's because i don't want to invest effort in manually listing individual policies to run

if all in the group are all disabled by default and i need to explicitly enable the ones i want to run, i think that's equivalent to naming them individually and then there's no real purpose of having policy groups in the first place (edited)

[migmartri]

@javirln @jiparis I'd love to get your take here

[javirln]

It looks good to me, but my primary concern is how this will impact the expectations for requirements. As checked offline, it is likely that if the ignored policies have requirements attached within frameworks, those requirements will never be met, which I think it is ok.

Additionally, those policies should never be evaluated, meaning they should not even be passed to the policy engine. This approach has the same effect as ignoring a policy but from an external perspective.

[jiparis]

Sounds good. I'd put this also in the context of a future evolution to controls, with some advanced logic for applying policies