Even though the current trend is to split an infrastructure into a number of "fit-for-purpose" clusters instead of having a gigantic monolith Red Hat OpenShift cluster, administrators still want to provide granular access and restrict certain functionality for particular users.
Info alert: Info alert titleNote
A "fit-for-purpose" OpenShift cluster refers to a cluster that is specifically designed and configured to meet the requirements and goals of a particular use case or workload, tailored to optimize performance, resource utilization, and other factors based on the characteristics of the workloads it will be managing. For Red Hat OpenShift Dev Spaces, it is recommended to have this type of cluster provisioned.
Previously, all users provisioned on an OpenShift cluster had access to OpenShift Dev Spaces, and it was difficult to restrict the usage for certain accounts. One of the options for administrators was to remove permissions for namespace / project creation on the OpenShift level, and disable automatic namespace provisioning for OpenShift Dev Spaces:
devEnvironments:
defaultNamespace:
autoProvision: false
Considering this, new optional properties that allow setting up granular access for different groups and users have been added to the OpenShift Dev Spaces Custom Resource: allowUsers
, allowGroups
, denyUsers
, and denyGroups
. Here is an example to illustrate this configuration:
networking:
auth:
advancedAuthorization:
allowUsers:
- user-a
- user-b
denyUsers:
- user-c
allowGroups:
- team-a
- team-b
denyGroups:
- team-c
Unauthorized users will not be able to use Red Hat OpenShift Dev Spaces and will see the warning shown in Figure 1 when trying to access the User Dashboard.
Dogfooding in action
For internal development and dogfooding purposes, we use an OpenShift Dedicated cluster with GitHub identity provider setup, as shown in Figure 2. Under the Users tab, all the accounts that have access to the cluster are listed.
There are a few teams working on OpenShift Dev Spaces with the corresponding OpenShift groups created and managed on the cluster, as we can see in Figure 3.
Each OpenShift group explicitly defines a set of users that belong to it:
kind: Group
apiVersion: user.openshift.io/v1
metadata:
name: che-team-a
users:
- ibuziuk
- ...
The advancedAuthorization
property of the OpenShift Dev Spaces Custom Resource explicitly defines the groups which are allowed:
networking:
auth:
advancedAuthorization:
allowGroups:
- che-team-a
- che-team-b
- che-docs
Users who do not belong to the groups from the list above are not allowed to use Red Hat OpenShift. This configuration allows the cluster administrator to explicitly manage the onboarding and curate the access.
Conclusion
More details about advanced authorization can be found in the official documentation. As always, we look forward to your valuable feedback, comments, and remarks. We wish you an enjoyable and productive coding experience with Red Hat OpenShift Dev Spaces!