Understanding Authentication & Authorization in OpenShift

In OpenShift or K8s, Authentication & Authorization are very crucial. These are required for cluster security. One must be authenticated (logged in) before your request can be authorized (granted permission to access). In this post, we’ll look at some of the components that comprise OpenShift Authentication & Authorization.

In this blog, we are going to learn:

1. Overview of authentication and authorization
2. Internal OAuth Server
3. Identity Providers
4. RBAC
5. Users
6. Groups
7. Service Accounts
8. Conclusion

Overview of authentication and authorization

A cluster administrator can enable user authentication to guarantee only allowed users have access to an OpenShift Container Platform cluster. Users must first authenticate to the OpenShift Container Platform API in some way before they can interact with an OpenShift Container Platform cluster. You may authenticate by including an OAuth access token or an X.509 client certificate in your OpenShift Container Platform API calls.

Authorization entails verifying whether the identified user has the necessary permissions to carry out the requested activity. Using RBAC components like rules, roles, and bindings, administrators may specify and grant rights to users. See Evaluating authorization to learn more about how authorization works in OpenShift Container Platform.

Projects and namespaces can also be used to restrict access to an OpenShift Container Platform cluster. You may utilise security context constraints to limit not just user access to a cluster, but also the activities a pod can do and the resources it can access (SCCs).

Internal OAuth Server

OpenShift has a built-in OAuth server that functions similarly to a club’s bouncer: if your name isn’t on the list, you won’t be in. On the first control plane is the internal OAuth server. Users get OAuth access tokens in order to authenticate themselves to the OpenShift API. It verifies your identification with the identity supplier of your choice.

Identity Providers

The identity provider is identical to the VIP list used by the Internal OAuth server to determine which users have access. When you first set up your cluster, there is simply the kubeadmin user and perhaps a development user. One of the first things you’ll need to do is choose an identity provider. When authenticating, OpenShift supports nine distinct identity providers. Here’s a rundown:

HTPasswd: This identity provider compares users and passwords to a flat file created by the htpasswd programme.

Keystone: When deploying OpenShift on OpenStack, this identity provider leverages the OpenStack Keystone server, which saves users in an internal database in OpenStack to share authentication.

LDAP:  This identity provider employs basic bind authentication to check users and passwords against an LDAP version 3 server. Authentication using Active Directory is included.

Basic Authentication: This identity provider is a backend integration that is general in nature. The credentials of the users are checked against a distant 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.

RBAC

Users can then be allocated roles that grant access to resources inside a project or throughout the cluster. RBAC is used to do this.
A user’s ability to do an activity within a project is determined by role-based access control. You can bind users and groups using one of the seven predefined cluster roles. These roles can be employed on a cluster-wide or project-specific basis.

The following are the default cluster roles:

Admin: Except for quota, the admin has the power to examine and alter any resource in the project.

Cluster-admin: This is the cluster’s superuser. They are capable of carrying out any activity in any project. It is advised that a cluster admin be created and the kubeadmin login be disabled.

Cluster-status: Users with this role have access to basic cluster status information. This is useful for monitoring.

Self-provisioner: With this job, users can construct their own projects.

Basic-user: Users with this position will have access to basic project and user information.

View: Users with this role can observe but not alter the majority of the elements in a project.

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.

Users

In OpenShift, a user is a person or entity who seeks access to the OpenShift API. Once a user has been granted access, roles may be established to allow specialized access to resources in a project or cluster.

Groups

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.

Service Accounts

A service account is one that allows a component to directly access the API. It enables you to govern API access without requiring a normal user’s credentials, which is preferable given how frequently a regular user’s responsibilities and access might change.

Conclusion

To access OpenShift Container Platform, each user must authenticate in some fashion. API requests with no or improper authentication are authenticated as requests from the anonymous system user. Policy governs what the user is permitted to do after they have been authenticated.

Related/References

• Openshift vs Kubernetes: What is the Difference?
• Kubernetes for Beginners
• Red Hat OpenShift- What, Why, and How?
• OpenShift For Beginners: 30+ Hands-On labs You Must Perform | Step-by-Step
• Deploy Applications Using OpenShift: Step-by-Step
• Install Single Node OpenShift Cluster (OKD): Step By Step
• OpenShift Official Documentation 

Next Task For You: Join Our FREE Class

The post Understanding Authentication & Authorization in OpenShift appeared first on Cloud Training Program.