RBAC

Role-Based Access Control

Tutorial

Because Kubernetes RBAC is REST-based, it maps HTTP verbs to permissions. For example, POST is mapped to the create right.

The main recommendation is to give users the least privileges they need to get the job done.

Kubernetes objects are defined through different API specifications. RBAC is part of the rbac.authorization.k8s.ioAPI group — this group references four different types of Kubernetes objects:

• Role, (WHAT can be done)

  • can be constrained to specific namespaces

• ClusterRole, (WHAT can be done)

  • allows you to constrain access to resources that are cluster-wide, such as nodes

  • used for Non-resource REST Endpoints such as /healthz.

• RoleBinding, (WHO can do it)

• ClusterRoleBinding (WHO can do it)

Kubernetes RBAC differentiates between human resources and software resources:

• User Accounts manage the access rights for users,

• Service Accounts manage the access rights for software resources.

How kubectl works (partly). The API server executes the following operations sequentially:

• On receiving the request, authenticate the user.

  • When the validation fails, reject the request by returning 401 Unauthorized.

  • Otherwise, move on to the next stage.

• The user is authenticated, but do they have access to the resource?

  • If they don't, reject the request by returning 403 Forbidden.

  • Otherwise, continue.

Decoupling users and permission with RBAC roles