You might have missed it as there wasn’t a lot of press, but IBM recently acquired a small startup called Red Hat. As with many IBMers, I have been on a steep learning curve to understand the capabilities this brings. As an interesting exercise, I thought I’d treat the OpenShift stack as an identity project and look at how the identities their access in the various layers of the stack could be managed and governed.
This article provides an overview of the Red Hat OpenShift stack and the Identity Governance and Administration (IGA) aspects of it. The stack is also a great candidate for Privileged Access Management (PAM). The article does not provide a detailed explanation of Red Hat Open Shift or Red Hat Enterprise Linux. Where appropriate I will highlight where IBM Security capabilities apply.
Note, this article is concerned with the Red Hat OpenShift stack not the Red Hat OpenStack which is a different (but related) technology set.
Red Hat OpenShift and Other Components in the Stack
Red Hat OpenShift (https://www.openshift.comand https://www.redhat.com/en/technologies/cloud-computing/openshift) is, to quote the Red Hat website, “an enterprise-ready Kubernetes container platform with full-stack automated operations to manage hybrid cloud and multicloud deployments.” It provides the middleware to run container-based applications in on-prem, private and public cloud environments. You will sometimes see it referred to as the “OpenShift Container Platform”.
The packaging of OpenShift contains both Red Hat Enterprise Linux (RHEL) and Red Hat OpenShift (RHOS). The OpenShift components are shown in blue in the following diagram and provide the container infrastructure and management and lifecycle automation for the containers. The Security capabilities include authentication and authorization.
From an identity perspective, it’s important to understand the layers in the stack. From bottom to top they are;
1. Infrastructure (in teal) – the underlying operating environment; physical or virtual servers, private or public clouds,
2. The Container OS (red) – labeled the “Enterprise-Grade Container OS”, which is Red Hat Enterprise Linux (RHEL),
3. RedHat OpenShift (blue) – based on Kubernetes and providing the runtime environment, and
4. The Applications (green) – the containers running the business applications
Lets look at these layers and the identity management implications in more detail.
Layer 1: The Underlying Infrastructure
The OpenShift stack can run on different types of infrastructure; physical or virtual servers or private or public clouds. OpenShift is running on RHEL, and RHEL is running on various platforms; physical servers, virtual servers, private or public clouds.
Where RHEL is running on physical servers, it is the native operating system. Thus, management of identities is just management of Linux accounts and groups.
If there are virtual servers, then there will be the OS underneath the hypervisor. The flavor of operating system will vary (dependent on the hypervisor) but there will be some form of operating system identities (Windows server, Linux/Unix, z/OS etc.) to be managed. These should be tightly controlled administrative users subject to Privileged Access Management (PAM) or highly-governed identity management.
OpenShift can run on many “clouds”, including RedHat Open Stack, AWS, Microsoft Azure public cloud, Google Cloud Platform, VMWare vSphere, and RedHat virtualization.https://blog.openshift.com/openshift-container-platform-reference-architecture-implementation-guides/.
When running on private or public cloud infrastructure, such as Amazon Web Services, there will be identities to manage. Each of these platforms have unique interfaces to manage them. For example:
- AWS has its own identities and access control tied to “accounts” (a customer using AWS services) and these identities can be managed via AWS APIs
- RedHat Open Stack uses a combination of LDAP for users and groups, and an internal component called “keystone” to manage the authorization objects (the authZ function (permissions, roles, projects))
Irrespective of the infrastructure underlying RHOS and RHEL, the identities should be tightly controlled administrative users subject to Privileged Access Management (PAM) or highly-governed identity management.
There are many identity adapters avalaible to support the different supporting infrastruture, from operating system adapters for Linux to cloud IaaS providers like Microsoft Azure and AWS. Adapter documentation can be found at https://www-01.ibm.com/support/docview.wss?uid=swg21689113.
Layer 2: The Container OS
Red Hat Enterprise Linux (RHEL) provides the foundation for Red Hat OpenShift (RHOS).
The native identities (locally stored credentials) will be RHEL users (and groups). Access control will be a mix of the traditional Unix file permissions and policy defined in SELinux (probably also su/sudo access). IGA integration for local identities will be some form of Linux connector leveraging SSH.
The RHEL implementation may also leverage remote authentication services via a Pluggable Authentication Module (PAM) that would also return the user and groups to Linux for authorization decisions using the access control mechanisms described above. This may be Active Directory (AD), Identity Management in Red Hat Enterprise Linux (IdM) or just LDAP (RH DS or Open LDAP) and Kerberos. IGA integration for these systems will vary, but most of these systems will support a LDAP connector or similar standard connector.
As with the identities in the underlying infrastructure, these identities should be tightly controlled administrative users subject to Privileged Access Management (PAM) or highly-governed identity management.
In addition to the Red Hat documentation, there is a detailed SELinux guide at: http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf
SELinux provides better security control over applications that use OpenShift because all processes are labeled according to the SELinux policy. For further information on Red Hat OpenShift and SELinux, see: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/chap-managing_confined_services-openshift.
As mentioned earlier, there is an IBM Security identity (IGI/ISIM) adapter for Linux. There are also LDAP adapters if RHEL is implemented with a remote LDAP via PAM.
Layer 3: Red Hat OpenShift
There are many components in OpenShift that may have their own access policy configuration, like Istio, but we will focus on the core OpenShift identity and access objects.
The OpenShift Container Platform implements a Role-based Access Control (RBAC) model. In addition to users and groups, it has the following objects:
- Rules – sets of permitted verbs on objects, like having permissions/rights on resources
- Roles – collections of rules, like (access) roles in most systems, and
- Bindings – associations between users and/or groups and roles
These objects may be tied to specific projects or apply to the entire cluster. The following figure is from the OpenShift documentation (https://access.redhat.com/documentation/en-us/openshift_container_platform/3.10/html-single/architecture/index#architecture-additional-concepts-authorization) and shows some examples.
Users in OpenShift may be regular users, system users and service accounts.
Note that from an identity governance perspective this model supports users being connected directly to roles. This means any governance solution that is only consuming users and groups may not see the entire picture of access all users have.
OpenShift provides a number of mechanisms to create and manage users:
- Just-in-time (JIT) provisioning – a user logs on to OpenShift and a user object is created
- API – APIs are available to create/manage users and groups
- LDAP Integration – OpenShift can integrate with a LDAP directory so that groups and group memberships in an LDAP directory match the groups and group memberships in OpenShift.
If LDAP Integration is used, there is a LDAP Synchronization function in OpenShift. The configuration of this includes mapping of LDAP groups to OpenShift groups and can also specify white- and black-lists of groups. This sync can be scheduled to run periodically via a cron job. There are also commands and the OpenShift API to drive synchronization.
So, any OpenShift deployment may have user and group objects stored in LDAP, and will have user, group, rules, roles and bindings definitions stored in etcd.
Management of users, groups and membership in LDAP will involve standard LDAP (or Microsoft Active Directory) connectors. This will be dependent on the LDAP sync in OpenShift.
Management of users, groups and memberships (and any other access-related objects) in OpenShift will involve using the OpenShift REST APIs for the different objects (e.g. https://docs.openshift.com/container-platform/3.11/rest_api/apis-user.openshift.io/v1.Group.htmlfor Groups).
Users in OpenShift may be privileged or regular users. Management of the privileged users should be via Privileged Access Management (PAM) or highly-governed identity management, whereas regular users can be managed using standard identity management processes.
There is currently no out-of-the-box IBM Security identity adapter for OpenShift. However as it is based on a REST API, building a bespoke one would not be a major challenge. There are Azure AD and LDAP adapters ready to use.
Layer 4: Applications and Containers
The “top” layer in the stack are the business applications running in containers, hosted and managed by OpenShift. These applications will have the same identity management challenges as any cloud applications. Management may be:
- Via an API directly into the application, either a standard like SCIM or bespoke API,
- To an application repository running on persistent storage, or
- To an enterprise repository (like Microsoft Azure Active Directory) that is leveraged by the application
At this layer you will have a mix of privileged users (more likely application administrators than infrastructure administrators) and ordinary users.
Management is no different from managing identities on other cloud applications, with standard connectors (like SCIM, LDAP) or application-specific connectors.
This concludes the exploration of the different layers in an OpenShift stack and the implications on identity management for each layer. The next section brings them together for a holistic view.
Provisioning & Governance of the Entire OpenShift Stack
As we have seen above, there are identity management needs at all layers of the stack. There are varying types of users at the different layers; from high-privilege (and high-risk) infrastructure administrators at the lower levels, up to privileged and ordinary application users at the higher layers. There are also varying types of systems with identities and access; some managed using standard interfaces (like LDAP) and others requiring bespoke integration using APIs.
A single identity management system could manage all the different types of users and their access membership. It could implement the different levels of controls (such as access approval) needed for the different levels of user. Either IBM Security Identity Manager (ISIM) or IBM Security Identity Governance and Intelligence (IGI) could meet this need.
Traditional identity management systems work best when accounts can be tied to individuals. Given the focus on privileged accounts in the lower layers of the stack, use of a Privileged Access Management (PAM) system would be advisable. PAM solutions control the credentials of the privileged accounts and who has access to them at any particular time – which is great for teams of administrators that need to share privileged accounts. IBM Security Secret Server (ISSS) would certianly meet this need, but may require some custom launchers and remote password changers to work with OpenShift.
Ideally you would leverage a combination of IGA and PAM solutions, with the IGA solution managing all the user-based access and access to the privileged accounts, and the PAM solution managing the privileged accounts themselves. This is shown in the following figure.
With a combined IGA+PAM solution, you can easily implement governance controls. You can see all the access for individuals – either directly managed in the IGA solution or via access into the PAM solution (e.g. John Smith can use the RHEL root account). You can apply access (re)certification to users and their access. There is out-of-the-box integration between IBM Security Identity Governance and Intelligence (ISI) and IBM Security Secret Server (ISSS).
You can also apply risk ratings to the accounts across the different layers (is access to a privileged account in the infrastructure or RHEL layer higher risk than one in OpenShift or the containers?). You can also apply Separation of Duties (SoD) controls to different accesses across the different layers. For example, it may be appropriate to highlight who has administrative privileges in both AWS and RHEL, or RHEL and OpenShift. This is the realm of IGI.
And as with any IGA solution, it makes sense to tie into an identity-aware Security Information and Event Manager (SEIM) platform, so you have visibility into what users are doing with the access they have. Of course this is a job for IBM QRadar SIEM.
One caution on identity governance. As we have seen some of the layers allow users to be connected directly to permissions. Most IGA systems will only manage users and groups, not permissions, so you may not get a complete picture of what access a user has. Even if the IGA system supports the extended data model with permissions and permission membership, consuming this fine-grained access from different layers in the stack (e.g. SELinux in RHEL, roles/rules in OpenShift) may be impractical.
Conclusion
In this article I have provided an introduction to the Red Hat OpenShift stack and explored each of the layers; the underlying infrastructure, the container OS (Red Hat Enterprise Linux), the OpenShift Container Platform, and the business applications running in containers.
For each layer I have explored the identity management implications. For most layers the identity management is following practices established over many years; users and/or groups, mapped to roles and/or permissions. Often standard interfaces, like LDAP, are used. Sometimes there are bespoke mechanisms leveraging APIs for managing identities and access.
The stack lends itself to a standalone IGA deployment managing all identities in one place. The large number of privileged accounts involved, particularly in the lower layers of the stack, suggest use of a Privileged Access Management (PAM) solution would be beneficial. A combined IGA and PAM solution would be optimum. This also supports the implementation of governance controls like access recertification and Separation of Duties controls.
An ideal solution to manage and govern identities in the OpenShift Stack comprises; IBM Security Identity Governance and Intelligence, IBM Security Secret Server and IBM QRadar SIEM.