Доступ к Kubernetes от имени пользователя

Пользователи Deckhouse Code отправляют запросы к кластеру через прокси Kubernetes API агента для Kubernetes. Агент может передавать каждый такой запрос в кластер от имени пользователя, который его отправил. Кластер получает в запросе имя пользователя и его группы. Группы соответствуют ролям пользователя в проектах и группах Deckhouse Code. Права пользователя в кластере определяют привязки RBAC Kubernetes к этим именам.

Доступ от имени пользователя настраивает в файле конфигурации агента участник проекта конфигурации агента с ролью Developer или выше. Права в кластере выдаёт администратор кластера.

Настройка доступа

Требования:

• на экземпляре включён Relay (KAS);
• агент для Kubernetes развёрнут в кластере, как описано в разделе «Агенты для Kubernetes»;
• у вас есть роль Developer или выше в проекте конфигурации агента.

Добавьте ключ user_access в файл конфигурации агента .gitlab/agents/<AGENT_NAME>/config.yaml, где <AGENT_NAME> — имя агента. Укажите в ключе user_access следующие параметры:

• access_as — режим доступа: user: {} задаёт доступ от имени пользователя;
• projects — полные пути проектов, участники которых получают доступ (не более 500 записей);
• groups — полные пути групп, участники которых получают доступ (не более 500 записей).

Пример ключа user_access, который даёт доступ участникам проекта group-1/project-1 и группы group-2:

user_access:
  access_as:
    user: {}
  projects:
    - id: group-1/project-1
  groups:
    - id: group-2

Агент читает файл конфигурации из ветки по умолчанию проекта конфигурации. Изменение в файле начинает действовать, когда оно попадает в ветку по умолчанию.

Следующие ограничения действуют, если на экземпляре выключена настройка «Включить авторизацию на уровне инстанса». Указывайте в projects и groups только проекты и группы из той же группы верхнего уровня, что и проект конфигурации агента. Записи из других групп Deckhouse Code игнорирует. Если проект конфигурации при этом находится в личном неймспейсе пользователя, Deckhouse Code игнорирует groups. В projects в этом случае действуют только проекты этого неймспейса.

Укажите в access_as ровно один ключ. Если вместо user: {} указать agent: {}, агент передаёт запросы от имени своего сервисного аккаунта.

Что получает кластер

API-сервер Kubernetes получает запрос пользователя со следующими данными:

• имя пользователя gitlab:user:<USERNAME>;
• группа gitlab:user, общая для всех пользователей;
• группа gitlab:project_role:<PROJECT_ID>:<ROLE> для каждой роли пользователя в каждом проекте из projects;
• группа gitlab:group_role:<GROUP_ID>:<ROLE> для каждой роли пользователя в каждой группе из groups;
• дополнительные поля agent.gitlab.com/id, agent.gitlab.com/username, agent.gitlab.com/access_type и agent.gitlab.com/config_project_id.

<PROJECT_ID> и <GROUP_ID> — числовые идентификаторы проектов и групп из файла конфигурации. Группы gitlab:project_role и gitlab:group_role пользователь получает только для проектов и групп, в которых у него есть роль Developer или выше.

Deckhouse Code учитывает роль пользователя в проекте из projects в следующих случаях:

• пользователь — участник проекта;
• пользователь — участник одной из родительских групп проекта;
• проект предоставлен группе, участник которой — пользователь.

Deckhouse Code учитывает роль пользователя в группе из groups, только если пользователь — прямой участник этой группы или одной из её родительских групп. Участие в группе, которой предоставлена группа из groups, Deckhouse Code не учитывает. Участие только в подгруппе группы из groups Deckhouse Code тоже не учитывает.

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

Пользователь получает свою роль и все младшие роли. Порядок ролей от младшей к старшей: guest, planner, reporter, security_manager, developer, maintainer, owner. Роль security_manager входит в этот список, только если на экземпляре включена роль «Менеджер безопасности». Поэтому привязка к gitlab:project_role:<PROJECT_ID>:developer действует и на участников проекта с ролями Maintainer и Owner.

Например, участник проекта 11 с ролью Developer получает следующие группы:

• gitlab:user;
• gitlab:project_role:11:guest;
• gitlab:project_role:11:planner;
• gitlab:project_role:11:reporter;
• gitlab:project_role:11:developer;
• gitlab:project_role:11:security_manager, если на экземпляре включена роль «Менеджер безопасности».

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

Выдача прав в кластере

Пока группа пользователя не указана в RoleBinding или ClusterRoleBinding, у пользователя нет прав в кластере.

Например, чтобы участники проекта 123 с ролями Maintainer и Owner могли читать большинство объектов в кластере, примените следующий манифест. Манифест связывает группу gitlab:project_role:123:maintainer со встроенной ClusterRole view:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: project-123-maintainers-view
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: gitlab:project_role:123:maintainer

Чтобы выдать права только в одном неймспейсе, создайте RoleBinding в этом неймспейсе. Правила привязок RBAC описывает страница документации Kubernetes Using RBAC Authorization.

Подключение к кластеру

1. Откройте проект конфигурации агента и перейдите в «Управление» → «Кластеры Kubernetes». Запишите числовой идентификатор агента.

2. Создайте персональный токен доступа с областями k8s_proxy и read_user.

3. Запросите метаданные экземпляра:

   curl --header "PRIVATE-TOKEN: <TOKEN>" "https://<HOSTNAME>/api/v4/metadata"

   Запишите адрес прокси Kubernetes API из поля kas.externalK8sProxyUrl ответа. Если поле kas.enabled равно false, сервер агентов Kubernetes на экземпляре выключен. Все поля ответа описывает страница Metadata.

4. Добавьте в kubeconfig кластер с адресом прокси Kubernetes API:

   d8 k config set-cluster <CLUSTER_NAME> --server "<K8S_PROXY_URL>"

5. Добавьте в kubeconfig учётные данные. Токен в них состоит из префикса pat:, идентификатора агента и персонального токена доступа:

   d8 k config set-credentials <USER_NAME> --token "pat:<AGENT_ID>:<TOKEN>"

6. Создайте контекст и переключитесь на него:

   d8 k config set-context <CONTEXT_NAME> --cluster <CLUSTER_NAME> --user <USER_NAME>
   d8 k config use-context <CONTEXT_NAME>

7. Проверьте имя пользователя и группы, которые получает кластер:

   d8 k auth whoami

   Команда выводит имя пользователя gitlab:user:<USERNAME> и группы из раздела «Что получает кластер».

Обозначения:

• <HOSTNAME> — адрес экземпляра Deckhouse Code;
• <K8S_PROXY_URL> — адрес прокси Kubernetes API из поля kas.externalK8sProxyUrl;
• <AGENT_ID> — идентификатор агента из первого шага;
• <TOKEN> — персональный токен доступа;
• <CLUSTER_NAME>, <USER_NAME>, <CONTEXT_NAME> — имена кластера, учётных данных и контекста в kubeconfig, которые вы выбираете сами.

Дополнительные ресурсы

• Группы и участники
• Защищённые окружения