RBAC decides what a Pod may ask the API server. A securityContext decides what the process may do on the node it runs on. Both matter: most attacks against a cluster start inside a container.

Who the process is

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    runAsNonRoot: true
  containers:
    - name: api
      image: stackmonsters/monster-market-api

Most images run as root by default. runAsUser changes that at launch; runAsNonRoot refuses to start a container whose effective user would be root, which catches the image you forgot. Check from inside:

kubectl exec api -- id

uid=1000 gid=3000 groups=3000

What it may touch

    - name: api
      image: stackmonsters/monster-market-api
      securityContext:
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

An app that writes a cache needs an emptyDir for it; the rest of the filesystem stays as the image shipped it.

Two levels

spec.securityContext on the Pod sets defaults for every container. spec.containers[].securityContext overrides per container and is the only place for capabilities, readOnlyRootFilesystem and allowPrivilegeEscalation.

Reading failures

A runAsNonRoot violation shows as:

NAME   READY   STATUS                       RESTARTS
api    0/1     CreateContainerConfigError   0

with describe pod saying container has runAsNonRoot and image will run as root. A read-only filesystem shows up in the app's own logs: can't create /var/cache/x: Read-only file system.