Ask an OpenShift Admin (Ep 33): Authentication and authorization

Main ideas / lessons

• Authentication vs. authorization in OpenShift

  • Authentication answers: who are you?
  • Authorization answers: what can you do once authenticated?

• OpenShift identity model

  • OpenShift recognizes roughly three user categories:
    • Regular users: Humans who authenticate to use/admin the cluster.
    • System users: Accounts created by OpenShift/system components (e.g., identities related to nodes/registry).
    • Service accounts: Machine/workload identities used by pods (e.g., a pod runs under a service account).
  • Groups are collections of users; users can belong to one or more groups.
  • OpenShift includes important virtual groups, notably:
    • system:authenticated (users authenticated via the cluster’s OAuth identity providers)
    • system:unauthenticated (unauthenticated users; technically possible to grant limited access, though uncommon)

• Flexible “management philosophy” (context setting)

  • The episode discusses cluster management approaches (e.g., GitOps/DevOps-style thinking), emphasizing there isn’t a single “must be 100% X” method.
  • Organizations choose what fits their skills, tooling, and risk tolerance (“burn factor”).
  • Example: GitOps tooling can coexist with other operational practices; you can disable parts temporarily and reapply later.

Demonstrations / key methodologies (step-by-step)

A) Configuring HTTP basic authentication (htpasswd) with OpenShift OAuth

1. Create an htpasswd file locally (example mentions htpasswd -c ...).
2. Create a Kubernetes secret from the htpasswd file:
   • Example command: oc create secret generic hd-pass-secret
   • Put the ht password file contents into the secret (key/value name like htpassword).
   • Store it in the openshift-config namespace.
3. Configure OAuth to use the htpasswd identity provider
   • Update/apply an OAuth config that defines an identity provider of type htpasswd
   • Point it at the secret created above.
4. Validate behavior
   • Before logging in, oc get users shows no user objects.
   • After logging in with one of the htpasswd accounts, OpenShift creates the corresponding User object automatically on first successful authentication.
5. Authorization defaults
   • Authenticated users get default capabilities such as project self-provisioning (ability to create projects).
6. Optional: disable self-provisioning
   • The docs approach removes the group membership from the self-provisioning role:
     • Remove system:authenticated (or related membership) from the self-provisioners group/cluster role mapping (via the documented patch process).
7. Assign cluster-admin permissions to specific htpasswd users
   • Add cluster role bindings for users (example uses a pattern like oc adm policy add-cluster-role-to-user cluster-admin ... after the user exists/when it becomes associated).

Operational caveat shown: Users may not appear until they first authenticate. Permissions can still be granted to a username, but some bindings may appear only after/once the user exists in OpenShift.

---

B) Configuring LDAP / Active Directory authentication with OpenShift OAuth

1. Decide whether everyone should be able to authenticate
   • LDAP is usually restricted to a subset of AD users (not the entire directory), using filters and base DN.
2. Prepare Active Directory groups
   • Example approach:
     • Use groups like openshift-admins and openshift-users
     • Put intended AD users into the appropriate groups.
3. Understand required LDAP OAuth settings
   • Key configuration concepts:
     • LDAP URL / host
     • Base DN (where users are found)
     • Bind DN and bind credentials (service account used for LDAP queries)
     • User attribute mappings
     • Filter to restrict eligible users (the default filter described is broad, so use care)
4. Prefer correct connection strategy for AD
   • Target the domain name rather than a single DC host to reduce latency and use the nearest DC.
5. Configure LDAP provider via OAuth
   • Provide settings including:
     • service account for bind checking (bind DN + password stored in a secret)
     • mapping of sAMAccountName as the OpenShift ID/username
     • handling for insecure vs insecure=false:
       • insecure=true → unencrypted LDAP (389)
       • insecure=false → LDAPS behavior
6. Apply the OAuth changes and allow the cluster to reconcile
   • OAuth operator updates may take a few moments.
7. Test authentication
   • Log in with an AD user to verify OpenShift can authenticate.
   • Note: authentication ≠ authorization; the user may still lack permissions until groups/roles are configured.

---

C) Synchronizing AD groups to OpenShift for authorization (RBAC)

1. Why group sync is needed
   • OpenShift must reflect AD group membership in OpenShift Groups so RBAC can use those groups.
2. Use oc adm group sync (sync configuration)
   • Provide a sync configuration mapping:
     • which AD users to consider
     • which AD groups to sync
     • mapping rules (example mentions avoiding spaces by mapping CNs to simpler names)
   • Use allow lists / filtering so only chosen groups are synced.
3. Assign RBAC via OpenShift groups
   • After sync, bind cluster roles to groups (e.g., bind cluster-admin to the mapped openshift-admins group).
4. Automate periodic updates
   • Synced groups update whenever sync runs.
   • A Group Sync Operator can automate synchronization on a schedule/timeframe.
5. Operational note
   • The demo showed progression delays; otherwise the workflow is straightforward: sync groups → assign roles to those groups.

Additional topics covered (non-auth core, but present in episode)

Shutting down a cluster gracefully

• Turn off guest OS normally (no hard power-off described as preferred).
• Order doesn’t matter much if workers and control plane are shut down together.
• After shutdown, nodes may not return if certificates require reapproval.
• Recovery steps described:
  • Use admin kubeconfig (system admin cert-based)
  • Connect to the API and run:
    • oc get csr and approve pending CSRs
  • After approving, nodes should come back as certificates/CSRs resolve.
• Warning:
  • Earlier OpenShift versions required manual certificate management.
  • Automatic renewal exists in later versions (around OpenShift 4.4-era changes).

Version alignment: CoreOS vs OpenShift

• On fresh installs, node OS updates to the appropriate CoreOS variant via machine configuration.
• Use the newest CoreOS for the OpenShift “y” version (example logic: OpenShift 4.6 uses the newest CoreOS 4.6.y).
• Complexity for existing clusters when scaling with UPI/adding nodes:
  • Ignition version changes (Ignition 2 → 3, and later to 3.2) can require updating ignition files for new nodes.
  • Helper steps/scripts exist (CSI mentioned in chat) to update worker ignition to the new spec.
• IPI behavior:
  • Installer clones from an OVA/template based on the original cluster state.
  • Machine Config Operator handles OS updates after ignition is corrected, so UPI scaling issues are often fewer than with existing-cluster scaling.

Speakers / sources featured

Speakers

• Chris Short (OpenShift TV; co-host)
• Andrew Sullivan (Red Hat; host of the authentication/authorization walkthrough)

Sources referenced (documents/tools)

• OpenShift Documentation
  • Authentication/authorization sections
  • Disabling project self-provisioning
  • OAuth identity provider concepts
  • Group sync references
• OpenShift mirror download site: mirror.openshift.com
• OpenShift install resources / console references: cloud.redhat.com
• OpenShift CLI / commands (as demonstrated conceptually):
  • oc create secret ...
  • OAuth configuration updates (oc apply -f ...)
  • oc get csr, approving CSRs
  • oc get user, oc get users
  • oc adm policy ...
  • oc adm group sync
• Tools/services referenced
  • htpasswd (Apache tooling)
  • LDAP / Active Directory
  • Group Sync Operator (for automated group synchronization)
  • Keycloak mentioned as a user question (no detailed solution provided)

Organization / platforms

• Red Hat / OpenShift