Managing Role-based Access Control (RBAC)

You are viewing documentation for a release that is no longer supported. The latest supported version of version 3 is [3.11]. For the most recent version 4, see

You can use the CLI to view and the administrator CLI to manage the roles and bindings.

Viewing roles and bindings

Roles can be used to grant various levels of access both as well as at the project-scope. can be associated with, or bound to, multiple roles at the same time. You can view details about the roles and their bindings using the command.

Users with the cluster-admin default cluster role bound cluster-wide can perform any action on any resource. Users with the bound locally can manage roles and bindings in that project.

To view the cluster roles and their associated rule sets:

To view the current set of cluster role bindings, which show the users and groups that are bound to various roles:

$ oc describe clusterrolebinding.rbac
Name:        admin
Labels:        <none>
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    admin
Subjects:
  Kind            Name                Namespace
  ----            ----                ---------
  ServiceAccount    template-instance-controller    openshift-infra
Name:        basic-users
Labels:        <none>
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    basic-user
Subjects:
  Kind    Name            Namespace
  ----    ----            ---------
  Group    system:authenticated
Name:        cluster-admin
Labels:        kubernetes.io/bootstrapping=rbac-defaults
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    cluster-admin
Subjects:
  Kind            Name        Namespace
  ----            ----        ---------
  ServiceAccount    pvinstaller    default
  Group            system:masters
Name:        cluster-admins
Labels:        <none>
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    cluster-admin
Subjects:
  Kind    Name            Namespace
  ----    ----            ---------
  Group    system:cluster-admins
  User    system:admin
Name:        cluster-readers
Labels:        <none>
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    cluster-reader
Subjects:
  Kind    Name            Namespace
  ----    ----            ---------
  Group    system:cluster-readers
Name:        cluster-status-binding
Labels:        <none>
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    cluster-status
Subjects:
  Kind    Name            Namespace
  ----    ----            ---------
  Group    system:authenticated
  Group    system:unauthenticated
Name:        registry-registry-role
Labels:        <none>
Annotations:    <none>
Role:
  Kind:    ClusterRole
  Name:    system:registry
Subjects:
  ----            ----        ---------
  ServiceAccount    registry    default
Name:        router-router-role
Labels:        <none>
Annotations:    <none>
Role:
  Kind:    ClusterRole
  Name:    system:router
Subjects:
  Kind            Name    Namespace
  ----            ----    ---------
Name:        self-access-reviewers
Labels:        <none>
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    self-access-reviewer
Subjects:
  Kind    Name            Namespace
  ----    ----            ---------
  Group    system:authenticated
  Group    system:unauthenticated
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
Name:        system:basic-user
Labels:        kubernetes.io/bootstrapping=rbac-defaults
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    system:basic-user
Subjects:
  Kind    Name            Namespace
  ----    ----            ---------
  Group    system:authenticated
  Group    system:unauthenticated
Name:        system:build-strategy-docker-binding
Labels:        <none>
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    system:build-strategy-docker
Subjects:
  Kind    Name            Namespace
  ----    ----            ---------
  Group    system:authenticated
Name:        system:build-strategy-jenkinspipeline-binding
Labels:        <none>
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    system:build-strategy-jenkinspipeline
Subjects:
  Kind    Name            Namespace
  ----    ----            ---------
  Group    system:authenticated
Name:        system:build-strategy-source-binding
Labels:        <none>
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    system:build-strategy-source
Subjects:
  Kind    Name            Namespace
  ----    ----            ---------
  Group    system:authenticated
Name:        system:controller:attachdetach-controller
Labels:        kubernetes.io/bootstrapping=rbac-defaults
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
  Kind:    ClusterRole
  Name:    system:controller:attachdetach-controller
Subjects:
  Kind            Name            Namespace
  ----            ----            ---------
  ServiceAccount    attachdetach-controller    kube-system
Name:        system:controller:certificate-controller
Labels:        kubernetes.io/bootstrapping=rbac-defaults
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:    ClusterRole
  Name:    system:controller:certificate-controller
Subjects:
  Kind            Name            Namespace
  ----            ----            ---------
Name:        system:controller:cronjob-controller
Labels:        kubernetes.io/bootstrapping=rbac-defaults
Annotations:    rbac.authorization.kubernetes.io/autoupdate=true
...

All of the default cluster roles can be bound locally to users or groups.

can be created.

The local role bindings are also viewable.

To view the current set of local role bindings, which show the users and groups that are bound to various roles:

$ oc describe rolebinding.rbac

By default, the current project is used when viewing local role bindings. Alternatively, a project can be specified with the -n flag. This is useful for viewing the local role bindings of another project, if the user already has the admin default cluster role in it.

$ oc describe rolebinding.rbac -n joe-project
Name:        admin
Labels:        <none>
Annotations:    <none>
Role:
  Kind:    ClusterRole
  Name:    admin
Subjects:
  Kind    Name    Namespace
  ----    ----    ---------
  User    joe
Name:        system:deployers
Labels:        <none>
Annotations:    <none>
Role:
  Kind:    ClusterRole
  Name:    system:deployer
Subjects:
  Kind            Name        Namespace
  ----            ----        ---------
  ServiceAccount    deployer    joe-project
Name:        system:image-builders
Labels:        <none>
Annotations:    <none>
Role:
  Kind:    ClusterRole
  Name:    system:image-builder
Subjects:
  Kind            Name    Namespace
  ----            ----    ---------
  ServiceAccount    builder    joe-project
Name:        system:image-pullers
Labels:        <none>
Annotations:    <none>
Role:
  Kind:    ClusterRole
  Name:    system:image-puller
Subjects:
  Kind    Name                    Namespace
  ----    ----                    ---------
  Group    system:serviceaccounts:joe-project

Adding, or binding, a to users or groups gives the user or group the relevant access granted by the role. You can add and remove roles to and from users and groups using oc adm policy commands.

When managing a user or group’s associated roles for local role bindings using the following operations, a project may be specified with the -n flag. If it is not specified, then the current project is used.

You can also manage cluster role bindings using the following operations. The -n flag is not used for these operations because cluster role bindings use non-namespaced resources.

For example, you can add the admin role to the alice user in joe-project by running:

$ oc adm policy add-role-to-user admin alice -n joe-project

You can then view the local role bindings and verify the addition in the output:

Creating a local role

1. To create a local role for a project, run the following command:

   $ oc create role <name> --verb=<verb> --resource=<resource> -n <project>

   In this command, specify: * <name>, the local role’s name * <verb>, a comma-separated list of the verbs to apply to the role * <resource>, the resources that the role applies to * <project>, the project name

   + For example, to create a local role that allows a user to view pods in the blue project, run the following command:

   +

   $ oc create role podview --verb=get --resource=pod -n blue

2. To bind the new role to a user, run the following command:

$ oc adm policy add-role-to-user podview user2 --role-namespace=blue -n blue

To create a cluster role, run the following command:

$ oc create clusterrole <name> --verb=<verb> --resource=<resource>

In this command, specify:

• <name>, the local role’s name

• <verb>, a comma-separated list of the verbs to apply to the role

• <resource>, the resources that the role applies to

For example, to create a cluster role that allows a user to view pods, run the following command:

Cluster and local role bindings

A cluster role binding is a binding that exists at the cluster level. A role binding exists at the project level. The cluster role view must be bound to a user using a local role binding for that user to view the project. Create local roles only if a cluster role does not provide the set of permissions needed for a particular situation.

Some cluster role names are initially confusing. You can bind the cluster-admin to a user, using a local role binding, making it appear that this user has the privileges of a cluster administrator. This is not the case. Binding the cluster-admin to a certain project is more like a super administrator for that project, granting the permissions of the cluster role admin, plus a few additional permissions like the ability to edit rate limits. This can appear confusing especially via the web console UI, which does not list cluster role bindings that are bound to true cluster administrators. However, it does list local role bindings that you can use to locally bind cluster-admin.

During a cluster upgrade, and on every restart of any master, the are automatically reconciled to restore any missing permissions.

If you customized default cluster roles and want to ensure a role reconciliation does not modify them:

1. Protect each role from reconciliation:

   $ oc annotate clusterrole.rbac <role_name> --overwrite rbac.authorization.kubernetes.io/autoupdate=false

2. Generate a default bootstrap policy template file:

   $ oc adm create-bootstrap-policy-file --filename=policy.json

   The contents of the file vary based on the OKD version, but the file contains only the default policies.

3. Update the policy.json file to include any cluster role customizations.

4. Use the policy file to automatically reconcile roles and role bindings that are not reconcile protected:

   $ oc auth reconcile -f policy.json

5. # oc adm policy reconcile-sccs \
       --additive-only=true \