Общие шаги подготовки окружения#

Замечание о работе с секретами

1. При использовании Vault все секреты размещаются в Vault, иначе все секреты размещаются в объектах Secret

2. Хранение разных по сути секретов (например, учетные данные OIDC и БД) возможно как по отдельности (в разных объектах Secret / по разным путям в Vault KV Engine), так и с произвольной группировкой

3. Далее приведены примеры для обоих случаев

Для TLS между клиентами и MPSM необходима установка с Ingress Gateway, подробнее в «Подготовка сертификатов для входящих соединений».

Предусловия для установки:

1. Развернутый и настроенный кластер Платформы (DropApp 1.1 и выше / Kubernetes 1.21 и выше);

2. Развернутый компонент POLM;

3. В кластере создан проект для развертывания MPSM;

4. В проекте создана учетная запись с правами на загрузку артефактов (администратор проекта);

5. Получена ссылка на целевой Docker-репозиторий;

6. Определены DNS-имя / IP-адрес и порт, по которым MPSM будет доступен для пользователей после установки;

7. Для использования TLS: подготовлены сертификаты для входящих соединений (Ingress Gateway / Ingress-контроллера): см. «Подготовка сертификатов для входящих соединений»;

8. При использовании Ingress Gateway: включена поддержка SSL Passthrough в Ingress-контроллере кластера (отключена по умолчанию в nginx-ingress-controller);

9. Для mpsm подготовлены ключи аутентификации: см. «Подготовка ключей для аутентификации на mpsm»;

10. «Подготовка при аутентификации по протоколу OIDC»;

11. При использовании внешней БД: см. «Подготовка при использовании внешней БД»;

12. Для использования GigaChat: см. «Подготовка при использовании GigaChat»;

13. При установке с использованием консоли, на рабочем месте должен быть установлен клиент Kubernetes (kubectl) и Helm.

Подготовка ключей для аутентификации на mpsm#

Некоторые действия должны выполняться операторами Vault.

Генерация ключей:

1. Сгенерируйте ключ подписи cookie, выполнив команду «dd if=/dev/urandom bs=12 count=1 | base64 | base64».

2. Сгенерируйте ключ аутентификации запросов mpsm, выполнив команду «dd if=/dev/urandom bs=12 count=1 | base64 | base64».

Создайте или обновите секреты (объекты Secret в целевом namespace или Key-Value секреты в Vault):

1. Со сгенерированными ключами: например, mpsm с полями session-cookie-secret и auth-jwt-key соответственно.

Подготовка при аутентификации по протоколу OIDC#

Действия по настройке аутентификации по протоколу OIDC приведены на примере KCSE. Некоторые действия должны выполняться операторами OIDC-провайдера и/или Vault.

Предусловия:

1. Подготовлены сертификаты для mTLS-соединения с OIDC-провайдером.

Действия в KCSE:

1. В KCSE в выбранном Realm создайте клиента с протоколом OpenID Connect.

2. Установите клиенту тип Confidential.

3. Добавьте клиенту Mapper типа User Client Role, добавляющий в userinfo Claim «roles» с JSON-типом string. В поле Client ID выберите только что созданного клиента.

4. Добавьте клиенту Mapper типа Group Membership, добавляющий в userinfo Claim «groups» с JSON-типом string. Включите передачу полной иерархии групп (Full group path).

5. Добавьте клиенту две Role с именами «admin» и «audit». Также допускается создание собственных ролей с префиксом «x-»; гарантируется, что они не будут конфликтовать со встроенными ролями портала.

6. Укажите клиенту Callback URL вида http(s)://<ingress-host>/api/auth/keycloak-oidc/handler/frame, где <ingress-host> — адрес, по которому MPSM доступен для пользователей.

7. Сохраните Client ID и Client Secret созданного клиента, Discovery URL Realm-а для дальнейших шагов.

Создайте или обновите секреты (объекты Secret в целевом namespace или Key-Value секреты в Vault):

1. С client secret: например, mpsm с полем oidc-client-secret.

2. С CA-сертификатом (также клиентским сертификатом и приватным ключом для mTLS): например, mpsm-egress-oidc или mpsm-sidecar-oidc с полем ca.crt (также tls.crt и tls.key для mTLS). Для тестовых окружений возможно взаимодействие без TLS или с отключенной проверкой сертификатов, в таком случае секрет не требуется.

Подготовка при использовании внешней БД#

Некоторые действия должны выполняться операторами Vault.

Предусловия:

1. На сервере PostgreSQL созданы выделенная база данных и пользователь с правами owner на нее;

2. Получены адрес и порт для подключения к серверу, имя базы данных, логин и пароль для аутентификации, сертификат для mTLS-соединения (при необходимости).

Создайте или обновите секреты (объекты Secret в целевом namespace или Key-Value секреты в Vault):

1. С логином и паролем: например, mpsm с полями db-user и db-password.

2. С CA-сертификатом для TLS-соединения (при необходимости).

Подготовка сертификатов для входящих соединений#

Некоторые действия должны выполняться операторами Vault.

При установке с Ingress Gateway вся цепочка взаимодействия между клиентами и MPSM защищается TLS. При установке без Ingress Gateway TLS защищается соединение между клиентом и Ingress-контроллером, но не между Ingress-контроллером и MPSM.

Предусловия:

1. Определены DNS-имя / IP-адрес и порт, по которым MPSM будет доступен для пользователей после установки.

2. При использовании Ingress Gateway и Vault PKI Engine:

   1. Определены параметры запрашиваемого у PKI Engine сертификата, как минимум:

      • Common Name = <ingress-host>, где <ingress-host> — адрес, по которому MPSM доступен для пользователей;

      • Формат сертификата = PEM;

      • Формат секретного ключа = PEM.

   2. Убедитесь, что в PKI Engine настроена роль для выпуска сертификатов Ingress Gateway:

      • Роль устанавливает Server flag в поле Extended Key Usage;

      • Роль разрешает выпуск сертификатов с Common Name и прочими определенными выше параметрами.

3. При использовании Ingress Gateway и Vault KV Engine / при использовании секрета Kubernetes (независимо от Ingress Gateway):

   1. Выпущен сертификат, подходящий для адреса, по которому MPSM доступен для пользователей.

   2. Получены сертификат, приватный ключ и CA-сертификат.

Создайте или обновите секреты (объекты Secret в целевом namespace или Key-Value секреты в Vault):

1. С сертификатом и приватным ключом в полях tls.crt и tls.key: например, mpsm-ingress.

Подготовка при использовании GigaChat#

1. Получите доступ к API GigaChat по схеме «pay-as-you-go», следуя разделу «Регистрация и покупка токенов» документации GigaChat.

2. Получите Client ID и Client Secret, , следуя разделу «Начало работы с API» документации GigaChat.

3. Обеспечьте сетевой доступ либо проксирование для адресов:

   • https://ngw.devices.sberbank.ru:9443 — получение токенов авторизации для API GigaChat;

   • https://gigachat.devices.sberbank.ru — API GigaChat.

4. Получите CA-сертификат НУЦ Минцифры, следуя разделу «Использование сертификатов НУЦ Минцифры в GigaChat» документации GigaChat (либо получите внутренний CA-сертификат при проксировании с анализом трафика).

5. Создайте или обновите секреты (объекты Secret в целевом namespace или Key-Value секреты в Vault):

   • с ключом аутентификации в форме base64(clientId + ":" + clientSecret): например, mpsm с полем gigachat-token;

   • с CA-сертификатами для получения токенов авторизации и для API GigaChat: например, mpsm-sidecar с полями gigachat-auth-ca.crt и gigachat-api-ca.crt.