fix(policy-controller): Define failurePolicy variable for cosign webhook

[ttryf]

Description of the change

Introduce failurePolicy variable for the cosign webhook to parameterise the default action (from the hardcoded Fail value).

Existing or Associated Issue(s)

Relates to #1182 issue

Additional Information

Checklist

• Chart version bumped in Chart.yaml according to semver. Where applicable, update and bump the versions in any associated umbrella chart
• Variables are documented in the values.yaml and added to the README.md. The helm-docs utility can be used to generate the necessary content. Use helm-docs --dry-run to preview the content.
• JSON Schema generated.
• List tests pass for Chart using the Chart Testing tool and the ct lint command.

[cmurphy]

Based on #553 it seems like there was an intent at some point to unify these two webhooks and not have separate configuration for them. Could the new cosign.failurePolicy be removed and could the other webhoook just use webhook.failurePolicy?

[cmurphy]

Can you bump this to 0.11.0 since this is adding a feature?

[ttryf]

Based on #553 it seems like there was an intent at some point to unify these two webhooks and not have separate configuration for them. Could the new cosign.failurePolicy be removed and could the other webhoook just use webhook.failurePolicy?

Thanks for the context @cmurphy, this is perfectly fine and it was my initial implementation (before submitting this PR).

One thing I noticed while working on this and calling it out for visibility (my rationale for separate configuration for failurePolicy):

The webhook is used to make calls to Fulcio/Rekor/TUF etc. and could fail independently of pod health, compared to ClusterImagePolicy webhook that does local validation - no dependencies. Keeping them separately configurable, reduces the blast radius (during an outage or service unavailability) of each functionality. Not blocking this PR either way, just flagging in case it changes your view on #553.

This is based on the three failure scenarios I considered:

1. Pod is fully down/unavailable: both cases fail regardless of the defined failurePolicy value.
2. Pod is healthy, external 3rd party verification is degraded - cosign webhook fails per request while ClusterImagePolicy (CIP) remains unaffected. This is the case where the asymmetry adds value with the Ignore case to mitigate a failure that is out of someone's control and it doesn't relate with the correctness of the policy object I'm admitting in the cluster.
3. An object fails admission and gets Ignored/Failed based on the CIP configuration.