mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
Update and restructure hardening guides pages
Signed-off-by: Guilherme Macedo <guilherme.macedo@suse.com>
This commit is contained in:
Guilherme Macedo
+243
-153
@@ -8,43 +8,29 @@ This document provides prescriptive guidance for how to harden a K3s cluster int
|
||||
This hardening guide describes how to secure the nodes in your cluster. We recommended that you follow this guide before you install Kubernetes.
|
||||
:::
|
||||
|
||||
This hardening guide is intended to be used for K3s clusters and associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
|
||||
This hardening guide is intended to be used for K3s clusters and is associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.22 up to v1.25 |
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 up to v1.25 |
|
||||
|
||||
For more details on how to evaluate a hardened K3s cluster against the official CIS benchmark, refer to the K3s self-assessment guides for specific CIS benchmark versions.
|
||||
:::note
|
||||
At the time of writing, the official Kubernetes v1.25 benchmark is still in draft status by CIS. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters.
|
||||
:::
|
||||
|
||||
For more details on how to evaluate a hardened K3s cluster against the official CIS benchmark, refer to the K3s self-assessment guides for specific Kubernetes and CIS benchmark versions.
|
||||
|
||||
K3s passes a number of the Kubernetes CIS controls without modification, as it applies several security mitigations by default. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
|
||||
|
||||
1. K3s doesn't modify the host operating system. Any host-level modifications need to be done manually.
|
||||
1. K3s does not modify the host operating system. Any host-level modifications need to be done manually.
|
||||
2. Certain CIS policy controls for `NetworkPolicies` and `PodSecurityStandards` (`PodSecurityPolicies` on v1.24 and older) restrict cluster functionality.
|
||||
You must opt into having K3s configure these policies. Add the appropriate options to your command-line flags or configuration file (enable admission plugins), and manually apply the appropriate policies.
|
||||
See further for more details.
|
||||
|
||||
The first section (1.1) of the CIS Benchmark primarily focuses on pod manifest permissions and ownership. Since everything in the distribution is packaged in a single binary, this section doesn't apply to the core components of K3s.
|
||||
The first section (1.1) of the CIS Benchmark primarily focuses on pod manifest permissions and ownership. Since everything in the distribution is packaged in a single binary, this section does not apply to the core components of K3s.
|
||||
|
||||
## Host-level Requirements
|
||||
|
||||
### Set kernel parameters
|
||||
|
||||
The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
|
||||
|
||||
```ini
|
||||
vm.panic_on_oom=0
|
||||
vm.overcommit_memory=1
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
```
|
||||
|
||||
Run `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
|
||||
|
||||
|
||||
## Kubernetes Runtime Requirements
|
||||
|
||||
The CIS Benchmark runtime requirements center around pod security (via PSP or PSA), network policies and API Server auditing logs.
|
||||
|
||||
### 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.
|
||||
@@ -59,15 +45,33 @@ spec:
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
### Set kernel parameters
|
||||
|
||||
The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
|
||||
|
||||
```ini
|
||||
vm.panic_on_oom=0
|
||||
vm.overcommit_memory=1
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
```
|
||||
|
||||
Run `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
|
||||
|
||||
This configuration needs to be done before setting the kubelet flag, otherwise K3s will fail to start.
|
||||
|
||||
## Kubernetes Runtime Requirements
|
||||
|
||||
The CIS Benchmark runtime requirements center around pod security (via PSP or PSA), network policies and API Server auditing logs.
|
||||
|
||||
By default, K3s does not include any pod security or network policies. However, K3s ships with a controller that enforces any network policies you create. By default, K3s enables both the `PodSecurity` and `NodeRestriction` admission controllers, among others.
|
||||
|
||||
### Pod Security
|
||||
|
||||
By default, K3s doesn't include any pod security or network policies. However, K3s ships with a controller that enforces any network policies you create. K3s doesn't enable auditing by default, so you must manually create audit log configuration and audit policies. By default, K3s enables both the `PodSecurity` and `NodeRestriction` admission controllers, among others.
|
||||
|
||||
<Tabs>
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 and Newer" default>
|
||||
|
||||
K3s v1.25 and newer support [Pod Security Admissions (PSAs)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) for controlling pod security.
|
||||
K3s v1.25 and newer support [Pod Security Admission (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) for controlling pod security.
|
||||
|
||||
You can specify the Pod Security Admission configuration by setting the `defaultPodSecurityAdmissionConfigurationTemplateName` field in the cluster configuration in Rancher:
|
||||
|
||||
@@ -75,10 +79,13 @@ You can specify the Pod Security Admission configuration by setting the `default
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
```
|
||||
|
||||
The `rancher-restricted` template is a Rancher provided PSS (Pod Security Standards) policy that enforces the highly-restrictive Kubernetes upstream [`Restricted`](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) profile with best practices for pod hardening.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
K3s v1.24 and older support [Pod Security Policies (PSPs)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) for controlling pod security.
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) for controlling pod security.
|
||||
|
||||
You can enable PSPs by passing the following flags in the cluster configuration in Rancher:
|
||||
|
||||
@@ -94,9 +101,14 @@ This maintains the `NodeRestriction` plugin and enables the `PodSecurityPolicy`.
|
||||
|
||||
Once you enable PSPs, you can apply a policy to satisfy the necessary controls described in section 5.2 of the CIS Benchmark.
|
||||
|
||||
Here's an example of a compliant PSP:
|
||||
:::note
|
||||
These are manual checks in the CIS Benchmark. The CIS scan flags the results as `warning`, because manual inspection is necessary by the cluster operator.
|
||||
:::
|
||||
|
||||
Here is an example of a compliant PSP:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
@@ -137,9 +149,8 @@ spec:
|
||||
|
||||
For the example PSP to be effective, we need to create a `ClusterRole` and a `ClusterRoleBinding`. We also need to include a "system unrestricted policy" for system-level pods that require additional privileges, and an additional policy that allows the necessary sysctls for full functionality of ServiceLB.
|
||||
|
||||
If we combine the configuration above with the Network Policy described in the next section, we can place a single file in the `/var/lib/rancher/k3s/server/manifests` directory. Here is an example of a `policy.yaml` file:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
@@ -273,6 +284,48 @@ rules:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:svc-local-path-provisioner-psp
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
resourceNames:
|
||||
- system-unrestricted-psp
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:svc-coredns-psp
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
resourceNames:
|
||||
- system-unrestricted-psp
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:svc-cis-operator-psp
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
resourceNames:
|
||||
- system-unrestricted-psp
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: default:restricted-psp
|
||||
@@ -325,6 +378,77 @@ subjects:
|
||||
- kind: ServiceAccount
|
||||
name: svclb
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: svc-local-path-provisioner-psp-rolebinding
|
||||
namespace: kube-system
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:svc-local-path-provisioner-psp
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: local-path-provisioner-service-account
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: svc-coredns-psp-rolebinding
|
||||
namespace: kube-system
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:svc-coredns-psp
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: coredns
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: svc-cis-operator-psp-rolebinding
|
||||
namespace: cis-operator-system
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:svc-cis-operator-psp
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: cis-operator-serviceaccount
|
||||
```
|
||||
|
||||
The policies presented above can be placed in a file named `policy.yaml` in the `/var/lib/rancher/k3s/server/manifests` directory. Both the policy file and the its directory hierarchy must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
|
||||
|
||||
```shell
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
|
||||
```
|
||||
|
||||
:::note
|
||||
The critical Kubernetes additions such as CNI, DNS, and Ingress are run as pods in the `kube-system` namespace. Therefore, this namespace has a less restrictive policy, so that these components can run properly.
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Network Policies
|
||||
|
||||
CIS requires that all namespaces apply a network policy that reasonably limits traffic into namespaces and pods.
|
||||
|
||||
:::note
|
||||
This is a manual check in the CIS Benchmark. The CIS scan flags the result as a `warning`, because manual inspection is necessary by the cluster operator.
|
||||
:::
|
||||
|
||||
The network policies can be placed in the `policy.yaml` file in `/var/lib/rancher/k3s/server/manifests` directory. If the directory was not created as part of the PSP (as described above), it must be created first.
|
||||
|
||||
```shell
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
|
||||
```
|
||||
|
||||
Here is an example of a compliant network policy:
|
||||
|
||||
```yaml
|
||||
---
|
||||
kind: NetworkPolicy
|
||||
apiVersion: networking.k8s.io/v1
|
||||
metadata:
|
||||
@@ -365,42 +489,10 @@ spec:
|
||||
name: kube-public
|
||||
```
|
||||
|
||||
:::note
|
||||
The critical Kubernetes additions such as CNI, DNS, and Ingress are run as pods in the `kube-system` namespace. Therefore, this namespace has a less restrictive policy, so that these components can run properly.
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Network Policies
|
||||
|
||||
CIS requires that all namespaces apply a network policy that reasonably limits traffic into namespaces and pods.
|
||||
|
||||
:::note
|
||||
This is a manual check in the CIS Benchmark. The CIS scan flags the result as a `warning`, because manual inspection is necessary by the cluster operator.
|
||||
:::
|
||||
|
||||
Here's an example of a compliant network policy:
|
||||
|
||||
```yaml
|
||||
kind: NetworkPolicy
|
||||
apiVersion: networking.k8s.io/v1
|
||||
metadata:
|
||||
name: intra-namespace
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
name: kube-system
|
||||
```
|
||||
|
||||
The active restrictions block DNS unless purposely allowed. Below is a network policy that allows DNS-related traffic:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
@@ -420,12 +512,10 @@ spec:
|
||||
- Ingress
|
||||
```
|
||||
|
||||
The metrics-server and Traefik ingress controller are blocked by default if network policies aren't created to allow access.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v1.21 and Newer" default>
|
||||
The metrics-server and Traefik ingress controller are blocked by default if network policies are not created to allow access.
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
@@ -446,7 +536,7 @@ metadata:
|
||||
name: allow-all-svclbtraefik-ingress
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
svccontroller.k3s.cattle.io/svcname: traefik
|
||||
ingress:
|
||||
@@ -467,58 +557,7 @@ spec:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
---
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="v1.20 and Older">
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-all-metrics-server
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
k8s-app: metrics-server
|
||||
ingress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-all-svclbtraefik-ingress
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
svccontroller.k3s.cattle.io/svcname: traefik
|
||||
ingress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-all-traefik-v120-ingress
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
app: traefik
|
||||
ingress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
---
|
||||
```
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
:::note
|
||||
You must manage network policies as normal for any additional namespaces you create.
|
||||
@@ -526,7 +565,7 @@ You must manage network policies as normal for any additional namespaces you cre
|
||||
|
||||
### API Server audit configuration
|
||||
|
||||
K3s doesn't create the log directory and audit policy by default, as auditing requirements are specific to each user's policies and environment.
|
||||
CIS requirements 1.2.22 to 1.2.25 are related to configuring audit logs for the API Server. K3s does not create by default the log directory and audit policy, as auditing requirements are specific to each user's policies and environment.
|
||||
|
||||
If you need a log directory, it must be created before you start K3s. We recommend a restrictive access permission to avoid leaking sensitive information.
|
||||
|
||||
@@ -537,13 +576,14 @@ sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/logs
|
||||
The following is a starter audit policy to log request metadata. This policy should be written to a file named `audit.yaml` in the `/var/lib/rancher/k3s/server` directory. Detailed information about policy configuration for the API server can be found in the [official Kubernetes documentation](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/).
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
rules:
|
||||
- level: Metadata
|
||||
```
|
||||
|
||||
Further configurations are also needed to pass CIS checks. These aren't configured by default in K3s, because they vary based on your environment and needs:
|
||||
Further configurations are also needed to pass CIS checks. These are not configured by default in K3s, because they vary based on your environment and needs:
|
||||
|
||||
- Ensure that the `--audit-log-path` argument is set.
|
||||
- Ensure that the `--audit-log-maxage` argument is set to 30 or as appropriate.
|
||||
@@ -557,19 +597,66 @@ spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS v1.20/v1.23 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS v1.20 1.2.21 and CIS v1.23 1.2.19
|
||||
- audit-log-maxage=30 # CIS v1.20 1.2.22 and CIS v1.23 1.2.20
|
||||
- audit-log-maxbackup=10 # CIS v1.20 1.2.23 and CIS v1.23 1.2.21
|
||||
- audit-log-maxsize=100 # CIS v1.20 1.2.24 and CIS v1.23 1.2.22
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS 1.2.18
|
||||
- audit-log-maxage=30 # CIS 1.2.19
|
||||
- audit-log-maxbackup=10 # CIS 1.2.20
|
||||
- audit-log-maxsize=100 # CIS 1.2.21
|
||||
```
|
||||
|
||||
### Controller Manager Requirements
|
||||
|
||||
CIS requirement 1.3.1 checks for garbage collection settings in the Controller Manager. Garbage collection is important to ensure sufficient resource availability and avoid degraded performance and availability. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
|
||||
|
||||
This can be remediated by setting the following configuration in the K3s cluster file in Rancher. The value below is only an example. The appropriate threshold value is specific to each user's environment.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-controller-manager-arg:
|
||||
- terminated-pod-gc-threshold=10 # CIS 1.3.1
|
||||
```
|
||||
|
||||
### Configure `default` Service Account
|
||||
|
||||
Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
|
||||
|
||||
For CIS requirement 5.1.5 the `default` service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
|
||||
This can be remediated by updating the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.
|
||||
|
||||
For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default)`, K3s does not automatically do this.
|
||||
|
||||
Save the following configuration to a file called `account_update.yaml`.
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
Create a bash script file called `account_update.sh`. Be sure to `chmod +x account_update.sh` so the script has execute permissions.
|
||||
|
||||
```shell
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
Run the script every time a new service account is added to your cluster.
|
||||
|
||||
## Reference Hardened K3s Template Configuration
|
||||
|
||||
The following reference template configuration is used in Rancher to create a hardened K3s custom cluster based on each CIS control in this guide. This reference doesn't include other required **cluster configuration** directives, which vary based on your environment.
|
||||
The following reference template configuration is used in Rancher to create a hardened K3s custom cluster based on each CIS control in this guide. This reference does not include other required **cluster configuration** directives, which vary based on your environment.
|
||||
|
||||
<Tabs groupId="rke2-version">
|
||||
<TabItem value='v1.25 and Newer' default>
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 and Newer" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
@@ -583,25 +670,26 @@ spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- enable-admission-plugins=NodeRestriction,ServiceAccount # CIS 1.2.16, CIS 5.2 and CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS v1.20/v1.23 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS v1.20 1.2.21 and CIS v1.23 1.2.19
|
||||
- audit-log-maxage=30 # CIS v1.20 1.2.22 and CIS v1.23 1.2.20
|
||||
- audit-log-maxbackup=10 # CIS v1.20 1.2.23 and CIS v1.23 1.2.21
|
||||
- audit-log-maxsize=100 # CIS v1.20 1.2.24 and CIS v1.23 1.2.22
|
||||
- request-timeout=300s # Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
|
||||
- service-account-lookup=true # Control CIS v1.23 1.2.24
|
||||
- enable-admission-plugins=NodeRestriction,ServiceAccount # CIS 1.2.15, 1.2.13
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS 1.2.18
|
||||
- audit-log-maxage=30 # CIS 1.2.19
|
||||
- audit-log-maxbackup=10 # CIS 1.2.20
|
||||
- audit-log-maxsize=100 # CIS 1.2.21
|
||||
- request-timeout=300s # CIS 1.2.22
|
||||
- service-account-lookup=true # CIS 1.2.24
|
||||
kube-controller-manager-arg:
|
||||
- terminated-pod-gc-threshold=10 # CIS 1.3.1
|
||||
secrets-encryption: true
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
kubelet-arg:
|
||||
- make-iptables-util-chains=true # Control 4.2.7
|
||||
protect-kernel-defaults: true # Control 4.2.6
|
||||
- make-iptables-util-chains=true # CIS 4.2.7
|
||||
protect-kernel-defaults: true # CIS 4.2.6
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value='v1.22 up to 1.24'>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
@@ -614,20 +702,22 @@ spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount # CIS 1.2.16, CIS 5.2 and CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS v1.20/v1.23 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS v1.20 1.2.21 and CIS v1.23 1.2.19
|
||||
- audit-log-maxage=30 # CIS v1.20 1.2.22 and CIS v1.23 1.2.20
|
||||
- audit-log-maxbackup=10 # CIS v1.20 1.2.23 and CIS v1.23 1.2.21
|
||||
- audit-log-maxsize=100 # CIS v1.20 1.2.24 and CIS v1.23 1.2.22
|
||||
- request-timeout=300s # Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
|
||||
- service-account-lookup=true # Control CIS v1.23 1.2.24
|
||||
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount # CIS 1.2.15, 5.2, 1.2.13
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS 1.2.18
|
||||
- audit-log-maxage=30 # CIS 1.2.19
|
||||
- audit-log-maxbackup=10 # CIS 1.2.20
|
||||
- audit-log-maxsize=100 # CIS 1.2.21
|
||||
- request-timeout=300s # CIS 1.2.22
|
||||
- service-account-lookup=true # CIS 1.2.24
|
||||
kube-controller-manager-arg:
|
||||
- terminated-pod-gc-threshold=10 # CIS 1.3.1
|
||||
secrets-encryption: true
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
kubelet-arg:
|
||||
- make-iptables-util-chains=true # Control 4.2.7
|
||||
protect-kernel-defaults: true # Control 4.2.6
|
||||
- make-iptables-util-chains=true # CIS 4.2.7
|
||||
protect-kernel-defaults: true # CIS 4.2.6
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
@@ -635,4 +725,4 @@ spec:
|
||||
|
||||
## Conclusion
|
||||
|
||||
If you've followed this guide, your K3s custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our K3s self-assessment guides to understand how we verified each of the benchmarks and how you can do the same on your cluster.
|
||||
If you have followed this guide, your K3s custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our K3s self-assessment guides to understand how we verified each of the benchmarks and how you can do the same on your cluster.
|
||||
@@ -4,7 +4,6 @@ title: Self-Assessment and Hardening Guides for Rancher
|
||||
|
||||
Rancher provides specific security hardening guides for each supported Rancher version's Kubernetes distributions.
|
||||
|
||||
|
||||
## Rancher Kubernetes Distributions
|
||||
|
||||
Rancher uses the following Kubernetes distributions:
|
||||
@@ -21,32 +20,33 @@ Each self-assessment guide is accompanied by a hardening guide. These guides wer
|
||||
|
||||
### RKE Guides
|
||||
|
||||
| Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|
||||
|------------------------------|-----------------------|----------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------|
|
||||
| Kubernetes v1.18 up to v1.23 | CIS v1.6 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-self-assessment-guide-with-cis-v1.6-benchmark.md) | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide.md) |
|
||||
| Kubernetes v1.19 up to v1.21 | CIS v1.20 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-self-assessment-guide-with-cis-v1.20-benchmark.md) | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide.md) |
|
||||
| Kubernetes v1.22 up to v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide.md) |
|
||||
|
||||
| Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|
||||
|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke1-hardening-guide.md) |
|
||||
| Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](rke1-hardening-guide.md) |
|
||||
| Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md) | [Link](rke1-hardening-guide.md) |
|
||||
|
||||
### RKE2 Guides
|
||||
|
||||
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|
||||
|----------------------------------|------------------------------|-----------------------|----------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|
|
||||
| Rancher provisioned RKE2 cluster | Kubernetes v1.21 up to v1.23 | CIS v1.6 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-self-assessment-guide-with-cis-v1.6-benchmark.md) | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide.md) |
|
||||
| Rancher provisioned RKE2 cluster | Kubernetes v1.22 up to v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-self-assessment-guide-with-cis-v1.23-benchmark.md) | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide-with-cis-v1.23-benchmark.md) |
|
||||
| Standalone RKE2 | Kubernetes v1.20 | CIS v1.6 | [Link](https://docs.rke2.io/security/cis_self_assessment16/) | [Link](https://docs.rke2.io/security/hardening_guide/) |
|
||||
| Standalone RKE2 | Kubernetes v1.25 | CIS v1.23 | [Link](https://docs.rke2.io/security/cis_self_assessment123/) | [Link](https://docs.rke2.io/security/hardening_guide/) |
|
||||
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|
||||
|------|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Rancher provisioned RKE2 | Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke2-hardening-guide.md) |
|
||||
| Rancher provisioned RKE2 | Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](rke2-hardening-guide.md) |
|
||||
| Rancher provisioned RKE2 | Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md) | [Link](rke2-hardening-guide.md) |
|
||||
| Standalone RKE2 | Kubernetes v1.25 | CIS v1.23 | [Link](https://docs.rke2.io/security/cis_self_assessment123) | [Link](https://docs.rke2.io/security/hardening_guide) |
|
||||
|
||||
### K3s Guides
|
||||
|
||||
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|
||||
|---------------------------------|------------------------------|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------|
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.21 | CIS v1.20 | [CIS v1.20](../reference-guides/rancher-security/hardening-guides/k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) and [CIS v1.23](../reference-guides/rancher-security/hardening-guides/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide.md) |
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.22 up to v1.24 | CIS v1.23 | [CIS v1.20](../reference-guides/rancher-security/hardening-guides/k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) and [CIS v1.23](../reference-guides/rancher-security/hardening-guides/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide.md) |
|
||||
| Standalone K3s | Kubernetes v1.22 up to v1.24 | CIS v1.23 | [Link](https://docs.k3s.io/security/self-assessment) | [Link](https://docs.k3s.io/security/hardening-guide) |
|
||||
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|
||||
|------|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](k3s-hardening-guide.md) |
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](k3s-hardening-guide.md) |
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md) | [Link](k3s-hardening-guide.md) |
|
||||
| Standalone K3s | Kubernetes v1.22 up to v1.24 | CIS v1.23 | [Link](https://docs.k3s.io/security/self-assessment) | [Link](https://docs.k3s.io/security/hardening-guide) |
|
||||
|
||||
## Rancher with SELinux
|
||||
|
||||
[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a kernel module that adds extra access controls and security tools to Linux. Historically used by government agencies, SELinux is now industry-standard. SELinux is enabled by default on RHEL and CentOS.
|
||||
|
||||
To use Rancher with SELinux, we recommend [installing](selinux-rpm.md#installing-the-rancher-selinux-rpm) the `rancher-selinux` RPM.
|
||||
To use Rancher with SELinux, we recommend [installing](../reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md) the `rancher-selinux` RPM.
|
||||
|
||||
|
||||
+52
-336
@@ -8,39 +8,41 @@ This document provides prescriptive guidance for how to harden an RKE cluster in
|
||||
This hardening guide describes how to secure the nodes in your cluster. We recommended that you follow this guide before you install Kubernetes.
|
||||
:::
|
||||
|
||||
This hardening guide is intended to be used for RKE clusters and associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
|
||||
This hardening guide is intended to be used for RKE clusters and is associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 up to v1.25 |
|
||||
|
||||
For more details on how to evaluate a hardened RKE cluster against the official CIS benchmark, refer to the RKE self-assessment guides for specific CIS benchmark versions.
|
||||
:::note
|
||||
At the time of writing, the official Kubernetes v1.25 benchmark is still in draft status by CIS. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters. Due to that, the CIS checks 5.2.3, 5.2.4, 5.2.5 and 5.2.6 might fail.
|
||||
:::
|
||||
|
||||
For more details on how to evaluate a hardened RKE cluster against the official CIS benchmark, refer to the RKE self-assessment guides for specific Kubernetes and CIS benchmark versions.
|
||||
|
||||
## Host-level requirements
|
||||
|
||||
### Configure Kernel Runtime Parameters
|
||||
|
||||
The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
|
||||
The following `sysctl` configuration is recommended for all nodes types in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
|
||||
|
||||
```ini
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
kernel.keys.root_maxbytes=25000000
|
||||
```
|
||||
|
||||
Run `sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
|
||||
|
||||
### Configure `etcd` user and group
|
||||
|
||||
A user account and group for the **etcd** service is required to be setup before installing RKE.
|
||||
The **uid** and **gid** for the **etcd** user will be used in the RKE **config.yml** to set the proper permissions for files and directories during installation time.
|
||||
A user account and group for the **etcd** service is required to be set up before installing RKE.
|
||||
|
||||
#### Create `etcd` user and group
|
||||
|
||||
To create the **etcd** user and group run the following console commands.
|
||||
The commands below use `52034` for **uid** and **gid** for example purposes.
|
||||
To create the **etcd** user and group run the following console commands.
|
||||
The commands below use `52034` for **uid** and **gid** for example purposes.
|
||||
Any valid unused **uid** or **gid** could also be used in lieu of `52034`.
|
||||
|
||||
```bash
|
||||
@@ -48,7 +50,7 @@ groupadd --gid 52034 etcd
|
||||
useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
|
||||
Update the RKE **config.yml** with the **uid** and **gid** of the **etcd** user:
|
||||
When deploying RKE through its cluster configuration `config.yml` file, update the `uid` and `gid` of the `etcd` user:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
@@ -63,11 +65,11 @@ services:
|
||||
|
||||
#### Set `automountServiceAccountToken` to `false` for `default` service accounts
|
||||
|
||||
Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod.
|
||||
Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
|
||||
Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod.
|
||||
Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
|
||||
The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
|
||||
For each namespace including **default** and **kube-system** on a standard RKE install, the **default** service account must include this value:
|
||||
For each namespace including `default` and `kube-system` on a standard RKE install, the `default` service account must include this value:
|
||||
|
||||
```yaml
|
||||
automountServiceAccountToken: false
|
||||
@@ -83,7 +85,7 @@ metadata:
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
Create a bash script file called `account_update.sh`.
|
||||
Create a bash script file called `account_update.sh`.
|
||||
Be sure to `chmod +x account_update.sh` so the script has execute permissions.
|
||||
|
||||
```bash
|
||||
@@ -94,18 +96,20 @@ for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.n
|
||||
done
|
||||
```
|
||||
|
||||
Execute this script to apply the `account_update.yaml` configuration to `default` service account in all namespaces.
|
||||
|
||||
### Configure Network Policy
|
||||
|
||||
#### Ensure that all Namespaces have Network Policies defined
|
||||
|
||||
Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints.
|
||||
|
||||
Network Policies are namespace scoped. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace. To enforce network policies, a CNI (container network interface) plugin must be enabled. This guide uses [Canal](https://github.com/projectcalico/canal) to provide the policy enforcement. Additional information about CNI providers can be found [here](https://www.suse.com/c/rancher_blog/comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/).
|
||||
Network Policies are namespace scoped. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace. To enforce network policies, a container network interface (CNI) plugin must be enabled. This guide uses [Canal](https://github.com/projectcalico/canal) to provide the policy enforcement. Additional information about CNI providers can be found [here](https://www.suse.com/c/rancher_blog/comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/).
|
||||
|
||||
Once a CNI provider is enabled on a cluster a default network policy can be applied. For reference purposes a **permissive** example is provided below. If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as “isolated”), you can create a policy that explicitly allows all traffic in that namespace. Save the following configuration as `default-allow-all.yaml`. Additional [documentation](https://kubernetes.io/docs/concepts/services-networking/network-policies/) about network policies can be found on the Kubernetes site.
|
||||
|
||||
:::note
|
||||
This `NetworkPolicy` is just an example and is not recommended for production use.
|
||||
:::caution
|
||||
This network policy is just an example and is not recommended for production use.
|
||||
:::
|
||||
|
||||
```yaml
|
||||
@@ -137,79 +141,27 @@ done
|
||||
|
||||
Execute this script to apply the `default-allow-all.yaml` configuration with the **permissive** `NetworkPolicy` to all namespaces.
|
||||
|
||||
|
||||
|
||||
## Known Limitations
|
||||
|
||||
- Rancher **exec shell** and **view logs** for pods are **not** functional in a hardened setup when only a public IP is provided when registering custom nodes. This functionality requires a private IP to be provided when registering the custom nodes.
|
||||
- When setting `default_pod_security_policy_template_id:` to `restricted` or `restricted-noroot`, based on the pod security policies (PSP) [provided](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) by Rancher, Rancher creates **RoleBindings** and **ClusterRoleBindings** on the default service accounts. The CIS v1.6/v1.20/v1.23 check 5.1.5 requires that the default service accounts have no roles or cluster roles bound to it apart from the defaults. In addition, the default service accounts should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
|
||||
## Known Issues
|
||||
|
||||
|
||||
The following are controls that RKE currently does not pass. Each gap will be explained and whether it can be passed through manual operator intervention or if it will be addressed in a future release.
|
||||
|
||||
<Tabs groupId="rke-version">
|
||||
<TabItem value='v1.25 and Newer' default>
|
||||
|
||||
#### CIS v1.23 - Control 5.2.3 - Minimize the admission of containers wishing to share the host process ID namespace (Automated)
|
||||
#### CIS v1.23 - Control 5.2.4 - Minimize the admission of containers wishing to share the host IPC namespace (Automated)
|
||||
#### CIS v1.23 - Control 5.2.5 - Minimize the admission of containers wishing to share the host network namespace (Automated)
|
||||
#### CIS v1.23 - Control 5.2.6 - Minimize the admission of containers with allowPrivilegeEscalation (Automated)
|
||||
|
||||
**Rationale**
|
||||
|
||||
Those controls are defined to evaluate certain PodSecurityPolicy resources in the benchmark, but the PodSecurityPolicy API is removed starting in Kubernetes v1.25, therefore those controls fail in the scan.
|
||||
|
||||
**Remediation**
|
||||
|
||||
Pod Security Admission is configured by setting the Pod Security Admission Configuration Template (PSACT) `rancher-restricted` in the cluster to enforce the restriction on applicable namespaces.
|
||||
Due to the lack of utilizing PSA in the current version of the benchmark, the above controls will not be addressed until an updated version of the benchmark is available.
|
||||
|
||||
|
||||
#### CIS v1.23 - Control 5.3.2 - Ensure that all Namespaces have Network Policies defined (Automated)
|
||||
|
||||
**Rationale**
|
||||
|
||||
The benchmark scanner expects to see one or more `networkpolicy` resources in every namespace.
|
||||
|
||||
**Remediation**
|
||||
|
||||
This is a known issue that rancher-cis-benchmark fails on validating this control. See [issue](https://github.com/rancher/rancher/issues/40648).
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value='v1.22 up to v1.24'>
|
||||
|
||||
#### CIS v1.23 - Control 5.3.2 - Ensure that all Namespaces have Network Policies defined (Automated)
|
||||
|
||||
**Rationale**
|
||||
|
||||
The benchmark scanner expects to see one or more `networkpolicy` resources in every namespace.
|
||||
|
||||
**Remediation**
|
||||
|
||||
This is a known issue that rancher-cis-benchmark fails on validating this control. See [issue](https://github.com/rancher/rancher/issues/40648).
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
- When setting `default_pod_security_policy_template_id:` to `restricted` or `restricted-noroot`, based on the pod security policies (PSP) [provided](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) by Rancher, Rancher creates `RoleBindings` and `ClusterRoleBindings` on the `default` service accounts. The CIS check 5.1.5 requires that the `default` service accounts have no roles or cluster roles bound to it apart from the defaults. In addition, the `default` service accounts should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
|
||||
## Reference Hardened RKE `cluster.yml` Configuration
|
||||
|
||||
The reference `cluster.yml` is used by the RKE CLI that provides the configuration needed to achieve a hardened installation of Rancher Kubernetes Engine (RKE). RKE [documentation](https://rancher.com/docs/rke/latest/en/installation/) provides additional details about the configuration items. This reference `cluster.yml` does not include the required **nodes** directive which will vary depending on your environment. Documentation for node configuration in RKE can be found [here](https://rancher.com/docs/rke/latest/en/config-options/nodes/).
|
||||
The reference `cluster.yml` is used by the RKE CLI that provides the configuration needed to achieve a hardened installation of RKE. RKE [documentation](https://rancher.com/docs/rke/latest/en/installation/) provides additional details about the configuration items. This reference `cluster.yml` does not include the required `nodes` directive which will vary depending on your environment. Documentation for node configuration in RKE can be found [here](https://rancher.com/docs/rke/latest/en/config-options/nodes/).
|
||||
|
||||
<Tabs groupId="rke-version">
|
||||
<TabItem value='v1.25 and Newer' default>
|
||||
<Tabs groupId="rke1-version">
|
||||
<TabItem value="v1.25 and Newer" default>
|
||||
|
||||
:::note
|
||||
If you intend to import an RKE cluster into Rancher, please consult the documentation for how to configure the Pod Security Admission to add Rancher's namespaces to the exemption list.
|
||||
If you intend to import an RKE cluster into Rancher, please consult the [documentation](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md) for how to configure the Pod Security Standards to add Rancher's namespaces to the exemption list.
|
||||
:::
|
||||
|
||||
```yaml
|
||||
# If you intend to deploy Kubernetes in an air-gapped environment,
|
||||
# please consult the documentation on how to configure custom RKE images.
|
||||
nodes: []
|
||||
kubernetes_version: v1.25.6-rancher2-1
|
||||
kubernetes_version: # Define RKE version
|
||||
services:
|
||||
etcd:
|
||||
uid: 52034
|
||||
@@ -253,13 +205,13 @@ addons: |
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value='v1.22 up to v1.24'>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
```yaml
|
||||
# If you intend to deploy Kubernetes in an air-gapped environment,
|
||||
# please consult the documentation on how to configure custom RKE images.
|
||||
nodes: []
|
||||
kubernetes_version: v1.24.10-rancher3-1
|
||||
kubernetes_version: # Define RKE version
|
||||
services:
|
||||
etcd:
|
||||
uid: 52034
|
||||
@@ -267,7 +219,7 @@ services:
|
||||
kube-api:
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
audit_log:
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
@@ -381,118 +333,36 @@ addons: |
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Reference Hardened RKE Template Configuration
|
||||
## Reference Hardened RKE Cluster Template Configuration
|
||||
|
||||
The reference RKE template provides the configuration needed to achieve a hardened installation of Kubernetes. RKE templates are used to provision Kubernetes and define Rancher settings. Follow the Rancher [documentation](../../../pages-for-subheaders/installation-and-upgrade.md) for additional installation and RKE template details.
|
||||
The reference RKE cluster template provides the minimum required configuration to achieve a hardened installation of Kubernetes. RKE templates are used to provision Kubernetes and define Rancher settings. Follow the Rancher [documentation](installation-and-upgrade.md) for additional information about installing RKE and its template details.
|
||||
|
||||
<Tabs groupId="rke-version">
|
||||
<TabItem value='v1.25 and Newer' default>
|
||||
<Tabs groupId="rke1-version">
|
||||
<TabItem value="v1.25 and Newer" default>
|
||||
|
||||
```yaml
|
||||
#
|
||||
#
|
||||
# Cluster Config
|
||||
#
|
||||
#
|
||||
default_pod_security_admission_configuration_template_name: rancher-restricted
|
||||
docker_root_dir: /var/lib/docker
|
||||
enable_cluster_alerting: false
|
||||
enable_cluster_monitoring: false
|
||||
enable_network_policy: true
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
name: ''
|
||||
name: # Define cluster name
|
||||
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 45
|
||||
authentication:
|
||||
strategy: x509
|
||||
dns:
|
||||
nodelocal:
|
||||
ip_address: ''
|
||||
node_selector: null
|
||||
update_strategy: {}
|
||||
enable_cri_dockerd: false
|
||||
ignore_docker_version: true
|
||||
#
|
||||
# # Currently only nginx ingress provider is supported.
|
||||
# # To disable ingress controller, set `provider: none`
|
||||
# # To enable ingress on specific nodes, use the node_selector, eg:
|
||||
# provider: nginx
|
||||
# node_selector:
|
||||
# app: ingress
|
||||
#
|
||||
ingress:
|
||||
default_backend: false
|
||||
default_ingress_class: true
|
||||
http_port: 0
|
||||
https_port: 0
|
||||
provider: nginx
|
||||
kubernetes_version: v1.25.6-rancher2-1
|
||||
monitoring:
|
||||
provider: metrics-server
|
||||
replicas: 1
|
||||
#
|
||||
# If you are using calico on AWS
|
||||
#
|
||||
# network:
|
||||
# plugin: calico
|
||||
# calico_network_provider:
|
||||
# cloud_provider: aws
|
||||
#
|
||||
# # To specify flannel interface
|
||||
#
|
||||
# network:
|
||||
# plugin: flannel
|
||||
# flannel_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
# # To specify flannel interface for canal plugin
|
||||
#
|
||||
# network:
|
||||
# plugin: canal
|
||||
# canal_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
network:
|
||||
mtu: 0
|
||||
options:
|
||||
flannel_backend_type: vxlan
|
||||
plugin: canal
|
||||
rotate_encryption_key: false
|
||||
#
|
||||
# services:
|
||||
# kube-api:
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kube-controller:
|
||||
# cluster_cidr: 10.42.0.0/16
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kubelet:
|
||||
# cluster_domain: cluster.local
|
||||
# cluster_dns_server: 10.43.0.10
|
||||
#
|
||||
strategy: x509|webhook
|
||||
kubernetes_version: # Define RKE version
|
||||
services:
|
||||
scheduler:
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
etcd:
|
||||
backup_config:
|
||||
enabled: true
|
||||
interval_hours: 12
|
||||
retention: 6
|
||||
safe_timestamp: false
|
||||
timeout: 300
|
||||
creation: 12h
|
||||
extra_args:
|
||||
election-timeout: 5000
|
||||
heartbeat-interval: 500
|
||||
retention: 72h
|
||||
snapshot: false
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
kube_api:
|
||||
always_pull_images: false
|
||||
kube-api:
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
@@ -500,134 +370,47 @@ rancher_kubernetes_engine_config:
|
||||
pod_security_policy: false
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
service_node_port_range: 30000-32767
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
fail_swap_on: false
|
||||
generate_serving_certificate: true
|
||||
ssh_agent_auth: false
|
||||
upgrade_strategy:
|
||||
max_unavailable_controlplane: '1'
|
||||
max_unavailable_worker: 10%
|
||||
windows_prefered_cluster: false
|
||||
scheduler:
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value='v1.22 up to v1.24'>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
```yaml
|
||||
#
|
||||
# Cluster Config
|
||||
#
|
||||
default_pod_security_policy_template_id: restricted-noroot
|
||||
docker_root_dir: /var/lib/docker
|
||||
enable_cluster_alerting: false
|
||||
enable_cluster_monitoring: false
|
||||
enable_network_policy: true
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
name: ''
|
||||
name: # Define cluster name
|
||||
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 45
|
||||
authentication:
|
||||
strategy: x509
|
||||
dns:
|
||||
nodelocal:
|
||||
ip_address: ''
|
||||
node_selector: null
|
||||
update_strategy: {}
|
||||
enable_cri_dockerd: false
|
||||
ignore_docker_version: true
|
||||
#
|
||||
# # Currently only nginx ingress provider is supported.
|
||||
# # To disable ingress controller, set `provider: none`
|
||||
# # To enable ingress on specific nodes, use the node_selector, eg:
|
||||
# provider: nginx
|
||||
# node_selector:
|
||||
# app: ingress
|
||||
#
|
||||
ingress:
|
||||
default_backend: false
|
||||
default_ingress_class: true
|
||||
http_port: 0
|
||||
https_port: 0
|
||||
provider: nginx
|
||||
kubernetes_version: v1.24.10-rancher3-1
|
||||
monitoring:
|
||||
provider: metrics-server
|
||||
replicas: 1
|
||||
#
|
||||
# If you are using calico on AWS
|
||||
#
|
||||
# network:
|
||||
# plugin: calico
|
||||
# calico_network_provider:
|
||||
# cloud_provider: aws
|
||||
#
|
||||
# # To specify flannel interface
|
||||
#
|
||||
# network:
|
||||
# plugin: flannel
|
||||
# flannel_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
# # To specify flannel interface for canal plugin
|
||||
#
|
||||
# network:
|
||||
# plugin: canal
|
||||
# canal_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
network:
|
||||
mtu: 0
|
||||
options:
|
||||
flannel_backend_type: vxlan
|
||||
plugin: canal
|
||||
rotate_encryption_key: false
|
||||
#
|
||||
# services:
|
||||
# kube-api:
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kube-controller:
|
||||
# cluster_cidr: 10.42.0.0/16
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kubelet:
|
||||
# cluster_domain: cluster.local
|
||||
# cluster_dns_server: 10.43.0.10
|
||||
#
|
||||
strategy: x509|webhook
|
||||
kubernetes_version: # Define RKE version
|
||||
services:
|
||||
scheduler:
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
etcd:
|
||||
backup_config:
|
||||
enabled: true
|
||||
interval_hours: 12
|
||||
retention: 6
|
||||
safe_timestamp: false
|
||||
timeout: 300
|
||||
creation: 12h
|
||||
extra_args:
|
||||
election-timeout: 5000
|
||||
heartbeat-interval: 500
|
||||
retention: 72h
|
||||
snapshot: false
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
kube_api:
|
||||
always_pull_images: false
|
||||
kube-api:
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
@@ -635,91 +418,24 @@ rancher_kubernetes_engine_config:
|
||||
pod_security_policy: true
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
service_node_port_range: 30000-32767
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
fail_swap_on: false
|
||||
generate_serving_certificate: true
|
||||
ssh_agent_auth: false
|
||||
upgrade_strategy:
|
||||
max_unavailable_controlplane: '1'
|
||||
max_unavailable_worker: 10%
|
||||
windows_prefered_cluster: false
|
||||
scheduler:
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Reference Hardened **cloud-config** Configuration
|
||||
|
||||
A **cloud-config** configuration file is generally used in cloud infrastructure environments to allow for configuration management of compute instances. The reference config configures SUSE Linux Enterprise Server (SLES), openSUSE Leap, Red Hat Enterprise Linux (RHEL) and Ubuntu operating system level settings needed before installing Kubernetes.
|
||||
|
||||
### Reference Hardened **cloud-config** for SUSE Linux Enterprise Server 15 (SLES 15) and openSUSE Leap 15
|
||||
|
||||
```yaml
|
||||
#cloud-config
|
||||
system_info:
|
||||
default_user:
|
||||
groups:
|
||||
- docker
|
||||
write_files:
|
||||
- path: "/etc/sysctl.d/90-kubelet.conf"
|
||||
owner: root:root
|
||||
permissions: '0644'
|
||||
content: |
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
kernel.keys.root_maxbytes=25000000
|
||||
package_update: true
|
||||
ssh_pwauth: false
|
||||
runcmd:
|
||||
# Docker should already be installed in SLES 15 SP3
|
||||
- zypper install docker containerd
|
||||
- systemctl daemon-reload
|
||||
- systemctl enable docker.service
|
||||
- systemctl start --no-block docker.service
|
||||
- sysctl -p /etc/sysctl.d/90-kubelet.conf
|
||||
- groupadd --gid 52034 etcd
|
||||
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
|
||||
### Reference Hardened **cloud-config** for Red Hat Enterprise Linux 8 (RHEL 8) and Ubuntu 20.04 LTS
|
||||
|
||||
```yaml
|
||||
#cloud-config
|
||||
system_info:
|
||||
default_user:
|
||||
groups:
|
||||
- docker
|
||||
write_files:
|
||||
- path: "/etc/sysctl.d/90-kubelet.conf"
|
||||
owner: root:root
|
||||
permissions: '0644'
|
||||
content: |
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
kernel.keys.root_maxbytes=25000000
|
||||
package_update: true
|
||||
ssh_pwauth: false
|
||||
runcmd:
|
||||
# Install Docker from Rancher's Docker installation scripts - github.com/rancher/install-docker
|
||||
- curl https://releases.rancher.com/install-docker/20.10.sh | sh
|
||||
- sysctl -p /etc/sysctl.d/90-kubelet.conf
|
||||
- groupadd --gid 52034 etcd
|
||||
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
## Conclusion
|
||||
|
||||
If you have followed this guide, your RKE custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our RKE self-assessment guides to understand how we verified each of the benchmarks and how you can do the same on your cluster.
|
||||
+26
-124
@@ -8,18 +8,22 @@ This document provides prescriptive guidance for how to harden an RKE2 cluster i
|
||||
This hardening guide describes how to secure the nodes in your cluster. We recommended that you follow this guide before you install Kubernetes.
|
||||
:::
|
||||
|
||||
This hardening guide is intended to be used for RKE2 clusters and associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
|
||||
This hardening guide is intended to be used for RKE2 clusters and is associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.22 up to v1.25 |
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 up to v1.25 |
|
||||
|
||||
For more details on how to evaluate a hardened RKE2 cluster against the official CIS benchmark, refer to the RKE2 self-assessment guides for specific CIS benchmark versions.
|
||||
:::note
|
||||
At the time of writing, the official Kubernetes v1.25 benchmark is still in draft status by CIS. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters. Due to that, the CIS checks 5.2.2, 5.2.3, 5.2.5, 5.2.6, 5.2.7 and 5.2.8 might fail.
|
||||
:::
|
||||
|
||||
For more details on how to evaluate a hardened RKE2 cluster against the official CIS benchmark, refer to the RKE2 self-assessment guides for specific Kubernetes and CIS benchmark versions.
|
||||
|
||||
RKE2 passes a number of the Kubernetes CIS controls without modification, as it applies several security mitigations by default. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
|
||||
|
||||
1. RKE2 will not modify the host operating system. Therefore, you, the operator, must make a few host-level modifications.
|
||||
2. 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 to `cis-1.5`, `cis-1.6`, or `cis-1.23`.
|
||||
1. RKE2 will not modify the host operating system. Therefore, you, the operator, must make a few host-level modifications.
|
||||
2. 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 to `cis-1.23` for v1.25 and newer or `cis-1.6` for v1.24 and older.
|
||||
|
||||
## Host-level requirements
|
||||
|
||||
@@ -58,6 +62,8 @@ sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
|
||||
|
||||
## Kubernetes runtime requirements
|
||||
|
||||
The runtime requirements to pass the CIS Benchmark are centered around pod security, network policies and kernel parameters. Most of this is automatically handled by RKE2 when using a valid `cis-1.xx` profile, but some additional operator intervention is required. 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.
|
||||
@@ -70,22 +76,20 @@ spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.23
|
||||
profile: # use cis-1.23 or cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
The runtime requirements to pass the CIS Benchmark are centered around pod security and network policies. Most of this is automatically handled by RKE2 when using a valid `cis-1.XX` profile, but some additional operator intervention is required. These are outlined in this section.
|
||||
|
||||
### PodSecurity
|
||||
### PodSecurity
|
||||
|
||||
RKE2 always runs with some amount of pod security.
|
||||
|
||||
<Tabs groupId="rke2-version">
|
||||
<TabItem value='v1.25 and Newer' default>
|
||||
<TabItem value="v1.25 and Newer" default>
|
||||
|
||||
On v1.25 and newer, [Pod Security Admission (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) are used for pod security.
|
||||
|
||||
Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.23-profile-hardened` available in Rancher.
|
||||
Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.23-hardened` available in Rancher.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
@@ -94,7 +98,6 @@ spec:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.23
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
When both the `defaultPodSecurityAdmissionConfigurationTemplateName` and `profile` flags are set, Rancher and RKE2 does the following:
|
||||
@@ -106,11 +109,11 @@ When both the `defaultPodSecurityAdmissionConfigurationTemplateName` and `profil
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value='v1.22 up to v1.24'>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
On Kubernetes v1.22 to v1.24, the `PodSecurityPolicy` admission controller is always enabled.
|
||||
On Kubernetes v1.24 and older, the `PodSecurityPolicy` admission controller is always enabled.
|
||||
|
||||
Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.23-profile-hardened` available in Rancher.
|
||||
Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.23-hardened` available in Rancher.
|
||||
|
||||
:::note
|
||||
In the following example the profile is set to `cis-1.6` which is the value defined in the upstream RKE2, but the cluster is actually configured to pass the CIS v1.23 hardened profile
|
||||
@@ -123,7 +126,6 @@ spec:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
|
||||
@@ -142,11 +144,11 @@ The Kubernetes control plane components and critical additions such as CNI, DNS,
|
||||
|
||||
### NetworkPolicies
|
||||
|
||||
When ran with a valid `cis-1.XX` profile, RKE2 will put `NetworkPolicies` in place that passes the CIS Benchmark for Kubernetes' built-in namespaces. These namespaces are: `kube-system`, `kube-public`, `kube-node-lease`, and `default`.
|
||||
When ran with a valid `cis-1.xx` profile, RKE2 will put `NetworkPolicies` in place that passes the CIS Benchmark for Kubernetes' built-in namespaces. These namespaces are: `kube-system`, `kube-public`, `kube-node-lease`, and `default`.
|
||||
|
||||
The `NetworkPolicy` used will only allow pods within the same namespace to talk to each other. The notable exception to this is that it allows DNS requests to be resolved.
|
||||
|
||||
:::caution Operator Intervention Required
|
||||
:::note
|
||||
Operators must manage network policies as normal for additional namespaces that are created.
|
||||
:::
|
||||
|
||||
@@ -204,145 +206,45 @@ rules:
|
||||
- level: None
|
||||
```
|
||||
|
||||
## Known issues
|
||||
|
||||
The following are controls that RKE2 currently does not pass. Each gap will be explained and whether it can be passed through manual operator intervention or if it will be addressed in a future release.
|
||||
|
||||
<Tabs groupId="rke2-version">
|
||||
<TabItem value='v1.25 and Newer' default>
|
||||
|
||||
#### CIS v1.23 - Control 5.2.2 - Minimize the admission of privileged containers (Manual)
|
||||
#### CIS v1.23 - Control 5.2.8 - Minimize the admission of containers with the NET_RAW capability (Automated)
|
||||
|
||||
**Rationale**
|
||||
|
||||
The benchmark scanner expects to see a PodSecurityPolicy resource named `global-restricted-psp` in the cluster. However, the PodSecurityPolicy resource Rancher creates is named `restricted-noroot-psp`.
|
||||
|
||||
**Remediation**
|
||||
|
||||
Create a PodSecurityPolicy resource named `global-restricted-psp` by cloning `restricted-noroot-psp`.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value='v1.22 up to v1.24'>
|
||||
|
||||
#### CIS v1.23 - Control 5.2.2 - Minimize the admission of privileged containers (Manual)
|
||||
#### CIS v1.23 - Control 5.2.3 - Minimize the admission of containers wishing to share the host process ID namespace (Automated)
|
||||
#### CIS v1.23 - Control 5.2.5 - Minimize the admission of containers wishing to share the host network namespace (Automated)
|
||||
#### CIS v1.23 - Control 5.2.6 - Minimize the admission of containers with allowPrivilegeEscalation (Automated)
|
||||
#### CIS v1.23 - Control 5.2.7 - Minimize the admission of root containers (Automated)
|
||||
#### CIS v1.23 - Control 5.2.8 - Minimize the admission of containers with the NET_RAW capability (Automated)
|
||||
|
||||
**Rationale**
|
||||
|
||||
Those controls are defined to evaluate certain PodSecurityPolicy resources in the benchmark, but the PodSecurityPolicy API is removed starting in Kubernetes v1.25, therefore those controls fail in the scan.
|
||||
|
||||
**Remediation**
|
||||
|
||||
Pod Security Admission is configured by setting the Pod Security Admission Configuration Template (PSACT) `rancher-restricted` in the cluster to enforce the restriction on applicable namespaces.
|
||||
Due to the lack of utilizing PSA in the current version of the benchmark, the above controls will not be addressed until an updated version of the benchmark is available.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Reference Hardened RKE2 Template Configuration
|
||||
|
||||
The reference template configuration is used in Rancher to create a hardened RKE2 custom cluster. This reference does not include other required **cluster configuration** directives which will vary depending on your environment.
|
||||
|
||||
|
||||
<Tabs groupId="rke2-version">
|
||||
<TabItem value='v1.25 and Newer' default>
|
||||
<TabItem value="v1.25 and Newer" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: rke2-125-new
|
||||
namespace: fleet-default
|
||||
name: # Define cluster name
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
kubernetesVersion: v1.25.6+rke2r1
|
||||
kubernetesVersion: # Define RKE2 version
|
||||
rkeConfig:
|
||||
etcd:
|
||||
disableSnapshots: false
|
||||
snapshotRetention: 5
|
||||
snapshotScheduleCron: 0 */5 * * *
|
||||
machineGlobalConfig:
|
||||
cni: calico
|
||||
disable-kube-proxy: false
|
||||
etcd-expose-metrics: false
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.23
|
||||
protect-kernel-defaults: true
|
||||
upgradeStrategy:
|
||||
controlPlaneConcurrency: '1'
|
||||
controlPlaneDrainOptions:
|
||||
deleteEmptyDirData: true
|
||||
disableEviction: false
|
||||
enabled: false
|
||||
force: false
|
||||
gracePeriod: -1
|
||||
ignoreDaemonSets: true
|
||||
skipWaitForDeleteTimeoutSeconds: 0
|
||||
timeout: 120
|
||||
workerConcurrency: '1'
|
||||
workerDrainOptions:
|
||||
deleteEmptyDirData: true
|
||||
disableEviction: false
|
||||
enabled: false
|
||||
force: false
|
||||
gracePeriod: -1
|
||||
ignoreDaemonSets: true
|
||||
skipWaitForDeleteTimeoutSeconds: 0
|
||||
timeout: 120
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem value='v1.22 up to 1.24'>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: rke2-v124
|
||||
namespace: fleet-default
|
||||
name: # Define cluster name
|
||||
spec:
|
||||
defaultPodSecurityPolicyTemplateName: restricted-noroot
|
||||
kubernetesVersion: v1.24.10+rke2r1
|
||||
kubernetesVersion: # Define RKE2 version
|
||||
rkeConfig:
|
||||
etcd:
|
||||
disableSnapshots: false
|
||||
snapshotRetention: 5
|
||||
snapshotScheduleCron: 0 */5 * * *
|
||||
machineGlobalConfig:
|
||||
cni: calico
|
||||
disable-kube-proxy: false
|
||||
etcd-expose-metrics: false
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
upgradeStrategy:
|
||||
controlPlaneConcurrency: '1'
|
||||
controlPlaneDrainOptions:
|
||||
deleteEmptyDirData: true
|
||||
disableEviction: false
|
||||
enabled: false
|
||||
force: false
|
||||
gracePeriod: -1
|
||||
ignoreDaemonSets: true
|
||||
skipWaitForDeleteTimeoutSeconds: 0
|
||||
timeout: 120
|
||||
workerConcurrency: '1'
|
||||
workerDrainOptions:
|
||||
deleteEmptyDirData: true
|
||||
disableEviction: false
|
||||
enabled: false
|
||||
force: false
|
||||
gracePeriod: -1
|
||||
ignoreDaemonSets: true
|
||||
skipWaitForDeleteTimeoutSeconds: 0
|
||||
timeout: 120
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
title: K3s Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
---
|
||||
|
||||
This document is a companion to the [K3s Hardening Guide](k3s-hardening-guide.md), which provides prescriptive guidance on how to harden K3s clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
This document is a companion to the [K3s Hardening Guide](../../../../pages-for-subheaders/k3s-hardening-guide.md), which provides prescriptive guidance on how to harden K3s clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
title: K3s Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.24
|
||||
---
|
||||
|
||||
This document is a companion to the [K3s Hardening Guide](k3s-hardening-guide.md), which provides prescriptive guidance on how to harden K3s clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
This document is a companion to the [K3s Hardening Guide](../../../../pages-for-subheaders/k3s-hardening-guide.md), which provides prescriptive guidance on how to harden K3s clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
title: K3s Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.25
|
||||
---
|
||||
|
||||
This document is a companion to the [K3s Hardening Guide](k3s-hardening-guide.md), which provides prescriptive guidance on how to harden K3s clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
This document is a companion to the [K3s Hardening Guide](../../../../pages-for-subheaders/k3s-hardening-guide.md), which provides prescriptive guidance on how to harden K3s clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
+3
-3
@@ -2,7 +2,7 @@
|
||||
title: RKE Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
---
|
||||
|
||||
This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
This document is a companion to the [RKE Hardening Guide](../../../../pages-for-subheaders/rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
@@ -2923,7 +2923,7 @@ in the Kubernetes cluster.
|
||||
### 5.3.2 Ensure that all Namespaces have Network Policies defined (Automated)
|
||||
|
||||
|
||||
**Result:** fail
|
||||
**Result:** pass
|
||||
|
||||
**Remediation:**
|
||||
Follow the documentation and create NetworkPolicy objects as you need them.
|
||||
@@ -2968,7 +2968,7 @@ echo "true"
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (Forbidden): networkpolicies.networking.k8s.io is forbidden: User "system:serviceaccount:cis-operator-system:cis-serviceaccount" cannot list resource "networkpolicies" in API group "networking.k8s.io" in the namespace "cattle-fleet-system" false
|
||||
true
|
||||
```
|
||||
|
||||
## 5.4 Secrets Management
|
||||
+3
-3
@@ -2,7 +2,7 @@
|
||||
title: RKE Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.24
|
||||
---
|
||||
|
||||
This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
This document is a companion to the [RKE Hardening Guide](../../../../pages-for-subheaders/rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
@@ -2923,7 +2923,7 @@ in the Kubernetes cluster.
|
||||
### 5.3.2 Ensure that all Namespaces have Network Policies defined (Automated)
|
||||
|
||||
|
||||
**Result:** fail
|
||||
**Result:** pass
|
||||
|
||||
**Remediation:**
|
||||
Follow the documentation and create NetworkPolicy objects as you need them.
|
||||
@@ -2968,7 +2968,7 @@ echo "true"
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (Forbidden): networkpolicies.networking.k8s.io is forbidden: User "system:serviceaccount:cis-operator-system:cis-serviceaccount" cannot list resource "networkpolicies" in API group "networking.k8s.io" in the namespace "cattle-fleet-system" false
|
||||
true
|
||||
```
|
||||
|
||||
## 5.4 Secrets Management
|
||||
+3
-3
@@ -2,7 +2,7 @@
|
||||
title: RKE Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.25
|
||||
---
|
||||
|
||||
This document is a companion to the [RKE Hardening Guide](rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
This document is a companion to the [RKE Hardening Guide](../../../../pages-for-subheaders/rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
@@ -2924,7 +2924,7 @@ in the Kubernetes cluster.
|
||||
### 5.3.2 Ensure that all Namespaces have Network Policies defined (Automated)
|
||||
|
||||
|
||||
**Result:** fail
|
||||
**Result:** pass
|
||||
|
||||
**Remediation:**
|
||||
Follow the documentation and create NetworkPolicy objects as you need them.
|
||||
@@ -2969,7 +2969,7 @@ echo "true"
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (Forbidden): networkpolicies.networking.k8s.io is forbidden: User "system:serviceaccount:cis-operator-system:cis-serviceaccount" cannot list resource "networkpolicies" in API group "networking.k8s.io" in the namespace "cattle-fleet-system" false
|
||||
true
|
||||
```
|
||||
|
||||
## 5.4 Secrets Management
|
||||
+7
-7
@@ -2,7 +2,7 @@
|
||||
title: RKE2 Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
---
|
||||
|
||||
This document is a companion to the [RKE2 Hardening Guide](rke2-hardening-guide.md), which provides prescriptive guidance on how to harden RKE2 clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
This document is a companion to the [RKE2 Hardening Guide](../../../../pages-for-subheaders/rke2-hardening-guide.md), which provides prescriptive guidance on how to harden RKE2 clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
@@ -2814,7 +2814,7 @@ for every namespace which contains user workloads.
|
||||
### 5.2.2 Minimize the admission of privileged containers (Manual)
|
||||
|
||||
|
||||
**Result:** fail
|
||||
**Result:** pass
|
||||
|
||||
**Remediation:**
|
||||
Add policies to each namespace in the cluster which has user workloads to restrict the
|
||||
@@ -2835,7 +2835,7 @@ kubectl get psp global-restricted-psp -o json | jq -r '.spec.runAsUser.rule'
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (NotFound): podsecuritypolicies.policy "global-restricted-psp" not found
|
||||
MustRunAsNonRoot
|
||||
```
|
||||
|
||||
### 5.2.3 Minimize the admission of containers wishing to share the host process ID namespace (Automated)
|
||||
@@ -2976,7 +2976,7 @@ kubectl get psp -o json | jq .items[] | jq -r 'select((.spec.allowPrivilegeEscal
|
||||
### 5.2.8 Minimize the admission of containers with the NET_RAW capability (Automated)
|
||||
|
||||
|
||||
**Result:** fail
|
||||
**Result:** pass
|
||||
|
||||
**Remediation:**
|
||||
Add policies to each namespace in the cluster which has user workloads to restrict the
|
||||
@@ -2997,7 +2997,7 @@ kubectl get psp global-restricted-psp -o json | jq -r .spec.requiredDropCapabili
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (NotFound): podsecuritypolicies.policy "global-restricted-psp" not found
|
||||
ALL
|
||||
```
|
||||
|
||||
### 5.2.9 Minimize the admission of containers with added capabilities (Automated)
|
||||
@@ -3078,7 +3078,7 @@ kubectl get pods --all-namespaces --selector='k8s-app in (calico-node, canal, ci
|
||||
### 5.3.2 Ensure that all Namespaces have Network Policies defined (Automated)
|
||||
|
||||
|
||||
**Result:** warn
|
||||
**Result:** pass
|
||||
|
||||
**Remediation:**
|
||||
Follow the documentation and create NetworkPolicy objects as you need them.
|
||||
@@ -3123,7 +3123,7 @@ echo "true"
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (Forbidden): networkpolicies.networking.k8s.io is forbidden: User "system:serviceaccount:cis-operator-system:cis-serviceaccount" cannot list resource "networkpolicies" in API group "networking.k8s.io" in the namespace "kube-system" false
|
||||
true
|
||||
```
|
||||
|
||||
## 5.4 Secrets Management
|
||||
+7
-7
@@ -2,7 +2,7 @@
|
||||
title: RKE2 Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.24
|
||||
---
|
||||
|
||||
This document is a companion to the [RKE2 Hardening Guide](rke2-hardening-guide.md), which provides prescriptive guidance on how to harden RKE2 clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
This document is a companion to the [RKE2 Hardening Guide](../../../../pages-for-subheaders/rke2-hardening-guide.md), which provides prescriptive guidance on how to harden RKE2 clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
@@ -2814,7 +2814,7 @@ for every namespace which contains user workloads.
|
||||
### 5.2.2 Minimize the admission of privileged containers (Manual)
|
||||
|
||||
|
||||
**Result:** fail
|
||||
**Result:** pass
|
||||
|
||||
**Remediation:**
|
||||
Add policies to each namespace in the cluster which has user workloads to restrict the
|
||||
@@ -2835,7 +2835,7 @@ kubectl get psp global-restricted-psp -o json | jq -r '.spec.runAsUser.rule'
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (NotFound): podsecuritypolicies.policy "global-restricted-psp" not found
|
||||
MustRunAsNonRoot
|
||||
```
|
||||
|
||||
### 5.2.3 Minimize the admission of containers wishing to share the host process ID namespace (Automated)
|
||||
@@ -2976,7 +2976,7 @@ kubectl get psp -o json | jq .items[] | jq -r 'select((.spec.allowPrivilegeEscal
|
||||
### 5.2.8 Minimize the admission of containers with the NET_RAW capability (Automated)
|
||||
|
||||
|
||||
**Result:** fail
|
||||
**Result:** pass
|
||||
|
||||
**Remediation:**
|
||||
Add policies to each namespace in the cluster which has user workloads to restrict the
|
||||
@@ -2997,7 +2997,7 @@ kubectl get psp global-restricted-psp -o json | jq -r .spec.requiredDropCapabili
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (NotFound): podsecuritypolicies.policy "global-restricted-psp" not found
|
||||
ALL
|
||||
```
|
||||
|
||||
### 5.2.9 Minimize the admission of containers with added capabilities (Automated)
|
||||
@@ -3078,7 +3078,7 @@ kubectl get pods --all-namespaces --selector='k8s-app in (calico-node, canal, ci
|
||||
### 5.3.2 Ensure that all Namespaces have Network Policies defined (Automated)
|
||||
|
||||
|
||||
**Result:** warn
|
||||
**Result:** pass
|
||||
|
||||
**Remediation:**
|
||||
Follow the documentation and create NetworkPolicy objects as you need them.
|
||||
@@ -3123,7 +3123,7 @@ echo "true"
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (Forbidden): networkpolicies.networking.k8s.io is forbidden: User "system:serviceaccount:cis-operator-system:cis-serviceaccount" cannot list resource "networkpolicies" in API group "networking.k8s.io" in the namespace "kube-system" false
|
||||
true
|
||||
```
|
||||
|
||||
## 5.4 Secrets Management
|
||||
+3
-3
@@ -2,7 +2,7 @@
|
||||
title: RKE2 Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.25
|
||||
---
|
||||
|
||||
This document is a companion to the [RKE2 Hardening Guide](rke2-hardening-guide.md), which provides prescriptive guidance on how to harden RKE2 clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
This document is a companion to the [RKE2 Hardening Guide](../../../../pages-for-subheaders/rke2-hardening-guide.md), which provides prescriptive guidance on how to harden RKE2 clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
@@ -3078,7 +3078,7 @@ kubectl get pods --all-namespaces --selector='k8s-app in (calico-node, canal, ci
|
||||
### 5.3.2 Ensure that all Namespaces have Network Policies defined (Automated)
|
||||
|
||||
|
||||
**Result:** warn
|
||||
**Result:** true
|
||||
|
||||
**Remediation:**
|
||||
Follow the documentation and create NetworkPolicy objects as you need them.
|
||||
@@ -3123,7 +3123,7 @@ echo "true"
|
||||
**Returned Value**:
|
||||
|
||||
```console
|
||||
Error from server (Forbidden): networkpolicies.networking.k8s.io is forbidden: User "system:serviceaccount:cis-operator-system:cis-serviceaccount" cannot list resource "networkpolicies" in API group "networking.k8s.io" in the namespace "kube-system" false
|
||||
true
|
||||
```
|
||||
|
||||
## 5.4 Secrets Management
|
||||
Reference in New Issue
Block a user