Feature Overview (aka. Goal Summary)  

Ensure MicroShift runs on systems that are security hardened according to the CIS Level 2 standard. 

Goals (aka. expected user outcomes)

The goal of this feature is to create the necessary tests, configuration and documentation how to run MicorShift on a CIS Level 2 compliance system. 

Requirements (aka. Acceptance Criteria):

1. Setup CI/QE test automation that adds MicroShift to a CIS Lvl2 compliant RHEL X86_64 system. 
2. Run tests to validate MicroShift works correctly. This could be
   1. Minimum requirement: A simple smoke test, e.g. a simple app with storage, exposed via route, showing that ingress, storage, scheduling works)
   2. Larger / all portions of the existing testing suite
3. Identify and document the necessary configurations step to make MicroShift work, if any. Example could be opening certain ports in the firewall, SELinux rules adjustments or similiar. 
4. Optional requirement: do the same for Aarch64 based system, if CIS Lvl2 is applicable/available for this architecture (see open questions)

Questions to Answer (Optional):

1. How to create / obtain a CIS Level2 system? Some options could be:
   1. Use RHEL9 CIS hardened base image of a cloud provider (e.g. this AMI)
   2. Use Ansible Roles like [this|http://example.com] to harden an existing 
2. Is CIS Lvl2 hardening available for Aarch64 architecture?
3. Could the OpenShift Compliance Operator be applied / used for MicroShift? Probably not, as it heavily depends on OpenShift API like the MachineConfig to configure the system for CIS compliance. This needs to be evaluated. 

Out of Scope

1. rpm-ostree or bootc image based systems. We do this first RPM based only, to reduce complexity. The assumption is that if we know how to run MicroShift CIS compliant on package mode, it should work the same on image mode. 

Background

Security sensitive customers require compliance with security policies.  There are plenty of other security policies out there, depending on the vertical (e.g. STIG, PCI-DSS, HIPA, NERC, ....). Its important to establish a validation process, so we can quickly add more standards when the need arises. 

Customer Considerations

<your text here>

Documentation Considerations

Needs instructions similiar / next to the "Designed for FIPS" documentation we already have.

Interoperability Considerations

Needs close collaboration with the Product Security Tea, (represented by the MicroShift Product Security Architect), to help with the learning curve and provide guidance on how to establish a CIS Lvl2 system, and also with remediations if any are needed.