Uploaded image for project: 'Red Hat Advanced Cluster Management'
  1. Red Hat Advanced Cluster Management
  2. ACM-8244

Gatekeeper operator enhancements for OpenShift

XMLWordPrintable

    • Gatekeeper operator enhancements for OpenShift
    • False
    • None
    • False
    • Not Selected
    • To Do
    • ACM-2707 - ACM Gatekeeper Enhancements
    • ACM-2707ACM Gatekeeper Enhancements
    • 0% To Do, 33% In Progress, 67% Done

      Epic Goal

      One of the key ways the Gatekeeper operator could provide a better experience on OpenShift is if key namespaces were ignored to prevent unintended behavior with constraints that may match all namespaces.

      Customer constraints may target specific namespaces or they could be written to general check all namespaces for governance risks.  There should be an easy way for customers to automatically ignore the "platform" namespaces which are governed by Red Hat OpenShift and not the customer.  These platform/infrastructure namespaces should be configurable since there may be special cases where the customer wants to restrict certain API calls for those OpenShift namespaces.

      Why is this important?

      A simple example is a constraint that requires readiness probes.  Many OpenShift deployments do not follow that best practice so gatekeeper could alert on or prevent critical deployments from properly being started.  This could lead to a damaged or unusable cluster.  The customer needs a good out of the box experience which can best be achieved by initially ignoring certain namespaces to prevent an accidental impact such as this.

      Scenarios

      See sample scenario above.  Consider other configuration that may be valuable instead of just namespace exclusions.  Is there a way to determine what are "infrastructure" or "platform" namespaces other than "openshift*"

      Acceptance Criteria

      ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      1. ...

      Open questions:

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
        Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub
        Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

            yikim@redhat.com Yi Rae Kim
            gparvin-redhat Gus Parvin
            Derek Ho Derek Ho
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: