Rancher RKE2 runtime must isolate security functions from nonsecurity functions.

Severity	Group ID	Group Title	Version	Rule ID	Date	STIG Version
medium	V-254569	SRG-APP-000233-CTR-000585	CNTR-R2-000940	SV-254569r1016537_rule	2024-12-20	2

Description
RKE2 runs as isolated as possible. RKE2 is a container-based Kubernetes distribution. A container image is essentially a complete and executable version of an application, which relies only on the host's OS kernel. Running containers use resource isolation features in the OS kernel, such as cgroups in Linux, to run multiple independent containers on the same OS. Unless part of the core RKE2 system or configured explicitly, containers managed by RKE2 should not have access to host resources. Proper hardening of the surrounding environment is independent of RKE2 but ensures overall security stature. When Kubernetes launches a container, there are several mechanisms available to ensure complete deployments: - When a primary container process fails it is destroyed rebooted. - When Liveness checks fail for the container deployment it is destroyed rebooted. - If a readiness check fails at any point after the deployment the container is destroyed rebooted. - Kubernetes has the ability to rollback a deployment configuration to a previous state if a deployment fails. - Failover traffic to a working replica if any of the previous problems are encountered. System kernel is responsible for memory, disk, and task management. The kernel provides a gateway between the system hardware and software. Kubernetes requires kernel access to allocate resources to the Control Plane. Threat actors that penetrate the system kernel can inject malicious code or hijack the Kubernetes architecture. It is vital to implement protections through Kubernetes components to reduce the attack surface.

Description

RKE2 runs as isolated as possible. RKE2 is a container-based Kubernetes distribution. A container image is essentially a complete and executable version of an application, which relies only on the host's OS kernel. Running containers use resource isolation features in the OS kernel, such as cgroups in Linux, to run multiple independent containers on the same OS. Unless part of the core RKE2 system or configured explicitly, containers managed by RKE2 should not have access to host resources. Proper hardening of the surrounding environment is independent of RKE2 but ensures overall security stature. When Kubernetes launches a container, there are several mechanisms available to ensure complete deployments: - When a primary container process fails it is destroyed rebooted. - When Liveness checks fail for the container deployment it is destroyed rebooted. - If a readiness check fails at any point after the deployment the container is destroyed rebooted. - Kubernetes has the ability to rollback a deployment configuration to a previous state if a deployment fails. - Failover traffic to a working replica if any of the previous problems are encountered. System kernel is responsible for memory, disk, and task management. The kernel provides a gateway between the system hardware and software. Kubernetes requires kernel access to allocate resources to the Control Plane. Threat actors that penetrate the system kernel can inject malicious code or hijack the Kubernetes architecture. It is vital to implement protections through Kubernetes components to reduce the attack surface.

ℹ️ Check
Ensure protect-kernel-defaults argument is set correctly. Run this command on each node: /bin/ps -ef \| grep kubelet \| grep -v grep If --protect-kernel-defaults is not set to "true", missing or is not configured, this is a finding.

✔️ Fix
Edit the RKE2 Server configuration file on all RKE2 Server hosts, located at /etc/rancher/rke2/config.yaml, to contain the following: kubelet-arg: --protect-kernel-defaults=true If configuration files are updated on a host, restart the RKE2 Service. Run the command "systemctl restart rke2-server" for server hosts and "systemctl restart rke2-agent" for agent hosts.