CIS 1.6 Self-Assessment Guide
CIS Kubernetes Benchmark v1.6 - RKE2 v1.20
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.20 release line of RKE2 and the v1.6.1 release of the CIS Kubernetes Benchmark.
For more detail about each control, including more detailed descriptions and remediations for failing tests, you can refer to the corresponding section of the CIS Kubernetes Benchmark v1.6. 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.yml
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.yml
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.6
, 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 --basic-auth-file
argument is not set (Automated)
Details
Rationale
Basic authentication uses plaintext credentials for authentication. Currently, the basic authentication credentials last indefinitely, and the password cannot be changed without restarting the API server. The basic authentication is currently supported for convenience. Hence, basic authentication should not be used.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --basic-auth-file
argument does not exist.
Remediation: By default, RKE2 does not run with basic authentication enabled. No manual remediation is needed.
1.2.3
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 basic authentication enabled. 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.
1.2.12
Ensure that the admission control plugin AlwaysPullImages is set (Manual)
Details
Rationale
Setting admission control policy toAlwaysPullImages
forces every new pod to pull the required images every time. In a multi-tenant cluster users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission control policy, once an image has been pulled to a node, any pod from any user can use it simply by knowing the image’s name, without any authorization check against the image ownership. When this plug-in is enabled, images are always pulled prior to starting containers, which means valid credentials are required.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 AlwaysPullImages
.
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.13
Ensure that the admission control plugin SecurityContextDeny is set if PodSecurityPolicy is not used (Manual)
Details
Rationale
SecurityContextDeny can be used to provide a layer of security for clusters which do not have PodSecurityPolicies enabled.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 is set to a value that includes SecurityContextDeny
, if PodSecurityPolicy
is not included.
Remediation:
By default, RKE2 automatically enables the PodSecurityPolicy
admission plugin. Therefore, the SecurityContextDeny
plugin need not be enabled. No manual remediation needed.
1.2.14
Ensure that the admission control plugin ServiceAccount
is set (Automated)
Details
Rationale
When you create a pod, if you do not specify a service account, it is automatically assigned thedefault
service account in the same namespace. You should create your own service account and let the API server manage its security tokens.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --disable-admission-plugins
argument is set to a value that does not includes ServiceAccount
.
Remediation: By default, RKE2 does not use this argument. If there's a desire to use this argument, follow the documentation and create ServiceAccount objects as per your environment. Then refer to RKE2's documentation to see how to supply additional api server configuration via the kube-apiserver-arg parameter.
1.2.15
Ensure that the admission control plugin NamespaceLifecycle
is set (Automated)
Details
Rationale
Setting admission control policy toNamespaceLifecycle
ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --disable-admission-plugins
argument is set to a value that does not include NamespaceLifecycle
.
Remediation: By default, RKE2 does not use this argument. No manual remediation needed.
1.2.16
Ensure that the admission control plugin PodSecurityPolicy
is set (Automated)
Details
Rationale
A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. ThePodSecurityPolicy
objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions.Note: When the PodSecurityPolicy admission plugin is in use, there needs to be at least one PodSecurityPolicy in place for ANY pods to be admitted. See section 1.7 for recommendations on PodSecurityPolicy settings.
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 is set to a value that includes PodSecurityPolicy
.
Remediation:
By default, RKE2 only sets NodeRestriction,PodSecurityPolicy
as the parameter to the --enable-admission-plugins
argument. No manual remediation needed.
1.2.17
Ensure that the admission control plugin NodeRestriction
is set (Automated)
Details
Rationale
Using theNodeRestriction
plug-in ensures that the kubelet is restricted to the Node
and Pod
objects that it could modify as defined. Such kubelets will only be allowed to modify their own Node
API object, and only modify Pod
API objects that are bound to their node.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Remediation:
By default, RKE2 only sets NodeRestriction,PodSecurityPolicy
as the parameter to the --enable-admission-plugins
argument. No manual remediation needed.
1.2.18
Ensure that the --insecure-bind-address
argument is not set (Automated)
Details
Rationale
If you bind the apiserver to an insecure address, basically anyone who could connect to it over the insecure port, would have unauthenticated and unencrypted access to your master node. The apiserver doesn't do any authentication checking for insecure binds and traffic to the Insecure API port is not encrypted, allowing attackers to potentially read sensitive data in transit.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --insecure-bind-address
argument does not exist.
Remediation:
By default, RKE2 explicitly excludes the use of the --insecure-bind-address
parameter. No manual remediation is needed.
1.2.19
Ensure that the --insecure-port
argument is set to 0
(Automated)
Details
Rationale
Setting up the apiserver to serve on an insecure port would allow unauthenticated and unencrypted access to your master node. This would allow attackers who could access this port, to easily take control of the cluster.Result: Pass
Audit: Run the below command on the master node.
/bin/ps -ef | grep kube-apiserver | grep -v grep
Verify that the --insecure-port
argument is set to 0.
Remediation: By default, RKE2 starts the kube-apiserver process with this argument's parameter set to 0. No manual remediation is needed.