Problem statement

Currently, customers are limited to using the profiles we provide. However, they do have the option of enhancing them by adding or removing rules and setting variables using the TailoredProfile construct. While this works well for customers aiming to slightly modify a certain profile, this doesn't address cases where folks need to comply with an entirely different standard.

The XCCDF standard actually allows for building tailorings without having to extend a profile. However, we don't allow this in the Compliance Operator. As we add new rules to our repertoire, it should be possible for customers to select from the rules we already have and use those to build a profile instead.

Epic Goal

• Allow customers/users to select the rules they want to build a TailoredProfile without extending another one (from scratch). They should be able to set variables here too.

Why is this important?

Currently, the speed of the engineering team is the bottleneck for customers getting profiles for the standards they need. If they'd be able to create their own, that would give them more flexibility and they'd be able to adopt the operator faster. If, from customer feedback, we know that a certain profile is being requested and tailored often, we could adopt it and start supporting it directly as a profile (not a tailoring).

Scenarios

• As an administrator, I'd like to get my clusters to comply with the X benchmark. Red Hat doesn't have a benchmark available for me yet in the form of a profile, so in the meantime I'll build it myself.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

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>