OpenShift RBAC Basics

Learn Role-Based Access Control (RBAC) in OpenShift, understand Users, Groups, Roles, RoleBindings, ClusterRoles, Service Accounts, and implement secure access control for Spring Boot applications.

Introduction

In an enterprise OpenShift cluster, hundreds of developers, DevOps engineers, QA teams, security administrators, and applications work together.

Without proper access control, anyone could:

Delete production applications
Modify deployments
Access Secrets
Change ConfigMaps
Delete databases
Restart critical Pods

This would create serious security risks.

To solve this problem, OpenShift implements Role-Based Access Control (RBAC).

RBAC ensures that users and applications can perform only the actions they are authorized to perform.

For example:

Developers can deploy applications.
QA engineers can view logs.
DevOps engineers can manage deployments.
Administrators have full cluster access.
Applications access only the resources they require.

Learning Objectives

By the end of this article, you will understand:

What is RBAC?
RBAC Architecture
Users and Groups
Roles
ClusterRoles
RoleBindings
ClusterRoleBindings
Service Accounts
Spring Boot integration
Enterprise security best practices

What is RBAC?

RBAC (Role-Based Access Control) is the authorization mechanism used by Kubernetes and OpenShift.

It determines:

Who can access the cluster
What resources they can access
Which operations they can perform

RBAC follows the Principle of Least Privilege.

RBAC Architecture

flowchart LR
    User[Developer / Service Account]
    --> RoleBinding

    RoleBinding
    --> Role

    Role
    --> Resource[Pods, Services, Secrets]

Authorization Flow

sequenceDiagram
    participant User
    participant API
    participant RBAC
    participant Resource

    User->>API: Request

    API->>RBAC: Check Permissions

    RBAC-->>API: Allow / Deny

    API-->>Resource: Execute Request

Every API request is validated before execution.

RBAC Components

Component	Purpose
User	Human user
Group	Collection of users
Role	Namespace permissions
ClusterRole	Cluster-wide permissions
RoleBinding	Assign Role
ClusterRoleBinding	Assign ClusterRole
ServiceAccount	Identity for Pods

Users

A User represents a human identity.

Examples:

alice

bob

developer1

admin

Authentication may come from:

LDAP
Active Directory
OAuth
GitHub
Google
Red Hat SSO

Groups

Groups simplify permission management.

Example:

Developers

QA

DevOps

Administrators

Instead of assigning permissions individually, assign them to a group.

Role

A Role defines permissions within a namespace (Project).

Example:

flowchart LR
    Developer
    --> Role

    Role
    --> Pods

    Role
    --> Services

    Role
    --> Deployments

Role Example

apiVersion: rbac.authorization.k8s.io/v1
kind: Role

metadata:
  name: developer-role

rules:

- apiGroups: [""]

  resources:

  - pods

  - services

  verbs:

  - get

  - list

  - create

  - update

Create Role:

oc apply -f role.yaml

RoleBinding

A Role has no effect until it is assigned to a user.

flowchart LR
    User

    --> RoleBinding

    --> Role

    --> Pods

RoleBinding Example

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding

metadata:
  name: developer-binding

subjects:

- kind: User

  name: alice

roleRef:

  kind: Role

  name: developer-role

  apiGroup: rbac.authorization.k8s.io

Apply:

oc apply -f rolebinding.yaml

ClusterRole

ClusterRoles provide permissions across the entire cluster.

Example:

Nodes
Storage Classes
Cluster Operators
Namespaces

flowchart TD
    ClusterRole

    --> Namespace1

    ClusterRole

    --> Namespace2

    ClusterRole

    --> Namespace3

ClusterRole Example

kind: ClusterRole

metadata:

  name: readonly-cluster

rules:

- apiGroups: [""]

  resources:

  - pods

  verbs:

  - get

  - list

ClusterRoleBinding

Assigns ClusterRoles to users.

flowchart LR
    User

    --> ClusterRoleBinding

    --> ClusterRole

    --> EntireCluster

Service Accounts

Applications running inside Pods do not use human users.

Instead, they use Service Accounts.

flowchart TD
    Pod

    --> ServiceAccount

    --> KubernetesAPI

Every Pod automatically receives a Service Account.

Service Account Example

apiVersion: v1
kind: ServiceAccount

metadata:

  name: payment-service-account

Deploy:

oc apply -f service-account.yaml

Deployment Using Service Account

spec:

  serviceAccountName:

    payment-service-account

Spring Boot Architecture

flowchart LR
    SpringBoot

    --> ServiceAccount

    --> KubernetesAPI

    KubernetesAPI

    --> ConfigMaps

    KubernetesAPI

    --> Secrets

The application accesses only authorized resources.

Banking Example

flowchart TD
    PaymentService

    --> ServiceAccount

    ServiceAccount

    --> Secrets

    ServiceAccount

    --> ConfigMaps

    ServiceAccount

    -. Cannot Access .-> CustomerNamespace

Each microservice has isolated permissions.

Namespace Isolation

flowchart LR
    Payments

    --> PaymentPods

    Customers

    --> CustomerPods

    PaymentPods -. No Access .-> CustomerPods

RBAC prevents cross-namespace access.

Built-in Roles

OpenShift provides predefined roles.

Role	Purpose
admin	Full project administration
edit	Modify resources
view	Read-only access
cluster-admin	Entire cluster administration

Assign Role

Grant developer access.

oc policy add-role-to-user edit alice

Grant view access.

oc policy add-role-to-user view bob

Verify Permissions

Check access.

oc auth can-i create deployment

Example:

yes

Check another permission.

oc auth can-i delete secrets

Example:

no

View Roles

oc get roles

View RoleBindings

oc get rolebindings

View ClusterRoles

oc get clusterroles

Enterprise Architecture

flowchart TD
    Developer

    --> RoleBinding

    --> DeveloperRole

    --> Namespace

    SpringBoot

    --> ServiceAccount

    --> Secret

    SpringBoot

    --> ConfigMap

    DevOps

    --> ClusterRoleBinding

    --> ClusterAdmin

Common Problems

Permission Denied

Example:

Error from server (Forbidden)

Possible causes:

Missing RoleBinding
Wrong namespace
Insufficient permissions

Cannot Access Secrets

Verify:

oc auth can-i get secrets

Wrong Service Account

Check Deployment.

oc describe deployment payment-api

Role Not Applied

Verify:

oc get rolebindings

Best Practices

Follow the Principle of Least Privilege.
Use Groups instead of assigning permissions to individual users.
Create one Service Account per application.
Separate Dev, QA, and Production namespaces.
Avoid using cluster-admin for applications.
Audit RBAC permissions regularly.
Restrict Secret access.
Use RoleBindings instead of ClusterRoleBindings whenever possible.

Common Mistakes

❌ Giving every user admin access.

❌ Running applications with cluster-admin permissions.

❌ Sharing one Service Account across multiple applications.

❌ Allowing unrestricted Secret access.

❌ Ignoring namespace isolation.

Advantages

Strong security
Namespace isolation
Fine-grained permissions
Enterprise compliance
Better auditing
Least privilege access
Multi-team collaboration
Secure application identity

Summary

RBAC is the foundation of security in OpenShift.

Key takeaways:

RBAC controls who can perform actions on cluster resources.
Roles apply within a namespace, while ClusterRoles span the entire cluster.
RoleBindings and ClusterRoleBindings assign permissions.
Service Accounts provide identities for applications.
Following least-privilege principles improves security and compliance.

Interview Questions

What is RBAC?
What is the difference between a Role and a ClusterRole?
What is a RoleBinding?
What is a Service Account?
Why shouldn't applications use cluster-admin permissions?
What is the Principle of Least Privilege?
How do you verify RBAC permissions?
What are the built-in OpenShift roles?
Why are Groups useful in RBAC?
What are the best practices for securing OpenShift clusters?