Uploaded image for project: 'Red Hat Advanced Cluster Security'
  1. Red Hat Advanced Cluster Security
  2. ROX-27895

Tighten OOTB OpenShift Violation exclusions

Create Feature from Fe...Move to CloseXMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • Policy Management
    • None
    • BU Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • 0

      Description:

      Over time we have introduced violation exclusions to OOTB system policies for things that should not have been  excluded, and sometimes  we made exclusions with a wide criteria (entire namespace) that can and should be tightened.

      It is important to understand that we never add exceptions for legitimate concerns. We only add exceptions for false alarms: policies that generally are good practice but in specific cases are wrong because the pod is doing exactly what it is supposed to do. This is why we go through an approval process when requests for exceptions are made, and inquire if the risky practice is indeed justified.As for the noise created by the platform related violations, well, that is why we introduced the Platform views.

      Some examples as seen in staging (ACS 4.6)

      Privileged Containers with Important and Critical Fixable CVEs

      • excluded for kube-system namespace

      Fixable Severity at least Important

      • excluded for Deployment community-operators-cms7q

      Goal Summary:

      Since policy exclusions increase the attack surface, OOTB exclusions should be made very carefully and be as tight as possible

      Goals and expected user outcomes:

      1. All CVE related OOTB policies shall have no exclusions (whether the policy is enabled or disabled by default)
      2. Exclusions for all critical and high severity policies shall be as tight as possible (MVP)
      3.  Exclusions for all medium severity policies should be as tight as possible
      4.  All low severity policies would be assessed and if the effort is reasonable they too would be made as tight as possible 

      Acceptance Criteria:

      A list of specific needs or objectives that a feature 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.

      <enter general Feature acceptance here>

      Success Criteria or KPIs measured:

      A list of specific, measurable criteria that will be used to determine if
      the feature is successful. Include key performance indicators (KPIs) or
      other metrics., etc. Initial completion during Refinement status.

      <enter success criteria and/or KPIs here>

              Unassigned Unassigned
              bmichael@redhat.com Boaz Michaely
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: