Support full customization of CustomResource mutation rules in vault-secrets-webhook Helm chart

[gnadaban]

Is your feature request related to a problem? Please describe. Problem: trying to use ACK iam-controller with vault-secrets-webhook injecting trust policy I'm running into issues because the CustomResource mutation config options are hardcoded to apply to all API versions. This means that the webhook considers all RBAC Role objects for insertion unless they are ignored en masse either via namespace limiting or annotations (which is often outside our control, eg. some Helm charts simply don't support annotating RBAC Roles).

Describe the solution you'd like I want to be able to selectively specify the exact custom resource API versions the webhook should consider for CR mutation.

Instead of this:

  rules:
  - operations:
    - CREATE
    - UPDATE
    apiGroups:
    - "*"
    apiVersions:
    - "*"
    resources:
{{ toYaml .Values.customResourceMutations | indent 6 }}

The Helm chart should ideally allow full customization of rules, with appropriate defaults set of course:

  rules:
{{ toYaml .Values.customResourceMutations.rules | indent  }}

Describe alternatives you've considered Ignoring multiple namespaces to work around not being able to limit what CRs not to consider for mutation.

[github-actions[bot]]

Thank you for your contribution! This issue has been automatically marked as stale because it has no recent activity in the last 60 days. It will be closed in 20 days, if no further activity occurs. If this issue is still relevant, please leave a comment to let us know, and the stale label will be automatically removed.

[github-actions[bot]]

Thank you for your contribution! This issue has been automatically marked as stale because it has no recent activity in the last 60 days. It will be closed in 20 days, if no further activity occurs. If this issue is still relevant, please leave a comment to let us know, and the stale label will be automatically removed.

[github-actions[bot]]

Thank you for your contribution! This issue has been automatically marked as stale because it has no recent activity in the last 60 days. It will be closed in 20 days, if no further activity occurs. If this issue is still relevant, please leave a comment to let us know, and the stale label will be automatically removed.