Skip to main content

Setting up RoleBindings

Kubernetes manages access rights via Role-Based Access Control (RBAC). This allows you to restrict which users and applications are permitted to view or modify which resources.

Prerequisites​

  • A Kubernetes cluster with the status Running and a verified connection via kubectl

The four object types​

ObjectScopePurpose
RoleA namespaceDefines permissions within a namespace
ClusterRoleEntire clusterDefines cluster-wide permissions
RoleBindingA namespaceAssigns a role or ClusterRole within a namespace
ClusterRoleBindingEntire clusterAssigns a ClusterRole across the entire cluster

Rights are granted exclusively on an additive basis: there are no prohibitive rules. Anything not expressly permitted is prohibited.

Tipp

A RoleBinding can also reference a ClusterRole. The rights defined therein then apply only within the namespace of the binding. This allows you to use predefined roles such as view or edit within a specific namespace without having to write your own roles.

Predefined ClusterRoles​

The Kubernetes comes with rollers that cover most use cases:

ClusterRolePermissions
viewRead access to most resources, excluding secrets
editRead and modify most resources, excluding RBAC objects
adminFull access within a namespace, including RBAC
cluster-adminUnrestricted access to the entire cluster

Permissions for a ServiceAccount​

Applications in the cluster authenticate via a ServiceAccount. By default, this has virtually no permissions – this is by design.

1. Create a ServiceAccount​

kubectl create serviceaccount app-sa -n produktion

2. Define a role with the required permissions​

Only grant the permissions that the application actually needs:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-leser
  namespace: produktion
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch"]

Common verbs include get, list, watch, create, update, patch and delete.

3. Assign a role​

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-sa-configmap-leser
  namespace: produktion
subjects:
  - kind: ServiceAccount
    name: app-sa
    namespace: produktion
roleRef:
  kind: Role
  name: configmap-leser
  apiGroup: rbac.authorization.k8s.io

How to use:

kubectl apply -f rbac.yaml

4. Using a ServiceAccount in the deployment​

    spec:
      serviceAccountName: app-sa
      containers:
        - name: app
          image: registry.example.com/app:1.0

Granting read access to a namespace​

For users who are only permitted to view a namespace, the predefined ClusterRole view is sufficient:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-lesezugriff
  namespace: produktion
subjects:
  - kind: User
    name: entwickler@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

Check permissions​

Use kubectl auth can-i to check whether a particular action is permitted:

# Eigene Rechte prüfen
kubectl auth can-i create deployments -n produktion

# Rechte eines ServiceAccounts prüfen
kubectl auth can-i list configmaps \
  --as=system:serviceaccount:produktion:app-sa \
  -n produktion

# Alle Rechte eines ServiceAccounts auflisten
kubectl auth can-i --list \
  --as=system:serviceaccount:produktion:app-sa \
  -n produktion

View existing bindings:

kubectl get rolebindings -n produktion
kubectl get clusterrolebindings
kubectl describe rolebinding app-sa-configmap-leser -n produktion

Recommendations​

  • Grant permissions according to the principle of least privilege – start with restrictive settings and add permissions on a case-by-case basis.
  • Use Role and RoleBinding instead of cluster-wide objects if permissions can be restricted to a single namespace.
  • Grant cluster-admin only to administrative accounts, never to applications.
  • Pay particular attention to permissions for secrets: anyone authorised to read this can view all the access credentials stored within it in plain text.
  • Create a separate service account for each application, rather than using the default service account.
Last updated on