Role-based Access Control (RBAC)

Role-based access control (RBAC) is a technique for managing access to resources in a computer system. Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project.

In OKD, 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 level of responsibility of the user: cluster and local.

Cluster administrators can use the cluster roles and bindings to control who has various access levels to the OKD cluster itself and all projects.

Developers can use local roles and bindings to control who has access to their projects. Note that authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.

Authorization is managed using:

Authorization object Description
Rules Sets of permitted verbs on a set of objects. For example, whether a user or service account can create pods.
Roles Collections of rules. You can associate, or bind, users and groups to multiple roles.
Bindings Associations between users and/or groups with a role.

There are two levels of RBAC roles and bindings that control authorization:

RBAC level Description
Cluster RBAC Roles and bindings that are applicable across all projects. Cluster roles exist cluster-wide, and cluster role bindings can reference only cluster roles.
Local RBAC Roles and bindings that are scoped to a given project. While local roles exist only in a single project, local role bindings can reference both cluster and local roles.

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.

This two-level hierarchy allows reuse across multiple projects through the cluster roles while allowing customization inside of individual projects through local roles.

During evaluation, both the cluster role bindings and the local role bindings are used. For example:

  • Cluster-wide "allow" rules are checked.
  • Locally-bound "allow" rules are checked.
  • Deny by default.