Как настроить авторизацию в установщике

1. Сопоставление IP-пользователь — пользователь определяется по IP адресу.
2. Прокси-авторизация. Предполагается, что установщик работает за прокси-сервером, который занимается авторизацией, а установщик получает данные о пользователе из заголовков.
3. Через OIDC сервер. Пользователь перенаправляется к OIDC серверу для авторизации.

Типы авторизации перечислены в порядке убывания приоритета. Все 3 типа авторизации могут быть настроены одновременно. Например, если данные о пользователе будут получены из заголовков, то перенаправления к OIDC серверу не будет. Чтобы отключить какой-то из типов авторизации, достаточно не указывать его в файле конфигурации.

Вся найстрока производится в файле конфигурации deployerParams.yaml. По умолчанию файл находится в папке /home/deployer/. Файл содержит 6 основных блоков:

• oidc — блок настройки OIDC сервера.
• groupsAdmin — список групп для назначения роли admin.
• groupsViewer — список групп для назначения роли viewer.
• byIpUsers — блок настройки авторизации по IP. Если пользователь подключится с заданного IP адреса, то ему будет назначено заданное имя пользователя. Сделано для подключения сторонних систем, например, ботов или CI/CD.
• proxyAuth — блок настройки прокси-авторизации: когда авторизацией занимается вышестоящий сервис, а в установщик приходят только заголовки с уже определенными значениями.
• overrideUsers — переопределение атрибутов пользователей. Эти значения имеют приоритет перед данными, полученными из OIDC или заголовков.

В установщике есть 2 роли пользователей:

• admin — полный доступ.
• viewer — только чтение.

Содержит следующие поля:

Пример конфигурации:

 
auth:  oidc:     host: https://biz.ws.vkwm1.on-premise.ru/auth/realms/EXCH.ON-PREMISE.RU/protocol/openid-connect     skipTls: false     clientId: api     clientSecret: otBrIQrxqvXj9VUtOk5iR1TcuBsmDzx8     authPath: /auth     tokenPath: /token     infoPath: /userinfo     scope: email     disableRefresh: false     infoFields:       email: email       username: preferred_username       firstName: given_name       lastName: family_name       role: deployerAccess      groups: groups

Если в ответе OIDC сервера возвращаются группы пользователя, можно настроить автоматическое назначение ролей.

1. Если поле role вернулось — используется оно.
2. Если поле role не вернулось — проверяется членство в группах из groupsAdmin. Если пользователь состоит хотя бы в одной из перечисленных групп, ему назначается роль admin.
3. Если ни одна из групп groupsAdmin не подошла — проверяется членство в группах из groupsViewer. Если пользователь состоит хотя бы в одной из перечисленных групп, ему назначается роль viewer.
4. Если ни одно из условий не сработало — используется defaultRole (см. раздел Дополнительные настройки авторизации).

Пример конфигурации:

 
groupsAdmin:  - Engineers  - SuperAdminsgroupsViewer:  - Mailx

Содержит следующие поля:

• cidr — IP/Subnet клиента.
• username — Обязательное поле. Идентификатор (имя пользователя), который будет назначен клиенту. Атрибуты пользователя будут взяты из блока overrideUsers.

Пример конфигурации:

 
auth:   byIpUsers:     - cidr: 172.20.70.190       username: ivanivanov

Содержит два основных блока:

• headers — маппинг заголовков в атрибуты пользователя.
• allowCIDRs — список IP/подсетей, с которых разрешен прием заголовков авторизации.

В блоке headers содержатся следующие поля:

Пример конфигурации:

 
auth:  proxyAuth:     headers:       email: x-email       username: x-username      firstName: x-given-name       lastName: x-family-name       role: x-role     allowCIDRs:       - 172.20.70.190

Состоит из имен пользователей, атрибуты которых необходимо переопределить. Например у нас есть пользователь ivanivanov:

Пример конфигурации:

 
auth:  overrideUsers:     as:       email: ivanivanov@mail.ru      firstName: ivan      lastName: ivanov      role: admin

Кроме шести блоков описанных выше, есть еще несколько полей для настройки авторизации:

• defaultRole — Роль по умолчанию, на случай, если из внешней системы получена пустая роль.
• auditLogPath — Путь к audit-логу установщика. Если поле пустое, то audit-лог не будет записываться.
• realIpHeader — Заголовок с реальным IP клиента, если установщик работает за прокси-сервером.
• realIpFrom — Список IP/посдсетей, с которых разрешен прием заголовка с реальным IP клиента. Если список пуст, то заголовок будет принят с любого адреса.

Пример конфигурации:

 
auth:  ...  defaultRole: admin auditLogPath: audit.logrealIpHeader: x-real-IP realIpFrom:  - 172.20.70.190

Скачать файл конфигурации

 
auth:  oidc:     host: https://biz.ws.vkwm1.on-premise.ru/auth/realms/EXCH.ON-PREMISE.RU/protocol/openid-connect     skipTls: false     clientId: api     clientSecret: otBrIQrxqvXj9VUtOk5iR1TcuBsmDzx8     authPath: /auth     tokenPath: /token     infoPath: /userinfo     scope: email    disableRefresh: false     infoFields:       email: email       username: preferred_username       firstName: given_name       lastName: family_name       role: deployerAccess       groups: groups  groupsAdmin:    - Engineers    - SuperAdmins  groupsViewer:    - Mailx      byIpUsers:     - cidr: 172.20.70.190       username: as   proxyAuth:     headers:       email: x-email       username: x-username       firstName: x-given-name       lastName: x-family-name       role: x-role     allowCIDRs:       - 172.20.70.190  overrideUsers:     as:       email: as@mail.ru       firstName: a       lastName: s       role: admin   defaultRole: admin auditLogPath: audit.log realIpHeader: x-real-IP realIpFrom:   - 172.20.70.190

Информацию об авторизации можно увидеть в логах установщика:

 
journalctl -fu deployer

Либо на стороне OIDC-провайдера. Например, на сервере с Keycloak выполнить команду:

 
journalctl -fu onpremise-container-keycloak1

Добавьте ключ и сертификат в строку запуска установщика:

 
./onpremise-deployer_linux -tlsCert fullchain.pem -tlsKey privkey.pem

Если установщик запускается через systemd:

1. Откройте для редактирования файл /etc/systemd/system/deployer.service:

    
   vim /etc/systemd/system/deployer.service

2. В строчке Exec добавьте:

    
   -tlsCert /etc/certs/fullchain.pem -tlsKey /etc/certs/privkey.pem

   Указав полный путь до ключей.

3. Выполните команды:

    
   systemctl daemon-reloadsystemctl restart deployer

Технический писатель: Груздев Никита