Kubernetes RBAC: A Step-by-Step Guide for Securing Your Cluster

These service accounts will be used to assign specific permissions to development and operations teams.

Step 3: Define roles

Create a file named role-bindings.yaml:

# roles.yaml

# Developer Role - Namespace specific (unchanged)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: dev
rules:
  # Allow developers to manage deployments and services
- apiGroups: ["", "apps"]
  resources: ["pods", "pods/log", "deployments", "services"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
  # Limited access to pod execution and configs
- apiGroups: [""]
  resources: ["pods/exec", "configmaps"]
  verbs: ["create", "get"]
---
# Operations Role - Modified for cluster-scoped resources
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ops-admin
rules:
  # Cluster-level read access for ops team
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
# Namespace-scoped resources
- apiGroups: [""]
  resources: ["namespaces", "pods", "services", "pods/log"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "daemonsets", "statefulsets"]
  verbs: ["get", "list", "watch"]

The developer role is namespace-scoped, while the ops-admin role has cluster-wide read access.

Step 4: Create role bindings

Create a file named role-bindings.yaml:

# role-bindings.yaml

# Developer RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-binding
  namespace: dev
subjects:
- kind: ServiceAccount
  name: dev-sa
  namespace: dev
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io
---
# Operations ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ops-binding
subjects:
- kind: ServiceAccount
  name: ops-sa
  namespace: ops
roleRef:
  kind: ClusterRole
  name: ops-admin
  apiGroup: rbac.authorization.k8s.io

These bindings connect our service accounts to their respective roles.

Step 5: Create a test application

Create a file named test-app.yaml:

# test-app.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: dev
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      serviceAccountName: dev-sa
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

This web-app deployment will run with the development team’s permissions.

Next, apply all configurations.

# Apply service accounts first
kubectl apply -f service-accounts.yaml

# Apply roles and role bindings
kubectl apply -f roles.yaml
kubectl apply -f role-bindings.yaml

# Deploy test application
kubectl apply -f test-app.yaml

Next, check that all resources were created correctly:

# Check service accounts
kubectl get serviceaccounts -n dev
kubectl get serviceaccounts -n ops

# Verify roles and bindings
kubectl get roles,rolebindings -n dev
kubectl get clusterroles,clusterrolebindings | grep ops

# Check test deployment
kubectl get deployments -n dev

Step 6: Test Permissions

Test the permissions for both service accounts:

# Test developer permissions

# Should have full access in dev namespace
kubectl auth can-i list pods --as=system:serviceaccount:dev:dev-sa -n dev
# Expected: yes

kubectl auth can-i create deployments --as=system:serviceaccount:dev:dev-sa -n dev
# Expected: yes


# Should not have cluster-wide access
kubectl auth can-i list nodes --as=system:serviceaccount:dev:dev-sa
# Expected: no



# Test operations permissions

# Should have read access across cluster
kubectl auth can-i list pods --as=system:serviceaccount:ops:ops-sa --all-namespaces
# Expected: yes

kubectl auth can-i list nodes --as=system:serviceaccount:ops:ops-sa
# Expected: yes


# Should not have write access
kubectl auth can-i create deployments --as=system:serviceaccount:ops:ops-sa -n dev
# Expected: no

Step 6: Cleanup

When you’re done testing, clean up all resources:

# Delete all resources created in the demo
kubectl delete -f service-accounts.yaml 
kubectl delete -f roles.yaml 
kubectl delete -f role-bindings.yaml 
kubectl delete -f test-app.yaml
  
# Delete Namespaces 
# Note: This will delete all resources in these namespaces 
kubectl delete namespace dev 
kubectl delete namespace ops

RBAC and Kubernetes backup and restore operations

Backup and restore operations in Kubernetes must integrate with existing access control mechanisms. While RBAC itself is a critical cluster resource requiring backup, the backup solution must operate within RBAC boundaries.

RBAC’s role in backup and restore

RBAC configurations define security policies, role definitions, and access bindings, all of which are essential components of cluster security. When implementing backup strategies, organizations need backup solutions that respect existing RBAC policies while having sufficient permissions to capture and restore the entire security context.

Solutions like Trilio, a Kubernetes-native data protection platform, demonstrate this integration by operating within RBAC boundaries for backup, recovery, and migration operations. Such platforms capture application data along with associated configurations, service accounts, and security contexts, ensuring that restored applications maintain their complete security posture.

Backup and security considerations

Key security aspects for Kubernetes backup operations:

• Backup operators need specific, limited RBAC permissions.
• Restore operations must maintain a security context.
• Backup data itself requires proper access controls.
• Backup and restore permissions should be regularly validated.

This approach ensures that backup operations maintain security while enabling effective disaster recovery.

RBAC in OpenShift

Key differences in RBAC implementation for OpenShift

OpenShift builds upon Kubernetes RBAC by providing additional security features and preconfigured roles. While OpenShift maintains compatibility with standard Kubernetes RBAC resources—roles, ClusterRoles, RoleBindings, and ClusterRoleBindings—it extends this model with its security context constraints (SCCs) and default cluster roles.

OpenShift’s preconfigured cluster roles include the following:

• admin: A project manager who can view and modify any resource in the project except quota
• basic-user: A user who can get basic information about projects and users
• cluster-admin: A super-user with full control to perform any action in any project, including quota management
• cluster-status: A user who can get basic cluster status information
• cluster-reader: A user who can get or view most objects but cannot modify them
• edit: A user who can modify most objects in a project but cannot view or modify roles or bindings
• self-provisioner: A user who can create their own projects
• view: A user who can see most objects in a project but cannot make modifications or view roles/bindings

Special considerations for OpenShift environments

As mentioned above, OpenShift introduces security context constraints that interact with RBAC to provide additional pod-level security controls. SCCs define conditions that a pod must run under. For example, SCCs in OpenShift do the following:

• Control permissions for pod execution
• Restrict access to host resources
• Regulate the capabilities available to containers

OpenShift introduces the concept of projects, which are enhanced Kubernetes namespaces with additional annotations and features. Projects in OpenShift differ from Kubernetes namespaces by adding resource quota management, built-in role-based access controls, and unique naming requirements.

Local role bindings in OpenShift automatically inherit cluster roles, allowing for simplified role management. For example, when you bind a user to the admin role in a project, they automatically receive all permissions defined in the admin role for that project scope. The service account system in OpenShift also differs by:

• Automatically creating project-specific service accounts
• Providing default SCCs for service accounts
• Integrating with the built-in OAuth server

Advanced RBAC Techniques

Using groups for efficient permission management

Groups in Kubernetes RBAC provide a way to manage permissions for multiple users collectively. Instead of managing individual RoleBindings, you can assign roles to groups, streamlining access management across the cluster. Groups can represent teams, departments, or functional roles within an organization.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-group-binding
  namespace: development
subjects:
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

Using Open Policy Agent for policy automation

Open Policy Agent (OPA) extends Kubernetes RBAC by providing dynamic policy enforcement. OPA allows you to implement complex access control policies beyond basic RBAC capabilities. It evaluates requests against custom policies written in Rego, making decisions about resource access.

Key capabilities of OPA include:

• Fine-grained access control based on resource attributes
• Dynamic policy enforcement using contextual information
• Centralized policy management across clusters
• Audit logging for policy decisions
• Real-time policy updates without cluster reconfiguration

Integrating RBAC with external identity providers

External identity providers enable centralized authentication and authorization management. Here are some common integrations.

Active Directory:

• Syncs AD groups to Kubernetes RBAC groups
• Manages user authentication via OAuth2/OIDC
• Supports single sign-on across clusters

Keycloak:

• Provides identity and access management
• Maps Keycloak roles to Kubernetes RBAC
• Enables granular access control through realm management

LDAP / Active Directory:

• Authenticates users against enterprise directories
• Maps LDAP groups to Kubernetes RBAC groups
• Maintains consistent access control across infrastructure

This integration ensures consistent access management across the organization while leveraging existing identity infrastructure.

RBAC best practices for Kubernetes administrators

Implementing effective RBAC policies requires understanding both security requirements and operational requirements. Here are key practices based on real-world Kubernetes deployments.

Principle of least privilege: Granting the minimum necessary permissions

Granting minimum required permissions starts with understanding workload requirements. Create roles that precisely match application needs rather than using broad permissions. A practical approach is to begin with read-only access and incrementally add permissions as needed. 

For example, a deployment team role might only need permissions to manage deployments and view logs, without access to sensitive resources like secrets or the ability to delete resources.

# Example: Custom role for application deployment
kind: Role
metadata:
  name: app-deployer
rules:
  # Note: Excluding delete verb to prevent accidental removal
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create", "update", "patch"]
  # Allows log access for debugging without pod manipulation
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

The above role gives developers the ability to deploy and monitor applications, while preventing delete operations.

Namespace isolation: Using namespaces to segment access

By segmenting access through namespaces, you can maintain clear boundaries between different teams and environments. This prevents accidental or unauthorized access across different parts of the cluster. 

Resource quotas complement RBAC by enforcing resource usage limits within these boundaries. For instance, development and production workloads should operate in separate namespaces with distinct RBAC policies.

# Development Team Namespace Setup
apiVersion: v1
kind: Namespace
metadata:
  name: team-a-dev
  # Labels help with resource organization and policy enforcement
  labels:
    environment: development
    team: team-a
---
# Role binding limited to this namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-access
  namespace: team-a-dev # Scope is limited to just this namespace
subjects:
- kind: Group
  name: team-a
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

The examples above create a dedicated namespace for Team A’s development work, with role bindings scoped only to their namespace.

Avoid wildcards due to the risks of using “*” in roles and bindings

Wildcard permissions (*) in RBAC rules create significant security risks by potentially granting unintended access. Instead, explicitly define required resources and verbs. 

This granular approach might require more initial configuration but provides clear visibility into permissions and reduces security risks. Always list specific resources like pods, services, or deployments rather than using wildcards.

Policy as code: Managing RBAC configurations with version control

Managing RBAC configurations through version control provides accountability and consistency. Store RBAC manifests alongside application code, implements review processes for changes, and maintains documentation that explains the purpose of each role. This approach ensures that RBAC changes follow the same rigorous process as application deployments and maintains a clear audit trail of security policy evolution.

Use automation tools to leverage open-source tools

Tools like rbac-manager help maintain consistent security policies across clusters. These tools can automate role creation, binding management, and policy enforcement. They integrate with existing CI/CD pipelines and can automatically adjust permissions based on predefined rules, reducing manual intervention and potential errors.

Use service account tokens

Service account tokens are JSON Web Token (JWT) credentials used for pod authentication to the Kubernetes API server. These tokens can be configured with time-bound validity, audience restrictions, and specific binding constraints to enhance security.

# Example: Service Account for a monitoring tool
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
  namespace: monitoring
  annotations:
    # Prevent automatic token mounting in pods
    kubernetes.io/enforce-mountable-secrets: "true"
automountServiceAccountToken: false
---
# Token with specific expiry and audience
apiVersion: v1
kind: Secret
metadata:
  name: prometheus-token
  annotations:
    kubernetes.io/service-account.name: prometheus
    # Token expires after a set time
    kubernetes.io/service-account.expiration: "2024-12-31T23:59:59Z"
    # Restrict token usage to specific services
    kubernetes.io/service-account.audience: ["monitoring.company.com"]
type: kubernetes.io/service-account-token

This setup creates a service account with a time-bound token, specific audience restrictions, and disabled automatic mounting. This means the token is only valid for specified services and expires automatically, reducing security risks.

Provide a read-only view of objects

The Kubernetes API server handles read operations differently from write operations in terms of performance and security impact. Read-only roles leverage this distinction by restricting verbs to non-mutating operations, making them ideal for monitoring and auditing scenarios.

# Example: Read-only role for monitoring dashboard
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # Provides access to key metrics without modification rights
  name: readonly-viewer
rules:
  # Core resource monitoring
- apiGroups: [""]
  resources: ["pods", "services", "nodes"]
  verbs: ["get", "list", "watch"]
  # Metrics access for monitoring tools
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods", "nodes"]
  verbs: ["get", "list", "watch"]

This role configuration allows monitoring tools or auditors to view cluster resources without modification rights. The permissions are explicitly limited to read operations (get, list, watch), ensuring that observers cannot make changes even accidentally.

Scheduling periodic reviews of RBAC policies

Periodic RBAC audits are key for maintaining security. Review access patterns, validate permissions against security baselines, and check for unused role bindings.

These audits should verify compliance with security policies and identify potential vulnerabilities. Maintain logs of RBAC changes and regularly review them for unintended modifications.