|
| 1 | +--- |
| 2 | +title: Gardener Benchmarking |
| 3 | +weight: 6 |
| 4 | + |
| 5 | +### FIXED, DO NOT MODIFY |
| 6 | +layout: learningpathall |
| 7 | +--- |
| 8 | + |
| 9 | + |
| 10 | +## Gardener Benchmark on GCP SUSE Arm64 VM |
| 11 | +This guide shows how to check the security health of a Gardener Kubernetes cluster running on a GCP SUSE Arm64 VM. We use a tool called **kube-bench**, which checks the cluster against CIS security standards |
| 12 | + |
| 13 | +### Prerequisites |
| 14 | +Before starting, make sure: |
| 15 | +- Gardener Local successfully installed |
| 16 | +- Garden cluster and Shoot cluster in Ready state |
| 17 | +- Docker running |
| 18 | +- Admin access on the VM |
| 19 | + |
| 20 | +**Why this matters:** |
| 21 | +If the cluster is not running or you don’t have admin access, security checks won’t work. |
| 22 | + |
| 23 | +**Verify cluster:** |
| 24 | + |
| 25 | +```console |
| 26 | +kubectl get shoots -n garden |
| 27 | +kubectl get nodes |
| 28 | +``` |
| 29 | +If the cluster is not ready, benchmarking does not make sense yet. |
| 30 | + |
| 31 | +### Download kube-bench |
| 32 | +Download the Arm64-compatible kube-bench binary from the official GitHub release. This tool will be used to check your Kubernetes cluster against CIS security benchmarks. |
| 33 | + |
| 34 | +```console |
| 35 | +curl -L \ |
| 36 | +https://github.com/aquasecurity/kube-bench/releases/download/v0.10.3/kube-bench_0.10.3_linux_arm64.tar.gz |
| 37 | +``` |
| 38 | + |
| 39 | +### Extract and Install kube-bench Configuration |
| 40 | +Extract the downloaded file and place the kube-bench binary and configuration files in standard system locations so the tool can run correctly. |
| 41 | + |
| 42 | +```console |
| 43 | +tar -xvf kube-bench_0.10.3_linux_arm64.tar.gz |
| 44 | +sudo mkdir -p /etc/kube-bench |
| 45 | +sudo cp -r cfg /etc/kube-bench/ |
| 46 | +sudo mv kube-bench /usr/local/bin/ |
| 47 | +``` |
| 48 | + |
| 49 | +**Verify binary:** |
| 50 | + |
| 51 | +Confirm that kube-bench is installed in the correct path and make it executable. This ensures the system can successfully run the benchmarking tool. |
| 52 | + |
| 53 | +```console |
| 54 | +ls -l /usr/local/bin/kube-bench |
| 55 | +``` |
| 56 | + |
| 57 | +**Make it executable:** |
| 58 | + |
| 59 | +Execute kube-bench to scan the Kubernetes cluster and evaluate its security based on industry standard CIS checks. |
| 60 | + |
| 61 | +```console |
| 62 | +sudo chmod +x /usr/local/bin/kube-bench |
| 63 | +``` |
| 64 | + |
| 65 | +### Run kube-bench Benchmark |
| 66 | +Execute kube-bench to scan the Kubernetes cluster and evaluate its security based on industry standard CIS checks. |
| 67 | + |
| 68 | +```console |
| 69 | +sudo /usr/local/bin/kube-bench --config-dir /etc/kube-bench/cfg |
| 70 | +``` |
| 71 | +You should see an output similar to: |
| 72 | + |
| 73 | +```output |
| 74 | +5.2.11 Add policies to each namespace in the cluster which has user workloads to restrict the |
| 75 | +admission of containers that have `.securityContext.windowsOptions.hostProcess` set to `true`. |
| 76 | +
|
| 77 | +5.2.12 Add policies to each namespace in the cluster which has user workloads to restrict the |
| 78 | +admission of containers with `hostPath` volumes. |
| 79 | +
|
| 80 | +5.2.13 Add policies to each namespace in the cluster which has user workloads to restrict the |
| 81 | +admission of containers which use `hostPort` sections. |
| 82 | +
|
| 83 | +5.3.1 If the CNI plugin in use does not support network policies, consideration should be given to |
| 84 | +making use of a different plugin, or finding an alternate mechanism for restricting traffic |
| 85 | +in the Kubernetes cluster. |
| 86 | +
|
| 87 | +5.3.2 Follow the documentation and create NetworkPolicy objects as you need them. |
| 88 | +
|
| 89 | +5.4.1 If possible, rewrite application code to read Secrets from mounted secret files, rather than |
| 90 | +from environment variables. |
| 91 | +
|
| 92 | +5.4.2 Refer to the Secrets management options offered by your cloud provider or a third-party |
| 93 | +secrets management solution. |
| 94 | +
|
| 95 | +5.5.1 Follow the Kubernetes documentation and setup image provenance. |
| 96 | +
|
| 97 | +5.7.1 Follow the documentation and create namespaces for objects in your deployment as you need |
| 98 | +them. |
| 99 | +
|
| 100 | +5.7.2 Use `securityContext` to enable the docker/default seccomp profile in your pod definitions. |
| 101 | +An example is as below: |
| 102 | + securityContext: |
| 103 | + seccompProfile: |
| 104 | + type: RuntimeDefault |
| 105 | +
|
| 106 | +5.7.3 Follow the Kubernetes documentation and apply SecurityContexts to your Pods. For a |
| 107 | +suggested list of SecurityContexts, you may refer to the CIS Security Benchmark for Docker |
| 108 | +Containers. |
| 109 | +
|
| 110 | +5.7.4 Ensure that namespaces are created to allow for appropriate segregation of Kubernetes |
| 111 | +resources and that all new resources are created in a specific namespace. |
| 112 | +
|
| 113 | +
|
| 114 | +== Summary policies == |
| 115 | +4 checks PASS |
| 116 | +4 checks FAIL |
| 117 | +27 checks WARN |
| 118 | +0 checks INFO |
| 119 | +
|
| 120 | +== Summary total == |
| 121 | +43 checks PASS |
| 122 | +38 checks FAIL |
| 123 | +49 checks WARN |
| 124 | +0 checks INFO |
| 125 | +``` |
| 126 | +### Benchmark summary on x86_64 |
| 127 | +To compare the benchmark results, the following results were collected by running the same benchmark on a `x86 - c4-standard-4` (4 vCPUs, 15 GB Memory) x86_64 VM in GCP, running SUSE: |
| 128 | + |
| 129 | +| Category / Subsection | PASS | FAIL | WARN | |
| 130 | +| ------------------------------------------- | :--: | :--: | :--: | |
| 131 | +| **1. Control Plane Security Configuration** | | | | |
| 132 | +| └─ 1.1 Control Plane Node Configuration Files | 0 | 18 | 3 | |
| 133 | +| └─ 1.2 API Server | 9 | 7 | 5 | |
| 134 | +| └─ 1.3 Controller Manager | 5 | 0 | 1 | |
| 135 | +| └─ 1.4 Scheduler | 1 | 1 | 0 | |
| 136 | +| **2. Etcd Node Configuration** | | | | |
| 137 | +| └─ 2.1-2.7 Etcd Node Config | 7 | 0 | 0 | |
| 138 | +| **3. Control Plane Configuration** | | | | |
| 139 | +| └─ 3.1 Authentication and Authorization | 0 | 0 | 3 | |
| 140 | +| └─ 3.2 Logging | 0 | 0 | 2 | |
| 141 | +| **4. Worker Node Security Configuration** | | | | |
| 142 | +| └─ 4.1 Worker Node Configuration Files | 2 | 5 | 4 | |
| 143 | +| └─ 4.2 Kubelet | 5 | 3 | 3 | |
| 144 | +| └─ 4.3 kube-proxy | 1 | 0 | 0 | |
| 145 | +| **5. Kubernetes Policies** | | | | |
| 146 | +| └─ 5.1 RBAC and Service Accounts | 0 | 6 | 7 | |
| 147 | +| └─ 5.2 Pod Security Standards | 0 | 0 | 13 | |
| 148 | +| └─ 5.3 Network Policies and CNI | 0 | 0 | 2 | |
| 149 | +| └─ 5.4 Secrets Management | 0 | 0 | 2 | |
| 150 | +| └─ 5.5 Extensible Admission Control | 0 | 0 | 1 | |
| 151 | +| └─ 5.7 General Policies | 0 | 0 | 4 | |
| 152 | +| **Total** | 34 | 42 | 54 | |
| 153 | + |
| 154 | +### Benchmark summary on Arm64 |
| 155 | +Results from the earlier run on the `c4a-standard-4` (4 vCPU, 16 GB memory) Arm64 VM in GCP (SUSE): |
| 156 | + |
| 157 | +| Category / Subsection | PASS | FAIL | WARN | |
| 158 | +|-------------------------------------------------|:----:|:----:|:----:| |
| 159 | +| **1. Control Plane Security Configuration** | | | | |
| 160 | +| └─ 1.1 Control Plane Node Configuration Files | 0 | 18 | 3 | |
| 161 | +| └─ 1.2 API Server | 9 | 7 | 5 | |
| 162 | +| └─ 1.3 Controller Manager | 5 | 0 | 1 | |
| 163 | +| └─ 1.4 Scheduler | 1 | 1 | 0 | |
| 164 | +| **2. Etcd Node Configuration** | | | | |
| 165 | +| └─ 2.1-2.7 Etcd Node Config | 7 | 0 | 0 | |
| 166 | +| **3. Control Plane Configuration** | | | | |
| 167 | +| └─ 3.1 Authentication and Authorization | 0 | 0 | 3 | |
| 168 | +| └─ 3.2 Logging | 1 | 0 | 1 | |
| 169 | +| **4. Worker Node Security Configuration** | | | | |
| 170 | +| └─ 4.1 Worker Node Configuration Files | 2 | 5 | 4 | |
| 171 | +| └─ 4.2 Kubelet | 5 | 3 | 3 | |
| 172 | +| └─ 4.3 kube-proxy | 1 | 0 | 0 | |
| 173 | +| **5. Kubernetes Policies** | | | | |
| 174 | +| └─ 5.1 RBAC and Service Accounts | 2 | 4 | 6 | |
| 175 | +| └─ 5.2 Pod Security Standards | 2 | 0 | 9 | |
| 176 | +| └─ 5.3 Network Policies and CNI | 0 | 0 | 2 | |
| 177 | +| └─ 5.4 Secrets Management | 0 | 0 | 2 | |
| 178 | +| └─ 5.5 Extensible Admission Control | 0 | 0 | 1 | |
| 179 | +| └─ 5.7 General Policies | 0 | 0 | 4 | |
| 180 | +| **Total** | 43 | 38 | 49 | |
| 181 | + |
| 182 | +### Gardener benchmarking comparison on Arm64 and x86_64 |
| 183 | + |
| 184 | +- **Strong Baseline Security:** The cluster passed **43 CIS checks**, indicating a solid foundational security posture out of the box on **Arm64 (C4A)** infrastructure. |
| 185 | +- **Control Plane Hardening Gaps:** A significant number of **FAIL results (38)** are concentrated in **control plane file permissions and API server settings**, which are commonly unmet in development and local/KinD-based setups. |
| 186 | +- **Healthy Etcd Configuration:** All **Etcd-related checks passed (7/7)**, demonstrating correct encryption, access controls, and secure peer/client configuration on **Arm64**. |
| 187 | +- **Worker Node Improvements Needed:** Worker node checks show mixed results, with failures mainly around **kubelet configuration and file permissions**, highlighting clear opportunities for security hardening. |
| 188 | +- **Policy-Level Defaults:** Most **Kubernetes policy checks surfaced as WARN**, reflecting features such as **Pod Security Standards, NetworkPolicies, and admission controls** being optional or not strictly enforced by default. |
| 189 | +- **Arm64 Parity with x86_64:** The overall benchmark profile aligns with typical results seen on **x86_64 clusters**, confirming that **Arm64 introduces no architecture-specific security limitations**. |
| 190 | +- **Production Readiness Signal:** With targeted remediation—especially for **control plane and kubelet configurations**—the **Arm64-based cluster** can achieve **full CIS compliance** while benefiting from **Arm’s cost and energy efficiency**. |
0 commit comments