Skip to content

Commit 6129de8

Browse files
neogopherneogopher
committed
add the Kubernetes Policies page
1 parent 30f652b commit 6129de8

File tree

1 file changed

+388
-3
lines changed

1 file changed

+388
-3
lines changed

‎vcluster/learn-how-to/hardening-guide/policies.mdx

Lines changed: 388 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,391 @@
11
---
2-
title: Self assessment guide to validate Policies
3-
sidebar_label: Policies
4-
description: Self assessment guide to validate Policies
2+
title: Self assessment guide - Kubernetes Policies
3+
sidebar_label: Kubernetes Policies
4+
description: Self assessment guide to validate Kubernetes policies
55
---
66

7+
This section covers specific security policies for Kubernetes elements:
8+
- RBAC configuration and least privilege access
9+
- Pod Security Standards and security contexts
10+
- Network policies and CNI security
11+
12+
_Assessment focus for vCluster_: This section is directly applicable to vCluster environments. Verification involves ensuring proper RBAC configurations are in place, Pod Security Standards are enforced, and network policies are appropriately configured within the virtual cluster.
13+
14+
## Validation using kube-bench
15+
16+
While most CIS Kubernetes Benchmark checks are not directly verifiable via kube-bench due to vCluster’s virtualized control plane architecture, the Policies section (Section 5) includes controls that are relevant and testable within the virtual cluster environment. These include namespace-level restrictions, pod security standards, and security contexts that can be enforced from within vCluster.
17+
18+
To validate your vCluster’s compliance with this section, you can run kube-bench with a customized kubeconfig pointing to the vCluster API server. The following steps outline the procedure to perform the compliance check:
19+
20+
**Step 1:** Create the vCluster but don't connect to it yet.
21+
```bash
22+
vcluster create my-vcluster --connect=false
23+
```
24+
25+
**Step 2:** Wait for the vCluster to be ready and get its kubeconfig; then connect to it.
26+
```bash
27+
vcluster connect my-vcluster --server `kubectl get svc -n vcluster-my-vcluster my-vcluster -o jsonpath='{.spec.clusterIP}'` --print > kubeconfig.yaml && vcluster connect my-vcluster
28+
```
29+
30+
**Step 3:** Create a dedicated namespace for the kube-bench job.
31+
```bash
32+
kubectl create namespace kube-bench
33+
```
34+
35+
**Step 4:** Load the vCluster kubeconfig into a secret.
36+
```bash
37+
kubectl create secret generic my-kubeconfig-secret \
38+
--from-file=kubeconfig=./kubeconfig.yaml \
39+
-n kube-bench
40+
```
41+
42+
**Step 5:** Harden service accounts (recommended)
43+
44+
To maintain compliance with service account token mounting policies, disable automatic token mounting for all service accounts in the cluster:
45+
```bash
46+
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
47+
for sa in $(kubectl get sa -n $ns -o jsonpath='{.items[*].metadata.name}'); do
48+
kubectl patch serviceaccount "$sa" \
49+
-p '{"automountServiceAccountToken": false}' \
50+
-n "$ns"
51+
done
52+
done
53+
```
54+
55+
This is aligned with CIS 5.1.5 & 5.1.6 and ensures that tokens are not unnecessarily exposed.
56+
57+
**Step 6:** Run the kube-bench job.
58+
59+
Deploy a short-lived job to run kube-bench using the kubeconfig you mounted.
60+
```bash
61+
kubectl apply -f - <<EOF
62+
apiVersion: batch/v1
63+
kind: Job
64+
metadata:
65+
name: kube-bench
66+
namespace: kube-bench
67+
spec:
68+
template:
69+
metadata:
70+
labels:
71+
app: kube-bench
72+
spec:
73+
containers:
74+
- command: ["/bin/sh", "-c"]
75+
args: ["kube-bench run --targets policies --benchmark cis-1.10 --include-test-output"]
76+
image: docker.io/aquasec/kube-bench:v0.10.6
77+
name: kube-bench
78+
volumeMounts:
79+
- name: kubeconfig-volume
80+
mountPath: /kube
81+
env:
82+
- name: KUBECONFIG
83+
value: /kube/kubeconfig
84+
automountServiceAccountToken: false
85+
restartPolicy: Never
86+
volumes:
87+
- name: kubeconfig-volume
88+
secret:
89+
secretName: my-kubeconfig-secret
90+
EOF
91+
```
92+
93+
**Step 7:** Once the job completes, inspect the logs for a detailed compliance report:
94+
```
95+
kubectl logs job/kube-bench -n kube-bench
96+
```
97+
98+
The status of the run would be displayed as below:
99+
```bash
100+
...
101+
== Summary total ==
102+
10 checks PASS
103+
1 checks FAIL
104+
24 checks WARN
105+
0 checks INFO
106+
...
107+
```
108+
109+
:::info
110+
The single failure for `Control 5.1.3 – Minimize wildcard use in Roles and ClusterRoles` is expected.
111+
This check often fails because many default or commonly used roles such as `cluster-admin` include wildcards (*) in their verbs, resources, or apiGroups. These wildcards grant broad permissions and violate the principle of least privilege.
112+
113+
To pass this control, audit, and refactor roles to avoid using wildcards where possible. Be aware that some third-party components and tools may require elevated privileges, so a balance between capability and security is often needed.
114+
:::
115+
116+
## 5.1 RBAC and Service Accounts
117+
### 5.1.1 Ensure that the cluster-admin role is only used where required (Manual)
118+
119+
**Result:** PASS
120+
121+
**Remediation:** Identify all clusterrolebindings to the cluster-admin role. Check if they are used and if they need this role or if they could use a role with fewer privileges. Where possible, first bind users to a lower privileged role and then remove the ClusterRoleBinding to the cluster-admin role :
122+
```bash
123+
kubectl delete clusterrolebinding [name]
124+
```
125+
126+
<!-- vale Google.Headings = NO -->
127+
### 5.1.2 Minimize access to secrets (Manual)
128+
<!-- vale Google.Headings = YES -->
129+
130+
**Result:** PASS
131+
132+
**Remediation:** Where possible, remove `get`, `list` and `watch` access to Secret objects in the cluster.
133+
134+
<!-- vale Google.Headings = NO -->
135+
### 5.1.3 Minimize wildcard use in Roles and ClusterRoles (Manual)
136+
<!-- vale Google.Headings = YES -->
137+
138+
**Result:** PASS
139+
140+
**Remediation:** Where possible replace any use of wildcards in clusterroles and roles with specific objects or actions.
141+
142+
<!-- vale Google.Headings = NO -->
143+
### 5.1.4 Minimize access to create pods (Manual)
144+
<!-- vale Google.Headings = YES -->
145+
146+
**Result:** PASS
147+
148+
**Remediation:** Where possible, remove `create` access to `pod` objects in the cluster.
149+
150+
### 5.1.5 Ensure that default service accounts are not actively used. (Manual)
151+
152+
**Result:** PASS
153+
154+
**Remediation:** Create explicit service accounts wherever a Kubernetes workload requires specific access to the Kubernetes API server. Modify the configuration of each default service account to include this value
155+
```
156+
automountServiceAccountToken: false
157+
```
158+
159+
<!-- vale Google.Headings = NO -->
160+
### 5.1.6 Ensure that Service Account Tokens are only mounted where necessary (Manual)
161+
<!-- vale Google.Headings = YES -->
162+
163+
**Result:** PASS
164+
165+
**Remediation:** Modify the definition of pods and service accounts which do not need to mount service account tokens to disable it.
166+
167+
<!-- vale Google.Headings = NO -->
168+
### 5.1.7 Avoid use of system:masters group (Manual)
169+
<!-- vale Google.Headings = YES -->
170+
171+
**Result:** WARN
172+
173+
**Remediation:** Remove the `system:masters` group from all users in the cluster.
174+
175+
<!-- vale Google.Headings = NO -->
176+
### 5.1.8 Limit use of the Bind, Impersonate and Escalate permissions in the Kubernetes cluster (Manual)
177+
<!-- vale Google.Headings = YES -->
178+
179+
**Result:** WARN
180+
181+
**Remediation:** Where possible, remove the impersonate, bind and escalate rights from subjects.
182+
183+
<!-- vale Google.Headings = NO -->
184+
### 5.1.9 Minimize access to create persistent volumes (Manual)
185+
<!-- vale Google.Headings = YES -->
186+
187+
**Result:** WARN
188+
189+
**Remediation:** Where possible, remove `create` access to PersistentVolume objects in the cluster.
190+
191+
### 5.1.10 Minimize access to the proxy sub-resource of nodes (Manual)
192+
193+
**Result:** WARN
194+
195+
**Remediation:** Where possible, remove access to the `proxy` sub-resource of `node` objects.
196+
197+
### 5.1.11 Minimize access to the approval sub-resource of certificatesigningrequests objects (Manual)
198+
199+
**Result:** WARN
200+
201+
**Remediation:** Where possible, remove access to the `approval` sub-resource of `certificatesigningrequest` objects.
202+
203+
<!-- vale Google.Headings = NO -->
204+
### 5.1.12 Minimize access to webhook configuration objects (Manual)
205+
<!-- vale Google.Headings = YES -->
206+
207+
**Result:** WARN
208+
209+
**Remediation:** Where possible, remove access to the `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` objects
210+
211+
### 5.1.13 Minimize access to the service account token creation (Manual)
212+
213+
**Result:** WARN
214+
215+
**Remediation:** Where possible, remove access to the `token` sub-resource of `serviceaccount` objects.
216+
217+
<!-- vale Google.Headings = NO -->
218+
## 5.2 Pod Security Standards
219+
<!-- vale Google.Headings = YES -->
220+
### 5.2.1 Ensure that the cluster has at least one active policy control mechanism in place (Manual)
221+
222+
**Result:** WARN
223+
224+
**Remediation:** Ensure that either Pod Security Admission or an external policy control system is in place for every namespace which contains user workloads.
225+
226+
<!-- vale Google.Headings = NO -->
227+
### 5.2.2 Minimize the admission of privileged containers (Manual)
228+
<!-- vale Google.Headings = YES -->
229+
230+
**Result:** PASS
231+
232+
**Remediation:** Add policies to each namespace in the cluster which has user workloads to restrict the admission of privileged containers.
233+
234+
### 5.2.3 Minimize the admission of containers wishing to share the host process ID namespace (Automated)
235+
236+
**Result:** PASS
237+
238+
**Remediation:** Add policies to each namespace in the cluster which has user workloads to restrict the admission of `hostPID` containers.
239+
240+
### 5.2.4 Minimize the admission of containers wishing to share the host IPC namespace (Automated)
241+
242+
**Result:** PASS
243+
244+
**Remediation:** Add policies to each namespace in the cluster which has user workloads to restrict the admission of `hostIPC` containers.
245+
246+
### 5.2.5 Minimize the admission of containers wishing to share the host network namespace (Automated)
247+
248+
**Result:** PASS
249+
250+
**Remediation:** Add policies to each namespace in the cluster which has user workloads to restrict the admission of `hostNetwork` containers.
251+
252+
<!-- vale Google.Headings = NO -->
253+
### 5.2.6 Minimize the admission of containers with allowPrivilegeEscalation (Automated)
254+
<!-- vale Google.Headings = YES -->
255+
256+
**Result:** PASS
257+
258+
**Remediation:** Add policies to each namespace in the cluster which has user workloads to restrict the admission of containers with `.spec.allowPrivilegeEscalation` set to true.
259+
260+
<!-- vale Google.Headings = NO -->
261+
### 5.2.7 Minimize the admission of root containers (Automated)
262+
<!-- vale Google.Headings = YES -->
263+
264+
**Result:** WARN
265+
266+
**Remediation:** Create a policy for each namespace in the cluster, ensuring that either `MustRunAsNonRoot` or `MustRunAs` with the range of UIDs not including 0, is set.
267+
268+
<!-- vale Google.Headings = NO -->
269+
### 5.2.8 Minimize the admission of containers with the NET_RAW capability (Automated)
270+
<!-- vale Google.Headings = YES -->
271+
272+
**Result:** WARN
273+
274+
**Remediation:** Add policies to each namespace in the cluster which has user workloads to restrict the admission of containers with the `NET_RAW` capability.
275+
276+
### 5.2.9 Minimize the admission of containers with added capabilities (Automated)
277+
278+
**Result:** WARN
279+
280+
**Remediation:** Ensure that `allowedCapabilities` is not present in policies for the cluster unless it is set to an empty array.
281+
282+
### 5.2.10 Minimize the admission of containers with capabilities assigned (Manual)
283+
284+
**Result:** WARN
285+
286+
**Remediation:** Review the use of capabilities in applications running on your cluster. Where a namespace contains applications which do not require any Linux capabities to operate consider adding a PSP which forbids the admission of containers which do not drop all capabilities.
287+
288+
<!-- vale Google.Headings = NO -->
289+
### 5.2.11 Minimize the admission of Windows HostProcess containers (Manual)
290+
<!-- vale Google.Headings = YES -->
291+
292+
**Result:** WARN
293+
294+
**Remediation:** Add policies to each namespace in the cluster which has user workloads to restrict the admission of containers that have .securityContext.windowsOptions.hostProcess set to true.
295+
296+
<!-- vale Google.Headings = NO -->
297+
### 5.2.12 Minimize the admission of HostPath volumes (Manual)
298+
<!-- vale Google.Headings = YES -->
299+
300+
**Result:** WARN
301+
302+
**Remediation:** Add policies to each namespace in the cluster which has user workloads to restrict the admission of containers with `hostPath` volumes.
303+
304+
<!-- vale Google.Headings = NO -->
305+
### 5.2.13 Minimize the admission of containers which use HostPorts (Manual)
306+
<!-- vale Google.Headings = YES -->
307+
308+
**Result:** WARN
309+
310+
**Remediation:** Add policies to each namespace in the cluster which has user workloads to restrict the admission of containers which use `hostPort` sections.
311+
312+
## 5.3 Network Policies and CNI
313+
<!-- vale Google.Headings = NO -->
314+
### 5.3.1 Ensure that the CNI in use supports NetworkPolicies (Manual)
315+
<!-- vale Google.Headings = YES -->
316+
317+
**Result:** WARN
318+
319+
**Remediation:** If the CNI plugin in use does not support network policies, consideration should be given to making use of a different plugin, or finding an alternate mechanism for restricting traffic in the Kubernetes cluster.
320+
321+
<!-- vale Google.Headings = NO -->
322+
### 5.3.2 Ensure that all Namespaces have NetworkPolicies defined (Manual)
323+
<!-- vale Google.Headings = YES -->
324+
325+
**Result:** WARN
326+
327+
**Remediation:** Follow the documentation and create `NetworkPolicy` objects as you need them.
328+
329+
<!-- vale Google.Headings = NO -->
330+
## 5.4 Secrets Management
331+
<!-- vale Google.Headings = YES -->
332+
### 5.4.1 Prefer using Secrets as files over Secrets as environment variables (Manual)
333+
334+
**Result:** WARN
335+
336+
**Remediation:** If possible, rewrite application code to read Secrets from mounted secret files, rather than from environment variables.
337+
338+
<!-- vale Google.Headings = NO -->
339+
### 5.4.2 Consider external secret storage (Manual)
340+
<!-- vale Google.Headings = YES -->
341+
342+
**Result:** WARN
343+
344+
**Remediation:** Refer to the Secrets management options offered by your cloud provider or a third-party secrets management solution.
345+
346+
<!-- vale Google.Headings = NO -->
347+
## 5.5 Extensible Admission Control
348+
### 5.5.1 Configure Image Provenance using ImagePolicyWebhook admission controller (Manual)
349+
<!-- vale Google.Headings = YES -->
350+
351+
**Result:** WARN
352+
353+
**Remediation:** Follow the Kubernetes documentation and setup image provenance.
354+
355+
<!-- vale Google.Headings = NO -->
356+
## 5.7 General Policies
357+
### 5.7.1 Create administrative boundaries between resources using namespaces (Manual)
358+
<!-- vale Google.Headings = YES -->
359+
360+
**Result:** WARN
361+
362+
**Remediation:** Follow the documentation and create namespaces for objects in your deployment as you need them.
363+
364+
<!-- vale Google.Headings = NO -->
365+
### 5.7.2 Ensure that the seccomp profile is set to docker/default in your Pod definitions (Manual)
366+
<!-- vale Google.Headings = YES -->
367+
368+
**Result:** WARN
369+
370+
**Remediation:** Use securityContext to enable the docker/default seccomp profile in your pod definitions. An example is as below:
371+
```yaml
372+
securityContext:
373+
seccompProfile:
374+
type: RuntimeDefault
375+
```
376+
377+
<!-- vale Google.Headings = NO -->
378+
### 5.7.3 Apply SecurityContext to your Pods and Containers (Manual)
379+
<!-- vale Google.Headings = YES -->
380+
381+
**Result:** WARN
382+
383+
**Remediation:** Follow the Kubernetes documentation and apply SecurityContexts to your Pods. For a suggested list of SecurityContexts, you may refer to the CIS Security Benchmark for Docker Containers.
384+
385+
<!-- vale Google.Headings = NO -->
386+
### 5.7.4 The default namespace should not be used (Manual)
387+
<!-- vale Google.Headings = YES -->
388+
389+
**Result:** WARN
390+
391+
**Remediation:** Ensure that namespaces are created to allow for appropriate segregation of Kubernetes resources and that all new resources are created in a specific namespace.

0 commit comments

Comments
 (0)