eclipse-che
Default user cluster roles do not grant view or edit permissions in Kubernetes
Describe the bug
When provisioning a user + user namespace for workspaces on Kubernetes, Che by default attaches no clusterRoles to the new user. This means that although a user is created, they are unable to perform any actions in the cluster.
Che version
next (development version)
Steps to reproduce
- Install Che in Kubernetes
- Log in as new user and check permissions in the
<username>-chenamespace
Expected behavior
Che should by default bind the edit and view ClusterRoles to the user account during provisioning.
Runtime
Kubernetes (vanilla)
Screenshots
No response
Installation method
chectl/next
Environment
Linux
Eclipse Che Logs
N/A
Additional context
User provisioning code: https://github.com/eclipse-che/che-server/blob/470e5b86be8f31f19ae29a3d48bd3e8af73521bd/infrastructures/kubernetes/src/main/java/org/eclipse/che/workspace/infrastructure/kubernetes/namespace/configurator/UserPermissionConfigurator.java#L31-L37
Default cluster roles in che.properties: https://github.com/eclipse-che/che-server/blob/470e5b86be8f31f19ae29a3d48bd3e8af73521bd/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties#L344-L345
On OpenShift, when a user creates a project, they by default have the edit and view roles for that namespace.
@skabashnyuk would be great if the platform team prioritize this bug on k8s. Basically, the user is missing the edit rights in the namespace on k8s
I'm not sure about this issue. It doesn't look like a bug. Because I don't remember we need such a Roles before. If you are sure that roles have to be there just create a pr and change the defaults of the property https://github.com/eclipse-che/che-server/blob/470e5b86be8f31f19ae29a3d48bd3e8af73521bd/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties#L344-L345.
BTW if we have one k8s namespace per user, why do we need to grant them cluster roles?
BTW if we have one k8s namespace per user, why do we need to grant them cluster roles?
well, edit and view are the default user-facing cluster roles - https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles
it is really strange why this works on OpenShift but not on Kubernetes from the provisioning perspective.
If I recall correctly this feature https://github.com/eclipse-che/che-server/blob/470e5b86be8f31f19ae29a3d48bd3e8af73521bd/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/che/che.properties#L344-L345 was requested for some extraordinary roles for workspaces. If you really think these roles are needed I would add them during Che-operator namespace provisioning, not che-server's. It's identical for all users and has no che-server's specific. This way it would have more k8s native look.
@tolusha wdyt?
@amisevsk Could you clarify the problme you have? Which action? Any errors?
Pre-devfile v2, Che used its own serviceaccount to perform all actions on the cluster. With Devfile v2, the responsibility for creating resources is shifted to the dashboard, which uses the user's token in place of its own for various tasks.
On OpenShift, when a user runs oc new-project amisevsk-che, the new project is created with a rolebinding to the admin clusterrole for the user that created it:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: admin
namespace: amisevsk-che
subjects:
- kind: User
apiGroup: rbac.authorization.k8s.io
name: amisevsk
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
On Kubernetes, namespace management is somewhat different and these roles are not automatically provisioned, meaning that the Che user's kube token can perform no actions in their namespace by default.
For details on how these default roles are expected to be used, see docs. Since conceptually, the user "owns" their -che namespace, it makes sense to either grant view/edit or admin roles there.
BTW if we have one k8s namespace per user, why do we need to grant them cluster roles?
You can create rolebindings referencing clusterroles in order to grant that clusterrole's privilege to a user/serviceaccount in one specific namespace. This is different from creating a clusterrolebinding.
Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.
Mark the issue as fresh with /remove-lifecycle stale in a new comment.
If this issue is safe to close now please do so.
Moderators: Add lifecycle/frozen label to avoid stale mode.
Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.
Mark the issue as fresh with /remove-lifecycle stale in a new comment.
If this issue is safe to close now please do so.
Moderators: Add lifecycle/frozen label to avoid stale mode.