Identity & Users

Check the current OAuth configuration:

Look at the spec.identityProviders section. You’ll see that an htpasswd identity provider is already configured - this was set up during cluster provisioning to provide the admin account you’re using now.

What about kubeadmin?

Fresh OpenShift clusters come with a kubeadmin bootstrap account stored as a Secret in kube-system. This account bypasses identity providers entirely - it’s meant for initial setup only. On this workshop cluster, kubeadmin has already been removed and replaced with the admin HTPasswd account you’re using now. That’s the correct production posture.

You can verify it’s gone:

Expected: not found - confirming the bootstrap account has been removed.

This lab environment provides LDAP with the following groups:

LDAP user credentials: All users have password Op#nSh1ft

To configure LDAP authentication, we need:

Create the LDAP bind password Secret:

Extract the CA certificate chain from the LDAP server:

Create ConfigMap with CA certificate:

Create and apply the OAuth configuration:

This script creates an OAuth configuration that adds the LDAP identity provider alongside the existing HTPasswd provider. It configures: the bind DN (uid=openshiftworkshop,…​), the LDAP URL (ldaps://ldap.jumpcloud.com) with a memberOf filter restricting login to the ose-user group, attribute mappings (dn → ID, mail → email, cn → display name, uid → username), and references the CA cert and bind password you created above.

Understanding the OAuth configuration:

The oauth-cluster.yaml file configures the LDAP identity provider. Key elements:

Key parameters:

For detailed LDAP configuration, see Configuring an LDAP identity provider.

Monitor the OAuth operator rollout:

Wait for: deployment "oauth-openshift" successfully rolled out

Verify OAuth pods are running:

All oauth-openshift pods should be Running and Ready 1/1.

The OAuth pods need a few moments after rollout to fully initialize their LDAP connections. This checks that LDAP login actually works before moving on:

If you reload the OCP Console tab and log out, you’ll now see both identity providers on the login page:

First, capture the API server URL for login commands:

Try logging in as a regular user:

You should see Login successful. - the user was authenticated against the LDAP server.

Check your identity:

Output: normaluser1

Check what you can do:

Output: no (project self-provisioning is disabled in this environment)

Notice the user was automatically created on first login. Log back in as admin to view the user object.

Log back in as cluster admin:

View the auto-created user:

You’ll see normaluser1 was automatically created on first login.

LDAP group synchronization imports LDAP groups as OpenShift Groups, making RBAC management easier.

Create the group sync configuration:

This configuration searches for LDAP groups matching ose-*, creates matching OpenShift Groups, and populates membership from LDAP.

Run the group sync:

Output shows created groups:

View the synced groups:

You’ll see:

Examine a specific group:

The group includes: - LDAP metadata (sync time, LDAP DN, LDAP server) - List of users in the group

See this in the console too: Navigate to User Management → Groups in the OCP Console:

Click on ose-fancy-dev - you’ll see fancyuser1 and fancyuser2 listed as members. Now click User Management → Users:

Notice only normaluser1 appears (and admin). The other users exist in LDAP groups but haven’t logged in yet, so OpenShift hasn’t created their User objects.

This is an important distinction: group membership is synced immediately, but User objects are created on first login. In production, you might see a group with 50 members but only 10 User objects - that just means 40 people haven’t logged in yet.

Confirms the same thing via CLI - only users who have authenticated appear here.

Grant the ose-fancy-dev group cluster-reader privileges to view cluster-wide resources:

What is cluster-reader? A role that allows viewing administrative information (all projects, nodes, cluster settings) without edit permissions.

You can verify this in the console. Navigate to User Management → RoleBindings, switch the Kind filter to Cluster-wide RoleBindings, and search for cluster-reader:

The first row shows ose-fancy-dev bound to cluster-reader across all namespaces - exactly what we just configured.

For more on roles, see Using RBAC to define and apply permissions.

Test as a regular user:

You should see no app- projects - normaluser1 isn’t in any project-specific groups. You may see one or two system namespaces that grant access to all authenticated users - that’s normal.

Test as a fancy developer:

Now you see all projects in the cluster:

This demonstrates group-based RBAC working correctly.

Check current user and groups:

Log back in as cluster admin:

Create a typical SDLC project structure:

Verify projects were created:

Grant the ose-teamed-app group edit access to dev and test:

Grant view access to production:

Grant ose-fancy-dev group edit access to production:

View role bindings for a project:

Describe a specific role binding:

Verify in the console. Navigate to User Management → RoleBindings, select project app-dev, and filter by Namespace RoleBindings:

You can immediately see that ose-teamed-app has the edit role in app-dev. Now switch the project to app-prod:

Notice the separation of privileges at a glance - ose-fancy-dev has edit access to production while ose-teamed-app only has view. This is the kind of access review that the console makes much faster than parsing CLI output.

Test as normaluser1 (no group access):

Result: No app- projects visible. This user is not in any project-specific groups.

Test as teamuser1 (ose-teamed-app member):

Now you see:

Verify permissions in development (edit access):

All should return: yes (teamuser1 has edit role in app-dev)

Verify permissions in production (view-only access):

Both should return: no (teamuser1 only has view role in app-prod)

Check what view access allows:

Both return: yes (view role allows read operations)

Perfect! This demonstrates how operations teams verify RBAC is correctly configured without creating test resources.

You configured LDAP authentication end-to-end: connected to an external directory, synced groups, mapped those groups to project-level RBAC, and verified it by logging in as three different users with different access levels.

Production recommendations:

Restore the cluster to its original authentication state before proceeding to other modules: