How to Assign Kubernetes Roles and Permissions

Introduction

This tutorial will help you understand the Kubernetes RBAC (Role-Based Access Control) feature, which allows you to manage and control access to your Kubernetes cluster resources. You will learn how to define Kubernetes Roles and ClusterRoles, and how to apply them using Role Bindings and ClusterRole Bindings.

Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL kubernetes(("`Kubernetes`")) -.-> kubernetes/TroubleshootingandDebuggingCommandsGroup(["`Troubleshooting and Debugging Commands`"]) kubernetes(("`Kubernetes`")) -.-> kubernetes/BasicCommandsGroup(["`Basic Commands`"]) kubernetes(("`Kubernetes`")) -.-> kubernetes/AdvancedCommandsGroup(["`Advanced Commands`"]) kubernetes(("`Kubernetes`")) -.-> kubernetes/ConfigurationandVersioningGroup(["`Configuration and Versioning`"]) kubernetes/TroubleshootingandDebuggingCommandsGroup -.-> kubernetes/describe("`Describe`") kubernetes/BasicCommandsGroup -.-> kubernetes/create("`Create`") kubernetes/BasicCommandsGroup -.-> kubernetes/get("`Get`") kubernetes/AdvancedCommandsGroup -.-> kubernetes/apply("`Apply`") kubernetes/ConfigurationandVersioningGroup -.-> kubernetes/config("`Config`") subgraph Lab Skills kubernetes/describe -.-> lab-415230{{"`How to Assign Kubernetes Roles and Permissions`"}} kubernetes/create -.-> lab-415230{{"`How to Assign Kubernetes Roles and Permissions`"}} kubernetes/get -.-> lab-415230{{"`How to Assign Kubernetes Roles and Permissions`"}} kubernetes/apply -.-> lab-415230{{"`How to Assign Kubernetes Roles and Permissions`"}} kubernetes/config -.-> lab-415230{{"`How to Assign Kubernetes Roles and Permissions`"}} end

Understanding Kubernetes RBAC

Kubernetes RBAC (Role-Based Access Control) is a powerful feature that allows you to manage and control access to your Kubernetes cluster resources. RBAC provides a way to define and enforce authorization policies, ensuring that only authorized users or processes can perform specific actions within the cluster.

In Kubernetes, RBAC is implemented through the use of Roles and ClusterRoles, which define the permissions and access levels for different entities within the cluster. Roles are scoped to a specific namespace, while ClusterRoles are cluster-wide.

To understand RBAC in Kubernetes, let's explore the following key concepts:

Kubernetes Roles and ClusterRoles

Roles and ClusterRoles are the building blocks of RBAC in Kubernetes. They define the set of permissions that can be granted to users, groups, or service accounts.

A Role specifies the permissions for a particular namespace, while a ClusterRole defines permissions that span across the entire cluster.

Here's an example of a Role that grants read access to Pods in the "default" namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] ## "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

And an example of a ClusterRole that grants cluster-wide admin access:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Applying RBAC: Role Bindings and ClusterRole Bindings

After defining the Roles and ClusterRoles, you need to bind them to users, groups, or service accounts using Role Bindings and ClusterRole Bindings.

A Role Binding grants the permissions defined in a Role to a user, group, or service account within a specific namespace. A ClusterRole Binding grants the permissions defined in a ClusterRole to a user, group, or service account across the entire cluster.

Here's an example of a Role Binding that grants the "pod-reader" Role to the "alice" user in the "default" namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: read-pods
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

And an example of a ClusterRole Binding that grants the "cluster-admin" ClusterRole to the "admin" user across the entire cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

By understanding these RBAC concepts and applying them to your Kubernetes cluster, you can effectively manage and control access to your resources, ensuring that only authorized entities can perform specific actions.

Defining Kubernetes Roles and ClusterRoles

Kubernetes Roles and ClusterRoles are the fundamental building blocks of the RBAC (Role-Based Access Control) system. They define the specific permissions and actions that can be performed on Kubernetes resources.

Kubernetes Roles

A Role is a namespaced resource, meaning that it defines permissions within a specific namespace. This allows you to granularly control access to resources within a particular namespace.

Here's an example of a Role that grants read access to Pods in the "default" namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] ## "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

In this example, the "pod-reader" Role allows the associated subjects (users, groups, or service accounts) to perform the "get", "list", and "watch" actions on Pods in the "default" namespace.

Kubernetes ClusterRoles

A ClusterRole, on the other hand, is a cluster-scoped resource, meaning that it defines permissions that span across the entire Kubernetes cluster. ClusterRoles are useful when you need to grant access to cluster-level resources or perform cluster-wide actions.

Here's an example of a ClusterRole that grants cluster-wide admin access:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

In this example, the "cluster-admin" ClusterRole allows the associated subjects to perform any action ("") on any resource ("") across the entire Kubernetes cluster.

When defining Roles and ClusterRoles, you can specify the following key elements:

apiGroups: The API groups that the permissions apply to (e.g., "" for the core API group, "apps" for the apps API group).
resources: The Kubernetes resources that the permissions apply to (e.g., "pods", "deployments", "services").
verbs: The actions that the permissions allow (e.g., "get", "list", "watch", "create", "update", "delete").

By carefully defining Roles and ClusterRoles, you can precisely control the access and permissions within your Kubernetes cluster, ensuring that users, groups, and service accounts can only perform the necessary actions on the required resources.

Applying Kubernetes Role Bindings and ClusterRole Bindings

After defining the Roles and ClusterRoles in your Kubernetes cluster, the next step is to apply them by creating Role Bindings and ClusterRole Bindings. These bindings associate the defined permissions with specific users, groups, or service accounts.

Role Bindings

A Role Binding grants the permissions defined in a Role to a user, group, or service account within a specific namespace. This allows you to control access to resources within a particular namespace.

Here's an example of a Role Binding that grants the "pod-reader" Role to the "alice" user in the "default" namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: read-pods
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

In this example, the "read-pods" Role Binding associates the "pod-reader" Role with the "alice" user in the "default" namespace. This means that the "alice" user will have the permissions defined in the "pod-reader" Role, which allows them to perform "get", "list", and "watch" actions on Pods in the "default" namespace.

ClusterRole Bindings

A ClusterRole Binding grants the permissions defined in a ClusterRole to a user, group, or service account across the entire Kubernetes cluster. This is useful when you need to grant cluster-wide access or permissions.

Here's an example of a ClusterRole Binding that grants the "cluster-admin" ClusterRole to the "admin" user across the entire cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

In this example, the "admin-user" ClusterRole Binding associates the "cluster-admin" ClusterRole with the "admin" user. This means that the "admin" user will have full administrative access and permissions across the entire Kubernetes cluster.

By applying Role Bindings and ClusterRole Bindings, you can effectively control and manage the access and permissions of users, groups, and service accounts within your Kubernetes cluster, ensuring that they can only perform the necessary actions on the required resources.

Summary

Kubernetes RBAC is a powerful feature that enables you to define and enforce authorization policies within your Kubernetes cluster. By understanding Roles, ClusterRoles, Role Bindings, and ClusterRole Bindings, you can ensure that only authorized users or processes can perform specific actions within the cluster, ensuring the security and integrity of your Kubernetes environment.