Ограничение доступов в Kubernetes

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

Принцип работы ограничений в Kubernetes

Механизм ограничения доступа в Kubernetes основан на концепции ролей и разрешений (RBAC, что расшифровывается, как Role-Based Access Control). RBAC позволяет администраторам Kubernetes определять, кто и в каком объеме имеет доступ к ресурсам и операциям в кластере.

Для настройки RBAC в Kubernetes используются следующие основные сущности:

• Роли (Roles). Определяют, какие действия разрешены на определенных ресурсах (например, чтение, запись, удаление).

• Привязки ролей к субъектам (RoleBindings). Обеспечивают связь с конкретными пользователями, сервисными аккаунтами или группами.

• Сервисные аккаунты (ServiceAccounts). Нужны для аутентификации приложений и сервисов внутри кластера.

При настройке RBAC администраторы могут управлять доступом к различным ресурсам Kube, таким как поды, службы, хранилища и т.д., в зависимости от потребностей и ролей пользователей или сервисов. RBAC предоставляет гибкую систему управления доступом, которая помогает обеспечить безопасность и контроль над кластером.

Таким образом, RBAC позволяет задавать доступы, например, на уровне ресурсов целого кластера (ClusterRole, ClusterRoleBinding), а можно ограничиться доступами в пределах конкретного пространства имен (Role и RoleBinding).

Как создавать Roles и RoleBindings для ограничения доступа

Для создания Role и RoleBinding в Kube необходимо создать YAML-файлы с определением этих объектов. Приведем конкретные примеры, и для начала пример кода с определением Role (назовем его getlistwatch.yaml):

kind: Role
metadata:
	namespace: default
	name: getlistwatch
rules:
- apiGroups: [""]
	resources: ["pods"]
	verbs: ["get", "list", "watch"]

Теперь пример кода с определением RoleBinding (назовем его getlistwatch-bind.yaml):

kind: RoleBinding
metadata:
	name: getlistwatch-bind
	namespace: default
subjects:
- kind: User
	name: username # Замените username на имя пользователя
	apiGroup: rbac.authorization.k8s.io
roleRef:
	kind: Role
	name: getlistwatch
	apiGroup: rbac.authorization.k8s.io

Применить созданные объекты можно с помощью команды kubectl apply -f, для наших примеров это будет выглядеть так:

kubectl apply -f getlistwatch.yaml
kubectl apply -f getlistwatch-bind.yaml

В этих примерах мы создали объект Role getlistwatch, который позволяет получать, перечислять и отслеживать ресурсы подов в кластере. Затем мы создали RoleBinding getlistwatch-bind, который связывает эту роль с конкретным пользователем. После применения этих файлов пользователь будет иметь разрешение на выполнение указанных операций над ресурсами подов в кластере.

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

Способы аутентификации

Основных способов три:

• базовый с передачей конфигурации через API;
• через сертификат клиента, заверенный в сертификационном центре Kube;
• через Bearer-token либо JWT.

Первый способ сегодня практически не задействуется, поэтому перейдем сразу ко второму.

Аутентификация через сертификаты Kubernetes

При аутентификации через сертификаты Kubernetes каждый пользователь или сервис получает свой собственный сертификат, который используется для проверки подлинности при попытке доступа к кластеру. Процесс аутентификации через сертификаты Kubernetes обычно включает следующие шаги:

• Генерация сертификатов. Администратор кластера генерирует сертификаты для каждого пользователя/сервиса, используя удостоверяющий центр или инструменты для создания сертификатов. Например, можно создать закрытые ключи RSA, а затем создать и отправить запросы на подпись в сертификационный центр.

• Настройка аутентификации. Администратор добавляет созданные сертификаты в конфигурацию Kubernetes, указывая, какие пользователи/сервисы имеют доступ к каким ресурсам в кластере. Это делается через kubeconfig, который генерируется для отдельного пользователя/сервиса, после чего туда добавляется уже подписанный сертификат.

• Создание ролей. На этом этапе создается Role и затем привязывается к пользователю/сервису через RoleBinding (см. код выше).

Теперь при попытке доступа к кластеру, пользователь/сервис должен будет предоставить свой сертификат для проверки. Кластер Kube использует этот сертификат для проверки подлинности и определения разрешений доступа. И при успешной проверке сертификата, пользователю/сервису предоставляются соответствующие разрешения на выполнение операций в кластере. Добавим, что существуют средства автоматизации этого процесса. Например, можно использовать bash-скрипты или средства Ansible.

Этот способ позволит вам создать набор типовых ролей, однако при этом возникает проблема контроля доступа по количеству пользователей/сервисов, а также могут возникнуть сложности с отзывом сертификата. Поэтому во многих случаях лучше и безопаснее использовать функционал, предлагаемый сторонними сервисами аутентификации: например, DEX и Keycloak, которые обеспечивают безопасную аутентификацию через OIDC (OpenID Connect).

Аутентификация через DEX

Одно из ключевых преимуществ DEX в том, что его очень легко освоить. Из относительных минусов отметим, что для настройки аутентификации через DEX нужно предварительно создать сертификаты для него и для Gangway, с которым он работает в паре, так как они связываются между собой через TLS. При развертывании внутри кластера Kubernetes будут созданы сущности вида dex.timeweb.cloud и gangway.timeweb.cloud, для которых и потребуются сертификаты. При этом не забывайте программно либо через cert-manager отслеживать сроки действия сертификатов, так как они ограничены. При этом cert-manager даже автоматически обновляет их. Устанавливается DEX через Helm-Chart, а все его настройки будут содержаться в configmap.

Аутентификация через Keycloak

Одним из плюсов Keycloak является то, что, в отличие от DEX, он обладает собственным веб-интерфейсом. Также он поддерживает гораздо большее число бэкендов и может работать не только с Kubernetes. Но и это не все достоинства данного сервиса: Keycloak станет оптимальным решением для тех, кому нужно настраивать доступ для пользователей к множеству приложений, так как он рассчитан на работу в качестве сервера SSO. Но за всё это приходится платить довольно высоким порогом входа, ведь даже опытным разработчикам, не знакомым с Keycloak, придется сначала изучить весьма объемную документацию.

Как работает аутентификация через сторонние сервисы

• После того как пользователь откроет форму Gangway, он будет переадресован на страницу авторизации DEX/Keycloak.

• После ввода данных приложение проверяет корректность введенных данных.

• При правильно введенных данных DEX/Keycloak возвращают Gangway-токены для аутентификации. Разумеется, пользователь ничего этого не видит, поскольку это автоматизированная процедура.

• Зато пользователь увидит и сможет скачать сгенерированный на основе полученных данных kubeconfig с настройками доступа.

• kubeconfig нужен для отправки запроса непосредственно на сервер Kube, где DEX/Keycloak проверяют, действительны ли токены.

Какой способ выбрать

В этой завершающей части приведем факторы, которые помогут вам сделать правильный выбор между сертификатами Kube, DEX и Keycloak.

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

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

• Наконец, вам стоит выбрать Keycloak, если вам нужно настроить доступ к множеству не связанных приложений для отдельных пользователей.

На этом всё, спасибо за внимание!