Kubernetes Security Basics: RBAC, Network Policies, and Pod Security

The Kubernetes Security Challenge

Kubernetes is incredibly powerful, but it's also complex. Out of the box, Kubernetes is configured for ease of use, not security. This means:

• Pods can communicate with any other pod by default


• Service accounts have more permissions than they need


• Containers often run as root


• Workloads aren't isolated from each other

Let's fix that with the three pillars of Kubernetes security.

Pillar 1: RBAC (Role-Based Access Control)

RBAC controls who can do what in your cluster. It's built around four concepts:

Roles and ClusterRoles

A Role defines permissions within a namespace. A ClusterRole defines permissions cluster-wide.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
apiGroups: [""]

  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBindings and ClusterRoleBindings

A RoleBinding grants a Role to a user or service account. A ClusterRoleBinding does the same for ClusterRoles.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
kind: ServiceAccount

  name: my-app
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RBAC Best Practices

• Follow least privilege — Grant only the permissions needed


• Use namespaces — Scope permissions to specific namespaces


• Audit regularly — Review who has access to what


• Avoid cluster-admin — Almost no one needs cluster-admin


• Use service accounts — Don't share credentials between workloads

Pillar 2: Network Policies

By default, all pods can talk to all other pods. Network Policies let you control traffic flow.

Basic Network Policy

This policy allows traffic to the api pods only from pods with the label role: frontend:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

Default Deny Policy

Start with a default deny policy and explicitly allow what's needed:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Network Policy Best Practices

• Start with default deny — Then allow specific traffic


• Use labels consistently — Network policies rely on labels


• Control egress too — Limit outbound connections


• Test thoroughly — Misconfigured policies break applications


• Use a CNI that supports policies — Not all do (Calico, Cilium work)

Pillar 3: Pod Security

Pod Security controls what pods can do at runtime.

Pod Security Standards

Kubernetes defines three built-in security profiles:

• Privileged — No restrictions (avoid this)


• Baseline — Prevents known privilege escalations


• Restricted — Heavily restricted, best for security

Enforcing Pod Security

Use Pod Security Admission to enforce standards at the namespace level:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Security Context

Configure security settings at the pod and container level:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

Pod Security Best Practices

• Run as non-root — Most containers don't need root


• Use read-only filesystems — Prevents runtime modifications


• Drop all capabilities — Add back only what's needed


• Disable privilege escalation — Prevent container breakout


• Use minimal images — Less software = smaller attack surface

Putting It All Together

A secure Kubernetes deployment uses all three pillars:

• RBAC — Controls who can manage the cluster


• Network Policies — Controls pod-to-pod communication


• Pod Security — Controls what pods can do at runtime

Quick Wins to Start

If you're just getting started, implement these today:

• Enable Pod Security Admission with "baseline" enforcement


• Create a default-deny network policy in each namespace


• Audit your RBAC bindings for overly permissive roles


• Ensure no pods run as root

Need Expert Help?

Kubernetes security can be complex. If you want help hardening your clusters to meet CIS benchmarks, we can help.