Who can do what in a cluster

Every pod runs as a service account, and every request it makes to the Kubernetes API carries that account’s token. So the question “what can this app do?” is really “what could anyone holding this token do?” - because if the app is ever broken into, that’s exactly who will be holding it.

Out of the box the answer is close to nothing. The RBAC docs are explicit: the default policies give “no permissions to service accounts outside the kube-system namespace” beyond basic API discovery. Every permission an app has, somebody granted.

Four objects, one question

Two rules make RBAC easy to reason about. Permissions are purely additive: there are no deny rules, so access is the union of every binding that applies. And a RoleBinding that points at a ClusterRole grants it only in the binding’s own namespace. That’s how you reuse one definition, such as the built-in view, without handing it out everywhere.

Just enough access

The reporter app logs a real-format error: it may not get the ConfigMap it needs. Find out what it’s allowed to do, make it work, then make it only work. The audit panel re-checks five questions after every command.

The finished shape - one verb, one resource, one name, one namespace - isn’t a classroom ideal. It’s exactly the Role tilt’s own config server runs with:

kind: Role
metadata:
  name: tilt-config-manager
  namespace: tilt-system
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["tilt-config"]
    verbs: ["get", "update", "patch"]

The same platform binds Velero’s service account to cluster-admin. Velero backs up and restores whole namespaces, so it genuinely needs very broad access - which makes its token one of the most valuable in the cluster. (It’s off unless you turn it on in tilt-config.json.)

Who may talk to whom

RBAC governs the API: who may read and change Kubernetes objects. It says nothing about network traffic between pods. That’s NetworkPolicy, and its defaults surprise people: a pod that no policy selects is “non-isolated”, and all inbound and outbound connections are allowed.

Policies are additive, like RBAC: the traffic allowed is the union of every policy that selects a pod. Selecting a pod at all is what isolates it; the rules then list what’s let back in.

What pods may be

The third control is about the pod itself: may it run privileged, mount the host’s disks, run as root? Pod Security admission applies one of three built-in levels - privileged, baseline or restricted - per namespace, with a label:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted

Each level can be applied in three modes. enforce rejects the pod. audit records the violation in the audit log and lets it through. warn shows the user a warning and lets it through. It’s the same audit-versus-enforce trap as Kyverno in the policy and scanning lesson: a namespace labelled audit: restricted looks locked down and admits everything.

SA=system:serviceaccount:tilt-system:tilt-config-server
kubectl auth can-i get configmaps/tilt-config -n tilt-system --as=$SA      # yes
kubectl auth can-i get configmaps/kube-root-ca.crt -n tilt-system --as=$SA  # no: wrong name
kubectl auth can-i get secrets -n tilt-system --as=$SA                    # no
kubectl auth can-i --list -n tilt-system --as=$SA

kubectl get clusterrolebindings -o wide | grep cluster-admin
kubectl get networkpolicy -A
kubectl get ns -L pod-security.kubernetes.io/enforce,pod-security.kubernetes.io/audit