Scribd
Upload
10 views9 pages

Kubernetes RBAC Notes

RBAC (Role-Based Access Control) in Kubernetes is a security mechanism that regulates user permissions on resources within a namespace or cluster-wide. It enables fine-grained access control, ensuring that only authorized users can perform specific actions, thus preventing accidental deletions and unauthorized access. RBAC is essential in multi-tenant environments, CI/CD pipelines, and when integrating with external identity providers for authentication.

Uploaded by

Avik Shau
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
10 views9 pages

Kubernetes RBAC Notes

RBAC (Role-Based Access Control) in Kubernetes is a security mechanism that regulates user permissions on resources within a namespace or cluster-wide. It enables fine-grained access control, ensuring that only authorized users can perform specific actions, thus preventing accidental deletions and unauthorized access. RBAC is essential in multi-tenant environments, CI/CD pipelines, and when integrating with external identity providers for authentication.

Uploaded by

Avik Shau
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

What is RBAC (Role-Based Access Control) in Kubernetes?

RBAC is a security mechanism in Kubernetes that regulates who


(user/service account) can do what (verbs) on which resources (pods,
secrets, etc.) in a namespace or cluster-wide.

RBAC ensures fine-grained access control over Kubernetes


resources.

Why Is RBAC Used?


Without RBAC:

1. Anyone with cluster access can perform unrestricted


operations

2. Accidental deletion of critical resources (like deleting all pods


or secrets)

3. Security risk: Unauthorized access to secrets, configs, logs,


etc.

With RBAC:

1. Define least privilege access

2. Allow only specific actions (e.g., view pods, but not delete
them)

3. Isolate teams, environments, and components


When Is RBAC Used?
In multi-tenant clusters (dev/prod teams)

For CI/CD pipelines (service accounts need controlled access)

To enforce principle of least privilege

To protect sensitive operations (e.g., managing secrets,


deployments)

With external identity providers like Okta, LDAP for enterprise


SSO

Problems Solved by RBAC

Problem Solved by RBAC


Everyone has admin
Assign roles with limited permissions
access
Only authorized users perform sensitive
Lack of auditability
actions
No environment
RBAC can be namespace-scoped
separation
Misuse of Service
Restrict SA to minimum required access
Accounts

Two Key Subjects in RBAC


Users – Human users (devs, admins)

Authenticated through identity providers (SSO, Okta,


LDAP)

Not created in Kubernetes directly (you configure


external auth)
ServiceAccounts – Non-human identities

Used by Pods/Controllers to interact with the API server

Auto-mounted inside Pods

How RBAC Works – Step-by-Step Flow


Scenario: Alice wants to list Pods in the dev namespace.

Step-by-Step RBAC Flow:

Authentication (Who is this?)

Kubernetes checks the user identity (from


token/certificate)

Identity could be from an Identity Provider (IdP)

Authorization (Are they allowed to?)

Kubernetes checks RBAC policies:

Does Alice have a Role or ClusterRole?

Is she bound using a RoleBinding or ClusterRoleBinding?

Decision

If allowed → request proceeds

If denied → HTTP 403 Forbidden

RBAC = Authorization layer (not authentication).


Identity Providers (for Authentication)
Kubernetes doesn’t manage user accounts. You integrate with:

Identity Provider Use Case


LDAP Traditional enterprise directory
Okta Cloud-based SSO, MFA
GitHub Useful for dev teams
Google Workspace (SSO) Google-authenticated access
Active Directory Windows-based enterprise environments

These providers handle who you are, then Kubernetes uses RBAC to
decide what you can do.

Core RBAC Resources


1. Role

Grants permissions within a specific namespace

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: dev
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]

2. ClusterRole

Grants cluster-wide or non-namespaced resource permissions

Can also be used in a namespace if bound appropriately


kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cluster-pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]

3. RoleBinding

Binds a Role to a user, group, or ServiceAccount in a


namespace

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: bind-alice
namespace: dev
subjects:
- kind: User
name: alice@example.com
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io

4. ClusterRoleBinding

Binds a ClusterRole to subjects across the entire cluster

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: admin-binding
subjects:
- kind: User
name: bob@example.com
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io

Real-World Example
Scenario: You want to allow a CI/CD pipeline (viaServiceAccount)
to only create and delete Deployments in the dev namespace.

Step 1: Create Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: cicd-deploy
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["create", "delete"]

Step 2: Bind the Role

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: bind-cicd-sa
namespace: dev
subjects:
- kind: ServiceAccount
name: cicd-pipeline
namespace: dev
roleRef:
kind: Role
name: cicd-deploy
apiGroup: rbac.authorization.k8s.io
Advantages of RBAC in Kubernetes

Advantage Description
Least Privilege Enforce fine-grained, minimal permissions
Extensible Integrates with Identity Providers
Auditable Easy to track who can do what
Separation of Users, teams, apps, and environments
Concerns isolated
Protects Critical
Avoid accidental damage
Resources
Define and manage using YAML (GitOps-
Declarative
friendly)
Easily restrict users to environments (dev,
Namespace Scoped
staging, prod)

Limitations / Considerations

Limitation Workaround
No built-in user management Use external IdPs
Debugging access issues can
Use kubectl auth can-i
be hard
Complex in large teams Use RBAC generators, policies
Use tools like OPA/Gatekeeper for
Static rules
dynamic policies
RBAC = Authorization framework in K8s

Users & ServiceAccounts are the subjects

Roles/ClusterRoles define permissions

RoleBinding/ClusterRoleBinding assign roles to users/SA

Identity Providers (SSO, LDAP, Okta) are used for authentication

RBAC allows secure, scalable, and compliant access control in K8s

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy