RBAC

1. Метафора

• Обліковий запис служби (Service Account, SA): “Cheedge” — це працівник (ідентифікаційна картка).
• Роль/ClusterRole: “Тільки для читання доступ до кожного банківського сейфу” (дозволи/авторизація).
• RoleBinding/ClusterRoleBinding: Контракт, що надає цьому чоловіку дозвіл на доступ до банківського сейфу.

Отже, згідно з вищенаведеним, цей чоловік може доступати банківський сейф щодня, але тільки для читання…

2. Визначення та використання

Після того, як ми розібрали базове значення цих понять, давайте розглянемо простий приклад, щоб контролювати операції create, delete, get і list для cm у поді:

Сценарій:

Надайте обліковому запису служби можливість створювати, видаляти, отримувати та перераховувати ConfigMaps у просторі імен default.

1. Створити Роль:

Визначте дозволи (отримати, перерахувати, створити, видалити cm у просторі імен default).

apiVersion: rbac.authorization.k8s.io/v1  
kind: Role  
metadata:  
 namespace: default  
 name: configmap-manager  
rules:  
- apiGroups: [""]  
 resources: ["configmaps"]  
 verbs: ["create", "delete", "get", "list"]

2. Створити Обліковий запис служби:

Представляє ідентичність пода.

apiVersion: v1  
kind: ServiceAccount  
metadata:  
 name: configmap-sa  
 namespace: default

3. Створити RoleBinding:

Надайте обліковому запису служби роль configmap-manager.

apiVersion: rbac.authorization.k8s.io/v1  
kind: RoleBinding  
metadata:  
 name: configmap-binding  
 namespace: default  
subjects:  
- kind: ServiceAccount  
 name: configmap-sa  
 namespace: default  
roleRef:  
 kind: Role  
 name: configmap-manager  
 apiGroup: rbac.authorization.k8s.io

4. Перевірити Налаштування:

Розгорніть под, який використовує обліковий запис служби, та перевірте дозволи:

apiVersion: v1  
kind: Pod  
metadata:  
 name: configmap-tester  
 namespace: default  
spec:  
 serviceAccountName: configmap-sa  
 containers:  
 - name: tester  
 image: bitnami/kubectl  
 command: ["sleep", "3600"]

Далі, виконайте команду в поді та спробуйте виконати команди:

kubectl exec -it configmap-tester -- /bin/sh  
kubectl create configmap test-config --from-literal=version=1  
kubectl get configmaps  
kubectl delete configmap test-config

Обліковий запис служби зможе виконувати лише ті дії, які дозволені роллю.

А якщо ми видалимо операцію create для cm, редагуючи role, тоді перевіримо ще раз і побачимо:

$ kubectl create configmap test-config --from-literal=version=1  
error: failed to create configmap: configmaps is forbidden: User "system:serviceaccount:default:configmap-sa" cannot create resource "configmaps" in API group "" in the namespace "default"

Тут ми бачимо повідомлення, яке говорить, що sa не може створювати cm.

5. Використовувати auth can-i для перевірки

Ми також можемо використовувати команду kubectl auth can-i для швидкої перевірки, чи можемо ми виконати певну дію з ресурсом.

kubectl auth can-i VERB RESOURCE --as=[USER|SA] -n NAMESPACE  
# наприклад  
$ k auth can-i create deploy --as=system:serviceaccount:ns1:view-sa -n ns1  
yes  
$ k auth can-i create deploy --as=new_user -n ns2  
no

Більше Деталей

Є ще деякі деталі, можливо, тривіальні, але краще їх роз'яснити.

1. Ролі ТІЛЬКИ Контролюють Ресурси Kubernetes

Role/ClusterRole стосується доступу до API:

• Ролі Kubernetes і ClusterRoles спеціально призначені для управління доступом до ресурсів API Kubernetes. Вони не поширюються на контроль за не-Kubernetes ресурсами, такими як файли, каталоги або системні процеси.
• Ці дозволи не "автоматично нічого не роблять", поки щось у поді не використовує їх, наприклад, kubectl, SDK Kubernetes (наприклад, client-go для Go), або інший інструмент, який взаємодіє з API Kubernetes.

Це означає, що якщо ви запустите под busybox з обліковим записом служби, який має дозволи на API, то под НЕ зможе нічого зробити з цими дозволами (якщо ви явно не встановите і не використовуватимете інструменти на кшталт kubectl або не напишете скрипт/застосунок, що робить API виклики).

Про користувача

Ми також можемо використовувати rolebinding (або clusterrolebinding), щоб прив'язати роль до користувача:

kubectl create rolebinding admin-binding \  
 --clusterrole=admin \  
 --user=user1 \  
 --user=user2 \  
 --group=group1 \  
 --namespace=default

Але для цього потрібна додаткова конфігурація, така як клієнтські сертифікати для автентифікації користувачів або створення контексту Kubernetes для користувача. Оскільки ми хочемо лише швидко поглянути на RBAC, як працюють sa, role, rolebinding разом, ми не будемо обговорювати випадок з користувачем. Якщо ви хочете більше деталей, зверніться до офіційної документації, тут.

3. Роль проти ClusterRole

• Використовуйте Roles: Коли вам потрібні дозволи, обмежені конкретним простором імен. Це безпечніше і більш обмежене.
• Використовуйте ClusterRoles: Коли вам потрібні дозволи для всього кластера (наприклад, для керування вузлами або ресурсами в кількох просторах імен).

Кращі практики:

• Використовуйте Roles де можливо, щоб зменшити область дії та потенційний ризик.
• Використовуйте ClusterRoles помірковано і тільки для завдань, які потребують дозволів на рівні всього кластера.

На практиці Roles є більш поширеними в багатокористувацьких кластерах, де простори імен ізолюють робочі навантаження. ClusterRoles використовуються для адміністративних завдань або операторами, які мають керувати ресурсами через простори імен.

4. Порівняння з концепціями хмарних сервісів

| **Kubernetes** | **AWS** | **Azure** |  
|------------------------------|-----------------------------------------|-------------------------------------|  
| **Service Account** | IAM Role/Instance Profile | Managed Identity |  
| **Role** | IAM Policy | Azure Role Definition |  
| **ClusterRole** | IAM Policy (with global permissions) | Azure Role Definition (global) |  
| **RoleBinding** | IAM Role Assignment (specific resource) | Role Assignment (specific resource) |  
| **ClusterRoleBinding** | IAM Role Assignment (global scope) | Role Assignment (global scope) |

Ключова різниця:

• У AWS та Azure концепції автентифікації та авторизації поєднуються в одну сутність (наприклад, IAM Role/Managed Identity), тоді як у Kubernetes ці процеси розділені (обліковий запис служби для автентифікації, роль для авторизації).

Оригінально опубліковано на https://notes-renovation.hashnode.dev 6 січня 2025.

Перекладено з: A glance of Kubernetes Role-Based-Access-Control (RBAC)