13.2 Role-Based Access Control

Core RBAC Concepts in OpenShift

OpenShift’s Role-Based Access Control (RBAC) builds on Kubernetes RBAC but integrates tightly with OpenShift-specific objects (projects, routes, image streams, builds, etc.) and its authentication model.

At a high level, RBAC in OpenShift answers:

• Who (users, groups, service accounts)
• Can do what (verbs like get, list, create, update, delete, watch, patch)
• On which resources (pods, routes, imagestreams, custom resources, etc.)
• In which scope (single project/namespace or cluster-wide)

RBAC in OpenShift is primarily expressed through four core resource types:

• Role – set of permissions within a single namespace
• ClusterRole – set of permissions cluster-wide (or reusable across namespaces)
• RoleBinding – assigns a Role or ClusterRole to subjects in a specific namespace
• ClusterRoleBinding – assigns a ClusterRole to subjects cluster-wide

OpenShift ships with many predefined roles and bindings to support its platform features (builders, deployers, routers, web console, etc.), in addition to the standard Kubernetes roles.

Roles and ClusterRoles

A Role defines permissions within a single namespace (OpenShift “Project”).

Basic structure:

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

Key points:

• apiGroups: "" is the core API group (pods, services, configmaps, etc.); other groups include apps, route.openshift.io, build.openshift.io, etc.
• resources: Kubernetes and OpenShift resources; can include subresources like pods/log.
• verbs: allowed actions; common verbs are get, list, watch, create, update, patch, delete.

A ClusterRole is similar but not bound to a namespace:

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

ClusterRoles are used for:

• Cluster-wide permissions
• Reusable permission sets that can be bound into any project via RoleBinding
• OpenShift “system” roles (e.g. cluster-admin, admin, view, edit)

Common patterns:

• Use a Role for strictly project-local behavior.
• Use a ClusterRole when:
• Permissions must apply to all namespaces.
• The same permission set is reused across many projects.

RoleBindings and ClusterRoleBindings

Roles and ClusterRoles define what is allowed. Bindings connect those definitions to who is allowed.

A RoleBinding gives permissions in one specific namespace:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: myproject
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Key details:

• subjects can be:
• User – a single user
• Group – a group of users
• ServiceAccount – identity used by pods
• roleRef refers to a Role in the same namespace or any ClusterRole.

Example binding a ClusterRole in a project:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: devs-can-edit
  namespace: team-a
subjects:
- kind: Group
  name: devs-team-a
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

A ClusterRoleBinding is cluster-scoped:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: platform-admins
subjects:
- kind: Group
  name: platform-admins
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBindings should be used sparingly because they grant permissions across all projects.

Subject Types in OpenShift RBAC

OpenShift RBAC subjects include standard Kubernetes types plus specifics important in OpenShift:

• Users
• Human identities authenticated via OAuth, external IdPs, etc.
• Example: User/alice.
• Groups
• Collections of users, often synced from an external directory.
• Example: Group/devs, Group/cluster-admins.
• ServiceAccounts
• Identities for workloads (pods).
• Format: system:serviceaccount:<namespace>:<name>
• Example: system:serviceaccount:myproject:default.

Service accounts are critical for controlling what applications can do in the cluster.

Example binding a service account to a role:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ci-job-can-deploy
  namespace: app-prod
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app-prod
roleRef:
  kind: ClusterRole
  name: system:deployer
  apiGroup: rbac.authorization.k8s.io

Built-in Roles in OpenShift

OpenShift ships with a rich set of predefined ClusterRoles. Some of the most commonly used high-level roles:

• cluster-admin
• Full control over the entire cluster and all resources.
• Should be restricted to a very small group of platform operators.
• admin
• Full control within a project, plus ability to modify project membership.
• Usually assigned per-project to a lead developer or team owner.
• edit
• Read/write access to most objects in a project.
• Cannot modify project membership or some sensitive resources.
• Typical role for developers working in a project.
• view
• Read-only access to most objects in a project.
• Good for QA, auditors, and observers.

These can be used directly with oc adm policy helpers or via standard RBAC objects.

Example: Grant a user project admin rights:

oc adm policy add-role-to-user admin alice -n myproject

Example: Allow a group to view a project:

oc adm policy add-role-to-group view auditors -n finance-app

OpenShift also defines system roles such as:

• system:deployer – used by deployment processes
• system:image-puller – allows pulling images from a project’s image streams
• system:image-pusher – allows pushing images
• system:build-strategy-* – used by build strategies like S2I

Generally, you don’t assign these directly to humans; they are used for platform and automation identities.

RBAC and Projects (Namespaces)

In OpenShift, a Project is a Kubernetes namespace with additional metadata and access control conventions.

Project-level access is typically managed by:

• Assigning roles (admin, edit, view) to:
• Users
• Groups
• Service accounts

Example: create a new project and add collaborators:

# As a cluster-admin:
oc new-project team-a
# Make alice the project admin:
oc adm policy add-role-to-user admin alice -n team-a
# Give devs group edit access:
oc adm policy add-role-to-group edit devs-team-a -n team-a

Behind the scenes, these commands create or update RoleBinding objects in that project.

Key behavior:

• Access to a project is almost entirely defined by RBAC bindings in that project.
• Removing a user’s bindings in a project effectively removes their access to it (assuming no cluster-wide role grants overlapping permissions).

Service Accounts, Pods, and RBAC

Each pod in OpenShift runs as a service account, which determines what the pod can do via RBAC.

Basics:

• Default service account in a project is default.
• Recommended practice is to create specific service accounts for specific applications or jobs with tightly scoped roles.

Example: Give an application permission to manage ConfigMaps in its own project:

oc create serviceaccount app-config-manager -n myproject

Create a Role:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: config-manager
  namespace: myproject
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

Bind the role:

oc create rolebinding app-config-manager-binding \
  --role=config-manager \
  --serviceaccount=myproject:app-config-manager \
  -n myproject

In the pod spec:

spec:
  serviceAccountName: app-config-manager

This pattern enforces least privilege for each workload.

Managing RBAC with the `oc` CLI

OpenShift provides conveniences around RBAC management beyond direct YAML editing.

Common inspection commands:

# View roles in a namespace
oc get roles -n myproject
# View cluster roles
oc get clusterroles
# Describe a role/clusterrole
oc describe role pod-reader -n myproject
oc describe clusterrole edit
# See who has which roles in a project
oc get rolebindings -n myproject
oc describe rolebinding devs-can-edit -n myproject

Common modification commands:

# Add/remove roles to/from users or groups
oc adm policy add-role-to-user edit alice -n myproject
oc adm policy remove-role-from-user edit alice -n myproject
oc adm policy add-role-to-group view auditors -n myproject
oc adm policy remove-role-from-group view auditors -n myproject
# Add a cluster role to a user or group cluster-wide
oc adm policy add-cluster-role-to-user cluster-admin ops-user
oc adm policy add-cluster-role-to-group cluster-reader auditors

These oc adm policy commands create or modify the underlying RoleBinding/ClusterRoleBinding objects.

Common RBAC Design Patterns in OpenShift

Per-Project Role Assignment

Typical structure:

• Project owner – admin role
• Development team – edit role
• Read-only stakeholders – view role
• Automation/service accounts – custom roles with specific verbs and resources

Example policy for a team:

• team-a-devs group:
• edit in team-a-dev, team-a-test
• team-a-ops group:
• admin in team-a-prod
• auditors group:
• view in team-a-* projects

Centralized Platform Admins

A small group of platform admins receives:

• cluster-admin via ClusterRoleBinding, or
• a set of higher-privilege ClusterRoles (e.g. cluster-reader, specific custom ClusterRoles) instead of full cluster-admin for stricter separation of duties.

Custom Fine-Grained Roles

When the built-in roles are too broad, you can:

1. Define a ClusterRole with exactly the needed rules.
2. Bind it at cluster or project level.

Example: a role that only allows managing routes:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: manage-routes
rules:
- apiGroups: ["route.openshift.io"]
  resources: ["routes"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Bind it in a project:

oc create rolebinding routes-admins \
  --clusterrole=manage-routes \
  --group=web-ops \
  -n frontend-app

RBAC Best Practices in OpenShift

• Prefer groups over individual users
• Bind roles to groups managed in your identity provider.
• Simplifies onboarding/offboarding.
• Use built-in roles where possible
• admin, edit, view cover many common needs.
• Reserve cluster-admin for true platform administrators only.
• Apply least privilege
• Create custom roles for automation/service accounts.
• Only include required resources and verbs.
• Separate duties
• Distinguish between:
• Platform operations (cluster roles)
• Application operations (project roles)
• Security/compliance (read-only but wide visibility).
• Scope cluster roles carefully
• Avoid granting cluster-admin to applications or pipeline service accounts.
• Prefer project-scoped RoleBindings that reference ClusterRoles with limited rules.
• Review and audit bindings regularly
• Periodically list ClusterRoleBindings and RoleBindings:

    oc get clusterrolebindings
    oc get rolebindings -A

• Look for unexpected or overly broad assignments.

• Align RBAC with organizational structure
• Map projects to teams or services.
• Use consistent naming for groups and roles to reflect responsibilities.

By designing RBAC carefully in OpenShift, you can ensure that both humans and workloads have only the access they need, aligned with the broader security policies of your organization.