RBAC

Exam tasks: 1.1 (manage role-based access control)

The decision: which rule object (Role or ClusterRole) and which binding (RoleBinding or ClusterRoleBinding) give this subject exactly the access the task asks for, in exactly the namespaces it names?

The four objectsCopy Anchor Link

• RBAC is additive only. There are no deny rules; access is the union of every binding that matches.
• A RoleBinding that references a ClusterRole grants those rules only in the binding's namespace. This is the normal way to reuse view, edit or admin per namespace.
• roleRef is immutable. To point a binding at a different role, delete and recreate it.

Writing rulesCopy Anchor Link

A rule combines apiGroups, resources, verbs and optionally resourceNames.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: release-reader
  namespace: orbit
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "deployments/scale"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: [""]                 # core group: pods, services, configmaps, secrets
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["orbit-flags"]  # one named object only
  verbs: ["get", "update"]

• The core group is the empty string "". Deployments, StatefulSets and DaemonSets are in apps, Jobs in batch, Ingress and NetworkPolicy in networking.k8s.io. Run kubectl api-resources -o wide for group and verbs.
• Subresources are separate resources: pods/log for logs, pods/exec for exec (verb create), deployments/scale for scaling, pods/portforward for port-forward.
• resourceNames can't restrict list, watch or create, because those requests carry no object name.
• Verbs are get, list, watch, create, update, patch, delete, deletecollection, plus special ones such as impersonate, bind and escalate.

The imperative way is faster and gets the plurals right:

k create role release-reader -n orbit --verb=get,list,watch --resource=deployments.apps,pods
k create clusterrole node-peeker --verb=get,list --resource=nodes
k create rolebinding rr-ci -n orbit --role=release-reader --serviceaccount=orbit:ci-runner
k create rolebinding view-maya -n orbit --clusterrole=view --user=maya
k create clusterrolebinding peek-ops --clusterrole=node-peeker --group=night-ops

SubjectsCopy Anchor Link

• k create sa ci-runner -n orbit creates one. Set it on a Pod with spec.serviceAccountName. Every namespace has a default ServiceAccount that Pods use when you don't set one.
• k create token ci-runner -n orbit --duration=1h issues a time-bound token for testing or for a kubeconfig.
• Set automountServiceAccountToken: false on the ServiceAccount or the Pod for workloads that never call the API.
• A new human user usually comes from a client certificate. Create a CertificateSigningRequest with signerName: kubernetes.io/kube-apiserver-client, then k certificate approve <name> and read the signed certificate from .status.certificate. The CN becomes the username and each O becomes a group.

Default and aggregated ClusterRolesCopy Anchor Link

admin, edit and view are aggregated: the control plane fills their rules from every ClusterRole carrying a matching label. To let view holders read a custom resource, label a small ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: telescopes-view
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["astro.example.io"]
  resources: ["telescopes"]
  verbs: ["get", "list", "watch"]

You can build your own aggregated role with aggregationRule.clusterRoleSelectors. Leave its rules empty; the controller overwrites them.

Proving it with auth can-iCopy Anchor Link

k auth can-i list deployments -n orbit --as=system:serviceaccount:orbit:ci-runner   # yes
k auth can-i delete pods -n orbit --as=maya                                         # no
k auth can-i get nodes --as=jo --as-group=night-ops                                  # cluster-scoped
k auth can-i --list -n orbit --as=system:serviceaccount:orbit:ci-runner
k auth can-i create pods --subresource=exec -n orbit --as=maya                       # subresources
k auth whoami                                                                        # who am I right now?

can-i get pods/log would ask about a Pod named log. Use --subresource for subresources.

ScenariosCopy Anchor Link

DrillCopy Anchor Link

kubectl config use-context cka-lab1

In namespace harbor-ops (create it if missing), create a ServiceAccount tally. It must be able to get, list and watch Pods and read Pod logs, and to scale Deployments, in harbor-ops only. It must not be able to delete Pods. Use a Role named tally-role and a RoleBinding named tally-bind.

k create ns harbor-ops
k create sa tally -n harbor-ops
# generate the first rule, then add the scale rule by hand
k create role tally-role -n harbor-ops --dry-run=client -o yaml \
  --verb=get,list,watch --resource=pods,pods/log > /tmp/role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tally-role
  namespace: harbor-ops
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "deployments/scale"]
  verbs: ["get", "update", "patch"]

k apply -f /tmp/role.yaml
k create rolebinding tally-bind -n harbor-ops --role=tally-role --serviceaccount=harbor-ops:tally

SA=system:serviceaccount:harbor-ops:tally
k auth can-i get pods --subresource=log -n harbor-ops --as=$SA          # yes
k auth can-i patch deployments --subresource=scale -n harbor-ops --as=$SA # yes
k auth can-i delete pods -n harbor-ops --as=$SA                   # no
k auth can-i list pods -n default --as=$SA                        # no

Further readingCopy Anchor Link

• Using RBAC authorization
• Service accounts
• Certificates and certificate signing requests
• Checking API access with kubectl auth can-i