Accepted Solutions
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:
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.
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:
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.
