cancel
Showing results for 
Search instead for 
Did you mean: 
AmitPatel
Cadet
Cadet
  • 4,266 Views

Openshift user self-provisioner role

Jump to solution

Hi Geeks,

Can we remove self provisioner role for single user ? I don’t want one specifc user to create project just one user only ,  rest all are allowed to do anything.  How can I achieve this?  OCP 3.9. 

Does anyone have idea?

Thanks,

Amit

 

Labels (1)
1 Solution

Accepted Solutions
beelandc
Flight Engineer Flight Engineer
Flight Engineer
  • 4,248 Views

You have some potential options, depending on your environment. Unfortunately, I don't think that any of them are really as straightforward as we'd like.

With a default installation, self-provisioning is enabled with a ClusterRoleBinding that maps the self-provisioner role to a virtual group that represents authenticated users. I don't have a 3.9 cluster on-hand, but here is a screenshot from a 3.11 cluster that I have:Capture.PNG

Here you can see that the role is mapped to system:authenticated: oauth. Unfortunately, I'm not aware of a way to filter out an individual user that is mapped to a group that is mapped to the role.

Since all users authenticated with oauth are automatically included in the system:authenticated: oauth virtual group, you will need can remove that role-binding. However, then nobody will automatically get the self-provisioner role.

The only solution I see is to create a new group (ex: a project-provisioners group) that contains all users except the user(s) that you don't want to have that role. Then you can create or modify the ClusterRoleBinding for the self-provisioner role to map to that group instead of the system:authenticated: oauth group.

You would either need to add new users to that group manually, or use another mechanism to automatically map new users to the group. For example, if you use an LDAP provider to manage your users, you could potentially map users to the group with LDAP Group Sync

Another consideration to keep in mind if you go down this route is that there are some default cluster roles that are automatically reconciled to restore any missing permissions during a cluster upgrade, and on every restart of any master. I'm not entirely sure if this would impact any of the changes needed for the approach described above, but something to be aware of. If you see in the screenshot above, there is a rbac.authorization.kubernetes.io/autoupdate=true annotation. If you're seeing issues with the ClusterRoleBinding being updated automatically, I believe you need to update this annotation to = false. The link below describes how to manage this in greater detail.

  1. https://docs.openshift.com/container-platform/3.11/admin_guide/manage_rbac.html#updating-policy-defi...

View solution in original post

2 Replies
beelandc
Flight Engineer Flight Engineer
Flight Engineer
  • 4,249 Views

You have some potential options, depending on your environment. Unfortunately, I don't think that any of them are really as straightforward as we'd like.

With a default installation, self-provisioning is enabled with a ClusterRoleBinding that maps the self-provisioner role to a virtual group that represents authenticated users. I don't have a 3.9 cluster on-hand, but here is a screenshot from a 3.11 cluster that I have:Capture.PNG

Here you can see that the role is mapped to system:authenticated: oauth. Unfortunately, I'm not aware of a way to filter out an individual user that is mapped to a group that is mapped to the role.

Since all users authenticated with oauth are automatically included in the system:authenticated: oauth virtual group, you will need can remove that role-binding. However, then nobody will automatically get the self-provisioner role.

The only solution I see is to create a new group (ex: a project-provisioners group) that contains all users except the user(s) that you don't want to have that role. Then you can create or modify the ClusterRoleBinding for the self-provisioner role to map to that group instead of the system:authenticated: oauth group.

You would either need to add new users to that group manually, or use another mechanism to automatically map new users to the group. For example, if you use an LDAP provider to manage your users, you could potentially map users to the group with LDAP Group Sync

Another consideration to keep in mind if you go down this route is that there are some default cluster roles that are automatically reconciled to restore any missing permissions during a cluster upgrade, and on every restart of any master. I'm not entirely sure if this would impact any of the changes needed for the approach described above, but something to be aware of. If you see in the screenshot above, there is a rbac.authorization.kubernetes.io/autoupdate=true annotation. If you're seeing issues with the ClusterRoleBinding being updated automatically, I believe you need to update this annotation to = false. The link below describes how to manage this in greater detail.

  1. https://docs.openshift.com/container-platform/3.11/admin_guide/manage_rbac.html#updating-policy-defi...
AmitPatel
Cadet
Cadet
  • 4,222 Views

Thank you very much for the detailed explanation , Really appreciated.

Join the discussion
You must log in to join this conversation.