Конфігурація Custom URL для сервісу управління користувачами та ролями Keycloak

Надання можливості конфігурації DNS імен для сервісу управління користувачами та ролями Keycloak використовуючи інтерфейс адмін-консолі.

Загальний опис

Дизайн по конфігурації DNS імені (окремого від імені OpenShift кластера) для Кабінету посадової особи та Кабінету отримувача послуг не враховував потребу в конфігурації також відповідного імені для сервісу управління користувачами та ролями (Keycloak) через адмін-консоль.

Також, якщо кластер OpenShift створений повністю у приватній мережі, то перевірка сертифікатів на рівні підсистеми управління міжсервісною взаємодією та аутентифікація за допомогою Keycloak відбуваються не коректно з деякими компонентами реєстру.

В цьому перехідному дизайні пропонується рішення для розв’язання цих проблем.

Ролі користувачів

Технічний адміністратор реєстру
Технічний адміністратор Платформи

Функціональні сценарії

Конфігурація DNS-імен компонента Keycloak через адмін-консоль на рівні Платформи
Вибір DNS-імені для логіна в кабінети користувачів через адмін-консоль на рівні реєстру
Видалення доданих DNS-імен до Keycloak

Загальні принципи та положення

Конфігурація наявних Keycloak DNS-імен задається технічним адміністратором Платформи
Разом з DNS-іменем, платформний адміністратор має також задати TLS-сертифікат в .pem форматі для домена
DNS-імена для реєстрових кабінетів користувачів конфігуруються реєстровим технічним адміністратором
Реєстровий адміністратор може вибрати домен для Keycloak з переліку доступних
Перелік доступних в системі доменів формується із заданих DNS-імен платформного Keycloak
В налаштуваннях кабінетів доступна можливість завантажити окремі TLS сертифікати в .pem форматі на кожний кабінет користувача
Адміністратор Платформи відповідальний за ротацію сертифікатів Keycloak та кабінетів користувачів
В системі має бути можливість редагувати встановлені раніше TLS-сертифікати та DNS-імена
Адмін-консоль має валідувати, що завантажений TLS сертифікат дійсно відповідає введеному домену, не є самопідписаним та строк його дії ще не минув.
Доступ до HasiCorp Vault для читання сертифікатів відбувається тільки через окремого сервісного користувача
У випадку розгортання реєстру без порталу (чиновника або громадянина) відповідні UI елементи для налаштування DNS-імен не повинні показуватись.
Заданий URL для Keycloak та кабінетів не може бути більше ніж 63 символи та має валідуватись на коректність.

Дизайн існуючого рішення

Keycloak DNS

В поточній версії Платформи, конфігурація DNS імені Keycloak відбувається наступним чином:

Вручну додати в values.yaml реєстру наступне налаштування:
```
keycloak:
  customHost: keycloak.example.com
```
Вручну налаштувати Keycloak Frontend URL у відповідному рілмі на нове DNS імʼя
Вручну створити OpenShift Route з доданим TLS сертифікатом
Вручну змінити Redash SAML URL

DNS-імена для адміністративних інтерфейсів користувачів

Дизайн по конфігурації DNS імені для кабінетів користувачів

Недоліки поточної реалізації

Налаштування DNS-імені центрального компонента Keycloak відбувається з конфігурації реєстрів
Потребує багато ручних налаштувань (route, request auth, keycloak realm тощо)
Технічний адміністратор Платформи не контролює DNS налаштування платформного Keycloak
DNS-імена задаються на рівні компонента common-web-app, а не на рівні реєстрової конфігурації

Технічний дизайн рішення

Перед початком конфігурації кастомного DNS-імені для Keycloak на рівні реєстру, потрібно спочатку додати відповідний домен в налаштуваннях Платформи.

При налаштованому Keycloak DNS-імені він повинен зʼявитись в dropdown елементі в налаштуваннях реєстру з пропозицією обрати DNS-імені для логіну в кабінети реєстру: кластерний за замовчуванням, чи один з кастомних.

Figure 1. Верхньорівнева діаграма взаємодії на рівні підсистем

Підсистема управління Платформою та реєстрами зберігає отримані TLS-сертифікати в підсистемі управління секретами та шифруванням та додає у values.yaml домен та шлях до TLS сертифіката відповідно прикладу:

Приклад конфігурації на рівні values.yaml репозиторія cluster-mgmt.git

keycloak:
  customHosts:
    - host: keycloak.example.com
      certificatePath: registry-kv/....
    - host: keycloak-login.instance.com
      certificatePath: registry-kv/....

Приклад конфігурації на рівні values.yaml реєстрового репозиторія

portals:
  officer:
    customHost:
       enabled: true
       host: officer.example.com
       certificatePath: registry-kv/....

Платформні TLS сертифікати зберігаються у HashiCorp Vault (user-management:hashicorp-vault) за шляхом, згенерованим згідно конвенції:

registry-kv/cluster/domains/<domain-name>

key:caCertificate value:<caValue>
key:certificate value:<certificateValue>
key:key value:<keyValue>

Реєстрові TLS сертифікати зберігаються у HashiCorp Vault (user-management:hashicorp-vault) за шляхом, згенерованим згідно конвенції:

registry-kv/registry/<registry-name>/domains/<portal-name>/<domain-name>

key:caCertificate value:<caValue>
key:certificate value:<certificateValue>
key:key value:<keyValue>

Figure 2. Верхньорівнева діаграма взаємодії на рівні розгортання конфігурації

При заданому кастомному DNS-імені для Keycloak та для кабінетів у відповідному реєстрі має відбутися:

конфігурація Redash Viewer:

Приклад конфігурації змінних оточення Redash Viewer

REDASH_SAML_METADATA_URL # дефолтний Keycloak URL OpenShift кластера
REDASH_SAML_REDIRECT_URL # зовнішнє (кастомне) Keycloak DNS-імʼя

cтворитися додаткові istio request authentication до вже існуючих:
Приклад конфігурації Istio RequestAuthentication для компонентів реєстрів
```
jwtRules:
    - forwardOriginalToken: true
      fromHeaders:
        - name: X-Access-Token
      issuer: {{ template "issuer.officer" . }}    #зовнішнє (кастомне) Keycloak DNS-імʼя
      jwksUri: {{ template "jwksUri.officer" . }}  #дефолтний Keycloak URL OpenShift кластера
```
Необхідно налаштувати для registry-rest-api, excerpt-service-api та registry-regulation-management
конфігурація Keycloak Frontend URL:
Приклад конфігурації Keycloak Frontend URL через KeycloakRealm CR
```
spec:
  frontendUrl: #зовнішнє (кастомне) Keycloak DNS-імʼя
```
конфігурація Keycloak redash viewer client web URL:
Приклад конфігурації Redash client webURL
```
spec:
  webUrl: #зовнішнє (кастомне) Redash DNS-імʼя
```

конфігурація Kong OIDC plugin:

Приклад конфігурації Kong OIDC плагіна

config:
  issuers_allowed:        #зовнішнє (кастомне) Keycloak DNS-імʼя
  discovery:              #дефолтний Keycloak URL OpenShift кластера
  introspection_endpoint: #зовнішнє (кастомне) Keycloak DNS-імʼя

конфігурація Istio Gateway для кабінетів користувачів:
Приклад конфігурації Istio Gateway
```
spec:
  ....
  servers:
    - hosts:
        ....
        - #зовнішнє (кастомне) officer-portal DNS-імʼя
```
конфігурація Istio Virtual Service для кабінетів користувачів:
Приклад конфігурації Virtual Service
```
spec:
  gateways:
    - gateway
  hosts:
    - #зовнішнє (кастомне) officer-portal DNS-імʼя
```

Орієнтовні макети дизайну адмін-консолі

Figure 3. Макет налаштування DNS на рівні платформи

Cluster Keycloak default DNS name вичитується адмін-консоллю зі специфікації Keycloak CR в user-management

Figure 4. Макет налаштування DNS на рівні платформи

Figure 5. Макет налаштування DNS на рівні платформи

Figure 6. Макет налаштування DNS на рівні реєстру

Сервісні користувачі для доступу в HashiCorp Vault:

Кожний компонент, що отримує доступ до Vault повинен запускатись від окремого OpenShift сервіс акаунта. Сервісні користувачі створені в HashiCorp Vault повинні бути типу Kubernetes Auth Method та створюватись під час початкового налаштування HashiCorp Vault через виконання script-init ConfigMap.

Компонент

Назва сервіс акаунта

Прив’язані Namespaces

Capabilities

Jenkins

control-plane-jenkins

Registry namespace, user-management

["read"]

Приклад Capability Policy HashiCorp Vault

{
      "policy": "path \"registry-kv/registry/<registry-name>/domains/\" \"{ capabilities = [ \"read\" ]}\""}
}

Приклад привʼязки сервіс акаунта OpenShift в HashiCorp Vault

{
      "bound_service_account_names": ["control-plane-jenkins"],
      "bound_service_account_namespaces": "ns",
      "policies": ["policy-name"],
      "ttl": "1h"
}

Компоненти реєстру та їх призначення в рамках дизайну рішення

Компонент

Службова назва

Призначення / Суть змін

Статус

Веб-інтерфейс інтерфейс управління Платформою та реєстрами

control-plane-console

Зміни інтерфейсів та логіки по зберіганню сертифікатів в Vault

To Do

Розгортання платформи та реєстрів

edp-library-stages-fork

Зміна логіки по отриманню сертифікатів з Vault та розгортання Keycloak та реєстрів

To Do

Кабінети користувачів

common-web-app

Конфігурація Kong плагінів

Done

Сервіс перегляду звітів

redash-viewer

Конфігурація змінних оточення

To Do

Налаштування реєстру

registry-configuration

Налаштування Keycloak Frontend URL

To Do

Keycloak Оператор

keycloak-operator

Конфігурація Keycloak Frontend URL

To Do

HashiCorp Vault

vault

конфігурація полісі та сервісного користувача

To Do

План розробки

Технічні експертизи

BE
DevOps

План розробки

Додати функціонал по налаштуванню Realm Frontend Url Keycloak оператором
Змінити UI адмін-консолі відповідно макетам та загальним положенням
Розробити функціонал по налаштуванню DNS-імен в пайплайнах та чартах компонентів реєстру

Міграція даних при оновленні реєстру

Вже налаштовані кастомні DNS-імена повинні залишитись при міграції.
Якщо DNS-імʼя для Keycloak вже було налаштоване, то pre-upgrade скрипт повинен перенести його до values.yaml та Vault
Враховуючи кількість ручних дій які були виконані на різних прод кластерах для налаштування доменів, неоднорідність та індивідуальність налаштувань після оновлення старі ресурси пропонується видалити самостійно адміністратору реєстра/платформи

Безпека

Бізнес Дані

Категорія Даних

Опис

Конфіденційність

Цілісність

Доступність

Технічні дані що містять відкриту інформацію

Налаштування системи, конфіги, параметри з не конфіденційними значеннями але зміна яких може негативно вплинути на атрибути системи

Відсутня

Висока

Технічні дані що містять службову інформацію

Налаштування системи, конфіги, параметри які являються службовою інформацію

Висока

Технічні дані що містять інформацію з обмеженим доступом

Налаштування системи, конфіги, параметри що містять інформацію з обмеженим доступом зміна яких може негативно вплинути на атрибути системи

Середня

Висока

Спрощена модель загроз

Механізми протидії ризикам безпеки та відповідність вимогам безпеки

Усі ризики було усунено в архітектурному дизайні