Kubernetes 1.7 - Настройка 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.

Одной из основных функций 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

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

$ 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)

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