Allow Red Hat OpenShift and Kubernetes customers to scan, remediate, and manage compliance workflows using a reusable API for ACS and ACM and can be deployed as a stand-alone service.

Epic Goal

• Gather use-cases from ACS and ACM, specifically, we need to know what about the current architecture doesn't enable ACS and ACM to better serve their customers
• See if there are any other teams within OCP who have ported an operator to a stand-alone service (is there anything we can learn from them?)
• Create a draft architecture document that addresses the use-cases from other groups and hold at least two feedback sessions with stakeholders (ACS and ACM) to verify the overall design and potentially proof-of-concepts
• Create a draft API document

Potential future goals related to this work will include the work to create a new project, determining where that project should live, it's deployment strategy, etc. The main goals of this epic is to produce design documents and proofs-of-concept that address the gaps highlighted by consumers (ACS/ACM).

Why is this important?

• Certain limitations for the compliance-operator hinder what ACS and ACM could do with compliance artifacts
• Missing functionally needed for reporting and trending
• We potentially have the opportunity to give customers a single pane of glass for all compliance standards they care about across the Red Hat products they use

Scenarios

1. Provide a workflow to schedule compliance scans
2. Provide a workflow to create custom compliance profiles

Main Workflows:

1. Ingest compliance-operator results from different clusters on different platforms into one storage system
2. Ingest ACS compliance results from different clusters on different platforms to one storage system
3. Provide an API that ACS and ACM can use to schedule scans, tailor a profile, view results, and remediations
4. Provide a way that helps to reconcile ACS compliance policies with those provided by the Compliance Operator for a common workflow
5. Provide a way to remediate a failure or add an exception for it
6. Provide a detailed view of the compliance failure by drilling down into the component that is out of technical compliance (provides better information to users and allows them to make informed decisions about remediation actions or exceptions)
7. Provide a workflow that allows me to share useful information with other teams who may need to decide whether to remediate or allow an exception
8. Create custom controls so that I am able to measure these standards in alignment with the company
9. Disable controls from the scope of a selected compliance assessment so that I do not see controls that are not relevant
10. Track compliance status over time, report trends for 3 months based on deployments
11. Notify when compliance policies are violated so that I can trigger a remediation workflow

Visibility

1. Provide a stand-alone Compliance service to provide Cloud platform Compliance for ACS and ACM for both workloads and Infrastructure
2. This has the potential to be useful outside the OpenShift organization, specifically for any product that is deployed in regulated environments

Acceptance Criteria

• Must have clearly documented use-cases and gaps from ACS and ACM that justify a standalone compliance service
• Must have a design document that describes the architecture of the service
• Must have a draft API document that describes the API we plan to expose, in addition to how we maintain this API along side the compliance-operator's existing functionality

Dependencies (internal and external)

1. Use-cases and gap analysis from ACS and ACM

Open questions::

1. Are there any other teams in OpenShift that have transitioned an operator to a managed service? If so, can we learn from what they did?
2. Since this is going to be a managed service, can we include someone who will be managing it in the design?

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>