Описание параметров компонента IAM Proxy продукта Platform V IAM (NGINX для Platform V с OIDC Relay Party)#

Каталоги и файлы для настройки#

Файлы используемые для настройки:

• /certs/server.crt.pem - Открытый ключ сертификата на https;

• /certs/server.key.pem - Закрытый ключ сертификата на https;

• /certs/server_backend.crt.pem - Открытый ключ клиентского сертификата на https с backend;

• /certs/server_backend.key.pem - Закрытый ключ клиентского сертификата на https с backend;

• /certs/trusted_*.crt.pem - Файлы с доверенными сертификатами для backend;

• /usr/local/openresty/nginx/conf/jct/*.server.conf - Файлы с настройками конкретных проксирумых backend (включаются на nginx в секцию server);

• /usr/local/openresty/nginx/conf/jct/*.upstream.conf - Файлы с настройками конкретных проксирумых backend (включаются на nginx в секцию http);

• /usr/local/openresty/nginx/conf/custom.d/*.http.conf - Кастомные настройки (конфигурации) сервера, включаются в секцию http;

• /usr/local/openresty/nginx/conf/custom.d/*.server.conf - Кастомные настройки (конфигурации) сервера, включаются в секцию server.

Переменные, используемые для настройки#

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

Параметры основной функциональности компонента IAM Proxy#

• STEND_NAME - Название стенда\сервиса для отображения в UI.

• STEND_ABBR - Используется для обозначения стенда в технических названиях (латиница в нижнем регистре).

• STEND_TYPE - Тип стенда. Допустимы следующие значения: dev, ift, psi, prom, nt. По умолчанию psi.

• PROXY_SESSION_SECRET - Секретный ключ для шифрования сессии прокси (произвольный набор символов, рекомендуется длинна не менее 512 символов).

• PROXY_SESSION_IDLETIME - Опциональный. По умолчанию имеет значение 180. Время жизни сессии прокси по не активности в минутах.

• PROXY_SESSION_NAME - Опциональный. По умолчанию имеет значение PLATFORM_SESSION. Имя сессионного cookie.

• PROXY_SESSION_CHECK_ADDR - True\ False. По умолчанию имеет значение False. Включает привязку сессии к IP.

• PROXY_WORKER_PROCESSES - Количество запускаемых процессов прокси для обработки соединений (по умолчаниюauto, и будет равно кол-ву CPU).

• SYSLOG_SERVER - Сервер:порт для отправки событий аудита по протоколу syslog (в IAM это syslog-ng).

• PROXY_KEEPALIVE_TIMEOUT - timeout [header_timeout], опциональный, default 180 170, параметр (timeout). ограничивающий время клиентских keepalive соединений, второй параметр header_timeout попадет в заголовок ответа в формате: Keep-Alive: timeout=header_timeout (по умолчанию будет заголовок Keep-Alive: timeout=170).

• PROXY_SSL_SESSION_CACHE - Опциональный. По умолчанию имеет значение none. Настройка использования кеша SSL сессий клиентских подключений, в параметре указывается объем памяти выделенный под кеш в мегабайтах (в 1 мегабайте может поместиться около 4000 SSL сессий), так же можно указать none(разрешение использования кеша на клиенте) или off( запрет использования Cache).

• PROXY_JCT_SSL_NAME - По умолчанию при проверке сертификата на проксируемом сервере считаем валидные CN\SAN (из сертификатов backend) c таким доменом\host .ru.

• DEBUG - Заполненное значение включает отладку на уровне bash-скриптов, значение 1 включает debug логирование на nginx, значение wait включает ожидание в 1 час после завершения процесса nginx.

• PROXY_METRICS_ENABLE - True/False. Опциональный. По умолчанию имеет значение False. True - активировать сбор метрик и публикацию их в формате Prometheus на http://127.0.0.1:10080/metrics/.

• PROXY_HEALTCHECK_ENABLE - True/False. Опциональный. По умолчанию имеет значение False, True - включение активного healthcheck до серверов backend (ответвления в которых есть строка /rds-healthcheck в applyJctRequestFilter), будет вызов GET /healtcheck каждые 10 секунд, в ответе ожидается http-код 200\302 для живого узла (статус доступен по url http://127.0.0.1:10080/status-healtcheck/).

• PROXY_SUPPORT_ISAM_HEADERS - True/False. Опциональный. По умолчанию имеет значение True. True - добавлять в запросы http-заголовки аналогично ISAM/WebSeal (iv-user, iv-groups, iv-remote-address); Для точечного отключения на ответвлении следует использовать опцию common/rds-disable-support-isam-headers.location.conf (в applyJctRequestFilter).

• PROXY_SUPPORT_CUSTOM_CONFIGS - True/False. Опциональный. По умолчанию имеет значение True. True - разрешить подключение/include файлов конфигурации из каталога custom.d.

• PROXY_X_FORWARDED_PORT - auto/номер порта. Опциональный. По умолчанию имеет значение auto. Значение auto - получить номер порта из заголовка X-Forwarded-Port или из $proxy_protocol_port или из заголовка Host или из заголовка X-Forwarded-Proto или из $scheme (указано в порядке получения).

• PROXY_X_FORWARDED_PROTO - https/http. Опциональный. По умолчанию будет scheme из listener.

• WAIT_EXIST_FILES - Опциональный. Cписок файлов через пробел, появления которых необходимо дождаться перед запуском прокси. К примеру это может понадобиться, когда файлы сертификатов доставляются по pod отдельным процессом\контейнером\sidecar, если на момент запуска IAM Proxy, файлов еще не будет, то нужно будет дождаться их появления, а потом начать старт IAM Proxy. Пример: /certs/server.key.pem /certs/server.crt.pem.

• J2_IGNORE_NAMES - Опциональный. Задать список шаблонов имен j2-файлов, которые нужно исключить из обработки j2-шаблонизатором. Пример: my.skip-files.*.j2 oidc-auth-secrets.server.conf.j2

• PROXY_LOG_TO_FLUENT_BIT_ENABLE - True/False, опциональный default False, включение логирования в /var/log/logsshare/*.log, используется при отправке журналов через fluent-bit

• PROXY_LOG_TO_FLUENT_BIT_ACCESS_LOG - опциональный, путь до файла access-логов отправляемых через fluent-bit (можно указать сервер-syslog, например syslog:server=127.0.0.1:15140)

• PROXY_LOG_TO_FLUENT_BIT_ERROR_LOG - опциональный, путь до файла error-логов отправляемых через fluent-bit (можно указать сервер-syslog, например syslog:server=127.0.0.1:15141)

• PROXY_ROTATE_FILES - опциональный, полные пути до файлов логов (через запятую), которые надо ротировать

• PROXY_ROTATE_FILE_SIZE - опциональный, default 4000, максимальный размер одного файла в кб

• PROXY_ROTATE_TOTAL_SIZE - опциональный, default 40000, максимальный размер всех файлов в кб, которые под ротацией

• PROXY_REQUEST_TO_UI_REGEX - опциональный, default /$, регулярное выражение применяемое к URI запроса, при совпадении считается что тип запроса - запрос к UI

• PROXY_REQUEST_TO_API_REGEX - опциональный, default /api/, регулярное выражение применяемое к URI запроса, при совпадении считается что тип запроса - запрос к API

Параметры подключения провайдеру аутентификации платформы (Platform V IAM KeyCloak.SE)#

• KEYCLOAK_FRONT_DNS_NAME - dns-имя сервиса Keycloak, используемое с front-end\браузера (LB)

• KEYCLOAK_HTTPS_PORT_ON_FRONTEND - порт к KEYCLOAK_FRONT_DNS_NAME

• KEYCLOAK_ADMIN_DNS_NAME - dns-имя сервиса Keycloak для административного интерфейса, используемое с front-end\браузера (LB)

• KEYCLOAK_HTTPS_ADMIN_PORT - порт к KEYCLOAK_HTTPS_ADMIN_PORT

• KEYCLOAK_REALM - используемое при аутентификации имя realm в Keycloak (по умолчанию "PlatformAuth")

• OIDC_POST_LOGON_BY_TOKEN_CALL_URI - вызвать endpoint на IDP после восстановления по токену сессии на прокси

Параметры для доступа сетевых клиентов с front-end (браузер/агент)#

• PROXY_DNSNAME - dns-имя сервиса IAM Proxy, используемое с front-end\браузера (LB)

• LB_HTTPS_PORT - порт к PROXY_DNSNAME

Параметры ограничения скорости запросов#

Описание#

Реализация Rate Limiter на стороне IAM Proxy подразумевает под собой защиту от аномального объема трафика как в сторону IDP-провайдера аутентификации, так и в сторону backend-приложения. Механизм защиты основан на конфигурируемом ограничении скорости по количеству запросов в единицу времени. В случае превышения количества запросов они будут задерживаться для соблюдения заданного лимита, или пользователю будет показано сообщение о повторении попытки через некоторое время.

Так как обычно клиентом является браузер, а проксирование производится на web-приложения, то нагрузка от одного клиента в большинстве случаев будет со значительными всплесками (например при открытии первый раз страницы или переходе на какой-то новый раздел в UI), по этому при ограничениях допускаются всплески в рамках одного клиента, чтобы пропустить без задержек разовую пиковую нагрузку.

Настройка#

Настройка на IAM Proxy производится параметрами:

• PROXY_LIMIT_PER_IP_ENABLE - True/False, опциональный, default False, включение ограничения скорости запросов, определение источника\клиента производится по его IP (на основе нескольких источников - X-Forwaded-For, PROXY Protocol, TCP ip.src)

• PROXY_LIMIT_PER_SESSION_ENABLE - True/False, опциональный, default False, включение ограничения скорости запросов, определение источника\клиента производится по его сессии аутентификации

• PROXY_LIMIT_REQ_PER_SEC - запросов/секунду, опциональный, default 60, ограничение скорости запросов на backend в количестве запросов допустимых в секунду (допускается всплеск запросов по кол-ву в 4 раза превышающий заданный лимит по r/s, запросы в пределах всплеска будут на время задерживаться, чтобы соблюсти заданную скорость, а по превышению всплеска запросы будут отклоняться с http-кодом 509)

• PROXY_LIMIT_REQ_OIDC_PER_MIN - запросов/минуту, опциональный, default 2, ограничение скорости запросов по сессии прокси к функциональности OIDC(обращения к провайдеру Open ID Connect) в максимально допустимом количестве запросов в минуту (допускается всплеск в кол-ве 10 запросов, по превышению всплеска запросы будут отклоняться с http-кодом 509)

Примечание: Лимиты действуют в рамках одного instance IAM Proxy, что следует учитывать при расчете возможной постоянной максимальной нагрузки на backend, которую пропустит IAM Proxy.

Пример расчета параметров#

Например, при включении ограничений по PROXY_LIMIT_PER_IP_ENABLE и PROXY_LIMIT_PER_SESSION_ENABLE, и с PROXY_LIMIT_REQ_PER_SEC=60, пройдут 240(60*4) запросов без ограничений (допустимый всплеск), потом они начнут искусственно задерживаться до соблюдения ограничения 60 запросов в секунду. Следующие запросы в рамках всплеска будут возможны, когда очередь ограничения запросов станет пустой (если полностью остановится нагрузка, то через 4 секунды можно будет повторить всплеск в 240 запросов).

Отдельное дополнительное ограничение будет для запросов связанных с IDP, если PROXY_LIMIT_REQ_OIDC_PER_MIN=2, то запросов приводящих к вызову IDP (например новая аутентификация) можно будет выполнить разово не более 10(допустимый всплеск), потом же таких запросов можно будет сделать не более 2 в минуту, иначе будет выдано сообщение повторить запрос позже.

Параметры подключения к Identity Provider OIDC#

• PROXY_OIDC_CLIENT_ID - CLIENT_ID используемый на прокси CLIENT_ID для аутентификации по OIDC на IDP

• PROXY_OIDC_CLIENT_SECRET - секрет к CLIENT_ID

• OIDC_CLIENT_RSA_PRIVATE_KEY - аутентификация на IDP методом "private_key_jwt", и тут указывается "закрытый клиентский ключ":

-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCOfXFnv2XWPEpX
...
-----END PRIVATE KEY-----

• OIDC_SSL_VERIFY - True/False, проверять сертификат на endpoint OIDC

• OIDC_DISCOVERY_URL - задание URL метаданных OIDC IDP ("https://all-sh-suddwsa02app.mycompany.mycompany.ru/mga/sps/oauth/oauth20")

• OIDC_LOGOUT_URI - задание URL на который делать redirect при logout ("https://all-sh-suddwsa02app.mycompany.mycompany.ru/pkmslogout")

• OIDC_POST_LOGOUT_REDIRECT_PATH - default "/openid-connect-auth/logoutSuccessful.html", относительный путь, на который будет перенаправление после успешного logout

• OIDC_SCOPE - задание дополнительных скоупов OIDC при аутентификации ("basic access")

• OIDC_USE_IDP_PROVIDER - вход на Keycloak через заранее указанного внешнего провайдера ("esia")

• OIDC_USE_CLIENT_CERT - True/False, использовать клиентский сертификат на endpoints OIDC

• OIDC_HOST_GRAY - использовать для подключения к OIDC IDP отдельный ip:port, а не тот который в URL из OIDC_DISCOVERY_URL (может потребоваться при необходимости использовании серых адресов IDP, для включения также необходимо выставить OIDC_USE_CLIENT_CERT в True). Пример "1.1.1.1:8443"

• PROXY_TO_BACKEND_ACCESS_TOKEN - True/False, использовать access token при отправке в backend, вместо id_token

• OIDC_USE_PKCE - True/False, default False, использовать PKCE при аутентификации по OIDC

• OIDC_USERNAME_ATTR - какой атрибут из jwt-токена использовать в качестве имени\логина пользователя, и будет использоваться в логах, в хидере iv-user и т.п. (default "preferred_username")

• OIDC_CHANGE_ORG_ENDPOINT - ссылка на endpoint смены организации на IDP (реализован на KCSE в провайдере ЕСИА). При его вызове передаются параметры client_uuid, redirect_uri, org_id. По умолчанию keycloak_base_url

  • /auth/realms/PlatformAuth/broker/esia/endpoint/change-org. (переменная keycloak_base_url формируется на основе параметров KEYCLOAK_*)

• OIDC_POST_CHANGE_ORG_ENDPOINT - ссылка, на которую будет перенаправление после успешной смены организации на IDP. Пример: /portal/start-page

• OIDC_MAP_HEADERS - добавить http заголовки по токену, пример 'header-with-user-id=sub, user_roles=realm_access.roles , user.audiences=aud, User-FIO=name,user-access-systems=resource_access'. В значении использовать модификаторы, детали смотрите в разделе "Использование модификаторов HTTP заголовков"

• OIDC_MAP_ROLES - задать мапинг получения ролей из токена, пример 'realm_roles=realm_access.roles, root_roles=roles, client_roles=resource_access.${client_id}.roles, esia. roles.from_userinfo=userinfo@esia.roles'

• OIDC_USERINFO_MAP - задать мапинг получения части userinfo из токена для сохранения\caching в сессии, пример 'esia.roles=esia.roles , org=upper@organization.org_name, client_roles=resource_access.${client_id}.role' ( потом к сохраненной части можно будет обратиться через модификатор userinfo в мапингах, пример: org_from_userinfo=userinfo@org)

• OIDC_ACCESS_TOKEN_EXPIRES_LEEWAY_RAND - за сколько секунд до истечения access-токена обновить токены (реальное кол-во секунд будет выбрано случайным образом от этого числа, а ошибка обновления будет проигнорирована если access-токен действителен). Можно указать проценты от времени действия access-токена, например 20% или 0.2 .

• OIDC_REVOKE_TOKENS_ON_LOGOUT - True/False, default True, включить процедуру отзыва токенов при logout (отзываются токены refresh и\или access при их наличии, и при условии что IDP поддерживает отзыв/revoke токенов)

• OIDC_DISABLE_LOGOUT_IN_IDP - True/False, default False, не производить logout сессии пользователя на IDP (logout на IDP обычно закрывает сессии всех клиентов\АС, созданных на данном IDP от имени пользователя)

• OIDC_IGNORE_SSO_ON_IDP - True/False, default False, включить принудительный запрос логин/пароля при каждой аутентификации на IDP (игнорируем SSO)

• OIDC_REUSE_REFRESH_COUNT - опциональный, default -1, определяет количество повторных использований одного refresh токена (значение менее 0 снимает ограничение)

Использование модификаторов HTTP заголовков#

Цель применения модификаторов состоит в изменении информации, передаваемой в заголовках HTTP запросов, определяемых опциями OIDC_MAP_HEADERS, OIDC_MAP_ROLES, OIDC_USERINFO_MAP.

Синтаксис использования: <модиификатор>@<параметры передаваемые в модификатор>

Список модификаторов, которые можно использовать для преобразования содержимого HTTP-заголовков:

• qp - преобразует данные в строку, содержащую только ASCII символы; модификатор заменяет не ASCII символы специальными последовательностями, состоящими из символа "=" и двух символов шестнадцатеричного кода;\ пример: значение "Hello, привет, мир!", будет преобразовано в "Hello, =D0=9F=D1=80=d0=B8=D0=B2=D0=B5=D1==82, =D0=BC=D0=B8=D1=80!";

• decode_qp - декодирование текста, закодированного в формате quoted-printable;
  пример: "Hello, =D0=9F=D1=80=d0=B8=D0=B2=D0=B5=D1==82, =D0=BC=D0=B8=D1=80!" будет преобразован в "Hello, привет, мир!" ;

• base64 - кодирование данных в формате base64;

• decode_base64 - декодирование данных, закодированных в формате base64;

• uri - кодирование текста в формат uri (стандарт https://docs.racket-lang.org/net/uri-codec.html), позволяющий использовать специальные символы в URI;
  пример, значение "my page" будет преобразовано в "my%20page";

• unescape_uri - декодирование текста, закодированного в формате uri;
  пример, значение "my%20page" будет преобразовано в "my page";

• md5 - вычисление хэш-суммы md5 от текста или данных;

• upper - преобразование текста в верхний регистр;

• lower - преобразование текста в нижний регистр;

• trunc - обрезка текста до длины в 255 символов;

• userinfo - позволяет получить данные из информации, полученной из endpoint userinfo API IDP (получение этой информации предварительно настраивается опцией OIDC_USERINFO_MAP),
  пример: userinfo@org передаст в http-заголовок атрибут org указанный в опции OIDC_USERINFO_MAP;

• joinStrBySpace - объединяет в строку значения полученные из id-token через пробел(не ASCII символы будут закодированы используя escape_uri), имена атрибутов id-token (которые необходимо объединить) задаются как параметры через ":",
  пример: joinStrBySpace@firstname:surname вернет "Ivan Ivanov";

• appendKey - используется для добавления ключа к указанному значению. Преобразует значение, добавляя к нему ключ в виде "ключ=значение". Например, значение "hello", ключ "world", модификатор преобразует в "world=hello";

• appendName - используется для добавления имени к указанному значению. Преобразует значение, добавляя к нему имя в виде "имя:значение" Например, значение "hello", имя "world", модификатор преобразует в "world: hello".

Использование ре-аутентификации#

Для защиты произвольного GET вызова явной аутентификацией на IDP (как пример какой-то важный вызов на подтверждение финансовой операции), есть два варианта активации ре-аутентификации на IAM Proxy:

• необходимо добавить в get-аргументы URL вызова аргумент requiredReauthentification=true

• вызвать специальный endpoint на IAM Proxy https://<iamproxy>/openid-connect-auth/reauth с аргументом redirect_uri=<защищаемый URL>

В результате при вызове произойдет перенаправление на IDP за аутентификацией с указанием не использовать SSO на IDP ( будет добавлен аргумент prompt=login в вызов на аутентификацию, при этом IDP провайдер должен его поддерживать), а далее при успешной ре-аутентификации будет перенаправление на защищаемый URL с добавлением/заменой в нем аргумента requiredReauthentification=<начало реаутентикации в unixtime>.

При реализации на backend следует так же проверять в аргументах GET вызова наличие не пустого параметра requiredReauthentification, чтобы удостовериться, что на IAM Proxy использовалась ре-аутентификация.

Параметры подключения к ОСА/SPAS (сервис авторизации ППРБ)#

Описание использования функциональности авторизации ОСА/SPAS смотрите в разделе Функциональность аутентификации на основе прав из ОСА (сервис авторизации) .

• AUTHZ_SPAS_URL - пример "https://10.x.x.10:8443/spas/rest", url для вызова API SPAS;

• AUTHZ_SPAS_SECRET - пример 123456 , секрет для вызова API SPAS.

• AUTHZ_SPAS_TICKET_LIFETIME - пример 3600, частота обновления тикета ОСА/SPAS, в секунду.

• AUTHZ_SPAS_TICKET_FAILED_LIFETIME - пример 5, частота получения тикета ОСА/SPAS, если ранее попытка была неуспешной, в секунду.

• AUTHZ_SPAS_RIGHTS_LIFETIME - пример 60, частота обновления полномочий из ОСА/SPAS, в секунду

• AUTHZ_SPAS_RIGHTS_FAILED_LIFETIME - пример 5, частота обновления полномочий из ОСА/SPAS, если ранее попытка была неуспешной, в секунду.

• AUTHZ_SPAS_SSL_VERIFY - пример False, проверять сертификат на endpoint authz_spas_url.

Для включения авторизации в настройках ответвления(в applyJctRequestFilter) задаем одну из опций:

• common/rds-use-authz-by-url.location.conf

• common/rds-use-authz-by-url-bridge.location.conf

• common/rds-use-authz-by-url-and-method.location.conf

Параметры подключения к авторизации OPA#

Описание использования функциональности авторизации смотрите в разделе Файлы дополнительных опций для ответвлений

• AUTHZ_OPA_URL - пример "https://10.x.x.10:8443/ssp-portal/rm/api/v1/check", url для вызова API OPA

• AUTHZ_OPA_SSL_VERIFY - пример False, проверять сертификат на endpoint authz_spas_url

Для включения авторизации в настройках ответвления(в applyJctRequestFilter) задаем common/rds-authz-opa.location.conf

Параметры RDS Client#

• RDS_SERVER_URLS - указывается список RDS-серверов через ";" , используется клиентская failover-балансировка. "https://mycompany-auth-svc-idp1-dev2.ca.mycompany.ru:7443/rds-for-proxy; http://mycompany-auth-svc-idp1-dev2.ca.mycompany.ru:7080/rds-for-proxy"

• READ_DATA_FROM_RDS_TIME_IN_SEC - частота опроса RDS-серверов на наличие изменений

• RDS_KEYSTORE - из этой базы берется клиентский сертификат для mTLS, и траст-сторе

• RDS_CLIENT_KEYALIAS - клиентский сертификат для mTLS

• RDS_CLIENT_KEYSTOREPASSWORD - пароль к RDS_KEYSTORE

• RDS_START_CONF - первоначальная конфигурация ответвлений на прокси в формате JSON (при задании данного параметра каталог /usr/local/openresty/nginx/conf/jct/ будет очищен)

Пример:

{
  "junctions": [
    {
      "junctionPoint": "/my-portal",
      "indexUrl": "/my-portal/start-page",
      "junctionName": "Мой портал",
      "description": "Расширенное описание подсистемы [Мой портал]"
      "https": true,
      "sslCommonName": "my.apps.company.ru",
      "transparent": true,
      "applyJctRequestFilter": "common/rds-ssl-sni-on.server.conf , common/rds-set-header-host-to-backend.location.conf",
      "serverAddresses": [
        "my.apps.company.ru:443"
      ]
    },
    {
      "junctionPoint": "/jct-snoop",
      "indexUrl": "/snoop/snoop/xxxxxx",
      "junctionName": "Тестовые ответвления/Диагностика (snoop непрозрачный)",
      "description": "Cервис диагностики (snoop непрозрачный)"
      "https": true,
      "sslCommonName": "*",
      "transparent": false,
      "applyJctRequestFilter": "common/rds-set-header-host-to-backend.location.conf",
      "serverAddresses": [
        "snoop:8443"
      ]
    },
    {
      "junctionPoint": "/jct-snoop-admin",
      "indexUrl": "/snoop/snoop/admin",
      "junctionName": "Тестовые ответвления/Диагностика с авторизацией по роли (snoop непрозрачный)",
      "description": "Cервис диагностики с авторизацией по роли (snoop непрозрачный)"
      "https": true,
      "sslCommonName": "*",
      "transparent": false,
      "authorizeByRoleTemplate": "my_snoop_*",
      "serverAddresses": [
        "snoop:8443"
      ]
    },
    {
      "junctionPoint": "/snoop",
      "indexUrl": "/snoop/snoop/yyyyyy/",
      "junctionName": "Диагностика (snoop прозрачный)",
      "description": "Cервис диагностики (snoop прозрачный)"
      "https": false,
      "transparent": true,
      "serverAddresses": [
        "127.0.0.1:10080"
      ]
    }
  ]
}

Примечание: Endpoint по <RDS_SERVER_URLS>/active отдает json в таком же виде/формате, как указано выше в примере, и при необходимости это дает возможность реализовать свой сервис по формированию junctions динамически, и менять маршруты проксирования на IAM Proxy в реальном времени.

Описание атрибутов в junctions смотрите в разделе Заполнение раздела с описанием параметров ответвлений.

Авторизация на прокси по JWT-токену из заголовка (aka OAuth2 Authorization on resource)#

Описание функциональности авторизации на прокси по JWT-токену из HTTP-заголовка запроса смотрите в разделе Файлы дополнительных опций для ответвлений).

• OIDC_NEED_AUTH - [true|false] Задание необходимости прохождения аутентификации по OIDC

• AUTHZ_BY_OAUTH_JWT_ENABLED - [true|false] Проверять токен из запроса, в случае отсутствия или ошибок проверки будет 403

• AUTHZ_BY_OAUTH_JWT_PUBLIC_KEY - Открытый ключ или сертификат для проверки подписи токена (в PEM, включая head\foot)

• PROXY_MTLS_FRONT_VERIFY_DN_REGEX - Проверка regexp строки «subject DN” клиентского сертификата для установленного на фронте SSL-соединения (* или пустая строка допускает любой DN), пример '^( CN=SMDEVPROFILEPRODusr,OU=MyCompdevices,O=MyCompany,C=RU|CN=SMCONSOLEGWPRODusr,OU=MyCompdevices,O=MyCompany,C=RU)$'.

Использование контейнера с корневой системой в ReadOnly#

Необходимо по пути $TMP_PATH (/tmp/platformauth-proxy) смонтировать файловую систему доступную на запись (например с типом EmptyDir). При старте контейнера в этом каталоге будут размещены все файлы и каталоги, в которые необходимо делать запись.

Для переключения корневой файловой системы контейнера в ReadOnly задается в Deployment(kind: Deployment) атрибут spec.template.spec.containers[0].securityContext.readOnlyRootFilesystem: true

Использование проксирования по корневому контексту#

При необходимости проксировать все запросы начиная с корня, необходимо добавить ответвление с пустым junctionPoint, и с transparent равным true.

Пример:

{
  "junctions": [
    {
      "junctionPoint": "",
      "indexUrl": "/start-page",
      "junctionName": "Мой портал",
      "https": true,
      "sslCommonName": "my-app-ui.apps.company.ru",
      "transparent": true,
      "applyJctRequestFilter": "common/rds-ssl-sni-on.server.conf , common/rds-set-header-host-to-backend.location.conf",
      "serverAddresses": [
        "my-app-ui.apps.company.ru:443"
      ]
    }
  ]
}

Все остальные endpoint IAM Proxy будут так-же, как и ранее, доступны по тем же URI.

Стартовая техническая страница IAM Proxy будет доступна по URI https://<host:port>/proxy/ , https://<host:port>/proxy/index.html.

Версию IAM Proxy можно узнать по URI https://<host:port>/proxy/version.txt.

Передача секретов через файлы вместо переменных окружения#

Для чтения содержимого параметра с секретом из файла необходимо в нужном параметре окружения задать символ @ или путь до файла в виде @/path/file. В первом случае, файл будет использоваться с именем переменной из каталога /secrets ( например /secrets/PROXY_SESSION_SECRET).

Допустимые имена параметров для передачи значений из файлов:

• PROXY_SESSION_SECRET

• PROXY_OIDC_CLIENT_ID

• PROXY_OIDC_CLIENT_SECRET

• OIDC_CLIENT_RSA_PRIVATE_KEY

• AUTHZ_SPAS_SECRET

• AUTHZ_BY_OAUTH_JWT_PUBLIC_KEY

• RDS_CLIENT_KEYSTOREPASSWORD

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

Для обеспечения данной логики в OSE\k8s можно создать секрет(kind: Secret), добавить в него все необходимые параметры с секретами, а потом его смонтировать в каталог /secrets. Пример:

kind: Secret
apiVersion: v1
metadata:
  name: iamproxy-secrets
stringData:
  RDS_CLIENT_KEYSTOREPASSWORD: "myPA***ord_"
  TEST_VALUE: myTest_
  PROXY_SESSION_SECRET: eEphMlo4VWxLN1owZVYwSmZQbzFLO....
  OIDC_CLIENT_RSA_PRIVATE_KEY: |
    -----BEGIN PRIVATE KEY-----
    MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCOfXFnv2XWPEpX...
    -----END PRIVATE KEY-----
type: Opaque

kind: Deployment
apiVersion: apps/v1
spec:
  selector:
    matchLabels:
      app: iamproxy
  template:
    spec:
      volumes:
        - name: volume-secrets
          secret:
            secretName: iamproxy-secrets
            defaultMode: 277
      ........
      containers:
        - name: iamproxy-test
          volumeMounts:
            - name: volume-secrets
              mountPath: /secrets
          env:
            - name: PROXY_SESSION_SECRET
              value: '@'
            - name: OIDC_CLIENT_RSA_PRIVATE_KEY
              value: '@'
            - name: RDS_CLIENT_KEYSTOREPASSWORD
              value: '@'
  ........      

В результате при старте контейнера получим 4 файла в каталоге /secrets :

• /secrets/RDS_CLIENT_KEYSTOREPASSWORD

• /secrets/TEST_VALUE

• /secrets/PROXY_SESSION_SECRET

• /secrets/OIDC_CLIENT_RSA_PRIVATE_KEY

Значения из этих файлов будут переданы в соответствующие параметры контейнера IAM Proxy.

Использование IAM Proxy в разных кейсах#

Примеры и различные кейсы с примерами использования можно найти в разделе Использование IAM Proxy.