--- title: "Управление пользователями кластера Kubernetes" description: "Управление пользователями кластера Kubernetes. Настройка и разделение доступов. Документация и инструкции по использованию и настройке облачных сервисов Timeweb Cloud." --- > Полный индекс документации для ИИ-агентов: [llms.txt](https://timeweb.cloud/llms.txt). В кластерах Kubernetes доступ к кластеру настраивается средствами самого Kubernetes. Конфигурационный файл `kubeconfig`, который скачивается из панели управления, содержит административные учетные данные и подходит для первичной настройки кластера. Если с кластером работают несколько сотрудников, не рекомендуется использовать один общий административный `kubeconfig`. Если такой файл попадет к постороннему человеку или останется у сотрудника после увольнения, отозвать доступ только для него не получится. Безопаснее создать отдельную учетную запись для каждого пользователя и выдать необходимые права через RBAC. Рассмотрим настройку персонального доступа через `ServiceAccount`, `RoleBinding` или `ClusterRoleBinding` и отдельный `kubeconfig` с токеном. ## Подготовка Для выполнения действий потребуется кластер Kubernetes, административный `kubeconfig`, скачанный из панели управления, и установленная [утилита kubectl](https://timeweb.cloud/docs/k8s/cluster-connection/kubectl). Чтобы скачать `kubeconfig`, перейдите на страницу управления кластером Kubernetes в панели управления. Во вкладке «Дашборд» нажмите ссылку «скачайте файл конфигурации». Скачанный файл будет иметь имя `twc-имя_кластера.yaml`. Проверьте подключение к кластеру: ```bash kubectl --kubeconfig=twc-имя_кластера.yaml get nodes ``` Если команда возвращает список нод, можно переходить к созданию учетной записи. ## Создание пространства для учетных записей Для управления учетными записями удобно создать отдельный неймспейс, например `kube-users`: ```bash kubectl create namespace kube-users ``` Создадим учетную запись для пользователя `twcuser`: ```bash kubectl create serviceaccount twcuser -n kube-users ``` В дальнейшем имя этой учетной записи будет использоваться при выдаче прав и выпуске токена. ## Выдача прав пользователю Права в Kubernetes выдаются через RBAC. Для этого используются: - `RoleBinding` — выдает права в пределах одного неймспейса; - `ClusterRoleBinding` — выдает права на уровне всего кластера. Выдавайте пользователю только минимально необходимые права. Если достаточно доступа к одному неймспейсу, используйте `RoleBinding` вместо `ClusterRoleBinding`. ### Доступ к одному неймспейсу Если пользователю нужен доступ только к одному неймспейсу, создайте `RoleBinding` в этом неймспейсе. В примере ниже пользователь `twcuser` получает права на изменение ресурсов в неймспейсе `app-prod`: ```bash kubectl create namespace app-prod kubectl create rolebinding twcuser-app-prod-edit \ --namespace app-prod \ --clusterrole edit \ --serviceaccount kube-users:twcuser ``` Вместо роли `edit` можно использовать другую встроенную роль: | **Роль** | **Описание** | | --- | --- | | `view` | Просмотр ресурсов без возможности изменять их. | | `edit` | Создание и изменение большинства ресурсов в неймспейсе. | | `admin` | Управление ресурсами в неймспейсе, включая роли и привязки ролей. | | `cluster-admin` | Полный административный доступ ко всему кластеру. | В таблице перечислены стандартные пользовательские `ClusterRole` Kubernetes. Но также [можно создать собственные ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#kubectl-create-clusterrole) с нужными правилами, если стандартных ролей недостаточно.  Для проверки прав выполните: ```bash kubectl auth can-i create deployments \ --as system:serviceaccount:kube-users:twcuser \ -n app-prod ``` Если доступ выдан корректно, команда вернет: ```shell yes ``` ### Доступ ко всему кластеру Если пользователю нужен полный административный доступ ко всему кластеру, создайте `ClusterRoleBinding`: ```bash kubectl create clusterrolebinding twcuser-cluster-admin \ --clusterrole cluster-admin \ --serviceaccount kube-users:twcuser ``` Используйте роль `cluster-admin` только для администраторов кластера. Для команд разработчиков безопаснее выдавать доступ в пределах нужного неймспейса. ## Создание токена Для подключения через `kubectl` пользователю нужен токен. В Kubernetes можно использовать временный токен или долгоживущий токен, сохраненный в `Secret`. ### Временный токен Временный токен создается командой `kubectl create token`. Например, выпустим токен на 24 часа: ```bash TOKEN=$(kubectl create token twcuser -n kube-users --duration=24h) ``` Посмотреть значение токена можно командой: ```bash echo "${TOKEN}" ``` Временный токен автоматически перестанет работать после окончания срока действия. У временных токенов нет отдельного объекта в кластере, поэтому отозвать один конкретный временный токен до истечения срока действия нельзя. Если нужно срочно закрыть доступ, удалите права пользователя или сам `ServiceAccount`. ### Долгоживущий токен Если нужен токен без заданного срока действия, создайте `Secret` типа `kubernetes.io/service-account-token`. Такой токен можно отозвать удалением `Secret`. Создайте файл `twcuser-token-secret.yaml`: ```yaml apiVersion: v1 kind: Secret metadata: name: twcuser-token namespace: kube-users annotations: kubernetes.io/service-account.name: twcuser type: kubernetes.io/service-account-token ``` Примените манифест: ```bash kubectl apply -f twcuser-token-secret.yaml ``` Получите значение секрета: ```bash TOKEN=$(kubectl get secret twcuser-token \ -n kube-users \ -o jsonpath='{.data.token}' | base64 -d) ``` Долгоживущие токены следует использовать только там, где временного токена недостаточно. Такой токен необходимо хранить как секретные учетные данные. ## Создание kubeconfig для пользователя Создадим отдельный файл `kubeconfig`, в котором будут данные кластера и токен пользователя `twcuser`. Сначала получим параметры текущего кластера из административного `kubeconfig`: ```bash CLUSTER_NAME=$(kubectl config view --minify -o jsonpath='{.clusters[0].name}') CLUSTER_SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') kubectl config view --raw --minify -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > ca.crt ``` Создайте новый файл конфигурации: ```bash kubectl config --kubeconfig=twcuser.kubeconfig set-cluster "${CLUSTER_NAME}" \ --server="${CLUSTER_SERVER}" \ --certificate-authority=ca.crt \ --embed-certs=true kubectl config --kubeconfig=twcuser.kubeconfig set-credentials twcuser \ --token="${TOKEN}" kubectl config --kubeconfig=twcuser.kubeconfig set-context twcuser-context \ --cluster="${CLUSTER_NAME}" \ --user=twcuser kubectl config --kubeconfig=twcuser.kubeconfig use-context twcuser-context ``` Если пользователь должен работать в конкретном неймспейсе, добавьте его в контекст: ```bash kubectl config --kubeconfig=twcuser.kubeconfig set-context twcuser-context \ --cluster="${CLUSTER_NAME}" \ --user=twcuser \ --namespace=app-prod ``` После этого файл `twcuser.kubeconfig` можно передать пользователю. ### Пример готового kubeconfig Ниже приведен пример пользовательского `kubeconfig` с авторизацией по токену. Значения `certificate-authority-data`, `server` и `token` будут отличаться в вашем кластере. ```yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: server: https://:6443 name: twc-example-cluster contexts: - context: cluster: twc-example-cluster namespace: app-prod user: twcuser name: twcuser-context current-context: twcuser-context kind: Config preferences: {} users: - name: twcuser user: token: ``` В готовом файле не должно быть административного пользователя, клиентского сертификата или приватного ключа из исходного `kubeconfig`. Перед передачей файла пользователю убедитесь, что в секции `users` осталась только учетная запись с токеном пользователя. ## Проверка доступа Проверьте работу нового `kubeconfig`: ```bash kubectl --kubeconfig=twcuser.kubeconfig get pods -n app-prod ``` Если пользователю выдан доступ только к неймспейсу `app-prod`, запросы к другим неймспейсам будут запрещены. Например: ```bash kubectl --kubeconfig=twcuser.kubeconfig get pods -n default ``` В этом случае Kubernetes вернет ошибку доступа: ```bash Error from server (Forbidden): pods is forbidden ``` Для проверки конкретного действия можно использовать команду `kubectl auth can-i`: ```bash kubectl --kubeconfig=twcuser.kubeconfig auth can-i update deployments -n app-prod ``` ## Отзыв доступа Способ отзыва зависит от того, какой доступ нужно отключить. ### Удаление прав пользователя Чтобы запретить пользователю выполнять действия в неймспейсе, удалите соответствующий `RoleBinding`: ```bash kubectl delete rolebinding twcuser-app-prod-edit -n app-prod ``` Если пользователю был выдан доступ на уровне всего кластера, удалите `ClusterRoleBinding`: ```bash kubectl delete clusterrolebinding twcuser-cluster-admin ``` После удаления привязки токен может оставаться технически действительным, но прав на выполнение действий у пользователя уже не будет. ### Отзыв долгоживущего токена Если токен был создан через `Secret`, удалите этот `Secret`: ```bash kubectl delete secret twcuser-token -n kube-users ``` После удаления `Secret` токен перестанет проходить аутентификацию. ### Полное удаление учетной записи Чтобы полностью удалить пользователя, удалите его `ServiceAccount`: ```bash kubectl delete serviceaccount twcuser -n kube-users ``` При удалении `ServiceAccount` выпущенные для него токены перестанут работать. Отзыв может примениться не мгновенно: Kubernetes может кэшировать результаты проверки токенов в течение короткого времени. После удаления учетной записи также удалите связанные `RoleBinding` и `ClusterRoleBinding`, если они больше не нужны.