Kubernetes security
Assess orchestration authority, workload identities, admission rules, secrets, and enforced network controls rather than treating namespaces as complete isolation.
What it means
Kubernetes security covers the API, control plane, nodes, workloads, identities, and network relationships used to run containers. Access to orchestration features can create more authority than access to a single workload. Review effective permissions and workload isolation rather than relying on namespace names alone.
A practical example
A team restricts who can create privileged workloads and which service accounts each application uses. It protects the management API, reviews secrets access, and tests network restrictions between services that should not communicate.
What to check
Review role bindings, workload admission policy, node hardening, secrets handling, and API audit visibility. Confirm that networking and policy mechanisms actually enforce the intended controls.
A common pitfall
A namespace is an organizational grouping, not a complete security boundary by itself. Broad roles or permissive workload settings can cross the separation the team expects.
Think it through
Why is permission to create workloads security-sensitive?
Answer: A caller may choose identities, mounts, and privilege settings that provide access beyond an ordinary application's intended scope.
Creating a workload can grant indirect authority
Imagine a fictional academy lets a deployment system create application workloads. Depending on the cluster's controls, workload creation might let the caller select service accounts, mount sensitive resources, or request powerful host interactions. Review these indirect effects rather than reading a role's name alone.
A narrow business purpose should map to an appropriate permission set and admission policy. The deployment system does not need unrestricted cluster administration simply because it releases one application.
Namespace organization and security differ
Suppose two teaching teams use separate namespaces. That separation can help organize objects, but effective roles, node sharing, secrets, and networking determine the actual boundary. A broad role binding can defeat an expected separation.
Network policy also needs a supporting implementation and correct configuration. A policy object in source control is not by itself proof that the deployed traffic restriction is enforced.
Workloads and control plane need different evidence
An API audit event can show a configuration operation while container logs show application behavior. An investigation may need both to explain how a new workload appeared and what it later did. Preserve identities, object references, and time context appropriately.
Secrets handling deserves the same concrete review: who can read values, who can cause a workload to receive them, and what occurs during replacement or revocation. Merely storing a value in an object named Secret does not answer those questions.
For a paper exercise, define an application team, a deployment identity, and a cluster administrator. List the minimum operations for each and one prohibited operation to validate. Add a workload that requests an unintended service account and state which control rejects it. This connects permission design, admission, runtime isolation, and observable evidence into a testable orchestration model.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Kubernetes Security