hacktricks/pentesting/pentesting-kubernetes/kubernetes-role-based-access-control-rbac.md

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.
The RBAC table is constructed from “Roles” and “ClusterRoles.” The difference between them 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.

Example of Role configuration:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: defaultGreen
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

Example of ClusterRole configuration:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

For example you can use a ClusterRole to allow a particular user to run:

kubectl get pods --all-namespaces

Role and ClusterRole Binding concept

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.

RoleBinding example:

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
  name: jane # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding example:

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

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

# Get current privileges
kubectl auth can-i --list
## use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

RBAC Structure

RBAC’s permission is built from three individual parts:

1. Role\ClusterRole ­– The actual permission. It contains rules that represent a set of permissions. Each rule contains resources and verbs. The verb is the action that will apply on the resource.
2. Subject (User, Group or ServiceAccount) – The object that will receive the permissions.
3. RoleBinding\ClusterRoleBinding – The connection between Role\ClusterRole and the subject.

This is what it will look like in a real cluster:

“Fine-grained role bindings provide greater security, but require more effort to administrate."

From Kubernetes 1.6 onwards, RBAC policies are enabled by default. **** But to enable RBAC you can use something like:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

This is enabled by default. RBAC functions:

• Restrict the access to the resources to users or ServiceAccounts.
• An RBAC Role or ClusterRole contains rules that represent a set of permissions.
• Permissions are purely additive (there are no “deny” rules).
• RBAC works with Roles and Bindings

{% hint style="info" %} When configuring roles and permissions it's highly important to always follow the principle of Least Privileges {% endhint %}