Запросить демо
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Дополнительные услуги
Оставить заявку
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Узнать стоимость
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Дополнительные услуги
Попробовать бесплатно
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Дополнительные услуги
Быть в теме

Kubernetes 1.7 - Настройка RBAC

15.06.2018 11 минут 1325

В этом руководстве будут рассмотрены основные объекты API Kubernetes, предназначенные для управления доступом на основе ролей (RBAC).

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

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

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

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


the server does not allow access to the requested resource

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

Предварительные требования

Это руководство предполагает, что перед тем, как двигаться дальше, у вас выполнены следующие требования:

  • У вас на вашем локальном компьютере установлен Minikube, а также включен RBAC:
    $ minikube start --extra-config=apiserver.Authorization.Mode=RBAC
  • Или у вас есть и запущен кластер Kubernetes
  • У вас установлен kubectl.
  • У вас установлен Helm и Tiller
  • У вас есть понимание того, как работает Kubernetes, и как функционируют его основные компоненты:
  • Pods
  • Deployments
  • Namespaces
  • Secrets
  • Replicasets
  • PersistentVolumes
  • ConfigMaps
  • Nodes
  • У вас установлен OpenSSL.

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:


$ kubectl create namespace office

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

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

  • Создайте закрытый ключ для своего пользователя. В этом примере мы назовем файл user1.key
    
    $ openssl genrsa -out user1.key 2048
    
  • Создайте запрос сертификата user1.csr, используя только что созданный вами закрытый ключ (user1.key). Убедитесь, что вы указали свое имя пользователя и группу в разделе -subj(CN для имени пользователя и O для группы). Как упоминалось ранее, мы будем использовать имя user1 и deparment1 в качестве группы:
    
    $ 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 существуют в соответствующей директории.
  • Создайте сертификат 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
    
  • Сохраните как user1.crt, так и user1.key где-нибудь в безопасном месте (например, в директории ~/.kube/certs/):
    
    $ mkdir ~/.kube/certs
    $ cp user1.crt ~/.kube/certs
    $ cp user1.key ~/.kube/certs
    
  • Добавьте новый контекст с новыми учетными данными для вашего кластера Kubernetes. Этот пример предназначен для кластера Minikube, аналогично нужно действовать и в других инсталляциях Kubernetes:
    
    $ kubectl config set-credentials user1 --client-certificate=$HOME/.kube/certs/user1.crt --client-key=$HOME/.kube/certs/user1.key
    $ kubectl config set-context user1-context --cluster=minikube --namespace=office --user=user1
    

Примечание: если вы разворачивали кластер по нашему руководству, то примеры команд на создание контекста будут следующими:


$ kubectl config set-credentials user1 --client-certificate=$HOME/.kube/certs/user1.crt --client-key=$HOME/.kube/certs/user1.key
$ kubectl config set-context user1-context --cluster=kubernetes --namespace=office --user=user1

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


$ kubectl --context=user1-context get pods
Error from server (Forbidden): User "user1" cannot list pods in the namespace "office". (get pods)

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

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


kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: office
name: deployment-manager
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["deployments", "replicasets", "pods"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # вы таже можете использовать ["*"] вместо списка

Создайте Role в вашем кластере Kubernetes при помощи команды kubectl create:

$ kubectl create -f role-deployment-manager.yaml

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

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


kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: deployment-manager-binding
namespace: office
subjects:
- kind: User
name: user1
apiGroup: ""
roleRef:
kind: Role
name: deployment-manager
apiGroup: ""

Применим эти настройки к нашему кластеру:


$ kubectl create -f rolebinding-deployment-manager.yaml

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

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

$ kubectl --context=user1-context run --image nginx mynginx
deployment "mynginx" created
$ kubectl --context=user1-context get pods
NAME                       READY     STATUS    RESTARTS   AGE
mynginx-3071068301-05ssq   1/1       Running   0          12s

Однако, если вы запустите ту же команду с аргументом --namespace=default, она не выполнится, так как пользователь user1 не имеет доступа к пространству имен default.

$ kubectl --context=user1-context run --image nginx --namespace=default mynginx

Ошибка будет следующей:

Error from server (Forbidden): User "user1" cannot create deployments.extensions in the namespace "default". (post deployments.extensions)

Теперь у вас есть понимание того, как создавать пользователей с ограниченными полномочиями в вашем кластере.

Сервисы упоминаемые в статье

  1. Публичное облако КРОК

Не пропустите самые важные, интересные и полезные статьи недели

Ваш e-mail успешно подписан.

Смотрите также