Course Preview

Kubernetes Security

Kubernetes security protects the cluster control plane, workloads, and data from unauthorized access and compromise. It covers RBAC, network policies, pod security standards, secrets management, image trust, runtime monitoring, and supply chain integrity.

itCloud native tools and technologies | OpenSkills.info

Recommended first:kubernetes-fundamentals

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Don't Panic — Kubernetes Security

Here is the sentence a colleague would give you at the coffee machine: a fresh Kubernetes cluster is not locked down, and it was never going to be. It ships mechanisms with the switches in the off position, and the work is deciding which to turn on. This is less alarming than it sounds and more work than anyone budgets for.

The reason it looks like sprawl is that the pieces live in unrelated APIs. Identity, admission, workload hardening, secrets, network rules, and audit logs are six separate conversations wearing one topic's name. The organizing frame the ecosystem uses is the 4C's — Cloud, Cluster, Container, Code — four nested layers where each one depends on everything outside it. Perfect application code inside a container that can reach the host kernel is not protected code, in the same way that an excellent lock on an open door is still an excellent lock.

Two ideas carry most of the weight. The first is that every interaction with a cluster goes through one component, the API server, and every request crosses three gates in a fixed order: authentication (which identity is this), authorization (is that identity allowed this action, in practice via RBAC, the role-based permission model), and admission (should this object be permitted or altered before it is stored). One front door, three checks, and almost all access control work happens at one of them.

The second is that hardening a workload means restricting what a container may be, not what it may talk to. A container is an ordinary process on a shared machine kernel, and the securityContext — the block of settings on a Pod that governs privilege — decides how much of that kernel it can touch. Because auditing every workload individually is nobody's idea of a career, the Pod Security Standards bundle these settings into three named profiles, and a label on a namespace applies one.

Now the surprise, and it is a good one. A Secret, the object built for sensitive values, is not encrypted. It is base64-encoded, which is a formatting choice, not a security one, and the cluster's datastore holds it in the clear until someone configures encryption at rest. The vocabulary is lying to you slightly. It is worth knowing on day one rather than during an incident review.

Where to go from here. The Cheatsheet is the compressed map — profiles, verbs, and a hardening order to work through. The Practice Reference has the commands, including the ones that ask the cluster what an identity can actually do. Field Notes covers the parts that surprise people who already know the mechanisms. The Exercise builds a throwaway cluster and breaks it on purpose, which is the fastest way to believe any of this.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources