How to Configure Cluster Permissions in OpenShift | DO280/EX280 Exam?

How to Configure Cluster Permissions in OpenShift | DO280/EX280 Exam?

Role-based Access Control (RBAC):

Role-based access control (RBAC) is a technique for managing access to resources in a computer system. In Red Hat OpenShift, RBAC determines if a user can perform certain actions within the cluster or project. There are two types of roles that can be used depending on the user’s level of responsibility: cluster and local.

Authorization Process

The authorization process is managed by rules, roles, and bindings.

Rule:

Allowed actions for objects or groups of objects.

Role:

Sets of rules. Users and groups can be associated with multiple roles.

Binding:

Assignments of users or groups to a role.

RBAC Scope

Red Hat OpenShift Container Platform (RHOCP) defines two groups of roles and bindings depending on the user’s scope and responsibility: cluster roles and local roles.

Cluster Role:

Users or groups with this role level can manage the OpenShift cluster.

Local Role:

Users or groups with this role level can only manage elements at a project level.

Managing RBAC Using the CLI

Cluster administrators can use the “oc adm policy” command to both add and remove cluster roles and namespace roles.

To add a cluster role to a user, use the “add-cluster-role-to-user” subcommand:

[user@redaix ~]$ oc adm policy add-cluster-role-to-user cluster-role username

For example, to change a regular user to a cluster administrator, use the following command:

[user@redaix ~]$ oc adm policy add-cluster-role-to-user cluster-admin username

To remove a cluster role from a user, use the “remove-cluster-role-from-user” subcommand:

[user@redaix ~]$ oc adm policy remove-cluster-role-from-user cluster-role username

For example, to change a cluster administrator to a regular user, use the following command:

[user@redaix ~]$ oc adm policy remove-cluster-role-from-user cluster-admin username

Rules are defined by an action and a resource. For example, the create user rule is part of the “cluster-admin” role.

You can use the “oc adm policy who-can” command to determine if a user can execute an action on a resource. For example:

[user@redaix ~]$ oc adm policy who-can delete user

Default Roles

Openshift ships with a set of default cluster roles that can be assigned locally or to the entire cluster.

admin:

Users with this role can manage all project resources, including granting access to other users to access the project.

basic-user:

Users with this role have read access to the project.

cluster-admin:

Users with this role have super access to the cluster resources. These users can perform any action on the cluster and have full control of all projects.

cluster-status:

Users with this role can get cluster status information.

edit:

Users with this role can create, change, and delete common application resources from the project, such as services and deployments.

These users can not act on management resources such as limit ranges and quotas, and cannot manage access permissions to the project.

self-provisioner:

Users with this role can create new projects. This is a cluster role, not a project role.

view:

Users with this role can view project resources, but cannot modify project resources.

Project administrators can use the “oc policy” command to add and remove namespace roles.

Add a specified role to a user with the “add-role-to-user” subcommand. For example:

[user@redaix ~]$ oc policy add-role-to-user role-name username -n project

For example, to add the user dev to the role basic-user in the wordpress project:

[user@redaix ~]$ oc policy add-role-to-user basic-user dev -n wordpress

User Types

Interaction with OpenShift Container Platform is associated with a user. An OpenShift Container Platform user object represents a user who can be granted permissions in the system by adding roles to that user or to a user’s group via rolebingings.

Regular users:

Most interactive OpenShift Container Platform users are reqular users, represented with the User object. This type of user represents a person that has been allowed access to the platform.

Examples of regular users include user1 and user2.

System users:

Many system users are created automatically when the infrastucture is defined, mainly for the purpose of enabling the infrastructure to securely interact with the API. System users include a cluster administrator (with access to everything), a per-node user, users for routers and registries, and various others. An anonymous system user is used by default for unauthenticated requests.

Examples of system users include: system:admin, system:openshift-registry, and system:node:node1.example.com

Service accounts:

These are special system users associated with projects. Some service account users are created automatically when the project is first created. Project administrators can create more for the purpose of defining access to the contents of each project. Service accounts are often used to give extra privileges to pods or deployments. Service accounts are represented with the ServiceAccount object.

Examples of service account users include “system:serviceaccount:default:deployer” and “system:serviceaccount:foo:builder”

  1. Log in to the OpenShift cluster and determine which cluster role bindings assign the self-provisioner cluster role.

1.1. Log in to the cluster as the “admin” user.

[student@redaix ~]$ oc login -u admin -p redhat https://api.ocp4.example.com:6443
Login successful.
...output omitted...

1.2. List all cluster role bindings that reference the self-provisioner cluster role.

[student@redaix ~]$ oc get clusterrolebinding -o wide | \
> grep -E 'NAME|self-provisioner'
NAME ROLE ...
self-provisioners ... ClusterRole/self-provisioner ...

2. Remove the privilege to create new projects from all users who are not cluster administrators by deleting the self-provisioner cluster role from the system:authenticated:oauth virtual group.

2.1. Confirm that the self-provisioners cluster role binding that you found in the previous step assigns the self-provisioner cluster role to the system:authenticated:oauth group.

[student@redaix ~]$ oc describe clusterrolebindings self-provisioners
Name: self-provisioners
Labels: <none>
Annotations: rbac.authorization.kubernetes.io/autoupdate: true
Role:
Kind: ClusterRole

Name: self-provisioner
Subjects:
Kind Name Namespace
---- ---- ---------
Group system:authenticated:oauth

2.2. Remove the self-provisioner cluster role from the system:authenticated:oauth virtual group, which deletes the selfprovisioners role binding.

[student@redaix ~]$ oc adm policy remove-cluster-role-from-group \
> self-provisioner system:authenticated:oauth
Warning: Your changes may get lost whenever a master is restarted, unless you
prevent reconciliation of this rolebinding using the following command:
oc annotate clusterrolebinding.rbac self-provisioner
'rbac.authorization.kubernetes.io/autoupdate=false' --overwrite
clusterrole.rbac.authorization.k8s.io/self-provisioner removed:
"system:authenticated:oauth"

2.3. Verify that the role has been removed from the group. The cluster role binding selfprovisioners should not exist.

[student@redaix ~]$ oc describe clusterrolebindings self-provisioners
Error from server (NotFound): clusterrolebindings.rbac.authorization.k8s.io "selfprovisioners"
not found

2.4. Determine if any other cluster role bindings reference the self-provisioner cluster role.

[student@redaix ~]$ oc get clusterrolebinding -o wide | \
> grep -E 'NAME|self-provisioner'
NAME ROLE ...

2.5. Log in as the leader user with a password of redhat.

[student@rediax ~]$ oc login -u leader -p redhat
Login successful.
...output omitted...

2.6. Try to create a project, the operation should fail.

[student@redaix ~]$ oc new-project test
Error from server (Forbidden): You may not request a new project via this API.

3. Create a project and add project administration privileges to the leader user.
3.1. Log in as the admin user.

[student@redaix ~]$ oc login -u admin -p redhat
Login successful.
...output omitted...

3.2. Create the auth-rbac project.

[student@redaix ~]$ oc new-project auth-rbac
Now using project "auth-rbac" on server "https://api.ocp4.example.com:6443".
...output omitted...

3.3. Grant project administration privileges to the leader user on the auth-rbac project.

[student@redaix ~]$ oc policy add-role-to-user admin leader
clusterrole.rbac.authorization.k8s.io/admin added: "leader"

4. Create the dev-group and qa-group groups and add their respective members.
4.1. Create a group called dev-group.

[student@redaix ~]$ oc adm groups new dev-group
group.user.openshift.io/dev-group created

4.2. Add the developer user to dev-group.

[student@redaix ~]$ oc adm groups add-users dev-group developer
group.user.openshift.io/dev-group added: "developer"

4.3. Create a second group called qa-group.

[student@redaix ~]$ oc adm groups new qa-group
group.user.openshift.io/qa-group created

4.4. Add the qa-engineer user to ga-group.

[student@redaix ~]$ oc adm groups add-users qa-group qa-engineer
group.user.openshift.io/qa-group added: "qa-engineer"

4.5. Review all existing OpenShift groups to verify that they have the correct members.

[student@redaix ~]$ oc get groups
NAME USERS
dev-group developer
qa-group qa-engineer

5. As the leader user, assign write privileges for dev-group and read privileges for qagroup to the auth-rbac project.
5.1. Log in as the leader user.

[student@redaix ~]$ oc login -u leader -p redhat
Login successful.
...output omitted...
Using project "auth-rbac".

5.2. Add write privileges to dev-group on the auth-rbac project.

[student@redaix ~]$ oc policy add-role-to-group edit dev-group
clusterrole.rbac.authorization.k8s.io/edit added: "dev-group"

5.3. Add read privileges to qa-group on the auth-rbac project.

[student@redaix ~]$ oc policy add-role-to-group view qa-group
clusterrole.rbac.authorization.k8s.io/view added: "qa-group"

5.4. Review all role bindings on the auth-rbac project to verify that they assign roles to the correct groups and users. The following output omits default role bindings assigned by OpenShift to service accounts.

[student@redaix ~]$ oc get rolebindings -o wide
NAME ROLE AGE USERS GROUPS ...
admin ClusterRole/admin 58s admin
admin-0 ClusterRole/admin 51s leader
edit ClusterRole/edit 12s dev-group
...output omitted...
view ClusterRole/view 8s qa-group

6. As the developer user, deploy an Apache HTTP Server to prove that the developer user has write privileges in the project. Also try to grant write privileges to the qa-engineer user to prove that the developer user has no project administration privileges.
6.1. Log in as the developer user.

[student@redaix ~]$ oc login -u developer -p developer
Login successful.
...output omitted...
Using project "auth-rbac".

6.2. Deploy an Apache HTTP Server using the standard image stream from OpenShift.

[student@redaix ~]$ oc new-app --name httpd httpd:2.4
...output omitted...
--> Creating resources ...
imagestreamtag.image.openshift.io "httpd:2.4" created
deployment.apps "httpd" created
service "httpd" created
--> Success
...output omitted...

6.3. Try to grant write privileges to the qa-engineer user, the operation should fail.

[student@redaix ~]$ oc policy add-role-to-user edit qa-engineer
Error from server (Forbidden): rolebindings.rbac.authorization.k8s.io is
forbidden: User "developer" cannot list resource "rolebindings" in API group
"rbac.authorization.k8s.io" in the namespace "auth-rbac"

7. Verify that the qa-engineer user only has read privileges on the httpd application.
7.1. Log in as the qa-engineer user.

[student@rediax ~]$ oc login -u qa-engineer -p redhat
Login successful.
...output omitted...
Using project "auth-rbac".

7.2. Attempt to scale the httpd application, the operation should fail.

[student@rediax ~]$ oc scale deployment httpd --replicas 3
Error from server (Forbidden): deployments.apps "httpd" is forbidden: User "qaengineer"
cannot patch resource "deployments/scale" in API group "apps" in the
namespace "auth-rbac"

8. Restore project creation privileges to all users.
8.1. Log in as the admin user.

[student@redaix ~]$ oc login -u admin -p redhat
Login successful.
...output omitted...

8.2. Restore project creation privileges for all users by recreating the self-provisioners cluster role binding created by the OpenShift installer.

[student@redaix ~]$ oc adm policy add-cluster-role-to-group \
> --rolebinding-name self-provisioners \
> self-provisioner system:authenticated:oauth
Warning: Group 'system:authenticated:oauth' not found
clusterrole.rbac.authorization.k8s.io/self-provisioner added:
"system:authenticated:oauth"

–The END —


2 thoughts on “How to Configure Cluster Permissions in OpenShift | DO280/EX280 Exam?

  1. olanzapine and ziprasidone both increase sedation viagra and cialis online Using quantitative real time PCR qRT PCR to estimate neomycin cassette numbers 32, the efficiency of iTAM induced Flp O mediated recombination in purified I ER SP C I73T I73T Flp AT2 cells isolated 1 week after induction was 89

Leave a Reply

Your email address will not be published. Required fields are marked *