Guides

Kubernetes Security Basics for Defenders

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Kubernetes security basics for defenders: control who can change the cluster (RBAC), isolate workloads (namespaces and network policy), keep secrets out of images, run containers with least privilege, and watch the API audit log — so one bad pod does not become a whole-cluster incident.

Identity → RBAC → Admission → Runtime (pod security) → Network → Audit
Exposed dashboard = “please crypto-mine me” era lessons
kubectl = production change control, not a toy

What do I need before this guide?

• Cloud shared duty mindset: Cloud IAM least privilege.
• Optional containers context from supply chain: SBOM / dependency / secrets.
• Optional Zero Trust flavour: Zero Trust explained simply.

What are we protecting in a cluster?

Layers beginners should name in interviews:

1. Cluster identity — who can talk to the API server.
2. RBAC — which verbs on which resources.
3. Admission / policy — block privileged pods before they schedule (vendor tools vary).
4. Workload hardening — non-root, read-only root FS themes, seccomp where supported.
5. Network — east-west limits so a web pod cannot freely hit the metadata service or payroll DB.
6. Secrets & supply chain — image provenance, SCA, secret managers.
7. Detection — audit logs, runtime sensors, SIEM alerts on weird exec / secret reads.

Educational warning: practise on minikube / kind / a cloud sandbox you own. Do not “test RBAC” on a shared company prod cluster without change tickets — you can lock teams out or expose services.

Real incident: Tesla Kubernetes cryptojacking (2018)

Public reporting on a 2018 Tesla cloud incident described an unauthenticated Kubernetes dashboard exposure that attackers used to run cryptocurrency mining workloads. The lasting lesson for every student cluster: management UIs and API endpoints are crown jewels. Convenience “open for debugging” kills.

Takeaways (vertical):

1. What happened — cluster console exposure leading to abusive workloads (mining) in public analyses.
2. What went wrong (theme) — internet-facing admin surface without adequate authentication.
3. Care-take — private control planes; SSO + MFA; no anonymous dashboard.
4. Care-take — network policies and egress controls limit miner profit even after a foothold.
5. Care-take — alert on sudden CPU / new Deployments in sensitive namespaces.
6. Bonus parallel — Capital One–era cloud identity lessons: metadata and over-broad roles still matter beside K8s RBAC.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Find open dashboards, kubelets, or mis-bound Services of type LoadBalancer.
• Steal service account tokens from mounts inside a compromised pod (high-level).
• Escape or widen access when pods run privileged (themes — not a how-to).
• Abuse CI credentials that can kubectl apply to prod.

Blue Team — defend, detect, respond

• SSO to the API; short-lived creds; no long-lived kubeconfig on laptops without disk encryption + MFA.
• Pod security standards / policies that deny privileged by default.
• Secrets in KMS-backed stores; rotate on leak.
• Audit log → SIEM: exec, secret get bursts, new ClusterRoleBindings.
• Break-glass admin with tickets and alarms.

How do I apply basics step by step?

Step 1 — Lock the front door

1. Confirm the API server endpoint is not anonymously usable from the internet.
2. Remove or strongly authenticate any dashboard.
3. Restrict kubectl access via your identity provider groups.

Step 2 — RBAC least privilege

1. Inventory ClusterRoles and RoleBindings.
2. Replace standing cluster-admin for humans with namespace-scoped roles.
3. CI bots get only the verbs they need (often apply in one namespace).

Step 3 — Namespace and network boundaries

1. One team / app per namespace when practical.
2. Default-deny ingress/egress policies; open only documented paths.
3. Keep kube-system and ingress controllers tightly watched.

Step 4 — Workload hardening

1. runAsNonRoot, drop capabilities, read-only root filesystem where apps allow.
2. CPU/memory limits — noisy neighbours and fork bombs hurt everyone.
3. Prefer distroless or minimal base images from maintained sources.

Step 5 — Secrets and images

1. No passwords in environment variables committed to git.
2. Image scan in CI; block critical fixable CVEs on prod paths.
3. Pin versions; record SBOMs for cluster images you ship.

Step 6 — Detect and practise (lab)

1. On a local kind/minikube cluster you own, create a read-only role and prove AccessDenied on delete.
2. Turn on audit logging (or provider equivalent) and ship a sample to your lab SIEM.
3. Deploy a deliberate too-open Service only inside host-only / local networking — never on a public VPS without auth.
4. Tabletop: “dashboard open for 2 hours — revoke, rotate, review Deployments”.

Starter policy themes (descriptive, not a paste-blind prod YAML)

1. Deny privileged containers in app namespaces.
2. Deny hostNetwork / hostPID for normal apps.
3. Allow egress to approved CIDRs / FQDNs only (mesh or DNS policy depending on stack).
4. Require labels: owner, app, data-class — so SOC knows who to page.

Managed Kubernetes vs DIY — shared habits

1. Cloud-managed control planes still need your RBAC, network policies and workload hardening.
2. Node OS patching may be shared with the provider — read their shared-responsibility doc for your service.
3. Store kubeconfigs in a password manager or SSO flow; never commit them to git.
4. Treat every LoadBalancer / public Ingress as an internet service with authn/authz and rate limits.
5. Keep a paper (or wiki) map: namespace → owner → data class → on-call.

Care-take — cluster habits that age well

1. GitOps with reviews for prod manifests — no cowboy kubectl on Friday night without tickets.
2. Separate prod cluster accounts / projects from personal experiments.
3. Rotate service account tokens and cloud node roles on a schedule.
4. Backup etcd / control plane recovery tested like any DR plan.
5. Patch nodes and middlewares; old kube versions are CVE magnets.
6. When someone leaves: revoke IdP group that gates cluster access first.

How do I fix common Kubernetes security mistakes?

Ghabru naka 😅 — these are the usual ones: