Rename openshift to kubernetes

[rhmdnd]

Over the last few months we started adding support for CIS EKS profiles, which is another kubernetes distribution. Until now, all kubernetes rules have been OpenShift-specific. Now that we're expanding the content to cover more kubernetes distributions, we should make the content platform agnostic.

This commit renames the applications/openshift/ directory to applications/kubernetes/ so it's more generic. Even though almost all the content under this directory is OpenShift-specific, we will clean up individual rules to handle multiple platforms as needed. This is just the first step in making the content platform-agnostic.

Description:

• Description here. Replace this text. Don't use the italics format!

Rationale:

• Rationale here. Replace this text. Don't use the italics format!

• Fixes # Issue number here (e.g. #26) or remove this line if no issue exists.

[jhrozek]

In general I'm all for reuse and making the rules generic. However, are you sure we should also move rules that check OpenShift specific objects (SCCs, routes, ...) under kubernetes? One way to check for OCP specific. Grepping for openshift.io should get an idea of rules that are using proprietary openshift APIs. Or is the idea to move all the rules under kubernetes regardless of what distribution are they specific for?

Moreover, at least when it comes to CIS, there are some checks where OCP CIS differs from upstream kube CIS -- from the top of my head I can think about the default image pull policy rule. But I guess we can cross that bridge when we actually start implementing the profiles for other distros?

[rhmdnd]

In general I'm all for reuse and making the rules generic. However, are you sure we should also move rules that check OpenShift specific objects (SCCs, routes, ...) under kubernetes? One way to check for OCP specific. Grepping for openshift.io should get an idea of rules that are using proprietary openshift APIs. Or is the idea to move all the rules under kubernetes regardless of what distribution are they specific for?

Moreover, at least when it comes to CIS, there are some checks where OCP CIS differs from upstream kube CIS -- from the top of my head I can think about the default image pull policy rule. But I guess we can cross that bridge when we actually start implementing the profiles for other distros?

That's a fair point. Initially - we wanted to try and organize the content so that distribution-specific rules were nested under a parent kubernetes/ directory. The kubernetes/ directory would only contain rules that are generally applicable. Each sub-directory would be for distributions (kubernetes/eks/) or sub-systems (kubernetes/logging/) but we hit an issue with that design where group names are not unique, even if they're in different file paths (see issue #8198).

This lead us to flatten the rules under kubernetes/ and potentially the sub-system (kubernetes/logging/) and then put distributions-specific differences in the rules itself.

Thoughts?

[openshift-ci[bot]]

@rhmdnd: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jhrozek]

In general I'm all for reuse and making the rules generic. However, are you sure we should also move rules that check OpenShift specific objects (SCCs, routes, ...) under kubernetes? One way to check for OCP specific. Grepping for openshift.io should get an idea of rules that are using proprietary openshift APIs. Or is the idea to move all the rules under kubernetes regardless of what distribution are they specific for? Moreover, at least when it comes to CIS, there are some checks where OCP CIS differs from upstream kube CIS -- from the top of my head I can think about the default image pull policy rule. But I guess we can cross that bridge when we actually start implementing the profiles for other distros?

That's a fair point. Initially - we wanted to try and organize the content so that distribution-specific rules were nested under a parent kubernetes/ directory. The kubernetes/ directory would only contain rules that are generally applicable. Each sub-directory would be for distributions (kubernetes/eks/) or sub-systems (kubernetes/logging/) but we hit an issue with that design where group names are not unique, even if they're in different file paths (see issue #8198).

This lead us to flatten the rules under kubernetes/ and potentially the sub-system (kubernetes/logging/) and then put distributions-specific differences in the rules itself.

Ah, I missed this part! This is pretty much how we handle linux_os isn't it?

Thoughts?

OK, this sounds fine to me. Thank you for the explanation.

[rhmdnd]

In general I'm all for reuse and making the rules generic. However, are you sure we should also move rules that check OpenShift specific objects (SCCs, routes, ...) under kubernetes? One way to check for OCP specific. Grepping for openshift.io should get an idea of rules that are using proprietary openshift APIs. Or is the idea to move all the rules under kubernetes regardless of what distribution are they specific for? Moreover, at least when it comes to CIS, there are some checks where OCP CIS differs from upstream kube CIS -- from the top of my head I can think about the default image pull policy rule. But I guess we can cross that bridge when we actually start implementing the profiles for other distros?

That's a fair point. Initially - we wanted to try and organize the content so that distribution-specific rules were nested under a parent kubernetes/ directory. The kubernetes/ directory would only contain rules that are generally applicable. Each sub-directory would be for distributions (kubernetes/eks/) or sub-systems (kubernetes/logging/) but we hit an issue with that design where group names are not unique, even if they're in different file paths (see issue #8198). This lead us to flatten the rules under kubernetes/ and potentially the sub-system (kubernetes/logging/) and then put distributions-specific differences in the rules itself.

Ah, I missed this part! This is pretty much how we handle linux_os isn't it?

Thoughts?

OK, this sounds fine to me. Thank you for the explanation.

Yep - The one clear downside is that rules are going to get more complicated as more Kubernetes distributions join the party (AKS/GKE) or even the CIS benchmark for kubernetes itself.

[jan-cerny]

@rhmdnd @jhrozek Do you have any updates?

[rhmdnd]

@rhmdnd @jhrozek Do you have any updates?

No update on this, yet. We're working through some other priorities at the moment.

[openshift-ci[bot]]

@rhmdnd: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-ocp4-high-node	1ee49d2f07a648c847749b8200249b5e9e581ca5	link	true	/test e2e-aws-ocp4-high-node
ci/prow/e2e-aws-ocp4-high	1ee49d2f07a648c847749b8200249b5e9e581ca5	link	true	/test e2e-aws-ocp4-high
ci/prow/e2e-aws-rhcos4-high	1ee49d2f07a648c847749b8200249b5e9e581ca5	link	true	/test e2e-aws-rhcos4-high
ci/prow/e2e-aws-ocp4-stig	1ee49d2f07a648c847749b8200249b5e9e581ca5	link	true	/test e2e-aws-ocp4-stig
ci/prow/e2e-aws-ocp4-stig-node	1ee49d2f07a648c847749b8200249b5e9e581ca5	link	true	/test e2e-aws-ocp4-stig-node

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[jan-cerny]

@rhmdnd please resolve the conflicts

[jan-cerny]

Closing because of inactivity. Feel free to reopen if you want this to get merged.