Value Statement

Whenever a user requires a new flag or argument to be passed to Gatekeeper, we've been adding a field in the CRD to configure that specific field. The user then needs to wait for the new Gatekeeper operator version to be able to set that.

The proposal is to have two new Gatekeeper CRD fields of:

• spec.audit.additionalArguments
• spec.webhook.additionalArguments

They each accept a list of objects with the `name` and `value` fields (like env in a Kubernetes Pod). If `value` is omitted, it's treated as a flag. These arguments get passed to their respective containers.

We will document that providing any configuration that is not "GA" in upstream is not supported by Red Hat unless stated otherwise in the documentation.

Definition of Done for Engineering Story Owner (Checklist)

• A user can specify addition arguments to the Gatekeeper audit pod and webhook pod without requesting a new field in the CRD

Development Complete

• The code is complete.
• Functionality is working.
• Any required downstream Docker file changes are made.

Tests Automated

• [ ] Unit/function tests have been automated and incorporated into the
  build.
• [ ] 100% automated unit/function test coverage for new or changed APIs.

Secure Design

• [ ] Security has been assessed and incorporated into your threat model.

Multidisciplinary Teams Readiness

• [ ] Create an informative documentation issue using the Customer

Portal Doc template that you can access from [The Playbook](

https://docs.google.com/document/d/1YTqpZRH54Bnn4WJ2nZmjaCoiRtqmrc2w6DdQxe_yLZ8/edit#heading=h.9fvyr2rdriby),

and ensure doc acceptance criteria is met.

• Call out this sentence as it's own action:

• [ ] Link the development issue to the doc issue.

Support Readiness

• [ ] The must-gather script has been updated.