Skip to main content
This guide covers basic user, identity, service account, and group management in OpenShift. It shows both CLI (oc) and web console workflows, with practical commands and YAML snippets you can reuse. Use this to quickly create users, map identities, manage service accounts, and assign roles via RoleBindings. Quick reference links

​
Common oc commands

​
Create a user

Use the CLI to create a user named miketest and verify it exists:
Verifying the oc get user output confirms the user exists in the cluster. Users are OpenShift API objects under user.openshift.io/v1.

​
Create an identity mapping for the user

OpenShift separates users and identities. To attach an external identity to an OpenShift user, create a user identity mapping. For example, map the identity allow_all:miketest to the OpenShift user miketest:
After mapping, the IDENTITIES column shows the attached identity. This is required when integrating external identity providers or when your authentication flow provides identities separate from OpenShift user objects.

​
Service accounts (UI and CLI)

Service accounts are Kubernetes core objects (apiVersion v1) that represent identities for in-cluster processes (pods). You can create them from the OpenShift web console or via oc. Example ServiceAccount YAML for the limittester namespace:
Create from the CLI (without -n will place it in the current project, commonly default):
To explicitly create it in a target namespace, include -n:
Always specify the target namespace (with -n <namespace>) when creating resources from the CLI to avoid unintentionally creating them in the default project.
Grant a role to a service account (example: give mikesa the view role in default):
Inspect the ServiceAccount object in YAML via the console or CLI. A typical ServiceAccount object contains metadata, secrets, and optional imagePullSecrets:
ServiceAccount is a core API object (group “, version v1) used extensively for pod identity and integrations.

​
Groups and RoleBindings (UI)

Groups let you manage collections of users. RoleBindings assign roles to subjects (users, groups, or service accounts) within a namespace. Use the console to create groups and RoleBindings, or apply YAML from the CLI. Create another user (example test) via CLI:
Example Group YAML you can use in the console to create a group and add users:
After creating a Group, bind a role to it using a RoleBinding. A RoleBinding grants a specific role (for example admin) inside a namespace to the subjects listed. Use the web console to create a RoleBinding (provide a name, target namespace, and role), or create one with oc. The console form looks like this:
A screenshot of the Red Hat OpenShift web console showing the "Create RoleBinding" form with radio options for Namespace or Cluster-wide role bindings and input fields for name and namespace. A dark left navigation menu lists sections like Networking, Storage, Builds, and RoleBindings.
For example, create a RoleBinding named testbinding that grants the admin role in the default namespace to the test-roles group. After binding, group members (such as test) will have admin privileges in that namespace. Once created, review the RoleBinding details in the console to confirm scope and subjects:
A screenshot of the Red Hat OpenShift web console showing RoleBinding details for an object named "testbinding" in the default namespace. The left sidebar shows navigation items (Networking, Storage, User Management) and a red banner warns the cluster is for development/testing.
RoleBindings and ClusterRoleBindings grant permissions. Always verify the role, namespace (scope), and subjects before applying bindings—especially when assigning admin or cluster-level roles.

​
Next steps and further reading

  • Study RBAC in depth: roles, ClusterRoles, RoleBindings, ClusterRoleBindings.
  • Learn authentication integrations for external identity providers and how identities map to OpenShift users.
  • Use oc describe and oc get -o yaml to inspect objects and troubleshoot access issues.
References

Watch Video