Начиная с 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/
