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.
The value of parameter
openshift4_authentication.identityProviders must be a dictionary.
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. The component supports any type of provider config which is supported by Openshift 4.
When configuring an LDAP identity provider which is secured with a certificate issued by a CA which is part of the system CA bundle, the LDAP server CA doesn’t need to be specified explicitly.
Otherwise, the CA can be provided as a literal string in field
ca of the LDAP identity provider config.
|Currently, the component only supports configuring a custom CA certificate for LDAP identity providers.|
Users should use the component’s secret configuration mechanism to deploy secrets containing identity provider credentials.
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 groups defined in
Using user impersonation, permissions can be escalated to full
oc --as cluster-admin get secret
The component also deploys a
RoleBinding and a
ClusterRoleBinding to ensure that users in the sudoers group can access the OpenShift cluster monitoring Alertmanager and its associated resources in the OpenShift console.
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