Guide to OpenShift authentication and authorization

Red Hat, the leader in Enterprise Open Source Software, prioritizes security as a fundamental aspect. Red Hat OpenShift, as a leading applications development platform, delivers many built-in security capabilities. This article discusses one critical aspect of OpenShift security: authentication and authorization.

OpenShift not only provides Kubernetes services, but it’s also a comprehensive development platform that delivers solutions for developers, DevOps, Ops, and security, so controlling access and permissions for users is important. OpenShift administrators can use the authentication and authorization pillars to manage who can access and interact with different components of the environment. Ignoring these two pillars of security is likely to put your organizations at risk.

Understanding authentication in OpenShift

In OpenShift, authentication verifies the users making requests to the OpenShift Container Platform API. Requests to the OpenShift Cloud Platform API are authenticated using OAuth Access Tokens or X.509 Certificates. Requests with invalid tokens or certificates result in a 401 error from OpenShift. If no access token or certificate is provided, the authentication layer assigns the system:anonymous virtual user and the system:unauthenticated virtual group to the request.

This lets the authorization layer determine which requests, if any, an anonymous user can make. This is intended mostly to identify a failed request to the rest of the API layers and does not grant any access. For granting access, there are a number of Identification Providers available within OpenShift. Depending on the solutions already in place in their organizations, administrators can leverage:

• htpasswd
• Request Header
• LDAP
• Active Directory
• GitHub/GitHub Enterprise
• GitLab
• Google
• Keystone
• Open ID Connect

OpenShift also supports the use of an OAuth Proxy via the OAuth Proxy Operator.

OpenShift authentication best practices

OpenShift authentication best practices starts with creating a well-defined set of policies that are continuously monitored. The following guidelines are a good place to start.

• When OpenShift is deployed, a kubeadmin user is automatically created. This should be removed as soon as an identity provider is configured.

• While OpenShift does have user objects, these are not intended to be used as a primary identity source. Oftentimes, using a centralized system of record (such as LDAP) is required by the security policies already in place, so administrators will want to incorporate the identity provider that is already being used in their organization. This will allow them to leverage any password policies, groups, and multi-factor authentication mechanisms that have already been put in place in their organization as these are created and managed outside of the OpenShift environment.

• By default, OpenShift will automatically create a user object for a user that logs in using an identity provider. This can be turned off if required.

• OpenShift also allows administrators to leverage groups to locally aggregate identities and manage permissions in a more maintainable way. OpenShift can also synchronize external groups from an LDAP server, dynamically provisioning them within OpenShift. The LDAP server doesn't need to be used as the identity provider to do this, either. This way, administrators can use an identity provider with stronger authentication as well as using LDAP for groups and authorization.

Understanding authorization in OpenShift

Authorization, however, should be managed within OpenShift to allow or restrict access to various resources. This can be done using the Role Based Access Control (RBAC) objects. The authorization objects include the rules, roles, and their bindings. There are two levels of RBAC roles and bindings that control authorization: Cluster RBAC and Local RBAC. A cluster role binding is a binding present at the cluster level, while a role binding exists at the project or namespace level.

To view a project, the cluster role view needs to be bound to a user using a local role binding. It's recommended to create local roles only when a cluster role fails to provide the required set of permissions for a specific situation. To emphasize an earlier statement, the kubeadmin user cannot be restricted using RBAC rules, which is why it is strongly recommended to remove kubeadmin user.

OpenShift authorization best practices

As a general rule, OpenShift administrators should always follow the principles of  least privilege when providing access in OpenShift. In other words, users should have access to only what they need and nothing else. This is possible by defining clear permissions and access rights using user roles. Some of our guidelines include:

• Administrators should also aim to remove groups that are no longer being used to simplify governance.

• OpenShift projects can be used to segregate workloads further by creating smaller access regions for users. For example, if a developer is hired for front-end design, there is no need for them to have access to back-end workloads. As such, these can be segregated using projects with the front-end developer only having access to the "Front-End" Project. This strategy helps reduce the possibility of resources being used by users who should not be using them as well as limiting possible threats from users being compromised. An attacker will have a much smaller attack vector if all they can see is a single project.

• There should also be a policy that removes or limits access to overly-privileged roles.
• There are a number of predefined cluster roles within OpenShift. These should be leveraged as much as possible as these are curated and maintained by the OpenShift team, since custom roles could result in unexpected behavior.

Beyond authorization and authentication

When done right, your OpenShift security strategy should follow your overall cloud-native security strategy, taking a comprehensive approach that includes the people, processes, and tooling involved. This includes adherences to DevSecOps principles of automation, collaboration, developer guardrails, shift-left, and using trusted and verified content sources.

Monitor your application’s runtime environments by leveraging monitoring and security solutions such as threat detection, events logging, and incident response is also of the highest importance. OpenShift administrators should take advantage of security-focused OpenShift Operators such as the Compliance Operator, File Integrity Operator, Security Profile Operator, and cert-manager Operator to ensure that the environment remains hardened and compliant with the standards required by the organization. Kubernetes network policies should be implemented using zero-trust and least principles.

By keeping all these in mind, and capitalizing on the complimentary products in OpenShift Platform Plus, like Advanced Cluster Security, Quay, Advanced Cluster Management, and Red Hat Data Foundations, administrators can shift security left and provide better protection for their environment from against external and internal threats while minimizing downtime caused by security incidents or issues.

Check out Red Hat OpenShift Platform Plus to see how it can help you build, deploy, scale, and manage cloud-native applications with advanced multi-cluster security and management capabilities.