Identity & Users

Duration: 55 minutes
Format: Hands-on identity provider configuration
Audience: Platform Engineers, Operations Teams, Security Administrators

Narrative Context:

You’ve verified the cluster is healthy. Now let’s configure enterprise user authentication by integrating with an LDAP directory.

As an operations team, you need to: - Integrate with existing identity management systems - Configure group-based access control - Manage user permissions across projects - Remove default administrative accounts for security

By the end of this module, you will be able to:

OpenShift uses an OAuth server for authentication. The OAuth server validates user credentials against configured identity providers and issues access tokens for API and console access.

Supported Identity Providers (OpenShift 4.20):

When to use each:

This workshop uses LDAP as the hands-on example - it’s the most common enterprise authentication method and demonstrates group synchronization.

For complete identity provider details, see Understanding identity providers.

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 the OAuth configuration file:

Apply the OAuth configuration:

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. Wait for them to be ready:

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 - you’ll learn about this in the Governance module)

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:

View the group sync configuration:

The configuration: - Searches for LDAP groups matching ose-* pattern - Creates OpenShift Groups with matching names - Populates group 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:

Result: No resources found. (Regular users can’t see all projects)

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.

The web console provides a graphical interface for user and group management.

View users in console:

Navigate to: User Management → Users

You’ll see all users who have logged in, their identities, and associated groups.

View groups in console:

Navigate to: User Management → Groups

Shows all synced LDAP groups and their members.

View role bindings in console:

Navigate to: User Management → RoleBindings

Filter by project to see who has access to what.

Console advantages: - Visual overview of all users/groups - Easy role binding management - Quick access review - No need to remember YAML syntax

Ensure kubeadmin is removed after configuring identity provider:

First, grant cluster-admin to a real user:

Verify it works:

Output: yes

In production, always remove kubeadmin:

After verifying your identity provider works and granting cluster-admin to at least one LDAP/OIDC user, delete the kubeadmin secret from the kube-system namespace. This removes the bootstrap account and ensures all cluster access goes through your enterprise identity provider. On this workshop cluster, kubeadmin has already been removed — you’re using the admin HTPasswd account instead.

Automate LDAP group sync with CronJob:

Instead of running group sync manually, production environments typically create a Kubernetes CronJob that runs the sync operation automatically (for example, every hour). This ensures LDAP group membership changes are reflected in OpenShift without manual intervention.

The CronJob would: - Run on a regular schedule (e.g., */60 * * * * for hourly) - Use a service account with appropriate permissions - Mount the group sync configuration from a ConfigMap - Execute oc adm groups sync with the --confirm flag

For complete implementation details, see the official documentation on automating LDAP sync.

For this lab, manual group sync is sufficient for learning purposes.

What you configured:

✅ LDAP Identity Provider - Integrated enterprise LDAP authentication
✅ Group Synchronization - Imported LDAP groups to OpenShift
✅ RBAC with Groups - Granted cluster-reader and project-specific roles
✅ Project Collaboration - Created dev/test/prod projects with team access
✅ Permission Testing - Verified users have correct access levels
✅ Security Hardening - Understood kubeadmin removal and group sync automation

Key takeaway: OpenShift authentication integrates with existing identity management (LDAP, OIDC, HTPasswd, GitHub, and others) and uses group-based RBAC for scalable permission management.

Production recommendations:

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