IAM integration with OpenShift

This topic contains the implementation details of IBM Cloud Private authentication and authorization integration with Red Hat OpenShift. OpenShift is integrated to the authentication of IBM Cloud Private and authorization frameworks.

Design considerations

1. OpenShift uses projects, whereas IBM Cloud Private uses namespaces. Projects and namespaces are treated as is in OpenShift and IBM Cloud Private. No cross mapping is done automatically.
2. The Kube API server of OpenShift doesn’t run on the 8001 port. The IBM Cloud Private management console currently uses port 8001 on the Configure Client page.
3. The authentication and authorization administration happens through IBM Cloud Private. The flow is only from IBM Cloud Private to OpenShift. If a user is created on OpenShift, it doesn’t flow back to IBM Cloud Private.

Authentication

Integration with the IBM Cloud Private OIDC provider

IBM Cloud Private authentication is backed by its OIDC provider that runs on WebSphere Liberty. The OpenShift authentication is integrated with the IBM Cloud Private authentication service as described in the OpenID Connect topic. This authentication service configuration in which OpenShift uses IBM Cloud Private OIDC authentication happens automatically at the end of the security services installation on IBM Cloud Private.

LDAP integration

IBM Cloud Private user authentication heavily relies on its integration with the Enterprise Lightweight Directory Access Protocol (ELDAP) server. The IBM Cloud Private OIDC provider is backed by the Liberty server. So when the Liberty server is configured with an LDAP via IBM Cloud Private, the authentication should work without issues from the OpenShift console as well. This means users that are defined on the LDAP can log in to OpenShift and they are authenticated by the OIDC and Liberty server of IBM Cloud Private after the OIDC integration is achieved.

User groups

With IBM Cloud Private, you can import user groups from the LDAP. OpenShift also supports user group by mandating a user group record that is created on OpenShift. The IBM Cloud Private with OpenShift integration handles the creation of the respective user group record on OpenShift internally when administered through the IBM Cloud Private Team Administration page. The following code is an example of the OpenShift user group record:

apiVersion: v1
kind: Group
metadata:
  annotations:
    openshift.io/ldap.sync-time: 2015-10-13T10:08:38-0400
    openshift.io/ldap.uid: cn=admins,ou=groups,dc=example,dc=com
    openshift.io/ldap.url: LDAP_SERVER_IP:389
  creationTimestamp:
  name: Administrators
users:
- jane.smith@example.com
- jim.adams@example.com

Tokens

IBM Cloud Private works with two tokens:

• Access token: This is provided by the Liberty server and is used for authentication in IBM Cloud Private.
• Identity token: This token is generated by the platform-identity-provider of IBM Cloud Private and is used for authentication and authorization to Kube API server and the kubectl CLI.

Postintegration of OpenShift to use our OIDC service, the identity token is replaced by the OpenShift token in the platform-identity-provider. Calls to the Kube API server and the kubectl CLI continue to work without requiring changes from the UI for both IBM Cloud Private and OpenShift.

Authentication impacts on the UI

• IBM Cloud Private CLI: Login will work as is without changes.
• IBM Cloud Private management console: No impact. The access token is available in the cookie and the identity token is available through the identitytoken API. The IAM calls with the access token and the Kube calls with the identity token continue to work as is.
• OpenShift CLI: The OpenShift CLI currently does not support login integration with the OIDC provider. This is due to authentication on OpenShift via the OIDC provider that happens only through the OAUTH Dance on the browser. In order to log in to the OpenShift CLI, it is necessary to get the token from the GUI. For example, the Copy Login Command menu from the OpenShift GUI and the Configure Client menu on the IBM Cloud Private management console.
• OpenShift GUI: No impact. The token work as is without changes.

Authorization

IBM Cloud Private integrates two authorization models namely the Cloud IAM and the Kubernetes RBAC. The IBM Cloud Private with OpenShift integration continues to support both authorization models.

The Kubernetes authorization in IBM Cloud Private is driven by the team-based role binding information that is present in the identity token. Because there’s no team concept in OpenShift, the Kubernetes authorization is driven by the Cluster role binding and the Project and Namespace role binding for the user and the user groups. This model works well with both IBM Cloud Private and OpenShift.

Role mapping

OpenShift roles

• cluster-admin
• admin
• edit
• view
• deployer
• image-builder
• image-puller

Mapping IBM Cloud Private roles

• Cluster administrator (cluster-admin)
• Administrator (admin)
• Operator (edit)
• Editor (edit)
• Viewer (view)

The cluster role bindings and the role bindings are created for the listed users and groups. The IBM Cloud Private to OpenShift role mapping is transparent to the user.

Authorization impacts on the UI

• IBM Cloud Private CLI: Authorization continues to work as is with the identity token. No impact.
• IBM Cloud Private management console: No impact. The identity token is available through the identitytoken API.The IAM calls with the access token and the Kube calls with the identity token continue to work as is.
• OpenShift CLI: No impact. Identity token can be fetched from the GUI. For example, the Copy Login Command menu from the OpenShift GUI and the Configure Client menu on the IBM Cloud Private management console. Rest work as is.
• OpenShift GUI: No impact. The token works as is without changes and the required authorization is enforced.