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 name\tServer\n»}{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 name\tServer\n»}{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/

Was this helpful?

0 / 0

#cli #k8s #linux #RBAC