Overview:

A high level summary that describes the Epic in a clear, concise way. Complete during New status.

Collapse the 32 possible combinations of settings or the Admission Controller in a cluster, into only 3 options: Off, Fail Open (the current default), or Fail Closed (a new, more strict form of enforcement based on several customers' requests)

Requirements:

A list of specific needs or objectives that an epic must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.

From UX-Install team-Core Workflows discussions:

• Lots of knobs to turn on, we can make it so the user only has to set one setting, and we will set the rest under the hood.
• 3 settings in Static side, 4 on Dynamic side (Note: The static and dynamic config terminology make sense only in the manifest and Helm install methods, and not in the Operator method)

• Remove these 7 settings in the UI ​​ Admission Control Settings: 
• Listen on events
• Listen on creates
• Listen on updates
• Enforce on creates
• Enforce on updates
• Timeout (seconds)
• Contact Image Scanners

• Replace the above with two options (to be worded by UX/Doc Team) but their jist will be:
• Hey customer, do you want the admission controller to enforce? By default, yes. A customer might switch it to No
• If yes to the question above, do you want the admission controller to fail open or fail closed? By default, it will fail open for backward compatibility. You may switch it to fail closed and we will warn you about the consequences but allow you to make that choice, trusting you know what you are doing.

• The “Disable use of Bypass annotation” will remain and needs to be worded better to allow users to understand 1) this is an admission controller configuration 2) what does it do? Maybe a tooltip will help. I can help with the wording or explaining what this option does - it allows/disallows the use of the `stackrox.io/break-glass` annotation on deployments to allow admission review requests from such deployments to be bypassed by the admission controller aka to skip policy eval and enforcement on such review requests and hence allow them to go through/persist in etcd. This DOES NOT prevent the event triggering the detection engine in sensor and policy eval and enforcement happening there.  Put differently: This is a way to exclude deployments from the admission controller’s detection engine only.
• Install team requirements Vlad Bologa Marcin Owsiany
• All methods of install - Manifest, Helm and Operator must have consistency across the default values for the various knobs of admission controller configuration that will be set under the hood.
• Appropriate deprecation documentation if these are made “uneditable” or we’d like to warn the user to not change them.
• By default, all these methods of install must deploy and configure the admission controller - and configure the defaults consistently, regardless of the install method. Depending on the decision whether we make it configurable in the first place (check comment for Alan above)

• UX Requirements

• Make an admission controller config section with the (optional) new option above + fail open/fail closed + disable bypass option
• Rethink the dynamic vs static config sections because they don’t make sense in Helm and Operator installs (but do in manifest install)

Technical Scope:

High-level list of items that are in scope; usually completed by a staff engineer or a lead from the Feature Delivery Team. Initial completion during Refinement status.

This will affect the ACS UI, the Operator options (new options added, old options deprecated but can't be removed), and new API options.

Out of Scope:

High-level list of items that are out of scope. Initial completion during Refinement status.

Outside of adding a "fail closed" option for admission controller enforcement, no new functionality will be added as part of this epic.

Outstanding Questions (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin. Initial completion during Refinement status.

tbd