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.
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 (R1, 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. 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
- User Accounts, representing a person, and
- Service Accounts, representing a technical entity.
The Requested 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
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. 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
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 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.
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.
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.
