Авторизация RBAC

Введение

В Kubernetes авторизация обычно выполняется с помощью RBAC (управления доступом на основе ролей).

Пользователь: сотрудник, например «Jane».
Role: ключ-карта с определёнными правами доступа, например «может входить в серверную» или «может читать документы».
RoleBinding: действие выдачи ключ-карты сотруднику.

RBAC важен, потому что доступ к кластеру связан не только с аутентификацией. После установления личности система должна определить, какие действия разрешено выполнять этой личности.

В этой лабораторной работе вы выступите в роли начальника службы безопасности:

Создадите «гостевой пропуск» (Role), который позволяет просматривать объекты, но не изменять их.
Назначите этот пропуск пользователю jane.
Проверите, что Jane может осматривать кластер, но получает отказ при попытке что-либо изменить.

Определите Role

Сначала создайте набор разрешений. Нам нужна роль «только для чтения». Она должна разрешать пользователю выполнять list и get (читать) объекты Pod, но запрещать create и delete.

RBAC отвечает за авторизацию в Kubernetes, а не за аутентификацию. Аутентификация отвечает на вопрос «Кто вы?». Авторизация отвечает на вопрос «Что вам разрешено делать?». В этой лабораторной работе рассматривается второй вопрос: для определённых типов ресурсов задаются явно разрешённые действия, называемые verbs.

Создайте файл role.yaml:

nano role.yaml

Вставьте следующий YAML-код. Это определение создаёт Role, которой разрешено выполнять действия get, watch и list над ресурсами pods.

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", "watch", "list"]

Сохраните файл и выйдите из редактора (Ctrl+X, Y, Enter).

Теперь примените эту «карточку» в кластере:

kubectl apply -f role.yaml

Проверьте, что Role существует:

kubectl get roles

В выводе должна присутствовать pod-reader.

Свяжите Role с пользователем

Теперь у нас есть «карточка» (pod-reader) и сотрудник (jane). Но Jane ещё не получила эту карточку. Чтобы связать их, нужен RoleBinding.

Сама по себе Role ничего не разрешает, пока на неё не ссылается binding. Такое разделение сделано намеренно. Администраторы могут один раз определить повторно используемый набор разрешений, а затем при необходимости назначать его разным пользователям, группам или сервисным аккаунтам.

Создайте файл rolebinding.yaml:

nano rolebinding.yaml

Вставьте следующее содержимое. Оно означает: «свяжите роль pod-reader с пользователем jane».

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: jane ## The employee
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader ## The key card
  apiGroup: rbac.authorization.k8s.io

Сохраните файл и выйдите из редактора (Ctrl+X, Y, Enter).

Примените binding:

kubectl apply -f rolebinding.yaml

Теперь Jane официально получила доступ только для чтения в пространстве имён default.

Проверьте доступ

Как это проверить? Не нужно выходить из системы и входить снова как Jane. Kubernetes позволяет «имитировать» пользователя для проверки разрешений с помощью флага --as.

Это практический приём администрирования. Проверять разрешения безопаснее, если сначала можно смоделировать личность, а уже затем предоставлять доступ реальному пользователю или автоматизированной учётной записи. Так вы проверите соответствие настроек цели, не создавая лишних изменений в кластере.

Проверьте, может ли Jane получить список Pod:

kubectl auth can-i list pods --as jane

В выводе должно быть yes.

Также проверьте, может ли она получить сведения о конкретном Pod:

kubectl auth can-i get pods --as jane

В выводе также должно быть yes.

Это подтверждает, что RoleBinding работает. Ключ-карта подходит к считывателям на двери!

Проверьте ограничения

Безопасность также означает понимание того, что делать нельзя. Поскольку у Jane есть только роль pod-reader, ей должно быть строго запрещено вносить изменения.

На практике это принцип минимальных привилегий. Вместо того чтобы предоставлять широкий доступ и надеяться на осторожность пользователей, начните с минимального набора разрешений, необходимого для задачи, и расширяйте его только при реальной операционной необходимости.

Проверьте, может ли Jane создать Pod:

kubectl auth can-i create pods --as jane

В выводе должно быть no.

Проверьте, может ли Jane удалить Pod:

kubectl auth can-i delete pods --as jane

В выводе должно быть no.

Если бы Jane действительно выполнила эти команды, API-сервер отклонил бы её запрос с ошибкой «Forbidden». Это подтверждает, что кластер защищён и следует принципу минимальных привилегий.

Итоги

В этой лабораторной работе вы защитили кластер с помощью RBAC.

Вы успешно:

Создали Role («ключ-карту») с ограниченными разрешениями только для чтения.
Создали RoleBinding, чтобы выдать эту карточку пользователю jane.
Проверили, что пользователю jane разрешено просматривать объекты, но не изменять их.

Это основа безопасности Kubernetes в средах с несколькими пользователями. Никогда не предоставляйте полный доступ администратора всем подряд!