Контроль доступа на основе ролей (RBAC) в Kubernetes

Контроль доступа на основе ролей (RBAC) используется для назначения доступа к компьютерным или сетевым ресурсам в кластере Kubernetes.

В этой статье мы разберем основы RBAC и создадим объекты Role, ClusterRole, RoleBinding и ClusterRoleBinding.

Затем мы создадим файл kubeconfig, чтобы предоставить ограниченный доступ определенному пользователю в выбранном пространстве имен.

Но прежде чем мы продолжим, давайте сначала разберемся с основами.

1. Role или ClusterRole содержит набор разрешений.
2. Role устанавливает разрешения в пределах конкретного пространства имен, а ClusterRole является ресурсом без пространства имен.
3. RoleBinding предоставляет разрешения, определенные в роли, пользователю или группе пользователей, в то время как ClusterRoleBinding предоставляет доступ на уровне кластера.
4. RoleBinding может ссылаться на любую Role в том же пространстве имен. В качестве альтернативы RoleBinding может ссылаться на ClusterRole и связывать этот ClusterRole с пространством имен RoleBinding.
5. Файл kubeconfig — это файл, используемый для настройки доступа к Kubernetes из командной строки kubectl.

Чтобы понять RBAC более подробно, посетите официальную документацию Kubernetes здесь.

Примечание: Смотрите скриншоты, чтобы избежать путаницы перед выполнением команд. ( ubuntu@master = мастер-узел и ubuntu@ip-172-31-25-70 = пользовательская машина)

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

1. Кластер Kubernetes с как минимум 1 рабочим узлом.
   Если вы хотите научиться создавать кластер Kubernetes, нажмите здесь. Этот гид поможет вам создать кластер Kubernetes с 1 мастером и 2 узлами на AWS Ubuntu EC2 Instances.

Что мы будем делать?

1. Создать файлы объектов Role, Role Binding, Cluster Role, Cluster Role Binding.
2. Создать объекты Role, Role Binding, Cluster Role, Cluster Role Binding в кластере.
3. Предоставить доступ пользователям с помощью файла kubeconfig.
4. Резюме создания файла kubeconfig.

Создание файлов объектов Role, Role Binding, Cluster Role, Cluster Role Binding.

Создайте файл для создания Role в пространстве имен “default”, который может использоваться для предоставления доступа на получение, просмотр и список подов.

vim my-role.yml

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Создайте новый файл для создания RoleBinding, который позволяет роли “pod-reader” пользователю “jane” в пространстве имен “default”.

vim my-role-binding.yml

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Создайте файл для создания ClusterRole, который может использоваться для предоставления доступа на получение, просмотр и список секретов в любом конкретном пространстве имен или во всех пространствах имен в зависимости от того, как он связан.

vim my-cluster-role.yml

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Создайте новый файл для создания ClusterRoleBinding, который позволит любому пользователю в группе “manager” читать секреты в любом пространстве имен.

vim my-cluster-role-binding.yml

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Создание объектов Role, Role Binding, Cluster Role, Cluster Role Binding.

Получите список существующих Roles и ClusterRoles из кластера.

kubectl get roles

kubectl get clusterroles

Получите список существующих RoleBindings и ClusterRoleBindings из кластера.

kubectl get rolebinding

kubectl get clusterrolebinding

Теперь создайте Role, RoleBinding и ClusterRole ClusterRoleBinding, используя файлы, которые мы создали на предыдущих шагах.

kubectl create -f my-role.yml

kubectl create -f my-role-binding.yml

kubectl create -f my-cluster-role.yml

kubectl create -f my-cluster-role-binding.yml

С помощью следующих команд проверьте, были ли созданы объекты.

kubectl get roles | grep pod-reader

kubectl get rolebinding | grep read-pods

kubectl get clusterroles | grep secret-reader

kubectl get clusterrolebinding | grep read-secrets-global

На приведенном выше скриншоте вы можете увидеть, что Role, RoleBinding и ClusterRole, ClusterRoleBinding были созданы.

Предоставление доступа пользователям с помощью файла kubeconfig (config).

Теперь в этом разделе мы создадим файл конфигурации, который можно будет поделиться с пользователем. Здесь, чтобы протестировать этот сценарий, мы создадим пользователя “bob” на сервере Linux и поделимся этим файлом конфигурации с пользователем “bob”. Затем мы попробуем выполнить операции, которые разрешены и запрещены этому пользователю. Мы свяжем административный ClusterRole с пользователем “bob”, что даст доступ ко всем объектам в пространстве имен “bob”.

На мастер-узлах создайте ключ и запрос на подпись сертификата (CSR) с помощью openssl.

pwd

mkdir user-bob

cd user-bob/

openssl req -new -newkey rsa:4096 -nodes -keyout bob-k8s.key -out bob-k8s.csr -subj "/CN=bob/O=devops"

cat bob-k8s.csr | base64 | tr -d '\n'

Создайте файл определения объекта CertificateSigningRequest, содержащий CSR, который мы сгенерировали на предыдущем шаге. В приведенном ниже файле добавьте вывод команды “cat bob-k8s.csr | base64 | tr -d ‘\n’” в свойство “request”.

vim k8s-csr.yaml

apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: bob-k8s-access
spec:
  groups:
  - system:authenticated
  request: # замените вывод: cat bob-k8s.csr | base64 | tr -d '\n'
  usages:
  - client auth

cat k8s-csr.yaml

Создайте объект CertificateSigningRequest в Kubernetes, содержащий CSR, который мы сгенерировали на предыдущем шаге.

kubectl get csr

kubectl create -f k8s-csr.yaml

kubectl get csr

Теперь мы хотим одобрить созданный на предыдущем шаге объект CSR (CertificateSigningRequest).

kubectl get csr

kubectl certificate approve bob-k8s-access

kubectl get csr

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

Получите сертификат, доступный в поле ‘status.certificate’ объекта CSR.

ls -lt

kubectl get csr bob-k8s-access -o jsonpath='{.status.certificate}' | base64 --decode > bob-k8s-access.crt

ls -lt

cat bob-k8s-access.crt

Получите сертификат CA кластера, который является следующим требованием для файла kubeconfig Боба, и сохраните его в файл “k8s-ca.crt”.

ls -lt

kubectl config view -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' --raw | base64 --decode - > k8s-ca.crt

ls -lt

cat k8s-ca.crt

Настройте конфигурацию кластера в файле kubeconfig Боба. Все эти данные будут взяты из нашего существующего kubeconfig с помощью следующей команды.

ls -lt

kubectl config set-cluster $(kubectl config view -o jsonpath='{.clusters[0].name}') --server=$(kubectl config view -o jsonpath='{.clusters[0].cluster.server}') --certificate-authority=k8s-ca.crt --kubeconfig=bob-k8s-config --embed-certs

ls -lt

cat bob-k8s-config

Настройте пользователя, который импортирует ключ и сертификат Боба в файл конфигурации.

ls -lt

kubectl config set-credentials bob --client-certificate=bob-k8s-access.crt --client-key=bob-k8s.key --embed-certs --kubeconfig=bob-k8s-config

ls -lt

cat bob-k8s-config

Создайте контекст для файла конфигурации “Боба” с помощью следующей команды.

ls -lt

kubectl config set-context bob --cluster=$(kubectl config view -o jsonpath='{.clusters[0].name}') --namespace=bob --user=bob --kubeconfig=bob-k8s-config

ls -lt

cat bob-k8s-config

Создайте пространство имен для Боба.

kubectl get ns

kubectl create ns bob

kubectl get ns -o wide

kubectl label ns bob user=bob env=sandbox

kubectl get ns -o wide

Укажите контекст, который Боб будет использовать для своих команд kubectl.

cat bob-k8s-config

kubectl config use-context bob --kubeconfig=bob-k8s-config

cat bob-k8s-config

Скопируйте “bob-k8s-config” с мастер-узла в файл “.kube/config” в домашнем каталоге Боба и протестируйте kubeconfig Боба, запустив ‘kubectl version’.

vim .kube/config #Все выводы команды "cat bob-k8s-config" выполненной на мастер-узле и сохраните в /home/bob/.kube/config на пользовательской машине.

kubectl version #Выполните это на пользовательской машине

Проверьте разрешения, выполнив следующие команды с пользовательской машины.

kubectl get nodes

kubectl get pods

kubectl get ns

kubectl get deployments

kubectl get all

На приведенном выше скриншоте вы можете увидеть, что пользователь “Боб” не может выполнять никакие операции, так как ему не был предоставлен доступ.

Назначьте пользователю Бобу роль по умолчанию «admin» для создания большинства типов объектов Kubernetes в своем пространстве имен. Эта роль “bob-admin” даст администраторский доступ пользователю “Боб” в пространстве имен “bob” с использованием ClusterRole “admin”.

Выполните следующую команду на мастер-узле.

kubectl create rolebinding bob-admin --namespace=bob --clusterrole=admin --user=bob 

kubectl get rolebinding

kubectl get clusterrole | grep admin

Получите пространства имен, созданные для Боба.

Теперь выполните все следующие команды с пользовательской машины.

kubectl get ns

kubectl get ns bob

На приведенном выше скриншоте вы можете увидеть, что пользователь “Боб” не может перечислить ресурсы пространства имен.

Создайте Pod в пространстве имен “bob”, установленном в качестве пространства имен по умолчанию в файле kubeconfig Боба.

kubectl run nginx --image=nginx

kubectl get pods

kubectl get pods -o wide

Проверьте текущее пространство имен, установленное в качестве пространства имен по умолчанию.

kubectl config get-contexts

На приведенном выше скриншоте вы можете увидеть, что “Боб” может создать Pod в пространстве имен “bob”, так как мы связали роль “admin” с пользователем “Боб” для пространства имен “bob”.

Попробуйте создать pod в пространстве имен “default”, на которое у Боба нет никаких разрешений. Поскольку мы разрешили пользователю “Боб” создавать объекты только в пространстве имен “bob”, пользователь Боб не сможет создать какие-либо ресурсы в любом пространстве имен, кроме “bob”.

kubectl run nginx-2 --image=nginx --namespace=default

Проверьте пространство имен, установленное в качестве пространства имен по умолчанию в файле kubeconfig. Это показывает, что пространство имен “bob” установлено в качестве пространства имен по умолчанию в файле конфигурации.

kubectl config view --minify | grep namespace:

Резюме создания файла Kubeconfig

1. Создайте ключ и запрос на подпись сертификата (CSR) с помощью openssl.
2. Создайте файл определения объекта CertificateSigningRequest.
3. Создайте объект CertificateSigningRequest.
4. Одобрите CSR (CertificateSigningRequest).
5. Получите сертификат объекта CSR.
6. Получите сертификат CA кластера.
7. Настройте конфигурацию кластера в файле kubeconfig.
8. Настройте пользователя.
9. Создайте контекст.
10. Создайте пространство имен для пользователя.
11. Укажите контекст в файле kubeconfig.
12. Передайте kubeconfig пользователю.
13. Протестируйте разрешения, используя файл конфигурации пользователя.
14. Назначьте роль пользователю.
15. Снова протестируйте разрешения, используя файл конфигурации пользователя.

Заключение

В этой статье мы рассмотрели основы Role, RoleBinding и ClusterRole, ClusterRoleBinding, а также создали эти объекты в нашем кластере. Затем мы создали файл конфигурации, который позволяет определенному пользователю выполнять операции в определенном пространстве имен. Мы увидели, как RBAC может помочь нам ограничить доступ к кластеру Kubernetes.