FIXING RKE2-CIS-1.24 CHECKS

[sm171190]

. MASTER:
a. Checks 1.1.10,1.1.20 are manual according to https://docs.rke2.io/security/cis_self_assessment124#1110-ensure-that-the-container-network-interface-file-ownership-is-set-to-root-manual and https://docs.rke2.io/security/cis_self_assessment124#1110-ensure-that-the-container-network-interface-file-ownership-is-set-to-root-manual respectively.
b. Check 1.3.6 is not relevant to an RKE2 cluster as RKE2 rotates TLS certificates internally - rancher/dashboard#4485. We will skip it and not score it
2. NODE:
a. Check 4.2.12 is the node-level equivalent of the master-level check 1.3.6 and is treated the same way.
@afdesk request review please.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Saurabh Misra seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[afdesk]

Contributor License Agreement is not signed yet.

[afdesk]

I'm still not sure about this. but if you're - we can merge it

my concerns are next:

• the mentioned issue - Rotate certificates for RKE2 provisioned clusters rancher/dashboard#4485, added a new feature - Rotate Certificates, if i understood correctly. (last updated on March,2022)
• CIS from RKE2 tells us to Ensure that the RotateKubeletServerCertificate argument is set to true (Last updated on Sep 18, 2024)

but we want to ignore it.

What did I miss? thanks!

[mjshastha]

These are two separate features, and based on this, As I see it we should not be skipping the check.

@sm171190 The --feature-gates option has been removed. You can verify this at https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates-removed/ to see if it helps clarify the issue.

[sm171190]

@afdesk Based on the reference shared by @ManojShastha https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates-removed/ the RotateKubeletServerCertificate feature gate was in GA from v1.19 to v1.21. SInce we're dealing with checks on k8s 1.24 I think we can skip it. Whatsay?

[sm171190]

Contributor License Agreement is not signed yet.

Have signed it already :)

[afdesk]

Contributor License Agreement is not signed yet.

Have signed it already :)

Github still doesn't detect it. Could you recheck?

[mjshastha]

also here.

The --feature-gates option has been removed. You can verify this at https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates-removed/ to see if it helps clarify the issue.

[mjshastha]

From the provided link, the check is labeled "manual." What’s the rationale behind setting the type to "manual"?

We shouldn't classify checks titled "manual" as type "manual," as they have different meanings.

The "manual" type indicates tests that cannot be automated. These tests always yield a WARN state and require user intervention.

CIS’s tool, CAT, has shifted from "score/not scored" to "Automated/Manual" in the 1.6 CIS benchmark to align with its functionality. We follow CIS benchmarks, which is why we use these titles.

[sm171190]

@mjshastha That is precisely why we want to keep type as manual. Someone using Kube-Bench recently complained about false positives regarding checks that CIS mentioned as Manual. The issue was that these users were seeing a PASS/FAIL for this check and wanted to cross-check. Setting type as manual will mark this check as WARN and not lead to someone thinking that Kube-Bench has incorrectly marked an audit as PAss/FAIL. WARN will, in some sense, force them to run the audit manually to verify - which is the very purpose of a Manual test to begin with ;)

[mjshastha]

If users have previously complained about false positives, it would be more beneficial to verify the check and adjust its implementation accordingly, rather than marking it as type: manual.

Marking it as manual does not address the root cause of the issue and may lead to confusion about the check's validity. We should only set the type to manual if it is truly a non-automatable check.

[mjshastha]

also here.

From the provided link, the check is labeled "manual." What’s the rationale behind setting the type to "manual"?

We shouldn't classify checks titled "manual" as type "manual," as they have different meanings.

The "manual" type indicates tests that cannot be automated. These tests always yield a WARN state and require user intervention.

CIS’s tool, CAT, has shifted from "score/not scored" to "Automated/Manual" in the 1.6 CIS benchmark to align with its functionality. We follow CIS benchmarks, which is why we use these titles.

[sm171190]

@mjshastha That is precisely why we want to keep type as manual. Someone using Kube-Bench recently complained about false positives regarding checks that CIS mentioned as Manual. The issue was that these users were seeing a PASS?FAIL fo rthis check and wanted to cross-check. Setting type as manual will mark this check as WARN and not lead to someone thinking that Kube-Bench has incorrectly marked an audit as PAss/FAIL. WARN will, in some sense, force them to run the audit manually to verify - which is the very purpose of a Manual test to begin with ;)

[mjshastha]

If users have previously complained about false positives, it would be more beneficial to verify the check and adjust its implementation accordingly, rather than marking it as type: manual.

Marking it as manual does not address the root cause of the issue and may lead to confusion about the check's validity. We should only set the type to manual if it is truly a non-automatable check.

[afdesk]

HI guys!
@sm171190 @mjshastha could you confirm the status of this PR?
thanks

[andypitcher]

Adding @dereknola (RKE2/K3s) for review, the RKE2/K3s profiles have been recently improved to be more accurate.