Kubernetes Role-Based Access Control(RBAC)
Role-Based Access Control (RBAC)
Kubernetes has an authorization module named Role-Based Access Control (RBAC) that helps to set utilization permissions to the API server.
RBAC’s permission model is built from three individual parts:
Subject (User, Group or ServiceAccount) – The object that will receive the permissions.
RoleBinding\ClusterRoleBinding – The connection between Role\ClusterRole and the subject.
The difference between “Roles” and “ClusterRoles” is just where the role will be applied – a “Role” will grant access to only one specific namespace, while a “ClusterRole” can be used in all namespaces in the cluster. Moreover, ClusterRoles can also grant access to:
cluster-scoped resources (like nodes).
non-resource endpoints (like /healthz).
namespaced resources (like Pods), across all namespaces.
From Kubernetes 1.6 onwards, RBAC policies are enabled by default. But to enable RBAC you can use something like:
Templates
In the template of a Role or a ClusterRole you will need to indicate the name of the role, the namespace (in roles) and then the apiGroups, resources and verbs of the role:
The apiGroups is an array that contains the different API namespaces that this rule applies to. For example, a Pod definition uses apiVersion: v1. It can has values such as rbac.authorization.k8s.io or [*].
The resources is an array that defines which resources this rule applies to. You can find all the resources with:
kubectl api-resources --namespaced=true
The verbs is an array that contains the allowed verbs. The verb in Kubernetes defines the type of action you need to apply to the resource. For example, the list verb is used against collections while "get" is used against a single resource.
Rules Verbs
(This info was taken from the docs)
HTTP verb | request verb |
---|---|
POST | create |
GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) |
PUT | update |
PATCH | patch |
DELETE | delete (for individual resources), deletecollection (for collections) |
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
use
verb onpodsecuritypolicies
resources in thepolicy
API group.
bind
andescalate
verbs onroles
andclusterroles
resources in therbac.authorization.k8s.io
API group.
impersonate
verb onusers
,groups
, andserviceaccounts
in the core API group, and theuserextras
in theauthentication.k8s.io
API group.
You can find all the verbs that each resource support executing kubectl api-resources --sort-by name -o wide
Examples
For example you can use a ClusterRole to allow a particular user to run:
RoleBinding and ClusterRoleBinding
From the docs: A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.
Permissions are additive so if you have a clusterRole with “list” and “delete” secrets you can add it with a Role with “get”. So be aware and test always your roles and permissions and specify what is ALLOWED, because everything is DENIED by default.
Enumerating RBAC
Abuse Role/ClusterRoles for Privilege Escalation
Abusing Roles/ClusterRoles in KubernetesLast updated