ComplianceAsCode
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:
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
Benefits
- Probably the closest to what we have today if we substitute
openshiftforkubernetesin 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
I have two proposals up for review. Both fall inline with the third solution:
https://github.com/ComplianceAsCode/content/pull/8189 https://github.com/ComplianceAsCode/content/pull/8195
The second PR is simpler since it's just a rename.
What is the current status on this issue? Is to possible to run scans with the compliance operator on a bare metal kubernetes? All the documentation is related to OpenShift and I cannot seems to find rules or profiles for vanilla kubernetes
