What are the basics of Kubernetes security (RBAC and network policies)?

Kubernetes ships open by default — broad permissions and flat networking — so security is something you must add. The two foundational controls are RBAC and network policies, and a strong answer explains both the mechanism and the default that bites people.

RBAC: who can touch the API

Everything in Kubernetes goes through the API server, so controlling API access is paramount.

• Roles / ClusterRoles define a set of allowed verbs (get, list, create, delete) on resources (pods, secrets). Roles are namespaced; ClusterRoles are cluster-wide.
• RoleBindings / ClusterRoleBindings attach those roles to subjects — users, groups, or service accounts.
• Least privilege: avoid binding anything to cluster-admin, avoid wildcard verbs/resources, and give each workload's service account only what it needs. A pod that can read all secrets is a serious escalation path if compromised.

Network policies: who can talk to whom

By default, any pod can reach any other pod — flat, allow-all networking. A compromised pod can scan and pivot freely.

• Apply a default-deny policy in a namespace, then add explicit ingress/egress rules allowing only the flows your app actually needs (e.g. frontend to backend on one port).
• Critical caveat: network policies are enforced by the CNI plugin. If your CNI doesn't support them (or you assume a no-op default does), the policy silently does nothing — a common reason a "deny" rule appears ignored.

What interviewers look for

Separating RBAC (API authz) from network policies (traffic segmentation), knowing both defaults (broad RBAC, allow-all networking), and the CNI dependency that makes network policies a no-op without support.