Kubernetes security

Every request goes through three checks

Everything in Kubernetes happens through the API server, whether it is kubectl, a CI job or a controller. Each request passes three steps: authentication (who are you?), authorisation (are you allowed to do this?) and admission control (does this object follow our rules, and should it be changed?). Security in a cluster is mostly about getting those three right, plus limiting what running containers can do.

RBAC: who can do what

RBAC (role-based access control) has four objects. A Role lists allowed actions (verbs like get, list, create) on resources inside one namespace. A ClusterRole does the same for the whole cluster, or as a reusable template. A RoleBinding gives a Role, or a ClusterRole, to someone inside one namespace. A ClusterRoleBinding gives a ClusterRole across the whole cluster. The "someone" is a user, a group or a ServiceAccount: an identity for pods and programs rather than people. RBAC only adds permissions; there are no deny rules, so start from nothing and add only what is needed (least privilege).

apiVersion: v1
kind: ServiceAccount
metadata:
  name: canteen-api
  namespace: canteen
automountServiceAccountToken: false   # the app does not call the Kubernetes API
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-config
  namespace: canteen
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: deployer-read-config
  namespace: canteen
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: canteen
roleRef:
  kind: Role
  name: read-config
  apiGroup: rbac.authorization.k8s.io

kubectl auth can-i list secrets -n canteen --as=system:serviceaccount:canteen:ci-deployer
kubectl auth can-i --list -n canteen --as=system:serviceaccount:canteen:ci-deployer
kubectl get clusterrolebindings -o wide | grep cluster-admin     # who has full control?

NetworkPolicies: who can talk to whom

By default every pod can reach every other pod in the cluster. If one pod is compromised, it can talk to your database directly. A NetworkPolicy selects pods by label and lists the traffic allowed in (ingress) or out (egress). The usual pattern is a default deny policy for the namespace, then small "allow" policies for the flows you need. NetworkPolicies only work if your network plugin (CNI) enforces them, for example Calico or Cilium; with a plugin that does not, they are silently ignored.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: canteen
spec:
  podSelector: {}          # every pod in the namespace
  policyTypes: ["Ingress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: canteen
spec:
  podSelector:
    matchLabels:
      app: canteen-api
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: canteen-web
      ports:
        - protocol: TCP
          port: 8080

Pod Security Standards and securityContext

Pod Security Standards define three levels. Privileged has no restrictions (for trusted system components). Baseline blocks known dangerous settings such as privileged containers and host networking. Restricted follows current hardening practice: run as non-root, drop capabilities, no privilege escalation. The built-in Pod Security Admission controller enforces a level per namespace through labels. (The older PodSecurityPolicy was removed in Kubernetes 1.25.)

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

The securityContext in a pod spec is where a container meets those rules. Each setting removes a common way for an attacker to go from "inside the container" to "in control of the node".

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: api
      image: ghcr.io/acme/canteen-api@sha256:4a1f...e9
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

Image policies with admission control

Admission controllers can check every new object against your rules. Policy engines such as Kyverno and OPA Gatekeeper let you write rules like "images must come from ghcr.io/acme", "the :latest tag is not allowed", "every image must have a valid cosign signature" and "every pod needs resource limits". Start new rules in audit mode, fix what they report, then enforce them.

Secrets, patching and audit logs

• Secrets: turn on encryption at rest for Secrets in etcd (the cluster database), restrict who can read them, prefer mounting them as files over environment variables, and source them from a secret manager.
• Patching: Kubernetes supports roughly the three most recent minor versions, each for about a year. Plan upgrades several times a year; managed services such as EKS, AKS and GKE make this easier but do not do it all for you. Patch node images too.
• Audit logs: the API server can record who did what and when. Send these logs to your central logging or SIEM (security information and event management) system and alert on events like new ClusterRoleBindings or reading many Secrets.
• Detection and checks: Falco detects suspicious behaviour inside running containers, and kube-bench checks a cluster against the CIS Kubernetes Benchmark.