Epic Goal

• ACM is aware that customers will adopt different PEPs and may have them configured through mechanisms outside of ACM.  The goal of this Epic is to determine if we can discover some of these PEPs and create useful ACM policies from what is discovered.  Some of the goals here could be:

• • Help the customer create policies from resources they have
  • Help the customer bring data from other PEPs into ACM
  • Help the customer be able to correlate data coming from multiple PEPs an a cluster or across clusters
  • Keep https://issues.redhat.com/browse/ACM-1180 in mind since CCM may want this same data.  Consider the data could be available directly from Policies rather than requiring additional discovery (TBD of course)

The CCM design is targeted toward finding PEPs and sending data from the PEP to a common Compliance repository.  While ACM would be involved in that flow, it would be focused more on getting data to CCM. The goal here is to find the PEPs and create policies based on what is found.  This is providing the data into ACM instead of a Compliance repository.  The goal isn't to achieve the compliance view (although it may be achieved through this too), but to help customers get started with ACM policies when they have already started with other PEPs.

TBD:  Would we run this on all managed cluster to create policies specific to those managed clusters or would we run discovery on a "type" of cluster so we can generate policies for clusters of that type?  Regardless the goal is the help a customer create policies from what they have and we will help get the results into ACM so their Policy management can be centralized.

Why is this important?

• …

Scenarios

1. Deliver a quick start with ACM Policies path that can generate policies from the customer PEPs.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Must support at least one of our supported PEPs: Compliance Operator or Gatekeeper

Dependencies (internal and external)

1. ...

Previous Work (Optional):

The policy generator automatically handles gatekeeper and kyverno resources by generating the policy details to detect audit failures.

Open questions::

1. See the TBD point above regarding how you scope the discovery

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>