CIS Hardening Guide
This document provides prescriptive guidance for hardening a production installation of RKE2. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Internet Security (CIS).
For more details about evaluating a hardened cluster against the official CIS benchmark, refer to the CIS Benchmark Self-Assessment Guide v1.23, or Self-Assessment Guide v1.6 for RKE2 versions prior to v1.25.
RKE2 is designed to be "hardened by default" and pass the majority of the Kubernetes CIS controls without modification. There are a few notable exceptions to this that require manual intervention to fully pass the CIS Benchmark:
- RKE2 will not modify the host operating system. Therefore, you, the operator, must make a few host-level modifications.
- Certain CIS controls for Network Policies and Pod Security Standards (or Pod Security Policies (PSP) on RKE2 versions prior to v1.25) will restrict the functionality of the cluster. You must opt into having RKE2 configure these for you. To help ensure these requirements are met, RKE2 can be started with the
profile
flag set tocis-1.23
, orcis-1.6
.
This guide assumes that RKE2 has been installed, but is not yet running. If you have already started RKE2, you will need to stop the RKE2 service.
Host-level requirements
There are two areas of host-level requirements: kernel parameters and etcd process/directory configuration. These are outlined in this section.
Ensure protect-kernel-defaults
is set
This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
When the profile
flag is set, RKE2 will set the flag to true
.
protect-kernel-defaults
is exposed as a top-level flag for RKE2. If you have set profile
to cis-1.XX
and protect-kernel-defaults
to false
explicitly, RKE2 will exit with an error.
RKE2 will also check the same kernel parameters that the kubelet does and exit with an error following the same rules as the kubelet. This is done as a convenience to help the operator more quickly and easily identify what kernel parameters are violating the kubelet defaults.
Ensure etcd is configured properly
The CIS Benchmark requires that the etcd data directory be owned by the etcd
user and group. This implicitly requires the etcd process run as the host-level etcd
user. To achieve this, RKE2 takes several steps when started with a valid cis-1.XX
profile:
- Check that the
etcd
user and group exists on the host. If they don't, exit with an error. - Create etcd's data directory with
etcd
as the user and group owner. - Ensure the etcd process is run as the
etcd
user and group by setting the etcd static pod'sSecurityContext
appropriately.
To meet the above requirements, you must:
Set kernel parameters
When RKE2 is installed, it creates a sysctl config file to set the required parameters appropriately. However, it does not automatically configure the host to use this configuration. You must do this manually. The location of the config file depends on the installation method used.
If RKE2 was installed via RPM, YUM, or DNF (the default on OSes that use RPMs, such as CentOS), run the following commands:
sudo cp -f /usr/share/rke2/rke2-cis-sysctl.conf /etc/sysctl.d/60-rke2-cis.conf
sudo systemctl restart systemd-sysctl
If RKE2 was installed via the tarball (the default on OSes that do not use RPMs, such as Ubuntu), run the following commands:
sudo cp -f /usr/local/share/rke2/rke2-cis-sysctl.conf /etc/sysctl.d/60-rke2-cis.conf
sudo systemctl restart systemd-sysctl
If your system lacks the systemd-sysctl.service
and/or the /etc/sysctl.d
directory, you will want to make sure the sysctls are applied at boot by running the following command during start-up:
sudo sysctl -p /usr/local/share/rke2/rke2-cis-sysctl.conf
Please perform this step only on fresh installations, before actually using RKE2 to deploy Kubernetes. Many Kubernetes components, including CNI plugins, set up their own sysctls. Restarting the systemd-sysctl
service on a running Kubernetes cluster can result in unexpected side-effects.