This content originally appeared on DEV Community and was authored by Sindhuja N.S
OpenShift is powerful β but what makes it even more valuable for teams is when developers can use it without needing cluster admin privileges. Thatβs exactly what you get by setting up developer self-service access on Azure Red Hat OpenShift (ARO).
In this blog, weβll show how to give developers access to a managed OpenShift cluster in Azure, allowing them to create their own projects and deploy apps β all in a secure and controlled way, without touching the command line.
What Weβre Aiming For
By the end of this setup:
Developers can log in using enterprise credentials
They can create their own OpenShift projects
They can deploy apps without needing admin access
Admins keep full control over whatβs allowed
Prerequisites
Before you start, make sure you have:
An ARO cluster running (Azure Red Hat OpenShift)
Access to the Azure Portal
A supported Identity Provider (IdP) (Azure AD, GitHub, LDAP, etc.)
Access to the OpenShift Web Console with cluster-admin privileges
Step 1: Configure Identity Provider
First, you need to connect your Identity Provider (such as Azure AD) to the OpenShift cluster.
How to do it:
Log in to the OpenShift Web Console as a cluster admin.
Go to Administration β Cluster Settings.
Under the Configuration tab, scroll down to OAuth.
Click on Identity Providers β Add.
Choose your provider (e.g., Azure, GitHub, LDAP).
Fill in the required fields (like client ID, secret, and issuer URL).
Save and wait for the changes to apply.
Once done, users from that provider can log into OpenShift.
Step 2: Create a RoleBinding for Developers
Now that users can log in, we need to grant developer-level access so they can create their own projects.
How to do it:
In the OpenShift console, go to User Management β RoleBindings.
Click Create Binding.
Give it a name like developer-access.
Choose the Cluster Role: self-provisioner.
Assign it to your developer group or users from the Identity Provider.
Save it.
This lets users create their own projects β but limits them to unprivileged operations.
Step 3: Test Developer Self-Service
Ask a developer to log in to the OpenShift Web Console.
They should be able to:
Click Create Project from the Dashboard
Get access to deploy workloads like containers and apps
Use Templates and Developer Catalog
View logs, metrics, and set environment variables
They wonβt be able to do admin actions like modifying cluster-wide settings.
Optional: Restrict What Developers Can Do
If you want tighter controls, you can:
Limit resource quotas in the namespace
Use SecurityContextConstraints (SCC) to restrict what containers can run
Disable the self-provisioner role entirely (if you want pre-approved projects only)
Why This Matters
Giving developers self-service access:
Speeds up deployment cycles
Removes bottlenecks from ops/admins
Keeps everything secure and auditable
Aligns with DevOps and platform engineering practices
Itβs a win for both agility and governance.
Final Thoughts
Azure Red Hat OpenShift is built for enterprise scale, but that doesnβt mean it has to be hard to use. With self-service access configured, your developers can move faster β and your admins can rest easier.
No CLI required. No YAML writing. Just smooth onboarding through the OpenShift Web Console.
For more info, Kindly follow: Hawkstack Technologies
This content originally appeared on DEV Community and was authored by Sindhuja N.S