Управление правами доступа к кластерам Kubernetes в Nutanix Karbon

Ранее я уже писал о том, как получить доступ к кластеру Kubernetes, развернутому с помощью Nutanix Karbon или Nutanix Kubernetes Engine по-новому, однако, считаю, что данный вопрос нужно осветить более подробно и углубиться в процедуру разграничения доступа пользователей.

Под катом мы посмотрим, как происходит авторизация пользователей в Karbon, как получить доступ к управлению кластером Kubernetes и что для этого нужно.

Чтобы получить доступ к кластеру Kubernetes нам нужен kubeconfig файл, который можно получить тремя способами:

  1. Скачать из интерфейса Prism Central:
  1. Запросить через API;
  2. Получить с помощью утилиты karbonctl, которая изначально находится на Prism Central в директории /home/nutanix/karbon:

Для этого предварительно необходимо подключиться к Prism Central:

karbonctl login --pc-ip 10.10.10.11 --pc-username admin

И запросить kubeconfig:

karbonctl cluster kubeconfig --cluster-name dev-k8s >> /opt/kube/dev-k8s.cfg

Командой выше мы указываем название кластера k8s (так, как он называется в Karbon) и место размещения файла kubeconfig на локальной машине.

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

Сообщаем kubectl, где находится конфигурационный файл:

export KUBECONFIG=/opt/kube/dev-k8s.cfg

И можем работать с кластером:

kubectl get nodes
NAME                                 STATUS   ROLES    AGE   VERSION
karbon-dev-k8s-8601db-k8s-master-0   Ready    master   34d   v1.19.13
karbon-dev-k8s-8601db-k8s-master-1   Ready    master   34d   v1.19.13
karbon-dev-k8s-8601db-k8s-worker-0   Ready    node     34d   v1.19.13
karbon-dev-k8s-8601db-k8s-worker-1   Ready    node     34d   v1.19.13
karbon-dev-k8s-8601db-k8s-worker-2   Ready    node     34d   v1.19.13

Все бы ничего, но изначально доступ к управлению кластерами Kubernetes, развернутым с помощью Karbon имеют только пользователи и члены групп с правами User Admin в Prism Central. В примере выше, я использовал учетную запись admin от Prism Central, которая обладает максимальными правами.

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

Примечательно, что даже наличие роли Cluster Admin не даст доступ в кластер.

Может возникнуть вопрос – как кластер Kubernetes понимает, в какой группе состоит пользователь Prism Central?

Если посмотреть сгенерированный файл kubeconfig, а точнее секцию token, которая изначально в кодировке base64, для пользователя admin, можно увидеть, что пользователь является членом группы system:masters (в зависимости от пользователя, групп может быть больше):

admin
groups\":[\"system:masters\"]

Так же посмотрим Cluster Role Binding в Kubernetes под названием cluster-admin. Все встает на места:

kubectl get clusterrolebindings cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2022-07-22T04:22:52Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "101"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin
  uid: 34accbbf-34a5-4783-63c4a9f6cf3a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

Члены группы system:masters обладают полными правами в кластерe Kubernetes. Соответственно, все члены группы User Admin в Prism Central, попадают в группу system:masters при генерации токена и имеют полные права.

Так что же делать, если мы хотим сделать пользователя администратором кластера Kubernetes, но не хотим давать огромные права в Prism Central?

Сделать это можно следующим образом:

  1. Предоставить пользователю\группе доступ к Prism Central;
  2. Настроить RBAC в кластере Kubernetes, указав необходимые права соответствующим пользователям\группам.

Мы уже выяснили, что для того, чтобы предоставить доступ к Kubernetes, пользователю нужен доступ в Prism Central откуда он сможет загружать kubeconfig со специально сгенерированным для него токеном, где будет отмечено название его учетной записи и список групп, в которых он состоит

Для предоставления доступа к Prism Central, пользователю должна быть назначена хотя бы одна роль.

Назначить пользователю роль можно в меню «шестеренки», в разделе Role Mapping, где можно назначить роль User Admin, Cluster Admin, либо Viewer, или создать более ограниченную в правах роль в меню «гамбургера» – Administration – Roles и затем назначить ее пользователю:

Я предпочитаю не использовать управлением правами из раздела шестеренки, поскольку они дают слишком большие полномочия пользователям. Даже роль Viewer дает возможность просматривать все состояние зарегистрированных в Prism Central кластеров Nutanix и виртуальных машин, что зачастую может быть лишним.

О том, как настраивается RBAC в Prism Central и как создаются роли, я подробно писал ранее, поэтому не буду углубляться в этот процесс.

Создадим минимальную роль для наших пользователей Kubernetes. Administration – Roles – Create Role:

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

Теперь определим пользователей (либо группы), а также объекты к которым они имеют доступ в разделе Manage Assignment для только что созданной роли:

Здесь в поле Users and groups я указываю доменную группу nutanix-devops и, важно, не указываю никаких объектов (например, VM), к которым члены данной группы имеют доступ в поле Entities.

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

Клик по Save:

Попробуем подключиться к Prism Central:

Доступ есть, но объектов нет.

Обратите внимание, что у пользователя отсутствует доступ к меню Karbon (Kubernetes), соответственно, скачать kubeconfig через веб-интерфейс у него не получится (но это не точно), однако не возникнет никаких проблем сделать это через утилиту karbonctl, либо через API.

Теперь переходим в консоль, где у нас имеются утилиты karbonctl и kubectl. Кстати, никто не запрещает скачать karbonctl с Prism Central и разместить утилиту там же, где есть kubectl.

Подключимся к Prism Central с помощью karbonctl пользователем группы nutanix-devops:

karbonctl login --pc-ip 10.10.10.11 --pc-username vmik@vmik.lab

Теперь скачаем kubeconfig файл:

karbonctl cluster kubeconfig --cluster-name dev-k8s >> /opt/kube/dev-k8s.cfg

Обозначим переменную KUBECONFIG, чтобы сообщить kubectl, где находится файл с данными для подключения к кластеру:

export KUBECONFIG=/opt/kube/dev-k8s.cfg

И попробуем запросить список узлов в кластере:

kubectl get nodes
Error from server (Forbidden): nodes is forbidden: User "vmik@vmik.lab" cannot list resource "nodes" in API group "" at the cluster scope

Как уже говорилось ранее, доступ к кластерам имеют пользователи из группы User Admin в Prism Central, которые являются членами группы system:masters в k8s, поэтому наш пользователь, не смотря на доступ к Prism Central доступа в кластер k8s все еще не имеет.

Чтобы дать полный доступ к кластеру, нам необходимо поправить RBAC в Kubernetes.

Аналогичным образом подключимся к PC пользователем из группы User Admin и скачиваем kubeconfig файл привилегированного пользователя, чтобы произвести изменения в RBAC.

Создадим YAML манифест Cluster Role Binding, в котором дадим группе nutanix-devops права cluster-admin:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin-nutanix-devops
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: nutanix-devops

В секции subjects, мы указываем kind – group, что соответствует группе пользователей. Можно так же указать user, что будет соответствовать пользователю. name – название группы, либо учетная запись пользователя.

Создаем Cluster Role Binding:

kubectl create -f ./clusterrolebinding-nutanix-devops.yaml
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-nutanix-devops created

Теперь получаем kubeconfig для пользователя группы nutanix-devops и проверяем:

karbonctl login --pc-ip 10.10.10.11 --pc-username vmik@vmik.lab

karbonctl cluster kubeconfig --cluster-name dev-k8s >> /opt/kube/dev-k8s.cfg

export KUBECONFIG=/opt/kube/dev-k8s.cfg

kubectl get nodes -A
NAME                                 STATUS   ROLES    AGE   VERSION
karbon-dev-k8s-8601db-k8s-master-0   Ready    master   41d   v1.19.13
karbon-dev-k8s-8601db-k8s-master-1   Ready    master   41d   v1.19.13
karbon-dev-k8s-8601db-k8s-worker-0   Ready    node     41d   v1.19.13
karbon-dev-k8s-8601db-k8s-worker-1   Ready    node     41d   v1.19.13
karbon-dev-k8s-8601db-k8s-worker-2   Ready    node     41d   v1.19.13

И попробуем запустить контейнер:

kubectl run nginx --image=nginx
pod/nginx created

kubectl get pods
NAME    READY   STATUS              RESTARTS   AGE
nginx   0/1     ContainerCreating   0          4s

Таким образом, мы настроили RBAC в Prism Central и Kubernetes, предоставив пользователям доменной группы полное управление кластером, и в то же время максимально ограничили их доступ к объектам Prism Central.

В качестве заключения:

Есть еще один момент, о котором я не упомянул. Ранее, я писал, что у пользователя с минимальными правами в Prism Central, отсутствует доступ к вкладке Karbon (Kubernetes) и скачать kubeconfig через web невозможно.

Это не совсем так. Интерфейс Karbon доступен по адресу Prism Central, по порту 7050 (https://pc.vmik.lab:7050).

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

К сожалению, в моей практике данный интерфейс работал корректно только в следующем случае:

  1. Необходимо предварительно подключиться и авторизоваться в Prism Central (порт 9440);
  2. В рамках этой же сессии перейти на тот же адрес, но по порту 7050.

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

Loading

Leave a Reply

Your email address will not be published. Required fields are marked *