πŸ” Configure Developer Self-Service Access on Azure Red Hat OpenShift (ARO)



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