Epic Goal

To address the gaps in policy compliance history, it is proposed to store compliance events in a central relational database so that they can be stored long-term and are queryable with rich metadata. Each managed cluster would be responsible for recording their compliance events through an HTTP API on the hub that abstracts the database.

Why is this important?

The current policy compliance history is stored in the policy template's parent policy and is limited to just 10 compliance events. When a policy is deleted, compliance history for that policy is lost for all clusters. If a cluster is deleted, all the compliance history for that cluster is lost. Additionally, the current compliance history is not easily queryable and does not provide rich context of the violation. One exception to this is that there are some metrics that expose whether a policy is compliant or noncompliant but those must be scraped by Prometheus and changes between scrapes will be lost, therefore, the data cannot be relied upon.

When a user wants to pass an audit or determine when an incident occurred, it is required to have accurate, historical, and queryable compliance data.

Scenarios

...

Acceptance Criteria

...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. ...

Open questions:

1. …

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>