Kubernetes content is specific to OpenShift

Description of problem:

OpenShift was the first kubernetes distribution with content in this repository. As a result, many of the rules and rule groups in applications/openshift are OpenShift-specific.

Now that we are adding content for other distributions, we should find a way to organize the content so it's platform agnostic. This makes it easier to use the content for EKS, ASK, OpenShift, and vanilla kubernetes.

Ideally, it would be great to:

1.) Reuse as many existing rules as we can 2.) Have content to be specific to the benchmark in question (content shouldn’t bleed details about irrelevant distributions when in use) 3.) Easily navigate content

Potential solutions:

Group rules by distribution

The layout would adhere to the following convention, where groups could be nested as needed:

applications/kubernetes/{distribution}/{group}/{rule}

Examples of the directory structure, omitting rules and only focusing on layout:

applications/kubernetes/ - contains all common rules for kubernetes applications/kubernetes/eks/ - contains rules specific to EKS applications/kubernetes/aks/- contains rules specific to AKS applications/kubernetes/openshift/ - contains rules specific to OpenShift applications/kubernetes/eks/logging/ - contains rules specific to EKS logging applications/kubernetes/openshift/logging/ - contains rules specific to OpenShift logging

Benefits

Well organized
Easy to find rules that are specific to a distribution
Easy to reuse common rules that are generally applicable to kubernetes

Drawbacks

Requires a lot of refactoring to get there
Having two groups with the same name and product type breaks CaC content builds
- Example: we can’t do applications/kubernetes/eks/logging and applications/kubernetes/openshift/logging
We would need to be careful nesting groups under the distribution and it would be inconsistent to have some logging rules in logging/ for one distribution and not another

Group rules by component subsystem

The layout would adhere to the following convention:

applications/kubernetes/{group}/{distribution}/{rule}

Examples of the directory structure, omitting rules and only focusing on layout:

applications/kubernetes/ - contains all common rules for kubernetes applications/kubernetes/logging/ - contains rules specific to logging applications/kubernetes/worker/ - contains rules specific to worker nodes applications/kubernetes/logging/eks/ - contains rules specific to EKS logging applications/kubernetes/logging/openshift/ - contains rules specific to OpenShift logging applications/kubernetes/worker/openshift/ - contains rules specific to OpenShift workers

Benefits

Uses a similar convention to what exists in linux_os
Still relatively easy to find rules, especially by subsystem
Common rules can still be towards the top of the hierarchy

Drawbacks

Having two groups with the same name and product type breaks CaC content builds
Can’t do applications/kubernetes/logging/eks and applications/kubernetes/worker/eks

Parameterize rules

The layout would adhere to the following convention, where groups are optional:

applications/kubernetes/{group}/{rule}

Examples of the directory structure, omitting rules and only focusing on layout:

Benefits

Probably the closest to what we have today if we substitute openshift for kubernetes in the application path
We don’t have issues with conflicting group names because we omit the distribution from the path entirely
We don’t have issues with conflicting group names because we won’t nest subsystems under distributions

Drawbacks

We’re going to be doing a lot of jinja templating logic and rules could get complex

ComplianceAsCode / content