edit and view are role or clusterrole

[fannullone]

According to student guide do280-4.12 chapter 3, edit and view are roles and not clusterrole.
Also by the RBAC guided exercise step 5.2, they are treated as role:
oc policy add-role-to-group edit dev-group

So why they dont show up in 'oc get role':
[student@workstation ~]$ oc get role -A | grep edit
openshift-monitoring monitoring-alertmanager-edit 2023-09-28T14:26:45Z
openshift-user-workload-monitoring user-workload-monitoring-config-edit 2023-09-28T14:26:45Z

but they show up in clusterrole:
[student@workstation ~]$ oc get clusterrole | grep "^edit"
edit 2023-09-28T14:07:30Z
?

[Natalie_Lind · Accepted solution]

Hi there! The edit and view roles are some of the default cluster roles. Cluster roles are defined at the cluster level, but can be bound at the cluster level or project level.

With local RBAC (at the namespace or project level) you can bind cluster roles to a user in a project by using local role bindings. This results in the user only having authorization for that role in the local project. In contrast, cluster RBAC binds cluster roles to a user at the cluster level, which results in the user having authorization for that role in all projects and at the cluster level.

If a user has a cluster-wide role binding to the cluster-admin cluster role, then they can use the oc adm policy command to manipulate policy in any project/namespace in the cluster (oc adm policy add-role-to-user <role> <username> -n <namespace>) or at the cluster level (oc adm policy add-cluster-role-to-user <role> <username>).

If a user has a namespace/project level or local role binding to the admin cluster role, then they can use the oc policy command to manipulate the local policy of a project (oc policy add-role-to-user <role> <username>). Cluster-admins can use this command too because they have authorization to execute any commands in the cluster.

To view the current set of local role bindings, which shows the users and groups that are bound to various roles in the current project, you can use the oc describe rolebinding.rbac command. If you execute that command in your project, then you should see the edit and view roles and the role bindings in your project.

[fannullone]

Please let me add also the following which I was finding very confusing; pls confirm that my statement is correct. These two commands have exaclty the same effect:
oc adm policy add-role-to-user edit user2 --rolebinding-name user2-rb
oc policy add-role-to-user edit user2 --rolebinding-name user2-rb

In fact the produce the same rolebinding manifest:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: "2024-03-05T16:47:23Z"
name: user2-rb
namespace: project2
resourceVersion: "454898"
uid: ffcb2ac3-9b60-4a4b-8ae8-09f35103b650
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: edit
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: user2

[M_Nabawy]

Hello
I tried them on the lab and found that they have the same result.

[fannullone]

Sorry to insist on this topic, but there is another point which I am very confused: suppose I want to make user1 admin for project1, which of the two is the correct approach:

oc policy add-role-to-user admin user1 -nproject1

oc adm policy add-cluster-role-to-user admin user1 -nproject1

The first creates a rolebinding in the project1, the second a clusterrolebinding, but both seem to work.