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.
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.
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.
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 cluster-read and impersonate permissions are granted to the groups defined in openshift4_authentication.sudoGroups.
Using user impersonation, permissions can be escalated to full cluster-admin:
oc --as cluster-admin get secretThe 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.
See how-to and explanation for further details.
Impersonating Users
impersonate permissions are granted to the groups defined in openshift4_authentication.sudoGroups.
This allows users in the sudoers group to impersonate other users in the cluster.
This is especially useful for debugging RBAC issues affecting other users. You can check the permissions of a user or service account by running:
kubectl --as=system:serviceaccount:NS:SERVICEACCOUNT auth can-i get deployments/test
kubectl --as=USER auth can-i get deployments/testWhen impersonating a user, their groups aren’t included in the impersonation. It’s however possible to add groups to the impersonated user:
kubectl --as=USER --as-group=GROUP auth can-i get deployments/test (1)| 1 | It’s not necessary to pass an existing user if you only want to impersonate groups. |
Group impersonation is only possible when impersonating a user.
Impersonation is logged in the Kubernetes API server audit logs.
❯ oc adm node-logs --role=master --path=kube-apiserver/audit.log | grep "impersonatedUser" | jq
{
"kind": "Event",
[...]
"verb": "get",
"user":
{
"username": "chuck.testa",
},
"impersonatedUser":
{
"username": "john.dwight",
"groups": ["system:authenticated"]
},
[...]
}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 |