Configuring Granular Access for Eclipse Che Authorized Users

Even though the current trend is to split an infrastructure into a number of 'Fit For Purpose' clusters instead of having a gigantic monolith Kubernetes cluster, administrators still want to provide granular access and restrict certain functionality for particular users.

Note

A 'Fit For Purpose' Kubernetes 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 Eclipse Che it is recommended to have this type of cluster provisioned.

Previously, all users provisioned on a Kubernetes cluster had access to Eclipse Che, 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 Kubernetes level, and disable automatic namespace provisioning for Eclipse Che:

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 Eclipse Che Custom Resource: allowUsers, allowGroups, denyUsers, and denyGroups. Below you can find an illustration exemplifying the configuration:

 networking:
    auth:
      advancedAuthorization:
        allowUsers:
          - user-a
          - user-b
        denyUsers:
          - user-c
        allowGroups:
          - team-a
          - team-b
        denyGroups:
          - team-c

Important

AllowGroups and DenyGroups properties are only supported on OpenShift.

Users who are not allowed will not be able to use Eclipse Che and will see the following warning 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. Under the Users tab, all the accounts that have access to the cluster are listed e.g.

 

There are a few teams working on Eclipse Che with the corresponding OpenShift Groups created and managed on the cluster:

 

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 Eclipse Che 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 Eclipse Che. 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, remarks, and proposals on this work or anything else related to the project, through our mailing list, GitHub, or Slack.  
We wish you an enjoyable and productive coding experience with Eclipse Che!