Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-19

1 RBAC (Role-based access control) - это система распределения прав доступа к различным объектам в кластере Kubernetes.Объекты в кластере Kubernetes - это YAML-манифесты, а права доступа определяют, какому пользователю можно только просматривать манифесты, а кто может их создавать, изменять или даже удалять.

2 Рассказываем, как устроен RBAC.

3 Материал подготовлен на основе лекции архитектора Southbridge Сергея Бондарева "Продвинутые абстракции Kubernetes" из курса <a>"Kubernetes База"</a>.

4 Пользователи кластера Kubernetes - это все, кто шлёт запросы в API-сервер, не только администраторы и разработчики, но и различные скрипты CI/CD, компоненты control plane, kubelet и kube-proxy на узлах, а также приложения, запущенные в кластере. В рамках модели контроля доступа на основании ролей есть 5 сущностей: Role, RoleBinding, ClusterRole, ClusterRoleBinding, ServceAccount. О них рассказываем в статье.

5 <h2>ServiceAccount</h2>

6 Начнём с конца. В Kubernetes есть самый простой тип пользователей, который называется ServiceAccount. Что же такое сервис аккаунт и чем он отличается от обычных пользователей?Дело в том, что Kubernetes ничего не знает о пользователях в том виде, в котором мы привыкли их видеть в других системах ограничения доступа, где у пользователей есть логин, пароль, группы и т. д. То есть внутри своих объектов Kubernetes никаких списков логинов, групп и паролей не хранит, но при этом у него есть механизмы вызова внешних сервисов проверки паролей, таких как oidc, есть вариант проверки пользовательского сертификата или даже обычный <a>HTTP Basic Auth</a> с классическим апачевским файликом htpasswd.

7 ServiceAccount был создан в первую очередь для ограничения прав ПО, которое работает в кластере. Всё общение между компонентами кластера идёт через запросы к API-серверу, и каждый такой запрос как раз авторизуется специальным JWT-токеном. Этот токен автоматически генерируется при создании объекта типа ServiceAccount и кладётся в secret.

8 В отличие от обычного пользователя, которому мы можем задать произвольный пароль, JWT-токен содержит внутри себя служебную информацию с названием ServiceAccount, Namespace и подписан корневым сертификатом кластера.Посмотреть содержимое JWT-токена можно, введя его в форму Debugger на сайте <a>https://jwt.io</a>

9 Далее этот secret монтируется внутрь контейнера, где работает наше приложение, и если приложение знает и умеет в Kubernetes, оно берёт токен из файла /var/run/secrets/kubernetes.io/serviceaccount/token, смонтированного из secret, и с ним делает запросы в API. Ничего не мешает взять из секрета этот сгенерированный токен и положить его в скрипт CI или отдать разработчику и объяснить, что с этим токеном он может делать запросы в API кластера. Когда разработчиков и CI в кластере немного, такой подход вполне приемлем - он простой и достаточно безопасный.

10 Перейдём в консоль и посмотрим на манифест ServiceAccount'а:

11 kubectl get serviceaccount

12 NAME SECRETS AGEdefault 1 2y298dВидим ServiceAccount default

13 Свой сервис аккаунт default есть в каждом неймспейсе, он создаётся автоматически. По умолчанию прав у этого аккаунта на доступ к API нет никаких.Смотрим внутрь:

14 k get sa default -o yaml

15 apiVersion: v1kind: ServiceAccountmetadata:creationTimestamp: "2019-05-18T20:08:00Z"name: defaultnamespace: defaultresourceVersion: "2120"uid: a2cf45e6-79a8-11e9-b6a7-fa163e91ccafsecrets:- name: default-token-2r2tz

16 Видим служебные поля и имя. Имя - это и есть то, что мы указываем при создании ServiceAccount. В поле secret лежит название секрета с токеном. Это поле добавляется контроллером автоматически.

17 Если посмотреть в secret, увидим там корневой сертификат кластера ca.crt. Он нужен, чтобы клиент был уверен, что он связывается именно с тем кластером, с которым надо. Есть поле namespace - оно показывает, в каком неймспейсе создан сервис аккаунт. И есть токен, с которым собственно и делаются запросы к API. Токен передаётся в заголовках HTTP-запроса.

18 Вы можете создать свой сервис аккаунт и указать его имя в манифесте пода, тогда при запуске контейнеров пода в них будет смонтирован секрет с токеном от этого сервис аккаунта. Если ServiceAccount не указывать, то будет смонтирован секрет от сервис аккаунта default.

19 Иногда говорят, что под в кластере Kubernetes работает с правами сервис аккаунта. Это приводит к путанице и проблемам в понимании принципов работы. Под нигде не работает, работает приложение. Приложение запущено в контейнерах пода на воркер-узлах и работает там как обычный Linux-процесс в самоизоляции. Всё!

20 Единственное, что происходит в кластере Kubernetes - kubelet монтирует токен внутрь контейнеров. И дальше уже приложение решает: если ему нужно обращаться к API кластера, будет ли оно брать токен из этого смонтированного секрета или возьмёт другой токен, например, запросит у пользователя.

21 <h2>Role</h2>

22 С сервис аккаунтами разобрались. Теперь рассмотрим, каким образом сервис аккаунтам выдаются права. Для этого используются ещё две сущности: Role и RoleBinding.Role - это YAML-манифест, который описывает некий набор прав на объекты кластера Kubernetes. Role ничего и никому не разрешает. Это просто список.Напомню, что объекты кластера - это YAML-манифесты, которые хранятся в etcd. Все права проверяются API-сервером и относятся к запросам, которые принимает API-сервер.

23 То есть если вы запретили девелоперу выполнять kubectl exec, но у него есть доступ на воркер-ноду, то зайти на воркер-ноду и сделать docker exec в контейнер RBAC запретить никак не сможет.

24 Идём в кластер и в ns ingress-nginx смотрим на роль: ingess-nginx

25 kubectl get role -n ingress-nginx ingress-nginx -o yaml

26 Нас интересует раздел rules - это список правил, описывающих права доступа.В каждом правиле у нас есть три параметра, например:

27 apiGroups:- extensions- networking.k8s.ioresources:- ingressesverbs:- get- list- watch

28 apiGroups - описывает API-группу манифеста. Это то, что написано в поле apiVersion: до слеша. Если в apiVersion указана только версия, без группы, например, как в манифесте Pod, то считается, что у этого манифеста так называемая корневая группа (core-group); в роли корневая группа указывается как пустая строка “”.

29 resourсes - список ресурсов, к которым мы описываем доступ, во множественном числе. Посмотреть список ресурсов в вашем кластере можно командой kubectl api-resources. Также есть подресурсы, описывающие специфические действия, например, подресурс pods/log разрешает просматривать логи контейнеров в поде.

30 verbs - список действий, которые можно сделать с ресурсами, описанными выше: получить, посмотреть список, следить за изменением, отредактировать, удалить и т.п. О том, что именно хотим сделать с объектом мы, согласно принципам REST, указываем типом HTTP-запроса ( GET, PUT, POST, DELETE) или кодируем в URL, если это какое-нибудь хитрое действие вроде watch или impersonate.

31 # GET /apis/networking.k8s.io/v1beta1/namespaces/{namespace}/ingresses/{name}- apiGroups: ["extensions", "networking.k8s.io"]resources: ["ingresses"]verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]# GET /api/v1/namespaces/{namespace}/pods/{name}/log- apiGroups: [""] # "" indicates the core API groupresources: ["pods", "pods/log"]verbs: ["get", "list"]

32 Посмотреть на примеры запросов к API-серверу проще всего, запуская команду kubectl get/create/delete с ключом ‘-v 6’.А ещё есть ResourceNames - c помощью этого поля можно указать название объекта и, например, дать права на изменение не всех configmap, а только одного конкретного configmap с именем ingress-controller-leader.Повторюсь, это просто список правил, объединённых в одну абстракцию. Никаких прав он никому не выдаёт. Для этих целей есть сущность RoleBinding - своим названием она нам говорит, что занимается назначением роли.

33 <h2>RoleBinding</h2>

34 Сразу смотрим в манифест Rolebinding:kubectl get rolebinding ingress-nginx -n ingress-nginx -o yamlВ нём есть два типа полей: roleRef и subjects:roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: ingress-nginxsubjects:- kind: ServiceAccountname: ingress-nginxnamespace: ingress-nginx- kind: Username: jane # "name" is case sensitiveapiGroup: rbac.authorization.k8s.io- kind: Groupname: developer # ex: organization in user certificateapiGroup: rbac.authorization.k8s.io

35 В roleRef указываем права из какой роли будут разрешены.subjects - кому будут разрешены эти права (или назначена эта роль).Если kind: ServiceAccount, то права выдаются сервис аккаунту ingress-nginx в неймспейсе ingress-nginx.

36 То есть API-сервер кластера при получении HTTP-запроса на действие с объектом кластера увидит в заголовке JWT-токен. Проверит, что токен подписан корневым сертификатом кластера. Возьмет из токена название сервис аккаунта и неймспейс и проверит соответствующие RoleBinding в кластере, чтобы узнать, разрешено ли производить запрошенное действие над объектом из запроса.

37 Но в списке subjects также есть kind: User и kind: Group. При этом команды `kubectl get user` и `kubectl get group` вернут сообщение, что в кластере нет ресурса такого типа.Что очень странно - ресурса нет, а kind: есть.

38 Эти kind нужны для того, чтобы описать разрешения для тех запросов, которые были аутентифицированы не через токен от сервис аккаунта, а другим способом. Например, через oidc, когда внешний сервис аутентификации прислал в ответе user и group, соответствующие oidc-токену. Или поля CommonName (CN) и Organization (O) из клиентского сертификата, который был предъявлен при отправке запроса по протоколу HTTPS/TLS.

39 <h2>ClusterRole</h2>

40 Role описывает права в неймспейсе, сущность Role неймспейс-зависимая, и мы можем создавать роли с одинаковым именем в разных неймспейсах.А Cluster Role - это кластерный объект, эта сущность описывает права на объекты во всём кластере.

41 В k8s есть много преднастроенных кластерных ролей. В том числе роли admin, edit и view - описывающие права, разрешающие администрирование, редактирование или только просмотр сущностей. Посмотреть роль можно в своём кластере, если у вас есть права администратора, командой

42 kubectl get clusterrole edit -o yaml

43 И есть ёще роль кластерного администратора, которая даёт все права на все сущности кластера.

44 kubectl get clusterrole cluster-admin -o yaml

45 <h2>ClusterRoleBinding</h2>

46 RoleBinding даёт доступ только к тем сущностям, которые находятся в том же неймспейсе, что и манифест Rolebinding. ClusterRoleBinding позволяет выдать доступ к сущностям во всех неймспесах кластера сразу.К сожалению, механизма, позволяющего выдать доступ к неймспейсам по label или регекспу имени не существует. Или RoleBinding в одном конкретном неймспейсе или ClusterRoleBinding сразу на все неймспейсы кластера.

47 <h2>Подведём итоги</h2>

48 Role в неймспесах привязываем через RoleBinding в неймспейсе - юзер получает права в неймспейсе.ClusterRole привязываем через ClusterRoleBinding - юзер получает права на весь кластер.Пока логично? А теперь внимательно следим за движением мысли.

49 ClusterRole можно привязать через RoleBinding в неймспейсе - и юзер получит права в неймспейсе.

50 Что нам это даёт? Нам нет нужды создавать в каждом неймспейсе одинаковые роли edit, мы можем использовать стандартную кластерную роль edit и назначать ее юзерам, раздавая им доступы в нужные неймспейсы.

51 На первое время вполне достаточно стандартных ролей edit и view. Чтобы разобраться в том, какие бывают ресурсы и действия с ними, посмотрите встроенные роли и роли в готовых наборах манифестов, например, в Helm Charts.

52 Много всего описано в документации, но иногда нужно и погуглить. Как правило, все нужные ресурсы/подресурсы уже расписаны в каких-либо специализированных статьях.

53 <a>Узнать подробнее о курсе "Kubernetes База"</a>

54 Фото на обложке статьи: Patrick Robert Doyle, Unsplash.com