liveBook · Manning

Principle of least privilege

As explained in Acing the Certified Kubernetes Administrator Exam, Second Edition

The principle of least privilege is a security practice of granting only the permissions required for an identity or component to perform its duties.

When granting access to the Kubernetes API, give each user, group, or Service Account only the permissions needed for its task. A subject that needs to view pods in one namespace should not automatically be able to delete pods or access other resources. RBAC enforces this boundary through roles and bindings. section 3.1

Turn the principle into an access check:

  • Choose the required resource and request verbs. For read-only pod access, grant viewing permissions without the delete verb. section 3.1 section 3.1.1
  • Choose the scope before binding the subject: Roles and RoleBindings apply within a namespace; ClusterRoles and ClusterRoleBindings can grant broader access. Avoid assigning unfettered cluster privileges. section 3.1.1
  • Test both an intended action and an action that must remain forbidden with `kubectl auth can-i` and `--as`. section 3.1.1
$ kubectl auth can-i get pods -n default --as carol
yes
$ kubectl auth can-i delete pods -n default --as carol
no

The permission checks return `yes` for getting pods and `no` for deleting them in the default namespace. Check the denied action as well as the allowed one: successful access alone does not establish least privilege. section 3.1.1

Limit a workload's API access

A pod can authenticate with its Service Account, but authentication is not a reason to grant unrestricted API access. For a Service Account that needs to list pods, create a role with `kubectl create role pod-list --verb=list --resource=pods`, then bind it with `kubectl create rolebinding pod-list-bind --role=pod-list --serviceaccount=default:nomount-sa`. Verify the grant with `kubectl auth can-i list pods --as system:serviceaccount:default:nomount-sa`; the shown result is `yes`. section 3.3

Keep credentials in mind when reviewing access. Pods normally receive a mounted Service Account token; token mounting can be disabled on a Service Account or pod when it is not needed. Be cautious about granting access to Secrets or Service Accounts, because Service Account tokens can authenticate to the API. section 3.3

How Acing the Certified Kubernetes Administrator Exam, Second Edition covers it

How deep it goes
Works through RBAC grants and permission checks; leaves other authorization modes outside the CKA-focused treatment.
Examples
Uses pod-read permission checks, a restricted user kubeconfig, and a Service Account bound to a pod-list role.
What it assumes
Assumes familiarity with pods, namespaces, and API access while explaining how RBAC grants the minimum required permissions.
What you can do after
Apply it via Kubernetes RBAC, then verify allowed and denied actions with `kubectl auth can-i`.
How it connects
Connects RBAC, Roles, RoleBindings, ClusterRoles, namespaces, users, groups, and Service Accounts.

Also explained in

Compare how 17 books explain principle of least privilege →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Acing the Certified Kubernetes Administrator Exam, Second Edition. The section links point to the parts of the book it draws on.