Поиск по сайту:

Как начать работу с Kubernetes RBAC


Управление доступом на основе ролей (RBAC) — это механизм определения действий, которые учетные записи пользователей могут выполнять в вашем кластере Kubernetes. Включение RBAC снижает риск, связанный с кражей учетных данных и захватом учетной записи. Предоставление каждому пользователю минимального набора разрешений, который им требуется, предотвращает чрезмерное привилегирование учетных записей.

Большинство популярных дистрибутивов Kubernetes начинаются с одной учетной записи пользователя, которой предоставлен доступ суперпользователя к кластеру. Аутентификация под этой учетной записью позволяет выполнять любые действия, но может представлять значительный риск для безопасности.

В этой статье мы покажем, как включить и настроить Kubernetes RBAC API, чтобы вы могли точно определить возможности пользователя. некоторые пользователи обычно только создают и перечисляют модули, в то время как администраторы также могут удалять элементы. Вы можете настроить и применить эти политики с помощью системы RBAC.

Включение RBAC в Kubernetes

RBAC — это необязательная функция Kubernetes, но в большинстве основных дистрибутивов она включена по умолчанию, в том числе от поставщиков управляемых облачных сервисов. Вы можете проверить, доступен ли RBAC в вашем кластере, выполнив следующую команду с Kubectl:

$ kubectl api-versions | grep rbac.authorization.k8s
rbac.authorization.k8s.io/v1

Команда должна выдать rbac.authorization.k8s.io/v1 в качестве вывода, если RBAC включен. RBAC отключается, если команда не производит никакого вывода. Вы можете активировать его, запустив сервер Kubernetes API с флагом --authorization-mode=RBAC:

$ kube-apiserver --authorization-mode=RBAC

Обратитесь к документации по вашему дистрибутиву Kubernetes, если вы не знаете, как настроить аргументы запуска сервера API.

Объекты RBAC Kubernetes

Реализация Kubernetes RBAC вращается вокруг четырех различных типов объектов. Вы можете управлять этими объектами с помощью Kubectl, аналогично другим ресурсам Kubernetes, таким как Pods, Deployments и ConfigMaps.

  • Роль. Роль — это набор правил управления доступом, которые определяют действия, которые могут выполнять пользователи.
  • RoleBinding. «Привязка» — это связь между ролью и одним или несколькими субъектами, которыми могут быть пользователи или учетные записи служб. Привязка позволяет субъектам выполнять любые действия, включенные в целевую роль.

Роли и привязки ролей — это объекты с пространством имен. Они должны существовать в определенном пространстве имен и контролировать доступ к другим объектам внутри него. RBAC применяется к ресурсам на уровне кластера, таким как сами узлы и пространства имен, с использованием ClusterRoles и ClusterRoleBindings. Они работают аналогично ролям и привязкам ролей, но нацелены на объекты без пространства имен.

Создание служебной учетной записи

Учетная запись службы Kubernetes — это тип пользователя, которым управляет API Kubernetes. Каждая учетная запись службы имеет уникальный токен, который используется в качестве учетных данных. Вы не можете добавлять обычных пользователей через API Kubernetes, поэтому в этом руководстве мы будем использовать учетную запись службы.

Используйте Kubectl для создания новой учетной записи службы:

$ kubectl create serviceaccount demo

Это создает новую учетную запись с именем demo. Затем вам нужно получить токен, который вы будете использовать для аутентификации в качестве этой учетной записи. Сначала найдите имя секрета, в котором хранится токен:

$ kubectl describe serviceaccount demo
Name:                demo
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   demo-token-w543b
Tokens:              demo-token-w543b
Events:              <none>

Токен этого сервисного аккаунта хранится в секрете с именем demo-token-w543b. Вы можете получить токен, получив значение секрета с помощью этой команды:

$ TOKEN=$(kubectl describe secret demo-token-w543b | grep token: | awk '{print $2}')

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

$ kubectl config set-credentials demo --token=$TOKEN
User "demo" set.
$ kubectl config set-context demo --cluster=default --user=demo
Context "demo" created.

Вы должны изменить значение флага --cluster, чтобы оно соответствовало имени вашего активного подключения к кластеру Kubectl. Обычно это default или имя текущего выбранного контекста. Вы можете проверить выбранный контекст, запустив kubectl config current-context.

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

$ kubectl config current-context
default

$ kubectl config use-context demo
Switched to context "demo".

Команды Kubectl теперь будут аутентифицироваться как сервисная учетная запись demo. Попробуйте получить список подов в вашем кластере:

$ kubectl get pods
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot list resource "pods" in API group "" in the namespace "default"

Операция запрещена, поскольку в сервисном аккаунте demo отсутствует роль, которая позволяет ему получать доступ к модулям.

Добавление роли

Роли создаются так же, как и любой другой объект Kubernetes. Вы пишете файл YAML, который определяет роль и предоставляемые ею разрешения. Каждая роль содержит одно или несколько правил, позволяющих выполнять определенные действия с набором ресурсов. Вот простая роль, которая позволяет пользователю получать информацию о существующих подах:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: demo-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]

Глаголы get и list, примененные к ресурсу pods, означают, что вы сможете запускать такие команды, как get pod. и описать модуль. Попытка создать новый под или удалить существующий будет запрещена, поскольку в роли опущены команды create и delete.

Вернитесь к своему исходному контексту Kubectl, чтобы вы могли добавить роль в свой кластер, используя свою учетную запись администратора:

$ kubectl config use-context default
Switched to context "default".

Теперь добавьте роль:

$ kubectl apply -f role.yaml
role.rbac.authorization.k8s.io/demo-role created

Привязка ролей к пользователям и учетным записям служб

Теперь вы можете связать свою роль с учетной записью службы demo, создав новую привязку RoleBinding. Создайте следующий файл YAML, чтобы определить вашу привязку:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: demo-role-binding
subjects:
  - kind: ServiceAccount
    name: demo
    apiGroup: ""
roleRef:
  kind: Role
  name: demo-role
  apiGroup: ""

Привязки RoleBindings должны включать один или несколько субъектов, которые идентифицируют пользователей и учетные записи служб, на которые нацелена привязка. Поле roleRef относится к роли, которую вы хотите назначить каждому из этих пользователей.

Role и RoleBinding должны существовать в одном и том же пространстве имен. Вместо этого используйте ClusterRole и ClusterRoleBinding для ресурсов без пространства имен.

Затем запустите kubectl apply, чтобы добавить привязку RoleBinding к вашему кластеру. Он вступит в силу немедленно, предоставив сервисному аккаунту demo возможности, заявленные в роли demo-role:

$ kubectl apply -f role-binding.yaml
rolebinding.rbac.authorization.k8s.io/demo-role-binding created

Проверка вашего правила RBAC

Протестируйте свою простую реализацию RBAC, вернувшись к новому контексту Kubectl, который вы создали для учетной записи demo:

$ kubectl config use-context demo
Switched to context "demo".

Теперь повторите команду get pods из предыдущей:

$ kubectl get pods
No resources found in default namespace.

На этот раз команда увенчалась успехом. Сервисному аккаунту demo теперь разрешено получать списки модулей, поскольку он привязан к роли demo-role. Вы по-прежнему увидите ошибку «Запрещено», если попытаетесь создать новый модуль, потому что эта операция не включена ни в одну роль, связанную с учетной записью:

$ kubectl run nginx --image=nginx
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot create resource "pods" in API group "" in the namespace "default"

Вы можете решить эту проблему, назначив пользователю другую роль, включающую команду create для ресурса pods. Кроме того, вы можете отредактировать файл YAML существующей роли и применить измененную версию к своему кластеру:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: demo-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create", "get", "list"]

Вы также можете добавить к своей роли дополнительные правила для создания различных комбинаций групп ресурсов и разрешенных действий.

Краткое содержание

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

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

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




Все права защищены. © Linux-Console.net • 2019-2024