OpenShift User Management Guide

• Model type: role-based
• Description: OpenShift uses Kubernetes RBAC extended with OpenShift-specific cluster roles and local (project-scoped) roles. Permissions are granted by binding a role to a user, group, or service account at either the cluster scope or namespace/project scope. OpenShift ships with a set of default cluster roles (cluster-admin, cluster-reader, admin, edit, view, basic-user, self-provisioner, etc.) and supports creation of fully custom roles with fine-grained API group/resource/verb combinations.
• Custom roles: Yes
• Custom roles plan: Available on all tiers (self-managed, ROSA, ARO); no additional plan required
• Granularity: API group + resource type + resource name + verb (get, list, watch, create, update, patch, delete, deletecollection). Roles can be scoped to cluster-wide or individual namespace/project.

1. Configure an identity provider (IDP) via Administration → Cluster Settings → Configuration → OAuth in the web console, or by editing the OAuth cluster object via CLI (oc edit oauth cluster). Supported IDPs include HTPasswd, LDAP, GitHub, GitLab, Google, OpenID Connect, Keystone, Request Header, and Basic Authentication.
2. For HTPasswd IDP: create an htpasswd file with 'htpasswd -c -B -b /tmp/htpasswd ', create a secret from the file ('oc create secret generic htpass-secret --from-file=htpasswd=/tmp/htpasswd -n openshift-config'), and reference the secret in the OAuth CR.
3. User objects are created automatically in OpenShift the first time a user authenticates via the configured IDP - there is no pre-provisioning step required for IDP-backed users.
4. To grant cluster-level access after first login: 'oc adm policy add-cluster-role-to-user '
5. To grant project-level access: 'oc adm policy add-role-to-user -n '
6. Alternatively, in the web console: navigate to User Management → Users, select the user, and use the Role Bindings tab to add role bindings.

Required fields: Username (as defined in the identity provider), Identity provider configuration (at least one IDP must be configured on the cluster), Role or role binding (required to grant any meaningful access)

Watch out for:

• User objects do not exist in OpenShift until the user logs in for the first time via an IDP - you cannot pre-create a user object and assign roles before their first login unless you create the User object manually via CLI ('oc create user ').
• HTPasswd IDP requires updating the secret and restarting the OAuth server for changes to take effect; there is no live user-add UI for HTPasswd.
• Multiple IDPs can be configured simultaneously, but usernames must be unique across all IDPs or identity mapping conflicts will occur.
• The 'kubeadmin' virtual user is not a real User object and cannot be managed via normal RBAC tooling.
• On ROSA (Red Hat OpenShift Service on AWS), the cluster-admin role cannot be self-assigned; it must be granted via the ROSA CLI ('rosa grant user cluster-admin --user= --cluster=') or the ROSA web console.

• Can delete users: Yes
• Delete/deactivate behavior: OpenShift supports both deletion of the User object and deletion of the associated Identity object. Deleting the User object ('oc delete user ') removes the user's cluster access and role bindings but does not prevent re-creation if the user authenticates again via the IDP. To fully prevent re-authentication, the Identity object must also be deleted ('oc delete identity :') AND the user must be removed from the upstream identity provider (e.g., removed from LDAP, HTPasswd file, or OIDC provider). There is no 'deactivate/suspend' state - access is binary (User+Identity objects exist, or they don't).

1. Identify the user's identity object: 'oc get identity | grep '
2. Delete the User object: 'oc delete user '
3. Delete the Identity object: 'oc delete identity :'
4. Remove the user from the upstream identity provider (LDAP directory, HTPasswd file, OIDC provider, etc.) to prevent re-authentication and re-creation of User/Identity objects.
5. For HTPasswd IDP: update the htpasswd file to remove the user entry, then update the secret: 'oc create secret generic htpass-secret --from-file=htpasswd=/tmp/htpasswd -n openshift-config --dry-run=client -o yaml | oc replace -f -'
6. Optionally revoke any OAuth tokens: 'oc delete oauthaccesstokens --field-selector=userName='

Watch out for:

• Deleting the User object alone is insufficient to block re-access - the Identity object must also be deleted, and the user must be removed from the upstream IDP, otherwise they will re-authenticate and a new User object will be auto-created.
• There is no 'disable' or 'suspend' state for users in OpenShift; the only way to block access is full deletion of User + Identity objects plus IDP-level removal.
• On ROSA, cluster-admin and dedicated-admin role grants must be revoked via the ROSA CLI or console before or alongside user deletion.
• Orphaned role bindings referencing deleted users are not automatically cleaned up and may accumulate over time.

• Where to check usage: For self-managed: Red Hat Subscription Management (RHSM) at https://access.redhat.com/management or Red Hat Hybrid Cloud Console at https://console.redhat.com. For ROSA: AWS Cost Explorer or ROSA console at https://console.redhat.com/openshift. Cluster-level user counts visible via 'oc get users' (CLI) or User Management → Users in the web console.
• How to identify unused seats: No built-in 'last login' reporting in the OpenShift web console. Administrators can query OAuth access token last-use timestamps via 'oc get oauthaccesstokens' and check '.spec.expiresIn' and creation timestamps. Users who have never logged in will have no OAuth tokens. Third-party audit log analysis (e.g., via OpenShift audit logs in /var/log/oauth-server/) is required for detailed last-login reporting.
• Billing notes: OpenShift licensing is entirely compute-based, not per-user or per-seat. Adding or removing users has no direct impact on subscription costs. Costs are driven by the number of cores/vCPUs running OpenShift worker and infrastructure nodes. For ROSA and ARO, costs accrue per running node-hour regardless of user count.

OpenShift licensing is compute-based, not per-user. Adding or removing users has no direct effect on subscription costs; what drives spend is the number of cores or vCPU-hours running on worker and infrastructure nodes.

That said, the operational cost of manual user management is real. There is no built-in last-login report in the web console. Identifying inactive users requires parsing raw OAuth token metadata via CLI (oc get oauthaccesstokens) or analyzing audit logs from /var/log/oauth-server/.

Neither path is fast at scale.

Removing a user is a multi-step process: delete the User object, delete the Identity object, remove the account from the upstream identity provider, and optionally revoke active OAuth tokens. Missing any step results in the user being silently re-created on their next login attempt.

Administrators consistently flag the multi-step offboarding process as the sharpest operational pain point. Deleting only the User object leaves the Identity object intact, and the user will re-authenticate and re-appear in the cluster without any error or warning.

The absence of native SCIM is a recurring complaint for teams managing every app through a centralized identity platform.

LDAP group sync (oc adm groups sync) is the recommended bulk provisioning path, but it requires scheduling an external cron job and does not create User objects - only Group objects - until users actually log in.

RBAC complexity is also frequently cited. The boundary between cluster-scoped and namespace-scoped role bindings, combined with the large set of default roles, creates uncertainty about which role is appropriate for a given use case.

On ROSA specifically, the inability to self-assign cluster-admin and the requirement to use the ROSA CLI for privilege grants surprises teams migrating from self-managed clusters.

Common complaints:

• Administrators report that deleting a user requires multiple steps (User object + Identity object + IDP-level removal) and that missing any step results in the user being silently re-created on next login.
• No native SCIM support means automated user lifecycle management requires custom LDAP sync jobs or external tooling, which is operationally complex compared to SaaS platforms with built-in SCIM.
• There is no built-in last-login or user activity reporting in the web console; admins must parse raw audit logs or OAuth token metadata to identify inactive users.
• The HTPasswd identity provider is considered unsuitable for production use at scale because adding or removing a single user requires updating a file secret and triggering an OAuth server reload.
• RBAC complexity is frequently cited as a barrier: the distinction between cluster-scoped and namespace-scoped role bindings, combined with the large number of default roles, creates confusion about which role to assign for a given use case.
• On ROSA, the inability to self-assign cluster-admin and the requirement to use the ROSA CLI for privilege grants is reported as an unexpected workflow difference from self-managed OpenShift.

Manual administration is workable for small, stable clusters where identity provider configuration is already in place and user turnover is low. The web console covers role binding management adequately for day-to-day project-level access changes.

It becomes operationally fragile at scale. No native SCIM means every app that needs automated provisioning requires a custom LDAP sync job or direct API integration. No last-login visibility means identifying stale accounts requires CLI scripting or third-party audit log tooling.

Teams running OpenShift alongside a broader SaaS portfolio will find the manual offboarding gap - where a deleted User object does not block re-authentication - to be the highest-risk failure mode. Any access governance process that relies on the web console alone will miss this.

Bottom line

OpenShift's user management model is purpose-built for infrastructure teams comfortable with CLI tooling and RBAC configuration, not for IT administrators expecting a SaaS-style user lifecycle UI.

The lack of native SCIM, the absence of last-login reporting in the console, and the multi-object deletion requirement for offboarding all create meaningful operational overhead.

Teams that need reliable, auditable user lifecycle management across every app in their stack will need to layer external tooling - LDAP sync jobs, audit log pipelines, or API-driven automation - on top of what OpenShift provides natively.