ComplianceAsCode / ComplianceAsCode/content

Incorrect instructions for ocp4-stig-node-worker-kubelet-enable-protect-kernel-sysctl-file-exist

Open
#11,253 1 comment 0 reactions 0 assignees View on GitHub
OpenShift
Dominant language
Shell
Stars
2.8k
Forks
828
Avg merge
3d 8m
Merged PRs (30d)
80

Description

#### Description of problem:
Error in the stig rule as installed with the compliance operator. The yaml for the fix states applying to masters instead of workers. So everywhere it mentions master it should be worker.

#### SCAP Security Guide Version:

#### Operating System Version:

#### Steps to Reproduce:

1. oc describe compliancecheckresults.compliance.openshift.io ocp4-stig-node-worker-kubelet-enable-protect-kernel-sysctl-file-exist

#### Actual Results:
Name: ocp4-stig-node-worker-kubelet-enable-protect-kernel-sysctl-file-exist
Namespace: openshift-compliance
Labels: compliance.openshift.io/check-severity=medium
compliance.openshift.io/check-status=FAIL
compliance.openshift.io/scan-name=ocp4-stig-node-worker
compliance.openshift.io/suite=ocp4-stig-node
Annotations: compliance.openshift.io/rule: kubelet-enable-protect-kernel-sysctl-file-exist
API Version: compliance.openshift.io/v1alpha1
Description: kubelet - Set Up Sysctl to Enable Protect Kernel Defaults - Check sysctl configuration file exist
Setup required tuned kernel parameters before enabling overwritten protection.

Before enabling kernel parameter overwritten protection default, it's important and necessary to first create a MachineConfig object that persist the required sysctl's. The required sysctl's are the following:

kernel.keys.root_maxbytes=25000000
kernel.keys.root_maxkeys=1000000
kernel.panic=10
kernel.panic_on_oops=1
vm.overcommit_memory=1
vm.panic_on_oom=0

The these need to be enabled via MachineConfig since they need to be available as soon as the node starts and before the Kubelet does. The manifest may look as follows:

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-kubelet-sysctls
spec:
config:
ignition:
version: 3.1.0
storage:
files:
- contents:
source: data:,vm.overcommit_memory%3D1%0Avm.panic_on_oom%3D0%0Akernel.panic%3D10%0Akernel.panic_on_oops%3D1%0Akernel.keys.root_maxkeys%3D1000000%0Akernel.keys.root_maxbytes%3D25000000%0A
mode: 0644
path: /etc/sysctl.d/90-kubelet.conf
overwrite: true

This will need to be done for each relevant MachineConfigPool in the cluster.

To configure, follow the directions in the documentation ( https://docs.openshift.com/container-platform/4.6/nodes/nodes/nodes-nodes-managing.html )
Id: xccdf_org.ssgproject.content_rule_kubelet_enable_protect_kernel_sysctl_file_exist
Instructions: Run the following command on the kubelet node(s):
$ sudo [ -f /etc/sysctl.d/90-kubelet.conf ] && echo "Exists" || echo "Not Exists"
The output should return Exists.
Kind: ComplianceCheckResult
Metadata:
Creation Timestamp: 2023-10-18T19:30:03Z
Generation: 1
Managed Fields:
API Version: compliance.openshift.io/v1alpha1
Fields Type: FieldsV1
fieldsV1:
f:description:
f:id:
f:instructions:
f:metadata:
f:annotations:
.:
f:compliance.openshift.io/rule:
f:labels:
.:
f:compliance.openshift.io/check-severity:
f:compliance.openshift.io/check-status:
f:compliance.openshift.io/scan-name:
f:compliance.openshift.io/suite:
f:ownerReferences:
.:
k:{"uid":"8cd0defa-59fa-44e4-a7a7-38220e55365d"}:
f:rationale:
f:severity:
f:status:
Manager: Go-http-client
Operation: Update
Time: 2023-10-18T19:30:03Z
Owner References:
API Version: compliance.openshift.io/v1alpha1
Block Owner Deletion: true
Controller: true
Kind: ComplianceScan
Name: ocp4-stig-node-worker
UID: 8cd0defa-59fa-44e4-a7a7-38220e55365d
Resource Version: 1518678
UID: 83559cf1-5d1b-4952-8911-7b43c744e33a
Rationale: Kernel parameters are usually tuned and hardened by the system administrators before putting the systems into production. These parameters protect the kernel and the system. Your kubelet kernel defaults that rely on such parameters should be appropriately set to match the desired secured system state. Ignoring this could potentially lead to running pods with undesired kernel behavior.
Severity: medium
Status: FAIL
Events:

#### Expected Results:
References in instructions refer to worker instead of master

#### Additional Information/Debugging Steps:

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.