Epic Goal

Currently, the Compliance Operator Profile CRD doesn't have a formal linkage between the profile and a benchmark. User ultimately need to imply an association between them based on the name and description of the profile.

While this may work for human users, it's harder for machines or components using the Compliance Operator (like ACS) to make this jump. To support this today, those components would need to parse the benchmark out of the profile using a regular expression, or a similar technique, which isn't ideal and is prone to breakage if profile descriptions change.

Why is this important?

Components that use the Compliance Operator, like ACS, want to be able to expose a benchmark view of compliance results. Providing an attribute of the Profile that corresponds to the name of the benchmark will make that easier to implement since they won't need to maintain an internal mapping of profiles to benchmarks, or rely on fragile regular expressions.

Scenarios

1. As a user of the Compliance Operator, I want to be able to see the benchmark a particular profile is related to (e.g., the ocp4-pci-dss profile should map to the PCI-DSS benchmark)
2. As a user of the Compliance Operator, I want to be able to see all the profiles related to a particular benchmark (e.g., ocp4-cis and ocp4-cis-node should both map to the same benchmark)
3. As a user of the Compliance Operator, I want to have a way to know who authored a benchmark (e.g., for OpenShift CIS benchmarks, I would expect CIS to be the authoring body)

Acceptance Criteria

• The benchmark name is exposed as a discoverable, identifiable attribute of the Profile CRD
• The benchmark provider is exposed as a discoverable, identifiable attribute of the Profile CRD
• New functional tests that assert the Profile CRD contains new attributes for benchmark name and benchmark provider
• The new attributes are optional, and must be derived from the content data stream

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>