Understanding authentication in OpenShift 4

Looking to learn more about OpenShift 4 authentication and become familiar with user and group management? In this post, we'll dive into some of the pieces that make up OpenShift Authentication.

OpenShift contains a built-in OAuth server then distributes access tokens for users to authenticate to the API. You can configure something called an Identity Provider that's used to confirm your identity to allow access by your OAuth server. Once authenticated, you then have Users, Groups, and Service Accounts that can be granted roles that have specific types of access controlled by RBAC. These are just some of the pieces that make up the OpenShift 4 authentication process.

Let’s dive into the different pieces that make up OpenShift Authentication.

As mentioned above, OpenShift comes with a built-in OAuth server that acts like the bouncer at a club: if you're not on the list, you're not getting in. The internal OAuth server is located on the first control plane. Users obtain OAuth access tokens so they can authenticate to the OpenShift API. It checks with the identity provider of your choosing. 

The identity provider is similar to the VIP list that the Internal OAuth server uses to check to see what users are allowed access. When you first install your cluster, there is only the kubeadmin user and sometimes a developer user as well. One of the first things you will need to set up is your identity provider of choice. OpenShift supports nine different identity providers to use when authenticating. Here's a list:

• HTPasswd - This identity provider validates users and passwords against a flat file that is generated by using the htpasswd command.

• Keystone - This identity provider is used when installing OpenShift on OpenStack and uses the OpenStack Keystone server that stores the users in an internal database in OpenStack to share authentication.

• LDAP - This identity provider validates users and passwords against a LDAP version 3 server and uses simple bind authentication. This includes Active Directory authentication.

• Basic Authentication - This identity provider is a generic backend integration. User credentials are validated against a remote identity provider. 

• Request Header - This identity provider identifies users from request header values. The values are headers like X-Remote-User. This identity provider  is normally used in combination with an authenticating proxy. The authenticating proxy usually sets the request header value that the identity provider will use.

• GitHub - This identity provider validates users and passwords against GitHub or GitHub Enterprise’s OAuth server.

• GitLab - This identity provider validates users and passwords against GitLab or any other GitLab instances.

• Google - This identity provider validates users and passwords against Google’s OpenID Connect integration.

• OpenID Connect - This identity provider validates users and passwords against an OpenID Connect identity provider using an Authorization Code Flow.

Users can then be assigned roles with permissions to resources in a project, or cluster-wide. This is accomplished using RBAC.

Or Role-based Access Control determines whether a user can perform an action within a project. There are seven default cluster roles you can use to bind users and groups. These roles can be used cluster-wide or locally in a project.

Here are a list of the default cluster roles:

• admin - Has the ability to view and modify any resource in the project except for quota.

• cluster-admin - This is a super-user for the cluster. They can perform any action in any project. It is recommended to create a cluster admin and disable the kubeadmin login.

• cluster-status - These users assigned this role can view basic cluster status information. Good for monitoring purposes. 

• self-provisioner - This role allows users to be able to create their own projects.

• basic-user - Users who are assigned this role will be able to get basic project and user information.

• view - Users who are assigned this role will be able to see most objects in a project but not modify them. 

• edit - Users who are assigned this role will be able to see and modify most objects with the exception of role and bindings.

These roles can be assigned to users, groups, and service accounts to allow them to perform specific tasks. Let’s take a look at each one.

A user in OpenShift is an entity that requests access to the OpenShift API. A user once granted access can then be assigned roles to grant specific access to resources in a project or cluster.

A group is a collection of users. Administrators usually group users together that would need the same access and grant the group the necessary role needed for resource access. This is a far more efficient way to disperse permissions to resources since you would only need to add a user to a group rather than assign every user individually the same role.

A service account is an account that can allow a component to access the API directly. It allows you to control API access without using a regular user's credentials which is a better way considering how often a regular user's roles and access can change.

These are just a few of the topics I will dive into on our journey through my OpenShift 4 Authentication and User Management course. If you want to learn more about authentication, user and group management, and resource access control, please join me in my adventures with OpenShift 4!