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 config.openshift.io/v1 OAuth with some small tweaks to simplify the input.
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.
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.
RBAC rules are set up in order to allow a sudo like method to gain cluster-admin privileges.
By default only
impersonate permissions are granted to the group defined in
Using user impersonation, permissions can be escalated to full
oc --as cluster-admin get nodes
The component deploys an Espejo syncconfig which deletes the
kubeadmin secret in namespace
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