Настройка управления доступом на основе ролей Kubernetes

Ролевой контроль доступа Kubernetes(K8s) — это мощный инструмент для ограничения доступа к ресурсам в кластере Kubernetes. В этой заметке мы кратко обсудим, что такое ролевой контроль доступа и как его настроить в Kubernetes. Обещаю, это не такой долгий процесс, как вам может показаться.

Что такое управление доступом на основе ролей?

Управление доступом на основе ролей (RBAC) — это модель безопасности, в которой пользователям назначаются роли, а затем им предоставляется доступ к определенным ресурсам на основе этих ролей. Например, организация может иметь систему управления доступом на основе ролей, которая позволяет инженерам DevOps выполнять привилегированные операции во всем кластере Kubernetes, ограничивая при этом разработчиков приложений только просмотром информации о своих приложениях, развернутых в определенном пространстве имен.

Определения

Прежде чем настраивать RBAC в Kubernetes, давайте рассмотрим некоторые ключевые понятия, с которыми мы будем иметь дело:

  • Учетные записи служб — это идентификаторы, которые можно использовать для делегирования доступа к ресурсам Kubernetes в пространстве имен. Они могут использоваться пользователями или службами. Позже в статье мы сделаем некоторые незначительные изменения, используя привязки кластеров, чтобы мы могли обойти ограничение «пространства имен».

  • Ресурсы — это объекты в кластере Kubernetes, для которых мы хотим реализовать контроль доступа на основе ролей. Примерами могут служить капсулы, развертывания, наборы реплик, конфигмапы и сервисы.

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

  • Ролевые привязки — это ассоциация роли с учетной записью службы. Другими словами, привязки ролей используются для назначения ролей. Рассматривайте привязку ролей как механизм подключения набора разрешений (роли) к учетной записи службы.

  • Кластерные роли — это роли, которые могут быть назначены учетным записям служб в кластере Kubernetes. В то время как роли привязываются к именам, кластерроли применяются ко всему кластеру. Некоторые роли по умолчанию в кластере k8s включают view, edit, admin и cluster-admin.

  • Привязки кластерролей — это ассоциации кластерролей с учетными записями служб. Как вы уже догадались, кластерролевые привязки позволяют нам назначать кластерные разрешения учетным записям служб через кластерроли.

Теперь давайте посмотрим, как можно настроить RBAC в Kubernetes.

Как настроить кластер Kubernetes с помощью RBAC

Необходимые условия

  • Работающий кластер Kubernetes. Если у вас его еще нет, вам может быть полезна эта статья. В ней перечислены несколько способов настройки кластера K8s.

  • Kubectl. Вы можете установить kubectl, следуя этому руководству.

  • Kubernetes 1.20 или более поздней версии. Более ранние версии Kubernetes более активно не поддерживаются, и RBAC в этих версиях не так стабилен. Эта документация может помочь вам в этом процессе.

  • Приборная панель Kubernetes, если вы собираетесь использовать ее в разделе «Доступ к приборной панели Kubernetes» далее.

Настройка RBAC в пространстве имен

Сначала давайте создадим пространство имен, с которым мы будем работать. Назовем его dev-env.

kubectl create namespace dev-env
Вход в полноэкранный режим Выход из полноэкранного режима

Выход:

Далее создадим служебную учетную запись app-dev, которую будем использовать на протяжении всей работы.

kubectl create serviceaccount app-dev --namespace dev-env
Вход в полноэкранный режим Выход из полноэкранного режима

Выход:

Далее мы создадим роль администратора, которая будет иметь все права в пространстве имен dev-env. Ниже приведен ее манифест, который также доступен на GitHub.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: admin
  namespace: dev-env
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
Вход в полноэкранный режим Выйдите из полноэкранного режима

Примените файл для создания роли администратора.

kubectl apply -f https://raw.githubusercontent.com/123MwanjeMike/k8s-rbac/main/admin-role.yaml
Войти в полноэкранный режим Выйти из полноэкранного режима

Выход:

Примечание: Мы будем создавать остальные ресурсы Kubernetes в этом учебнике из предварительно написанных файлов манифестов в этом репозитории, как мы это делали выше. Однако вы также можете редактировать эти манифесты, если хотите создать ресурсы K8s в соответствии с вашими потребностями.

123MwanjeMike / k8s-rbac

Настройка ролевого управления доступом Kubernetes в манифестах учебника

k8s-rbac

Список ресурсов Kubernetes для настройки контроля доступа на основе ролей в статье Настройка контроля доступа на основе ролей Kubernetes.

Посмотреть на GitHub

Далее создайте привязку роли app-dev-rolebinding роли admin к учетной записи службы app-dev. Ниже приведен манифест.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: app-dev-rolebinding
  namespace: dev-env
subjects:
- kind: ServiceAccount
  name: app-dev
  namespace: dev-env
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: admin
Вход в полноэкранный режим Выход из полноэкранного режима

Выполните приведенную ниже команду для создания.

kubectl apply -f https://raw.githubusercontent.com/123MwanjeMike/k8s-rbac/main/rolebinding.yaml
Войти в полноэкранный режим Выйти из полноэкранного режима

Выход:

Наша учетная запись службы теперь является администратором в пространстве имен dev-env. Мы можем даже пойти дальше и определить права доступа для нее во всем кластере. Допустим, основываясь на примере инженера DevOps и разработчика приложений, который мы привели в начале, мы хотим, чтобы наши разработчики приложений могли просматривать любые ресурсы кластера и даже использовать приборную панель Kubernetes. Как мы можем это сделать?

Настройка RBAC для всего кластера

Для первой части нам повезло! Kubernetes имеет кластерроль view по умолчанию, который можно использовать для просмотра всех ресурсов в кластере; и поэтому мы просто воспользуемся этим. Мы создадим кластерролевую привязку app-dev-view, которая будет делать именно это.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: app-dev-view
subjects:
- kind: ServiceAccount
  name: app-dev
  namespace: dev-env
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
Вход в полноэкранный режим Выход из полноэкранного режима

Создайте кластерную привязку

kubectl apply -f https://raw.githubusercontent.com/123MwanjeMike/k8s-rbac/main/clusterrolebindings/view.yaml
Войти в полноэкранный режим Выход из полноэкранного режима

Теперь, чтобы app-dev получил доступ к приборной панели Kubernetes, мы могли бы просто создать привязку кластерроля по умолчанию edit к нему, поскольку он имеет необходимые для этого права доступа. Однако это также даст учетной записи службы больше прав доступа, чем она должна иметь, поэтому мы хотим использовать более тонкую кластерроль в соответствии с принципом наименьших привилегий.

Итак, мы создадим пользовательский кластерроль с разрешениями, необходимыми для доступа к приборной панели K8s, в дополнение к тем, которыми уже обладает учетная запись службы через кластерроль по умолчанию view.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: view-addition-for-k8s-dashboard-access
rules:
- apiGroups: [""]
  resources: ["pods/attach", "pods/exec", "pods/portforward", "pods/proxy", "services/proxy"]
  verbs: ["get", "list", "watch", "create"]
- apiGroups: [""]
  resources: ["services"]
  verbs: ["proxy"]
Вход в полноэкранный режим Выход из полноэкранного режима

Выполните приведенную ниже команду, чтобы создать кластерроль view-addition-for-k8s-dashboard-access с приведенным выше определением.

kubectl apply -f https://raw.githubusercontent.com/123MwanjeMike/k8s-rbac/main/custom-clusterrole.yaml
Войти в полноэкранный режим Выход из полноэкранного режима

Теперь мы можем привязать кластерроль view-addition-for-k8s-dashboard-access к учетной записи службы app-dev, чтобы она получила доступ к приборной панели K8s. Давайте посмотрим на манифест привязки кластера для этого.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: app-dev-use-k8s-dashboard
subjects:
- kind: ServiceAccount
  name: app-dev
  namespace: dev-env
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view-addition-for-k8s-dashboard-access
Вход в полноэкранный режим Выход из полноэкранного режима

Создайте кластерную привязку app-dev-use-k8s-dashboard

kubectl apply -f https://raw.githubusercontent.com/123MwanjeMike/k8s-rbac/main/clusterrolebindings/use-k8s-dashboard.yaml
Войдите в полноэкранный режим Выход из полноэкранного режима

Наша учетная запись службы app-dev теперь может использоваться нашими «разработчиками приложений» для создания приложений в пространстве имен dev-env и удобного доступа к приборной панели k8s.

Использование

Создайте конфигурацию kubectl

Нам понадобится токен для учетной записи сервиса app-dev, поэтому для его получения выполните следующие команды

export NAMESPACE="dev-env"
export SERVICE_ACCOUNT="app-dev"
kubectl -n ${NAMESPACE} describe secret $(kubectl -n ${NAMESPACE} get secret | (grep ${SERVICE_ACCOUNT} || echo "$_") | awk '{print $1}') | grep token: | awk '{print $2}'n
Войти в полноэкранный режим Выйти из полноэкранного режима

На выходе вы получите длинную строку. Она должна начинаться с чего-то похожего на то, что я привел ниже. Сохраните этот токен где-нибудь на время.

Затем получите данные сертификата, выполнив приведенную ниже команду в том же терминале, где вы задали переменные NAMESPACE и SERVICE_ACCOUNT.

kubectl  -n ${NAMESPACE} get secret `kubectl -n ${NAMESPACE} get secret | (grep ${SERVICE_ACCOUNT} || echo "$_") | awk '{print $1}'` -o "jsonpath={.data['ca.crt']}"
Войти в полноэкранный режим Выйти из полноэкранного режима

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

С этими двумя данными давайте создадим наш конфигурационный файл kubectl. Возможно, у вас уже есть файл *.kube/config, который вам еще может понадобиться. Поэтому мы сохраним его как .kube/config.bak и создадим новый для app-dev. Выполните приведенные ниже команды, чтобы сделать именно это.

cd
mv .kube/config .kube/config.bak
nano .kube/config
Войти в полноэкранный режим Выйти из полноэкранного режима

Откроется текстовый редактор nano. Заполните приведенный ниже шаблон, вставив его в редактор. Перед сохранением изменений не забудьте заменить certificate-data, server-ip-address, cluster-name и token на правильные значения. Не забудьте удалить токен и данные сертификата оттуда, где вы их временно сохранили.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:  <certificate-data>
    server: https://<server-ip-address>:6443
  name: <cluster-name>
contexts:
- context:
    cluster: <cluster-name>
    namespace: dev-env
    user: app-dev
  name: <cluster-name>
current-context: dev-env
kind: Config
preferences: {}
users:
- name: app-dev
  user:
    client-key-data:  <certificate-data>
    token:  <token>
Вход в полноэкранный режим Выход из полноэкранного режима

Зайдите в панель управления Kubernetes

  1. Запустите kubectl proxy и нажмите здесь, чтобы получить доступ к приборной панели.
  2. Войдите в систему с помощью .kube/config, который мы создали в предыдущем шаге.
  3. Попытайтесь создать роль пользователя в пространстве имен dev-env с помощью приведенного ниже манифеста. Все должно пройти успешно.
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test-admin
  namespace: dev-env
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
Вход в полноэкранный режим Выход из полноэкранного режима

  1. Попытайтесь создать роль пользователя в пространстве имен kube-public с приведенным ниже манифестом.
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test-admin
  namespace: kube-public
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
Войти в полноэкранный режим Выход из полноэкранного режима

Тадаа!

Мы сделали это. app-dev не имеет таких прав вне пространства имен dev-env. Теперь все разработчики приложений могут использовать этот файл .kube/config для получения контролируемого доступа к кластеру.

Заключение

В этой статье мы рассмотрели, как можно реализовать RBAC не только на уровне пространства имен, но и на уровне кластера. Мы специально использовали служебную учетную запись, поскольку она управляется Kubernetes, снимая с нас эту задачу. Важно отметить, что Kubernetes также использует учетные записи пользователей, как и учетные записи служб. Ключевое различие между ними заключается в том, что учетные записи пользователей представляют реальных пользователей Kubernetes, в отличие от учетных записей служб.

Я надеюсь, что вам понравилась эта статья и что вы окажете мне какую-либо поддержку, поскольку я буду очень признателен за это. А если у вас есть какие-либо мысли или вопросы по этому поводу, не стесняйтесь задавать их в разделе комментариев. Я буду рад услышать вас.

Счастливого взлома

Дополнительные ресурсы

  1. Использование авторизации RBAC
  2. Определения кластерролей по умолчанию в Kubernetes
  3. Принцип наименьших привилегий

Оцените статью
devanswers.ru
Добавить комментарий