In cloud computing, role-based access control (RBAC) connects a user to a specific role, where a role is a collection of permissions applied to either a project or to an entire cluster. To work with RBAC, you must recognize that different types of users exist, and each can be used with these roles.
Verbs such as
patch are used to manage permissions. They're crucial parameters when defining roles, which are API resources that provide access to OpenShift resources.
OpenShift, Red Hat's enterprise-ready Kubernetes container platform, includes several cluster roles by default. In most cases, the default roles are all you need when setting up user permissions. However, understanding users and roles is an important part of managing a cluster with OpenShift.
A user is granted access to cluster resources using role bindings and is created as a specific user type. For example, there are regular users, system users, and service accounts.
- The regular user role defines an object granted access to a cluster platform.
- The system user role is automatically created when infrastructure is defined to allow system components access to a specific resource.
Examples of system users include:
- The system:admin account provides full admin access.
- The system:openshift-registry account offers registry access.
- The system:node:server1.example.com account gives node access.
- An anonymous user account is for unauthenticated requests.
The service account role is a special system account (often generated automatically at project initialization) that provides extra privileges to pods or deployments.
[ Get this complimentary eBook from Red Hat: Managing your Kubernetes clusters for dummies. ]
Examples of service accounts and their functions include:
- The system:serviceaccount:default:deployer service accounts are used to create deployments.
- The system:serviceaccount:foo:builder service accounts are used to create configurations in Source-to-image (S2I).
In most cases, OpenShift's default roles are sufficient for setting up permissions for users. They can be applied locally or to the entire cluster.
- The view role allows users to view but not modify any project resources.
- The edit role permits modifying and creating common application resources but gives no access to permissions, limit ranges, or quotas that also correspond to the typical developer user.
- The self-provisioner role allows users to create new projects (all users have self-provisioner by default).
- The basic-user role provides read access to projects.
- The cluster-admin role allows users to perform any action in the cluster.
- The cluster-status role permits users to request status information.
- The admin role gives full control and permissions to project resources.
Sometimes, you need more granularity when granting permissions. You can achieve this by creating either a local role or a cluster role to provide access to project-based resources.
Create a custom local role
To create a custom local role, use the
oc create command with the following syntax:
$ oc create role NAME --verb=VERB --resource=RESOURCE -n PROJECT
[ Learn some quick tips for using OpenShift's oc client. ]
The verb you use depends on the resource you're managing. For example, if you look at a pod as a resource, then valid verbs are
delete. If you want to grant a user permission to view pods within an OpenShift project called
demo1, for example, type the following:
$ oc create role podview --verb=get --resource=pod -n demo1 role.rbac.authorization.k8s.io/podview created
Manage custom local role RBAC with oc adm policy
Cluster administrators use the
oc adm policy command to manage cluster and namespace roles.
A role binding is essential because it connects your local custom roles and cluster roles to a user or group. Without a role binding, local roles and cluster roles are useless.
Add and bind the local custom role to a user in a specific namespace, and provide the role name and user name:
$ oc adm policy add-role-to-user podview johndoe --role-namespace=demo1 -n demo1 role.rbac.authorization.k8s.io/podview added: "johndoe"
Create a custom cluster role
Cluster roles can provide default permissions to any project. For example, you might create a cluster role to allow users to only view pods.
[ Get the Kubernetes glossary cheat sheet. ]
Creating a cluster role is similar to creating a custom local role. Use
oc create clusterrole, along with a name for the role you're creating, a verb, and a resource to create a cluster role. Here is an example:
$ oc create cluster role podviewonly --verb=get --resource=pod clusterrole.rbac.authorization.k8s.io/podviewonly created
Manage custom cluster role RBAC with oc adm policy
If you apply your new cluster role to a specific user, then that user can see pod information throughout the cluster. For this to be fully effective, you must add and bind this local custom cluster role to a user:
$ oc adm policy add-cluster-role-to-user podviewonly janedoe clusterrole.rbac.authorization.k8s.io/podviewonly added: "janedoe"
Verify local role binding
To see which local roles are assigned to a specific project (in this case,
demo1) with a non-cluster scope, use
oc describe rolebinding.rbac:
$ oc describe rolebinding.rbac -n demo1 | grep podview -A 10 Name: podview Labels: <none> Annotations: <none> Role: Kind: Role Name: podview Subjects: Kind Name Namespace ---- ---- --------- User johndoe Name: system:deployers Labels: <none> Annotations: openshift.io/description: Allows deploymentconfigs in this namespace to rollout pods in this namespace. It is auto-managed by a controller; remove subjects to disa...
Verify cluster role binding
For an overview of users, groups, and roles, use
oc describe clusterrolebindings.rbac. This command checks the custom cluster local role binding to the
podviewonly cluster role assigned to the user
$ oc describe clusterrolebindings.rbac podviewonly Name: podviewonly Labels: <none> Annotations: <none> Role: Kind: ClusterRole Name: podviewonly Subjects: Kind Name Namespace ---- ---- --------- User janedoe
[ Learn how to manage your Linux environment for success. ]
oc adm policy command provides an overview of all security credentials with specific permissions to perform an action. The
oc adm policy who-can command is very useful to view who has access to perform an action within a project. Here are two different ways of using this command:
$ oc adm policy who-can <verb> <resource> $ oc adm policy who-can get pod $ oc adm policy who-can delete user
This article introduces the basics of local roles and cluster roles for RBAC permissions. There's much more to learn, but the above information provides a head start. Explore OpenShift and its documentation to learn more.