Kubernetes RBAC: access control in a container cluster

Kubernetes 1.6 introduces RBAC (Role-Based Access Control) — granular access control for API resources. How to design a security model for a multi-tenant cluster.

Why RBAC in Kubernetes¶

A default Kubernetes installation has no access control — anyone with API access can do anything. In a production environment with multiple teams, this is unacceptable.

RBAC (Role-Based Access Control) allows you to define who (subject) can do what (verb) with what (resource). Granular permissions at the namespace or cluster level.

Role, ClusterRole and Bindings¶

The RBAC model has four objects:

# Role - permissions in a namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

---
# RoleBinding - assigning a role to a user
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: [email protected]
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Role = permissions in a namespace. ClusterRole = permissions across the entire cluster. Binding = linking a role to a subject.

Designing the RBAC model¶

Recommended approach for enterprise:

• Cluster admin — full access (infrastructure team only)
• Namespace admin — full access within the team’s namespace
• Developer — deploy, view logs, exec into pods in their namespace
• Viewer — read-only access for monitoring and debugging

Principle of least privilege — start with the minimum and add as needed. Audit permissions regularly.

Service Accounts and automation¶

Service Accounts are identities for processes (CI/CD, operators, monitoring):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-deployer
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deploy
  namespace: production
subjects:
- kind: ServiceAccount
  name: ci-deployer
  namespace: production
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

CI/CD pipelines use a service account token instead of personal credentials. Token rotation and audit logging are best practices.

Conclusion: security as a first-class citizen¶

RBAC is essential for production Kubernetes clusters. Invest time in designing your permissions model before opening the cluster to multiple teams. Least privilege, regular audits and service accounts for automation are the key best practices.