Implementing Role-Based Access Control

Implementing Role-Based Access Control

Role-Based Access Control (RBAC) provides fine-grained permissions management in orchestration platforms. Properly implemented RBAC prevents privilege escalation and limits blast radius from compromised credentials. Both Docker Swarm and Kubernetes support RBAC, though Kubernetes provides more granular control. RBAC policies should follow least privilege principles while remaining manageable.

Kubernetes RBAC uses four primary objects: Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. Roles define permissions within namespaces while ClusterRoles apply cluster-wide. RoleBindings grant permissions to users, groups, or service accounts. Careful RBAC design prevents common mistakes like overly broad permissions or privilege escalation paths.

# Example: Kubernetes RBAC configuration for different teams
# Developer role with limited permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: development
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log", "pods/exec", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]
  resourceNames: ["app-secrets", "registry-creds"]

---
# Security team cluster role
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: security-auditor
rules:
- apiGroups: [""]
  resources: ["pods", "nodes", "namespaces", "services"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "daemonsets", "replicasets", "statefulsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["podsecuritypolicies", "poddisruptionbudgets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["networking.k8s.io"]
  resources: ["networkpolicies", "ingresses"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["audit.k8s.io"]
  resources: ["events"]
  verbs: ["get", "list", "watch"]

---
# CI/CD service account with deployment permissions
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-deployer
  namespace: production
automountServiceAccountToken: false

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ci-deployer
  namespace: production
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "update", "patch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["create", "update"]
  resourceNames: ["app-secrets"]

---
# Bind roles to users/groups
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: developer
subjects:
- kind: Group
  name: "developers"
  apiGroup: rbac.authorization.k8s.io

---
# Aggregated roles for easier management
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-admin
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
rules:
- apiGroups: [""]
  resources: ["resourcequotas", "limitranges"]
  verbs: ["create", "delete", "update", "patch"]

Service account management requires careful attention in orchestrated environments. Each workload should use dedicated service accounts with minimal permissions. Default service accounts should have no permissions. Token rotation reduces exposure from compromised tokens. Workload identity systems provide better security than static service account tokens.