Управление пользователями

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

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

Рассмотрим настройку персонального доступа через ServiceAccount, RoleBinding или ClusterRoleBinding и отдельный kubeconfig с токеном.

Подготовка

Для выполнения действий потребуется кластер Kubernetes, административный kubeconfig, скачанный из панели управления, и установленная утилита kubectl.

Чтобы скачать kubeconfig, перейдите на страницу управления кластером Kubernetes в панели управления. Во вкладке «Дашборд» нажмите ссылку «скачайте файл конфигурации». Скачанный файл будет иметь имя twc-имя_кластера.yaml.

Проверьте подключение к кластеру:

    

      

    
    kubectl --kubeconfig=twc-имя_кластера.yaml get nodes
  

Если команда возвращает список нод, можно переходить к созданию учетной записи.

Создание пространства для учетных записей

Для управления учетными записями удобно создать отдельный неймспейс, например kube-users:

    

      

    
    kubectl create namespace kube-users
  

Создадим учетную запись для пользователя twcuser:

    

      

    
    kubectl create serviceaccount twcuser -n kube-users
  

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

Выдача прав пользователю

Права в Kubernetes выдаются через RBAC. Для этого используются:

• RoleBinding — выдает права в пределах одного неймспейса;

• ClusterRoleBinding — выдает права на уровне всего кластера.

Выдавайте пользователю только минимально необходимые права. Если достаточно доступа к одному неймспейсу, используйте RoleBinding вместо ClusterRoleBinding.

Доступ к одному неймспейсу

Если пользователю нужен доступ только к одному неймспейсу, создайте RoleBinding в этом неймспейсе. В примере ниже пользователь twcuser получает права на изменение ресурсов в неймспейсе app-prod:

    

      

    
    kubectl create namespace app-prod
 
kubectl create rolebinding twcuser-app-prod-edit \
  --namespace app-prod \
  --clusterrole edit \
  --serviceaccount kube-users:twcuser

  

Вместо роли edit можно использовать другую встроенную роль:

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

Для проверки прав выполните:

    

      

    
    kubectl auth can-i create deployments \
  --as system:serviceaccount:kube-users:twcuser \
  -n app-prod

  

Если доступ выдан корректно, команда вернет:

    

      

    
    yes
  

Доступ ко всему кластеру

Если пользователю нужен полный административный доступ ко всему кластеру, создайте ClusterRoleBinding:

    

      

    
    kubectl create clusterrolebinding twcuser-cluster-admin \
  --clusterrole cluster-admin \
  --serviceaccount kube-users:twcuser

  

Используйте роль cluster-admin только для администраторов кластера. Для команд разработчиков безопаснее выдавать доступ в пределах нужного неймспейса.

Создание токена

Для подключения через kubectl пользователю нужен токен. В Kubernetes можно использовать временный токен или долгоживущий токен, сохраненный в Secret.

Временный токен

Временный токен создается командой kubectl create token. Например, выпустим токен на 24 часа:

    

      

    
    TOKEN=$(kubectl create token twcuser -n kube-users --duration=24h)
  

Посмотреть значение токена можно командой:

    

      

    
    echo "${TOKEN}"
  

Временный токен автоматически перестанет работать после окончания срока действия.

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

Долгоживущий токен

Если нужен токен без заданного срока действия, создайте Secret типа kubernetes.io/service-account-token. Такой токен можно отозвать удалением Secret.

Создайте файл twcuser-token-secret.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

  

Примените манифест:

    

      

    
    kubectl apply -f twcuser-token-secret.yaml
  

Получите значение секрета:

    

      

    
    TOKEN=$(kubectl get secret twcuser-token \
  -n kube-users \
  -o jsonpath='{.data.token}' | base64 -d)

  

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

Создание kubeconfig для пользователя

Создадим отдельный файл kubeconfig, в котором будут данные кластера и токен пользователя twcuser.

Сначала получим параметры текущего кластера из административного kubeconfig:

    

      

    
    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

  

Создайте новый файл конфигурации:

    

      

    
    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

  

Если пользователь должен работать в конкретном неймспейсе, добавьте его в контекст:

    

      

    
    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 будут отличаться в вашем кластере.

    

      

    
    apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <CA_DATA>
    server: https://<API_SERVER>: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: <TOKEN>

  

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

Проверка доступа

Проверьте работу нового kubeconfig:

    

      

    
    kubectl --kubeconfig=twcuser.kubeconfig get pods -n app-prod
  

Если пользователю выдан доступ только к неймспейсу app-prod, запросы к другим неймспейсам будут запрещены. Например:

    

      

    
    kubectl --kubeconfig=twcuser.kubeconfig get pods -n default
  

В этом случае Kubernetes вернет ошибку доступа:

    

      

    
    Error from server (Forbidden): pods is forbidden
  

Для проверки конкретного действия можно использовать команду kubectl auth can-i:

    

      

    
    kubectl --kubeconfig=twcuser.kubeconfig auth can-i update deployments -n app-prod
  

Отзыв доступа

Способ отзыва зависит от того, какой доступ нужно отключить.

Удаление прав пользователя

Чтобы запретить пользователю выполнять действия в неймспейсе, удалите соответствующий RoleBinding:

    

      

    
    kubectl delete rolebinding twcuser-app-prod-edit -n app-prod
  

Если пользователю был выдан доступ на уровне всего кластера, удалите ClusterRoleBinding:

    

      

    
    kubectl delete clusterrolebinding twcuser-cluster-admin
  

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

Отзыв долгоживущего токена

Если токен был создан через Secret, удалите этот Secret:

    

      

    
    kubectl delete secret twcuser-token -n kube-users
  

После удаления Secret токен перестанет проходить аутентификацию.

Полное удаление учетной записи

Чтобы полностью удалить пользователя, удалите его ServiceAccount:

    

      

    
    kubectl delete serviceaccount twcuser -n kube-users
  

При удалении ServiceAccount выпущенные для него токены перестанут работать. Отзыв может примениться не мгновенно: Kubernetes может кэшировать результаты проверки токенов в течение короткого времени.

После удаления учетной записи также удалите связанные RoleBinding и ClusterRoleBinding, если они больше не нужны.