OpenShift 4 Authentication: A Commodore component to manage authentication (via OAuth) on OpenShift 4

OpenShift 4 Authentication: A Commodore component to manage authentication (via OAuth) on OpenShift 4 is a Commodore component for Managing the OpenShift 4 authentication config. The component allows to configure identity providers, templates to customize the look and feel of the login and the validity of the issued tokens.

This reflects the documentation provided by oc explain --api-version OAuth with some small tweaks to simplify the input.

The parameters openshift4_authentication.templates.(err,login,providerSelection) directly take the template string. The values will be written to a secret which then gets referenced in the OAuth CRD.

As of now, the parameter openshift4_authentication.identityProviders requires at least one provider config of type LDAP. The value of parameter openshift4_authentication.identityProviders must be a dictionary. However, the keys of the dictionary are only present to allow customizing the configuration of an identity provider later in the hierarchy. The keys themselves aren’t reflected anywhere in the generated configuration. Each value in the dictionary must be a valid identityProvider configuration for OpenShift 4. Additional provider configs can be of other types. The documentation requires to configure the LDAP bind password as a secret, and the CA certificate as a config map, the component accepts their literal value. Secrets and config maps will be created and referenced as needed only for LDAP provider configs.

LDAP Group Sync

The LDAP group sync is configured to sync and prune groups from LDAP. Configured groups are synced from the LDAP provider and will be pruned once deleted again in LDAP.

The sync cronjob is configured to be scheduled on the master nodes. The reason for this scheduling configuration stems from a combination of two factors: first, LDAP servers may be protected with IP allow-lists, and second, an OCP4 cluster may be deployed with public IPs for all nodes

If both of those factors are combined, we need to add all the master node IPs to the allow-list, so that the control plane can talk to the LDAP server. In this scenario, if the LDAP sync cronjob is scheduled on the master nodes, we don’t need to add additional infra or worker node IPs to the allow-list.

Cluster Admin Sudo

RBAC rules are set up in order to allow a sudo like method to gain cluster-admin privileges.

By default only view and impersonate permissions are granted to the group defined in openshift4_authentication.sudoGroupName. Using user impersonation, permissions can be escalated to full cluster-admin:

oc --as cluster-admin get nodes

See how-to and explanation for further details.

Removing the kubeadmin user

The component deploys an Espejo syncconfig which deletes the kubeadmin secret in namespace kube-system. This removes the kubeadmin user generated by the OpenShift installer, as described in the OpenShift docs. To avoid removing the user before other authentication methods are configured, the component ensures that the syncconfig is only deployed after the authentication configuration is deployed on the cluster.

Removing this user doesn’t affect the kubeconfig file generated by the OpenShift installer. The kubeconfig file uses a client certificate to authorize against the cluster as cluster-admin. This certificate remains valid even if the kubeadmin user is removed from the cluster. In order words, emergency access with kubeconfig is still possible.