Ранее я уже писал о том, как получить доступ к кластеру Kubernetes, развернутому с помощью Nutanix Karbon или Nutanix Kubernetes Engine по-новому, однако, считаю, что данный вопрос нужно осветить более подробно и углубиться в процедуру разграничения доступа пользователей.
Под катом мы посмотрим, как происходит авторизация пользователей в Karbon, как получить доступ к управлению кластером Kubernetes и что для этого нужно.
Чтобы получить доступ к кластеру Kubernetes нам нужен kubeconfig файл, который можно получить тремя способами:
- Скачать из интерфейса Prism Central:
- Запросить через API;
- Получить с помощью утилиты 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?
Сделать это можно следующим образом:
- Предоставить пользователю\группе доступ к Prism Central;
- Настроить 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 напрямую из браузера:
К сожалению, в моей практике данный интерфейс работал корректно только в следующем случае:
- Необходимо предварительно подключиться и авторизоваться в Prism Central (порт 9440);
- В рамках этой же сессии перейти на тот же адрес, но по порту 7050.
Тестировал данный функционал на разных версиях PC и к сожалению, ни разу у меня он не заработал корректно, поэтому рекомендовать его как основной метод не могу, но, возможно, у вас не возникнет никаких проблем.