CIS 1.23 Self-Assessment Guide
CIS Kubernetes Benchmark v1.23 - RKE2
Overview
This document is a companion to the RKE2 security hardening guide. The hardening guide provides prescriptive guidance for hardening a production installation of RKE2, and this benchmark guide is meant to help you evaluate the level of security of the hardened cluster against each control in the CIS Kubernetes benchmark. It is to be used by RKE2 operators, security teams, auditors, and decision makers.
This guide is specific to the v1.25 release line of RKE2 and the v1.23 release of the CIS Kubernetes Benchmark.
For more details about each control, including detailed descriptions and remediations for failing tests, you can refer to the corresponding section of the CIS Kubernetes Benchmark v1.23 You can download the benchmark after logging in to CISecurity.org.
Testing controls methodology
Each control in the CIS Kubernetes Benchmark was evaluated against an RKE2 cluster that was configured according to the accompanying hardening guide.
Where control audits differ from the original CIS benchmark, the audit commands specific to RKE2 are provided for testing.
These are the possible results for each control:
- Pass - The RKE2 cluster under test passed the audit outlined in the benchmark.
- Not Applicable - The control is not applicable to RKE2 because of how it is designed to operate. The remediation section will explain why this is so.
- Manual - Operator Dependent - The control is Manual in the CIS benchmark and it depends on the cluster's use case or some other factor that must be determined by the cluster operator. These controls have been evaluated to ensure RKE2 does not prevent their implementation, but no further configuration or auditing of the cluster under test has been performed.
Controls
1 Master Node Security Configuration
1.1 Master Node Configuration Files
1.1.1
Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)
Details
Rationale
The API server pod specification file controls various parameters that set the behavior of the API server. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.Result: Pass
Audit:
stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
644
Remediation:
By default, RKE2 creates these files with 644
permissions. No manual remediation needed.
1.1.2
Ensure that the API server pod specification file ownership is set to root:root
(Automated)
Details
Rationale
The API server pod specification file controls various parameters that set the behavior of the API server. You should set its file ownership to maintain the integrity of the file. The file should be owned byroot:root
.Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
root:root
Remediation:
By default, RKE2 creates these files with root:root
ownership. No manual remediation needed.
1.1.3
Ensure that the controller manager pod specification file permissions are set to 644
or more restrictive (Automated)
Details
Rationale
The controller manager pod specification file controls various parameters that set the behavior of the Controller Manager on the master node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.Result: Pass
Audit:
stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
644
Remediation:
By default, RKE2 creates these files with 644
permissions. No manual remediation needed.
1.1.4
Ensure that the controller manager pod specification file ownership is set to root:root
(Automated)
Details
Rationale
The controller manager pod specification file controls various parameters that set the behavior of various components of the master node. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
root:root
Remediation:
By default, RKE2 creates these files with root:root
ownership. No manual remediation needed.
1.1.5
Ensure that the scheduler pod specification file permissions are set to 644
or more restrictive (Automated)
Details
Rationale
The scheduler pod specification file controls various parameters that set the behavior of the Scheduler service in the master node. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.Result: Pass
Audit:
stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/kube-scheduler.yaml
644
Remediation:
By default, RKE2 creates these files with 644
permissions. No manual remediation needed.
1.1.6
Ensure that the scheduler pod specification file ownership is set to root:root
(Automated)
Details
Rationale
The scheduler pod specification file controls various parameters that set the behavior of the kube-scheduler service in the master node. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/kube-scheduler.yaml
root:root
Remediation:
By default, RKE2 creates these files with root:root
ownership. No manual remediation needed.
1.1.7
Ensure that the etcd pod specification file permissions are set to 644
or more restrictive (Automated)
Details
Rationale
The etcd pod specification file /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml controls various parameters that set the behavior of the etcd service in the master node. etcd is a highly-available key-value store which Kubernetes uses for persistent storage of all of its REST API object. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.Result: Pass
Audit:
stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml
644
Remediation:
By default, RKE2 creates these files with 644
permissions. No manual remediation needed.
1.1.8
Ensure that the etcd pod specification file ownership is set to root:root
(Automated)
Details
Rationale
The etcd pod specification file /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml controls various parameters that set the behavior of the etcd service in the master node. etcd is a highly-available key-value store which Kubernetes uses for persistent storage of all of its REST API object. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml
root:root
Remediation:
By default, RKE2 creates these files with root:root
ownership. No manual remediation needed.
1.1.9
Ensure that the Container Network Interface file permissions are set to 644 or more restrictive (Manual)
Details
Rationale
Container Network Interface provides various networking options for overlay networking. You should consult their documentation and restrict their respective file permissions to maintain the integrity of those files. Those files should be writable by only the administrators on the system.Result: Pass
Audit:
stat -c %a /var/lib/rancher/rke2/server/manifests/rke2-canal.yaml
644
Remediation:
RKE2 deploys the default CNI, Canal, using a Helm chart. The chart is defined as a custom resource in a file with 644
permissions. No manual remediation needed.
1.1.10
Ensure that the Container Network Interface file ownership is set to root:root
(Manual)
Details
Rationale
Container Network Interface provides various networking options for overlay networking. You should consult their documentation and restrict their respective file permissions to maintain the integrity of those files. Those files should be owned by root:root.Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/server/manifests/rke2-canal.yaml
root:root
Remediation:
RKE2 deploys the default CNI, Canal, using a Helm chart. The chart is defined as a custom resource in a file with root:root
ownership. No manual remediation needed.
1.1.11
Ensure that the etcd data directory permissions are set to 700 or more restrictive (Automated)
Details
Rationale
etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. This data directory should be protected from any unauthorized reads or writes. It should not be readable or writable by any group members or the world.Result: Pass
Audit:
stat -c %a /var/lib/rancher/rke2/server/db/etcd
700
Remediation: RKE2 manages the etcd data directory and sets its permissions to 700. No manual remediation needed.
1.1.12
Ensure that the etcd data directory ownership is set to etcd:etcd
(Automated)
Details
Rationale
etcd is a highly-available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. This data directory should be protected from any unauthorized reads or writes. It should be owned by etcd:etcd.Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/server/db/etcd
etcd:etcd
Remediation:
When running RKE2 with the profile
flag set to cis-1.23
, RKE2 will refuse to start if the etcd
user and group doesn't exist on the host. If it does exist, RKE2 will automatically set the ownership of the etcd data directory to etcd:etcd
and ensure the etcd static pod is started with that user and group.
1.1.13
Ensure that the admin.conf
file permissions are set to 644
or more restrictive (Automated)
Details
Rationale
The admin.conf is the administrator kubeconfig file defining various settings for the administration of the cluster. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.In RKE2, this file is located at /var/lib/rancher/rke2/server/cred/admin.kubeconfig
.
Result: Pass
Audit:
stat -c %a /var/lib/rancher/rke2/server/cred/admin.kubeconfig
644
Remediation:
By default, RKE2 creates this file at /var/lib/rancher/rke2/server/cred/admin.kubeconfig
and automatically sets its permissions to 644
. No manual remediation needed.
1.1.14
Ensure that the admin.conf file ownership is set to root:root
(Automated)
Details
Rationale
The admin.conf file contains the admin credentials for the cluster. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.In RKE2, this file is located at /var/lib/rancher/rke2/server/cred/admin.kubeconfig
.
Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/server/cred/admin.kubeconfig
root:root
Remediation:
By default, RKE2 creates this file at stat -c %U:%G /var/lib/rancher/rke2/server/cred/admin.kubeconfig
and automatically sets its ownership to root:root
.
1.1.15
Ensure that the scheduler.conf
file permissions are set to 644
or more restrictive (Automated)
Rationale
The scheduler.conf file is the kubeconfig file for the Scheduler. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.
In RKE2, this file is located at /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
.
Result: Pass
Audit:
stat -c %a /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
644
Remediation:
By default, RKE2 creates this file at /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
and automatically sets its permissions to 644
. No manual remediation needed.
1.1.16
Ensure that the scheduler.conf
file ownership is set to root:root
(Automated)
Details
Rationale
The scheduler.conf file is the kubeconfig file for the Scheduler. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.In RKE2, this file is located at /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
.
Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
root:root
Remediation:
By default, RKE2 creates this file at /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
and automatically sets its ownership to root:root
.
1.1.17
Ensure that the controller.kubeconfig
file permissions are set to 644
or more restrictive (Automated)
Details
Rationale
The controller.kubeconfig file is the kubeconfig file for the Scheduler. You should restrict its file permissions to maintain the integrity of the file. The file should be writable by only the administrators on the system.In RKE2, this file is located at /var/lib/rancher/rke2/server/cred/controller.kubeconfig
.
Result: Pass
Audit:
stat -c %a /var/lib/rancher/rke2/server/cred/controller.kubeconfig
644
Remediation:
By default, RKE2 creates this file at /var/lib/rancher/rke2/server/cred/controller.kubeconfig
and automatically sets its permissions to 644
. No manual remediation needed.
1.1.18
Ensure that the controller.kubeconfig
file ownership is set to root:root
(Automated)
Details
Rationale
The controller.kubeconfig file is the kubeconfig file for the Scheduler. You should set its file ownership to maintain the integrity of the file. The file should be owned by root:root.In RKE2, this file is located at /var/lib/rancher/rke2/server/cred/controller.kubeconfig
.
Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/server/cred/controller.kubeconfig
root:root
Remediation:
By default, RKE2 creates this file at /var/lib/rancher/rke2/server/cred/controller.kubeconfig
and automatically sets its ownership to root:root
.
1.1.19
Ensure that the Kubernetes PKI directory and file ownership is set to root:root
(Automated)
Details
Rationale
Kubernetes makes use of a number of certificates as part of its operation. You should set the ownership of the directory containing the PKI information and all files in that directory to maintain their integrity. The directory and files should be owned by root:root.Result: Pass
Audit:
stat -c %U:%G /var/lib/rancher/rke2/server/tls
root:root
Remediation:
By default, RKE2 creates the directory and files with the expected ownership of root:root
. No manual remediation should be necessary.
1.1.20
Ensure that the Kubernetes PKI certificate file permissions are set to 644
or more restrictive (Automated)
Details
Rationale
Kubernetes makes use of a number of certificate files as part of the operation of its components. The permissions on these files should be set to 644 or more restrictive to protect their integrity.Result: Pass
Audit: Run the below command on the master node.
stat -c %n\ %a /var/lib/rancher/rke2/server/tls/*.crt
Verify that the permissions are 644
or more restrictive.
Remediation:
By default, RKE2 creates the files with the expected permissions of 644
. No manual remediation is needed.
1.1.21
Ensure that the Kubernetes PKI key file permissions are set to 600
(Automated)
Details
Rationale
Kubernetes makes use of a number of key files as part of the operation of its components. The permissions on these files should be set to 600 to protect their integrity and confidentiality.Result: Pass
Audit: Run the below command on the master node.
stat -c %n\ %a /var/lib/rancher/rke2/server/tls/*.key
Verify that the permissions are 600
or more restrictive.
Remediation:
By default, RKE2 creates the files with the expected permissions of 600
. No manual remediation is needed.
1.2 API Server
This section contains recommendations relating to API server configuration flags
1.2.1
Ensure that the --anonymous-auth argument is set to false (Manual)
Details
Rationale
When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the API server. You should rely on authentication to authorize access and disallow anonymous requests.If you are using RBAC authorization, it is generally considered reasonable to allow anonymous access to the API Server for health checks and discovery purposes, and hence this recommendation is Manual. However, you should consider whether anonymous discovery is an acceptable risk for your purposes.
Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that --anonymous-auth=false
is present.
Remediation: By default, RKE2 kube-apiserver is configured to run with this flag and value. No manual remediation is needed.
1.2.2
Ensure that the --token-auth-file parameter is not set (Automated)
Details
Rationale
The token-based authentication utilizes static tokens to authenticate requests to the apiserver. The tokens are stored in clear-text in a file on the apiserver, and cannot be revoked or rotated without restarting the apiserver. Hence, do not use static token-based authentication.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --token-auth-file
argument does not exist.
Remediation: By default, RKE2 does not run with token authentication enabled. No manual remediation is needed.
1.2.3
Ensure that the --DenyServiceExternalIPs is not set (Automated)
Details
Rationale
This admission controller rejects all net-new usage of the Service field externalIPs. This feature is very powerful (allows network traffic interception) and not well controlled by policy. When enabled, users of the cluster may not create new Services which use externalIPs and may not add new values to externalIPs on existing Service objects. Existing uses of externalIPs are not affected, and users may remove values from externalIPs on existing Service objects.Most users do not need this feature at all, and cluster admins should consider disabling it. Clusters that do need to use this feature should consider using some custom policy to manage usage of it.
Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --enable-admission-plugins
argument does not have DenyServiceExternalIPs
.
Remediation:
By default, RKE2 does not set DenyServiceExternalIPs
to the admission plugin flag. No manual remediation is needed.
1.2.4
Ensure that the --kubelet-https
argument is set to true (Automated)
Details
Rationale
Connections from apiserver to kubelets could potentially carry sensitive data such as secrets and keys. It is thus important to use in-transit encryption for any communication between the apiserver and kubelets.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --kubelet-https
argument does not exist.
Remediation:
By default, RKE2 kube-apiserver doesn't run with the --kubelet-https
parameter as it runs with TLS. No manual remediation is needed.
1.2.5
Ensure that the --kubelet-client-certificate
and --kubelet-client-key
arguments are set as appropriate (Automated)
Details
Rationale
The apiserver, by default, does not authenticate itself to the kubelet's HTTPS endpoints. The requests from the apiserver are treated anonymously. You should set up certificate- based kubelet authentication to ensure that the apiserver authenticates itself to kubelets when submitting requests.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --kubelet-client-certificate
and --kubelet-client-key
arguments exist and they are set as appropriate.
Remediation: By default, RKE2 kube-apiserver is ran with these arguments for secure communication with kubelet. No manual remediation is needed.
1.2.6
Ensure that the --kubelet-certificate-authority
argument is set as appropriate (Automated)
Details
Rationale
The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --kubelet-certificate-authority
argument exists and is set as appropriate.
Remediation: By default, RKE2 kube-apiserver is ran with this argument for secure communication with kubelet. No manual remediation is needed.
1.2.7
Ensure that the --authorization-mode
argument is not set to AlwaysAllow
(Automated)
Details
Rationale
The API Server, can be configured to allow all requests. This mode should not be used on any production cluster.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the argument value doesn't contain AlwaysAllow
.
Remediation:
By default, RKE2 sets Node,RBAC
as the parameter to the --authorization-mode
argument. No manual remediation is needed.
1.2.8
Ensure that the --authorization-mode
argument includes Node
(Automated)
Details
Rationale
The Node authorization mode only allows kubelets to read Secret, ConfigMap, PersistentVolume, and PersistentVolumeClaim objects associated with their nodes.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify Node
exists as a parameter to the argument.
Remediation:
By default, RKE2 sets Node,RBAC
as the parameter to the --authorization-mode
argument. No manual remediation is needed.
1.2.9
Ensure that the --authorization-mode
argument includes RBAC
(Automated)
Details
Rationale
Role Based Access Control (RBAC) allows fine-grained control over the operations that different entities can perform on different objects in the cluster. It is recommended to use the RBAC authorization mode.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify RBAC
exists as a parameter to the argument.
Remediation:
By default, RKE2 sets Node,RBAC
as the parameter to the --authorization-mode
argument. No manual remediation is needed.
1.2.10
Ensure that the admission control plugin EventRateLimit is set (Manual)
Details
Rationale
UsingEventRateLimit
admission control enforces a limit on the number of events that the API Server will accept in a given time slice. A misbehaving workload could overwhelm and DoS the API Server, making it unavailable. This particularly applies to a multi-tenant cluster, where there might be a small percentage of misbehaving tenants which could have a significant impact on the performance of the cluster overall. Hence, it is recommended to limit the rate of events that the API server will accept.Note: This is an Alpha feature in the Kubernetes 1.15 release.
Result: Manual - Operator Dependent
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --enable-admission-plugins
argument is set to a value that includes EventRateLimit.
Remediation:
By default, RKE2 only sets NodeRestriction,PodSecurityPolicy
as the parameter to the --enable-admission-plugins
argument.
To configure this, follow the Kubernetes documentation and set the desired limits in a configuration file. Then refer to RKE2's documentation to see how to supply additional api server configuration via the kube-apiserver-arg parameter.
1.2.11
Ensure that the admission control plugin AlwaysAdmit
is not set (Automated)
Details
Rationale
Setting admission control plugin AlwaysAdmit allows all requests and do not filter any requests.The AlwaysAdmit admission controller was deprecated in Kubernetes v1.13. Its behavior was equivalent to turning off all admission controllers.
Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that if the --enable-admission-plugins
argument is set, its value does not include AlwaysAdmit
.
Remediation:
By default, RKE2 only sets NodeRestriction,PodSecurityPolicy
as the parameter to the --enable-admission-plugins
argument. No manual remediation needed.