Initiative

Dog food ACS to test for security best practices across OpenShift Container Platform and all related Red Hat products (typically as operators) 

Background:

ACS provides a set of out-of-the-box policies based on security and regulatory best practices. These policies are for Kubernetes components and workloads deployed to Kubernetes clusters. 
Many OpenShift core platform and layered components violate some of these ACS OOTB policies. Mostly this occurs with low severity policies.

In some cases,  components have valid reasons to not follow the practice. For example, some openshift components require elevated privileges to function. On the other hand,  in many cases these components can improve their security posture by following the recommendations.  

To minimize impact on sales, we have hard coded some policy exclusions by ACS team. The problems with this approach are:

1. The ACS team does not have the resources or skill-set to find out all of the violations across the portfolio  in our test env
2. The ACS team does not know which policy violations should be excluded and which should be opened as bugs against the respective component

Goals

1. Establish the practice for every RH Openshift component/product to be tested against ACS OOTB security violations on an ongoing basis. Violations would be analyzed by component owners and either:
   1. Found as justified:  owner would submit a request to the ACS team identifying the component, the violation , and describing why the violation is justified. It would then be made hidden by the ACS team in a subsequent release.
   2. Identified as a security flaw and added to the component backlog for prioritization. A request may be submitted to ACS to temporarily hide the violation, explaining why it is a low security risk and therefore a low priority.
2. As part of this process, establish a method to uniquely identify Red Hat component in a way that is independent of customer environments (specifically, customers may change namespace names, and may deploy their own components into RH predefined namespaces). As an example, we can evaluate using unique labels or annotations. 

Benefit Hypothesis:

What are the benefits (to Red Hat, eventually to customers, to the community, etc.)? Does it improve security, performance, supportability, etc? Why is work a priority?

The benefits are twofold:

1. Improve product security by consistently applying container security best practices.
2. Increase customer confidence in Red Hat products (and reduce customer and field frustration) by eliminating non actionable, false positive alerts in ACS regarding those product components.

Resources

Add any resources (docs, slides, etc.) pertinent to the definition of the work. These might not be known until later. Update as necessary.

• slide deck

Responsibilities

Indicate which roles and/or teams will be responsible for contributing to the initiative and generally what they might be expected to do.

TBD

Success Criteria

Provide some examples of how we will know if we have achieved the goal. What can be measured to determine success? What observable actions/outcomes that can be seen to determine success? Specific, Measurable, Achievable, fits within the Time-box.

We will know we are successful when

1. Every component/product team has joined the process
2. Every component/product has submitted an initial list of justified policy violations (violations that should be hidden by ACS)
3. An ACS OOTB deployment would show zero justified policy violations for Red Hat components across all supported environments including On-prem (BM or Vsphere), ROSA, ARO,  *KS (EKS, AKS, GKE),  ACSCS, etc.

Outcomes

Add outcomes here once the Initiative is started. Recommend discussions & updates once per quarter in bullets.