Have you ever wondered how LDAP groups are synced? Are there benefits to using one authentication method over another? In previous episodes we’ve brushed up against the topic of authentication and authorization, but this week we’ve gone in-depth, looking at how it works, how to configure multiple methods, and answering your questions!
As always, please see the list below for additional links to specific topics, questions, and supporting materials for the episode!
If you’re interested in more streaming content, please subscribe to the OpenShift.tv streaming calendar to see the upcoming episode topics and to receive any schedule changes. If you have questions or topic suggestions for the Ask an OpenShift Admin Office Hour, please contact us via Discord, Twitter, or come join us live, Wednesdays at 11am EDT / 1500 UTC, on YouTube and Twitch.
Episode 33 recorded stream:
Use this link to jump directly to where we start talking about today’s topic. During the stream we referenced a gist which had examples and additional information regarding authentication and authorization. You can find that gist here.
This week’s top of mind topics:
- Is there a recommended management philosophy for OpenShift and applications deployed to OpenShift? Red Hat and OpenShift offer, enable, and support multiple ways of managing clusters. Is there one way that’s better than others? Is there one that’s preferred? We talk about this in-depth on the stream, but the short answer is “no!” The way that we want you to manage your cluster and applications is the way that works best for you.
- Are there any special considerations when shutting down and restarting OpenShift clusters? Depending on how long the cluster has been down, you may need to re-approve the CSRs for the nodes. Make sure you have the kubeconfig file available so you can do certificate based authentication if you think this may happen. If you don’t have it, for whatever reason, you can create a new one.
- Does the version of Red Hat Enterprise Linux CoreOS I use to install new nodes need to precisely match the OpenShift version? No, you’ll want to use the most recent z-release for the y-version you’re using. For example, if your cluster is 4.6.x, use the most recent 4.6.x RHCOS version available on the mirror that is not newer than your OpenShift version. There are some nuances if you’re using IPI or if you’re adding new nodes to a UPI or non-integrated cluster that was originally 4.5 and is now 4.6 or later . Please watch or listen to the stream for details.
Questions answered during the stream:
- Can I have more than one cluster admin? Yes, you can, you only need to add the ClusterRole cluster-admin to the user or group as needed. We show doing that here.
- OpenShift has some basic user types and groups they are assigned to. These principles are important to understand as the basis for how to apply authorization rules to users and groups.
- Permissions can be assigned to a user account before the user account exists. The accounts are created by the authentication system, automatically, the first time a user logs in.
- We configure htpasswd authentication against an OpenShift cluster here, which is a quick and easy way to add basic authentication and user control to a cluster.
- Did you know you can use the admin interface to configure authentication providers? There’s a wizard for each of the provider types, making it easy to input the data needed.
- By default, authenticated users have the ability to provision their own Projects for applications. If you want to change that, you’ll need to remove the self-provision permission from the authenticated users group.
- Active Directory authentication is one of the most commonly used methods. Configuring the LDAP filters is important to ensure that only the users you want to login are allowed. Additionally, it’s recommended to use an Active Directory service account - one which doesn’t have permissions in OpenShift - for bind validation.
- The example LDAP filter we use during the stream works with Active Directory, including nested groups, to limit authentication to only specific groups.
- My preference is to use the domain name for the LDAP server name when using Active Directory for authentication. This means that Active Directory will automatically direct the authentication request to a domain controller that is local, or close by, to the site the request is coming from.
- Groups are synced separately, which you can find in the docs here, and the syncing needs to be done on a recurring basis. The gist that accompanies this stream has two suggestions for syncing groups: use a CronJob or use the Group Sync Operator.
