Securing Kubernetes Beyond the Default Install
Spinning up a Kubernetes cluster is the easy part. The real challenge begins when you realize that out-of-the-box configurations prioritize “it just works” over “it’s locked down.” I have seen many teams leave their API servers exposed or use default service account tokens simply because they didn’t know which of the 100+ security toggles to flip.
To automate the audit process, we use two industry-standard tools: kube-bench and kube-hunter. While both focus on security, they tackle the problem from different angles. One checks your blueprints, while the other tries to pick your locks. Understanding how to combine them is the secret to a truly hardened environment.
The Inspector vs. The Attacker
When I audit a cluster, I look at it through two lenses: configuration hygiene and active exploitability.
Static Configuration Auditing (kube-bench)
Think of kube-bench as a building inspector. It compares your cluster settings against the Center for Internet Security (CIS) Kubernetes Benchmark. It checks for specific flaws, such as whether your etcd database is encrypted at rest or if the API server allows --anonymous-auth. It is a checklist-driven tool that ensures you followed the manual during installation.
Active Vulnerability Scanning (kube-hunter)
Kube-hunter acts more like a penetration tester. It doesn’t care what your config files say; it cares if it can actually break in. It probes for open ports like 10250 (Kubelet API) or 2379 (etcd) and looks for misconfigured dashboards. You can run it from outside to see what a hacker sees, or from inside a pod to simulate a malicious container trying to move laterally through your network.
Pros & Cons
kube-bench
- Pros: This is the gold standard for compliance. If a client asks for a CIS report, this tool provides the exact “PASS/FAIL” data they need. It even gives you the specific shell commands to fix each failure.
- Cons: It only sees what is on the disk. It won’t detect a zero-day vulnerability in your application code or a sneaky runtime threat.
kube-hunter
- Pros: It uncovers real-world attack paths. It identifies critical risks like unauthenticated Kubelet ports that static checks might overlook if the process itself is running with insecure defaults.
- Cons: The output can be noisy. Some findings might be “low risk” info disclosures (like version numbers) that aren’t immediate threats, requiring a human to filter the results.
A Professional Workflow
I recommend a hybrid approach. Run kube-bench during your initial setup and after every major version upgrade. This keeps your core infrastructure compliant. Then, integrate kube-hunter into your CI/CD pipeline or run it as a weekly cron job. This helps catch security regressions introduced by new deployments or configuration drift.
When I’m fixing these issues, I often need to generate strong, unique passwords for service accounts. I use the browser-based password generator at toolcraft.app for this. Since it runs entirely in your local browser, no sensitive keys are ever sent over the wire. It’s a small habit that prevents credential leaks during the remediation phase.
Implementation Guide
Step 1: Running kube-bench as a Job
The most reliable way to audit a cluster is running kube-bench as a Kubernetes Job. This gives the tool the necessary permissions to inspect the host’s file system and control plane processes.
# Create the audit job
cat <<EOF > kube-bench-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: kube-bench
spec:
template:
spec:
hostPID: true
containers:
- name: kube-bench
image: aquasec/kube-bench:latest
command: ["kube-bench"]
volumeMounts:
- name: var-lib-etcd
mountPath: /var/lib/etcd
readOnly: true
- name: var-lib-kubelet
mountPath: /var/lib/kubelet
readOnly: true
- name: etc-systemd
mountPath: /etc/systemd
readOnly: true
- name: etc-kubernetes
mountPath: /etc/kubernetes
readOnly: true
restartPolicy: Never
volumes:
- name: var-lib-etcd
hostPath:
path: /var/lib/etcd
- name: var-lib-kubelet
hostPath:
path: /var/lib/kubelet
- name: etc-systemd
hostPath:
path: /etc/systemd
- name: etc-kubernetes
hostPath:
path: /etc/kubernetes
EOF
# Run the audit
kubectl apply -f kube-bench-job.yamlCheck the logs once the pod finishes. You will see a detailed breakdown for the Master Node and Worker Nodes. Look specifically for anything marked [FAIL].
Step 2: Rapid Remediation
The best part of the kube-bench report is the “Remediations” section. It doesn’t just complain; it provides the fix. For example, if it flags 1.2.19 Ensure that the --insecure-port argument is set to 0, it will tell you exactly which manifest file to edit to close that hole.
Step 3: Hunting for Vulnerabilities
With the config files secured, it’s time to test the perimeter. I usually start by running a remote scan from my workstation to see what is visible from the public internet.
# Remote scan via Docker
docker run -it --rm aquasec/kube-hunter --remote 1.2.3.4 # Replace with your Cluster IPTo simulate an “insider threat,” run a pod-level scan. This shows what happens if one of your applications is compromised:
kubectl run kube-hunter --image=aquasec/kube-hunter --restart=Never -- --pod-scanStep 4: Hardening the Perimeter
After reviewing the reports, prioritize your fixes. Start with the “High” severity items from kube-hunter. Most often, this involves updating API Server manifests, restricting access to /metrics, and implementing Network Policies to block pods from talking to the Kubelet API. Hardening is a marathon, not a sprint. Running these tools monthly ensures that minor drifts don’t turn into major breaches.
