Kubernetes — пример использования RBAC

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




Примеры включают:




  • Защиту кластера путем разрешения привилегированные действий (например, доступ к секретам) только администраторам.




  • Включение принудительной аутентификации пользователей в вашем кластере.




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




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




В следствие того, что в последних версиях Kubernetes RBAC включен по умолчанию, вы, возможно, уже обнаружили специфические ошибки при настройке решений по сетевой виртуализации (например, flunneld) или деплое Helm в вашем кластере. Обычно такие ошибки выглядят следующим образом:




the server does not allow access to the requested resource




ща рассмотрим как правильно работать с RBAC, чтобы вы могли решать такого рода проблемы.




API объекты RBAC




Одной из основных функций Kubernetes является то, что все его ресурсы представляют собой моделируемые API объекты, которые позволяют выполнять с ними операции CRUD (Create, Read, Update, Delete). Примерами ресурсов являются:




  • Pods




  • Deployments




  • Namespaces




  • Secrets




  • Replicasets




  • PersistentVolumes




  • ConfigMaps




  • Nodes




Примеры возможных операций над этими ресурсами:




  • create




  • get




  • delete




  • list




  • update




  • edit




  • watch




  • exec




Высокоуровневые ресурсы связаны с группами API (например, Pod относится к core группе API, а Deployments относятся к группе API apps). Дополнительные сведения обо всех доступных ресурсах, операциях и группах API см. в официальном справочнике API Kubernetes.




Для управления RBAC в Kubernetes, помимо ресурсов и операций, нам нужны следующие элементы:




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




  • Roles и ClusterRoles. Оба состоят из правил. Разница между Role и ClusterRole – это область применимости: в Role правила применимы к одному пространству имен, тогда как ClusterRole правила распространяются на весь кластер, поэтому правила применяются к нескольким пространствам имен. ClusterRoles также могут определять правила для ресурсов уровня кластера (например, узлы). Roles и ClusterRoles мапятся на API ресурсы внутри нашего кластера.




  • Subjects. Субъекты соответствуют объектам, которые пытаются выполнить операции в кластере. Существует три типа субъектов:




  • User Accounts (учетные записи пользователей): глобальны и предназначены для людей или процессов, живущих вне кластера. В кластере Kubernetes нет связанного с этим субъектом объекта API ресурса.




  • Service Accounts (учетные записи служб). Этот вид учетной записи предназначен для внутрикластерных процессов, запущенных в Pod-ах вашего кластера, которым необходимо получить доступ к API кластера.




  • Groups (группы). Группы используется для ссылки на сразу несколько учетных записей.Некоторые группы, такие как cluster-admin (объясняется в последующих разделах), создаются по умолчанию.




  • RoleBindings (связи ролей) и ClusterRoleBindings (связи кластерных ролей): как видно из названия сущностей, они связывают субъекты с ролями (т.е. операциями, которые может выполнять конкретный пользователь). Что касается их разницы с ClusterRoles, разница заключается в области применимости: RoleBinding применяет правила внутри одного пространства имен, тогда как ClusterRoleBinding применяет их во всех пространствах имен кластера.




Вы можете найти примеры каждого элемента API в официальной документации Kubernetes.




Создание пользователя с ограничениями по пространству имен




В этом примере мы создадим следующую учетную запись пользователя:




  • Имя пользователя: user1




  • Группа: deparment1




Мы добавим необходимые политики RBAC, чтобы этот пользователь мог полностью управлять развертываниями (т.е. использовать команду kubectl run) только внутри пространства имен office. В конце мы проверим созданные политики, чтобы убедиться, что они работают так, как мы их определили.




Создание пространства имен




Выполните команду kubectl create для создания пространства имен office. Команду необходимо запустить от пользователя Kubernetes admin:




[root@kub-master-1 ~]# kubectl create namespace office




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




Как уже упоминалось ранее, в Kubernetes нет объектов API для управления учетными записями пользователей. Из доступных способов управления аутентификацией (см. официальную документацию Kubernetes) для простоты мы будем использовать сертификаты OpenSSL. Необходимые шаги:




  • Создайте закрытый ключ для своего пользователя. В этом примере мы назовем файл user1.key[root@kub-master-1 ~]# openssl genrsa -out user1.key 2048




  • Создайте запрос сертификата user1.csr, используя только что созданный вами закрытый ключ (user1.key). Убедитесь, что вы указали свое имя пользователя и группу в разделе -subj(CN для имени пользователя и O для группы). Как упоминалось ранее, мы будем использовать имя user1 и deparment1 в качестве группы:




[root@kub-master-1 ~]# openssl req -new -key user1.key -out user1.csr -subj «/CN=user1/O=deparment1»




  • Найдите свой центр сертификации кластера Kubernetes (CA). Он будет отвечать за утверждение запроса и получение необходимого сертификата для доступа к API кластера. Обычно он располагается в директории /etc/kubernetes/pki/. В случае Minikube это будет ~/.minikube/. Убедитесь, что файлы ca.crt и ca.key существуют в соответствующей директории.




[root@kub-master-1 ~]# ll /etc/kubernetes/pki/

total 156

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 admin-kub-master-1-key.pem

-rw-------. 1 kube kube-cert 1399 Mar  8 18:58 admin-kub-master-1.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 admin-kub-master-2-key.pem

-rw-------. 1 kube kube-cert 1399 Mar  8 18:58 admin-kub-master-2.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 admin-kub-master-3-key.pem

-rw-------. 1 kube kube-cert 1399 Mar  8 18:58 admin-kub-master-3.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 apiserver-key.pem

-rw-------. 1 kube kube-cert 2444 Mar  8 18:58 apiserver.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 ca-key.pem

-rw-------. 1 kube kube-cert 1090 Mar  8 18:58 ca.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 front-proxy-ca-key.pem

-rw-------. 1 kube kube-cert 1111 Mar  8 18:58 front-proxy-ca.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 front-proxy-client-key.pem

-rw-------. 1 kube kube-cert 1367 Mar  8 18:58 front-proxy-client.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-controller-manager-key.pem

-rw-------. 1 kube kube-cert 1375 Mar  8 18:58 kube-controller-manager.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 kube-proxy-kub-master-1-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-master-1.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-proxy-kub-master-2-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-master-2.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 kube-proxy-kub-master-3-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-master-3.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-proxy-kub-worker-1-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-worker-1.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-proxy-kub-worker-2-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 kube-proxy-kub-worker-2.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 kube-scheduler-key.pem

-rw-------. 1 kube kube-cert 1363 Mar  8 18:58 kube-scheduler.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-master-1-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-master-1.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-master-2-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-master-2.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-master-3-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-master-3.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-worker-1-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-worker-1.pem

-rw-------. 1 kube kube-cert 1679 Mar  8 18:58 node-kub-worker-2-key.pem

-rw-------. 1 kube kube-cert 1273 Mar  8 18:58 node-kub-worker-2.pem

-rw-------. 1 kube kube-cert 1675 Mar  8 18:58 service-account-key.pem




  • Создайте сертификат user1.crt, одобрив запрос на подпись сертификата, user1.csr, сделанный ранее. Убедитесь, что вы заменили CA_LOCATION в примере команды ниже на местоположение вашего актуального CA кластера. Сертификат будет действителен в течение 500 дней:




$ openssl x509 -req -in user1.csr -CA CA_LOCATION/ca.crt -CAkey CA_LOCATION/ca.key -CAcreateserial -out user1.crt -days 500




в моём случае это команда:




[root@kub-master-1 ~]# openssl x509 -req -in user1.csr -CA /etc/kubernetes/pki/ca.pem -CAkey /etc/kubernetes/pki/ca-key.pem -CAcreateserial -out user1.crt -days 500
и её вывод:




Signature ok

subject=/CN=user1/O=deparment1

Getting CA Private Key




  • Сохраните как user1.crt, так и user1.key где-нибудь в безопасном месте (например, в директории ~/.kube/certs/):
    $ mkdir ~/.kube/certs
    $ cp user1.crt ~/.kube/certs
    $ cp user1.key ~/.kube/certs




  • добавьте новый контекст с новыми учетными данными для вашего кластера Kubernetes.
    [root@kub-master-1 ~]# kubectl config set-credentials user1 —client-certificate=$HOME/.kube/certs/user1.crt —client-key=$HOME/.kube/certs/user1.keyСмотрим имя кластера:
    [root@kub-master-1 ~]# kubectl config view -o jsonpath='{«Cluster nametServern»}{range .clusters[*]}{.name}{«t»}{.cluster.server}{«n»}{end}’




  • добавьте новый контекст с новыми учетными данными для вашего кластера Kubernetes.
    [root@kub-master-1 ~]# kubectl config set-credentials user1 —client-certificate=$HOME/.kube/certs/user1.crt —client-key=$HOME/.kube/certs/user1.keyСмотрим имя кластера:
    [root@kub-master-1 ~]# kubectl config view -o jsonpath='{«Cluster nametServern»}{range .clusters[*]}{.name}{«t»}{.cluster.server}{«n»}{end}’




  • [root@kub-master-1 ~]# kubectl config set-context user1-context —cluster=cluster.local —namespace=office —user=user1




добавим теперь пользователя  под которым будем работать:




[root@kub-master-1 ~]# adduser test
[root@kub-master-1 ~]# mkdir -p /home/test/.kube/certs
[root@kub-master-1 ~]# cp /root/.kube/certs/user1.* /home/test/.kube/certs/




смотрим файл:
[root@kub-master-1 ~]# cat /root/.kube/config




нас интересует:




certificate-authority-data
и
server




и создаём файл следующего вида:




[root@kub-master-1 ~]# cat /home/test/.kube/config




apiVersion: v1

clusters:

- cluster:

    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMrVENDQWVHZ0F3SUJBZ0lKQUl0L0JPdHQrWUhVTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIydDFZbVV0WTJFd0lCY05NakV3TXpBNE1USTFPREE1V2hnUE1qRXlNVEF5TVRJeE1qVTRNRGxhTUJJeApFREFPQmdOVkJBTU1CMnQxWW1VdFkyRXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCCkFRQ2FRZk9nbzdpZ3oyV0QyWEd1dzNSd2x6VUhxcjRFT2k1d0wwaWZvVnBaWXBzZk9ORlE0ME90akVEQUVsUXYKSW5YeW1iVEdQN0w0QUFIZlNFZWRULysyUFh4NmV6VDV3WlozbGg5WWt1UmhHcWZUamtsVXN6LzVoOVpNekhzNgpwWWVyNzVJQUZyRXlxSDFtR2pwM0FjaUZmNUU1TmFvczJXQ21HWklPbmdqTmVUMElXdHFGQjNVTzNMSTkxS0JJCi9tNWRPZTh6elJjVWxBODltTTFhTzBBSTZEYWNUbXRiVllDcklwVW01cE45UHFWSjVZNGorTXQvSlpISTlnRisKMUsvUW5hb0owVm5udkl0T0dJbzhaSlZ5ellTVTlNZlltcmE0RkhvYmQzaGsrN1RBZ3lNRWJlOERLdUlpRENzKwozOVhEaXByL0FaRHVnYnZuOVJYV0M5WnhBZ01CQUFHalVEQk9NQjBHQTFVZERnUVdCQlJaUUtYWFdJTlpCSkJzCkZERTlpTTYydHJuSDhUQWZCZ05WSFNNRUdEQVdnQlJaUUtYWFdJTlpCSkJzRkRFOWlNNjJ0cm5IOFRBTUJnTlYKSFJNRUJUQURBUUgvTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFBQVgrakdVT3k4R1lEKzh6M244SFV6V25XeAp0RWRrdEJEakxVcjB2anovN0lVRDU0R0MrRm5FY0ZybXZMVHhkYWNNNXNEQmo2MHhscjh2dG9mbDFzekJxMjVVCnFUWTRveDZ1VzUreGlBU1hqNFhHeEZtUG8rUzVGUi9EZjA3clBJZ3QzWWdEYkZHUUw5aHh4UXdKMDdVR3JKa08KM0QyNjYzUDJ4WTBndGdyYzY0UG5EWDBuZ1VxSzJ0akxsKy9qU1c1MHdnWURvbUlYNjlyWUxyMElzOWpYZmk0OQpFK3ljb2ZURElSeUFWT2U2QTBXbmQ2MFhlMEZPdUdqUVZHcWRKeVhBeVhrOW1FK1lNRk9kS09PZjMxNmtYeW90ClppNmE3bnZtYjhFSWpXZWFpd1JwQzNGOEgrdHRFYzFmSVdvNkoralJZTlFjME5BaFhZbFRwRmp6blA0TAotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==

    server: https://192.168.1.201:6443

  name: cluster.local

contexts:

- context:

    cluster: cluster.local

    namespace: office

    user: user1

  name: user1-context

kind: Config

preferences: {}

users:

- name: user1

  user:

    client-certificate: certs/user1.crt

    client-key: certs/user1.key




не забываем указать certificate-authority-data и server




Теперь при попытке использовать kubectl с этим конфигурационным файлом мы будем получать отказ в доступе. Это ожидаемое поведение, поскольку мы не определили никаких разрешенных операций для только что созданного пользователя. Убедитесь в этом сами:




[test@kub-master-1 ~]$ kubectl get pod -n my-site
The connection to the server localhost:8080 was refused — did you specify the right host or port?
данная ошибка логична потому что мы не указали context




[test@kub-master-1 ~]$ kubectl —context=user1-context get pods -n my-site
Error from server (Forbidden): pods is forbidden: User «user1» cannot list resource «pods» in API group «» in the namespace «my-site»




а вот эта как рас та ошибка что и должна прилетать Forbidden




Создание роли для управления развертываниями




Создайте файл role-deployment-manager.yaml с приведенным ниже содержимым. В этом yaml-файле мы создаем правило, которое позволяет пользователю выполнять несколько операций с Deployments, Pods и ReplicaSets (необходимых для создания Deployment), которые принадлежат к core (выделены “” в yaml-файле) extensions группам API:




[root@kub-master-1 ~]# cat role-deployment-manager.yaml




apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  namespace: office

  name: deployment-manager

rules:

- apiGroups: ["", "extensions", "apps"]

  resources: ["deployments", "replicasets", "pods"]

  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # вы таже можете использовать ["*"] вместо списка




[root@kub-master-1 ~]# kubectl create -f role-deployment-manager.yaml




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




Создайте файл rolebinding-deployment-manager.yaml так, как показано ниже. В этом файле мы привязываем Role deployment-manager к субъекту User Account user1 внутри пространства имен office:




[root@kub-master-1 ~]# cat rolebinding-deployment-manager.yaml




apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: deployment-manager-binding

  namespace: office

subjects:

- kind: User

  name: user1

  apiGroup: ""

roleRef:

  kind: Role

  name: deployment-manager

  apiGroup: ""




[root@kub-master-1 ~]# kubectl create -f rolebinding-deployment-manager.yaml




Тестирование политик RBAC




Теперь вы можете выполнять следующие команды без каких-либо проблем:




[test@kub-master-1 ~]$ kubectl —context=user1-context get pods -n office
No resources found in office namespace.




запустим тестовое приложение и проверим что нам доступно из под нашего пользователя:




[test@kub-master-1 ~]$ kubectl —context=user1-context get all -n office




NAME                                        READY   STATUS    RESTARTS   AGE

pod/my-deployment-apache-859486bd8c-8ccxd   1/1     Running   0          96s



NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE

deployment.apps/my-deployment-apache   1/1     1            1           96s



NAME                                              DESIRED   CURRENT   READY   AGE

replicaset.apps/my-deployment-apache-859486bd8c   1         1         1       96s

Error from server (Forbidden): replicationcontrollers is forbidden: User "user1" cannot list resource "replicationcontrollers" in API group "" in the namespace "office"

Error from server (Forbidden): services is forbidden: User "user1" cannot list resource "services" in API group "" in the namespace "office"

Error from server (Forbidden): daemonsets.apps is forbidden: User "user1" cannot list resource "daemonsets" in API group "apps" in the namespace "office"

Error from server (Forbidden): statefulsets.apps is forbidden: User "user1" cannot list resource "statefulsets" in API group "apps" in the namespace "office"

Error from server (Forbidden): horizontalpodautoscalers.autoscaling is forbidden: User "user1" cannot list resource "horizontalpodautoscalers" in API group "autoscaling" in the namespace "office"

Error from server (Forbidden): jobs.batch is forbidden: User "user1" cannot list resource "jobs" in API group "batch" in the namespace "office"

Error from server (Forbidden): cronjobs.batch is forbidden: User "user1" cannot list resource "cronjobs" in API group "batch" in the namespace "office"




как видим нам доступны только следующие сущности:
deployments  replicasets   pods




как рас их мы и перечислили в конфиге  role-deployment-manager.yaml  для нашего namespace office




проверим удаление:




YAML




[test@kub-master-1 ~]$ kubectl --context=user1-context delete pod my-deployment-apache-859486bd8c-8ccxd -n office

pod "my-deployment-apache-859486bd8c-8ccxd" deleted




как видим всё ок.




Источник: https://sidmid.ru/kubernetes-пример-использования-rbac/



2023-01-02T06:12:18
DevOps