Kubernetes RBAC — Access Control in a Multi-Tenant Cluster

Kubernetes 1.6 brings RBAC as a beta feature — and for us, it’s absolutely critical. In a single cluster, we have developers, an ops team, and a CI/CD pipeline, each needing different permissions.

Why We Need RBAC¶

Up to version 1.6, Kubernetes essentially had two modes: ABAC (static policies in a JSON file on the API server) or no authorization at all. ABAC was impractical — every change required restarting the API server.

RBAC is dynamic. Role, ClusterRole, RoleBinding, ClusterRoleBinding — everything is a Kubernetes object, manageable via kubectl and versionable in Git.

Our Model: Namespace per Team¶

Each team (or client) gets its own namespace. Within that namespace, they have full rights — they can create deployments, services, configmaps. But they can’t see or modify anything in another namespace.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  namespace: team-alpha
  name: team-alpha-admin
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  namespace: team-alpha
  name: team-alpha-binding
subjects:
- kind: Group
  name: "team-alpha"
roleRef:
  kind: Role
  name: team-alpha-admin
  apiGroup: rbac.authorization.k8s.io

Service Accounts for CI/CD¶

Jenkins needs to deploy to the cluster, but we don’t want to give it cluster-admin. We create a service account with precisely defined permissions — it can create and update deployments and services in a specific namespace, nothing more.

The service account token is passed to Jenkins as a credential. If someone compromises Jenkins, they don’t gain access to the entire cluster.

Integration with LDAP/Active Directory¶

Kubernetes itself has no user management — it delegates authentication to an external system. We use an OIDC provider (Dex) connected to our corporate Active Directory. AD groups map to Kubernetes groups.

The setup isn’t trivial, but the result is elegant: someone leaves the company, you disable their AD account, and they automatically lose access to Kubernetes.

Tips from Practice¶

• Start with --authorization-mode=RBAC from the beginning — migrating later is painful
• Use groups, not individual users, in RoleBindings
• Audit — kubectl auth can-i --list shows what a user can do
• Watch out for the default service account — it often has more permissions than you’d want
• Network policies + RBAC = defense in depth

RBAC Is the Foundation of a Secure Cluster¶

Without RBAC, a Kubernetes cluster is like a house without locks. With version 1.6, we finally have a production-ready authorization model. Investing in proper RBAC configuration pays back many times over.