What is Kubernetes RBAC?

RBAC (Role-Based Access Control) is a security mechanism that controls who can access what resources in a Kubernetes cluster based on their role.

Key Point: RBAC is simple to understand but can become complicated if not implemented correctly, as it directly impacts cluster security.

Two Main Areas of RBAC

1. User Management

Controls access for human users (developers, QA engineers, DevOps teams)

Example scenarios:

• Developers need access to deploy applications
• QA engineers only need read access to view logs
• DevOps team needs administrative access
• Nobody should accidentally delete critical system resources (like etcd)

2. Service Account Management

Controls access for applications/pods running in the cluster

Example scenarios:

• Should a pod be able to read ConfigMaps?
• Should a pod have access to Secrets?
• Can a pod accidentally delete important cluster resources?

The Three Pillars of RBAC

1. Service Accounts / Users
2. Roles / Cluster Roles
3. Role Bindings / Cluster Role Bindings

Component Breakdown

1. Service Accounts / Users

Users:

• Kubernetes does NOT manage users directly
• User management is offloaded to Identity Providers
• Examples of identity providers:
  • AWS IAM (for EKS)
  • Azure AD (for AKS)
  • LDAP
  • Okta
  • GitHub (via Keycloak)
  • Google OAuth

Service Accounts:

• Created within Kubernetes as YAML files
• Automatically created for pods (default service account)
• Can create custom service accounts

2. Roles

Defines permissions (what actions are allowed on which resources)

Example permissions:

• Access to Pods
• Access to ConfigMaps
• Access to Secrets
• Read-only vs. Write access

Types:

• Role: Permissions within a specific namespace
• Cluster Role: Permissions across the entire cluster

3. Role Bindings

Connects users/service accounts to roles

Function: Binds permissions (from roles) to users

Types:

• Role Binding: Namespace-scoped
• Cluster Role Binding: Cluster-scoped