Inside Kubernetes RBAC

By Andrew Chen and Dominik Tornow

Kubernetes is a Container Orchestration Engine designed to host containerized applications on a set of nodes, commonly referred to as a cluster. Using a systems modeling approach, this series aims to advance the understanding of Kubernetes and its underlying concepts.

The Kubernetes API is an Http API that provides Create/Read/Update/Delete access to query and modify the Kubernetes Object Store. Kubernetes supports multiple authentication and authorization strategies to control the access to the API.

Figure 1. Authentication, Impersonation, and Authorization Request Pipeline

This post provides a concise, detailed model of Kubernetes’ Role-based Access Control (RBAC), but may not be suitable as introductory material. The model is supported by partial specifications in TLA+.

Authorization

Conceptually, general authorization may be modeled as a relation hasAccess between a requesting user and a requested operation.

In this example

  • the tuples (U1, O1) and (U1, O2) are elements of the relation hasAccess.

Therefore the user U1 has access to the operations O1 and O2 but not to the operations O3 and O4.

Role-based Authorization

Conceptually, general role based authorization may be modeled as two relations, a relation matches between a role and a user and a relation grants between a role and an operation.

Role-based Authorization is an additive authorization concept, that is, access to an operation is denied implicitly and granted explicitly.

In this example

  • the tuple (R1, U1) is an element of the relation matches
  • the tuples (R1, O1) and (R2, O2) are elements of the relation grants.

Therefore, the user U1 has access to the operations O1 and O2 but not to the operations O3 and O4.

Kubernetes Role-based Authorization

Kubernetes provides 4 Kubernetes Object Kinds to express Role-based Authorization, Roles and Cluster Roles as well as Role Bindings and 
Cluster Role Bindings.

The remainder of this post describes how Kubernetes represents Users, Operations, Roles, Role Bindings and their relations.

The Requesting User

Figure 1. User

Figure 1. illustrates Kubernetes’ representation of the requesting user in the context of the authentication and authorization subsystem.

The Kubernetes authentication subsystem maps each incoming HTTP Request to a user.

Kubernetes distinguishes between

The Requested Operation

Figure 2. Operation

Figure 2. illustrates Kubernetes’ representation of the requested operation in the context of the authorization subsystem.

The Kubernetes authorization subsystem maps each incoming HTTP Request to an operation according to Tables 1.1 and 1.2

Table 1.1. Resource Requests as Operations for Namespace Kinds
Table 1.2. Resource Requests as Operations for Non-Namespace Kinds

Note, the Kubernetes API provides access to “Non-Resource Resources” like /api or /health. For brevity, this blog post ignores “Non-Resource Resources” but the same concepts apply.

Roles and Cluster Roles

Figure 3. Role Objects and Cluster Role Objects

Figure 3. illustrates Kubernetes Role Objects and Cluster Role Objects that are used to grant permission to perform a requested operation:

Role Binding and Cluster Role Binding

Figure 4. Role Binding Objects and Cluster Role Binding Objects

Role Binding Objects and Cluster Role Binding Objects are Kubernetes Objects that are used to bind a Subject and a Role or Cluster Role Object.

A Subject represents

  • a User Account
  • a Service Account, or
  • a Group

Note, that a Role Binding may reference Roles in the same namespace or Cluster Roles. However, a Cluster Role Binding may only reference Cluster Roles.

Granting Access

Finally, a requesting user has access to a requested operation if there exists a role binding so that the user matches the role binding and a referenced role so that the role grants the requested operation:

Note, that Role Bindings grant permission to operations targeting the same namespace, Cluster Role bindings grant permission to any operation
[Line 5 and Line 9].

Example

Listing 1.1 and Listing 1.2 show examples of a User Account foo@example.org and a Service Account ChaosMonkey. User Accounts and Service Accounts can (only) be distinguished by their distinct naming patterns.

Listing 1.1 User Account
Listing 1.2 Service Account

Listing 2.1 shows an example of a Cluster Role GrowPods that grants access to any operation on Kubernetes Pod Objects. Listing 2.2 shows an example of a Role SowChaos that grants access to List and Delete operations on Kubernetes Pod Objects.

Listing 2.1 Cluster Role
Listing 2.2 Role

Finally, Listing 3.1 shows an example of a Cluster Role Binding GrowPods that binds the group Editors and the Cluster Role GrowPods. Listing 3.2 shows an example of a Role Binding SowChaos, that binds the Service Account ChaosMonkey to the Role SowChaos.

Listing 3.1 Cluster Role Binding
Listing 3.2 Role Binding

In total, the User Account foo@example.org has access to any operation on Kubernetes Pods across all namespaces, the Service Account ChaosMonkey has access to List and Delete operations on Kubernetes Pods in the default namespace.