Механізм безпечного опублікування ресурсів в OpenShift 4.x кластері

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

Функціональність для безпечного публікування роутів в OpenShift 4.x кластері та механізму контролю доступу до ресурсів.

Зовнішній доступ до ресурсів кластера відбувається за допомогою роутів.

Роут (англ. Route) — абстракція в конфігурації OpenShift, яка дозволяє розміщувати веб-додатки за загальнодоступною URL-адресою.

1. Дизайн рішення

На даній діаграмі зображені залучені для реалізації вимог компоненти платформи та взаємодія між ними.

secure-endpoints

На діаграмі зображені основні потоки трафіку до основних операційних зон (кожна зона має свій список дозволених CIDR):

operational-zones

2. Функціональні можливості

З метою забезпечення безпечного доступу до наступних компонент кластера OpenShift 4.x:

  • Платформні;

  • Реєстрові;

  • Інфраструктурні.

    Більш детально ознайомитись з кожною категорією можна тут.

Платформа реалізує функціонал блокування доступу до кожного маршруту (route) на рівні HAProxy наступним чином:

2.1. Реєстрові

  1. При створенні реєстру Адміністратором, у нього є можливість задати IP-адреси з яких буде дозволений доступ до реєстрових компонентів. Інтерфейс адміністрування платформи додає внесені IP-адреси до файлу values.yaml в реєстрову конфігурацію в форматі:

    global:
  whiteListIP:
    adminRoutes: "192.168.1.64/26 172.16.0.192/27"
    officerPortal: "192.168.1.240/29"
    citizenPortal: "0.0.0.0/0"

    який, надалі використовується Helm-чартами компонент для розгортання реєстру з анотаціями у відповідних роутах:

    metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.64/26 172.16.0.192/27

    Адміністратор має можливість задавати список IP-адрес окремо для кабінету чиновника, кабінету громадянина та окремо для адміністративних компонентів.

    Кожен компонент має містити публічну IP-адресу кластера. Keycloak, у свою чергу, має містити всі CIDR з інших операційних зон або доступний всім, якщо кабінет громадянина не має обмежень.

    Інтерфейс додавання має наступний вигляд:

    adding-route-registry-ui

    процес ввведення IP-адреси:

    adding

    інтерфейс відображення та редагування списку IP-адрес реєстру має наступний вигляд:

    editing-route-registry-ui

  2. При редагуванні вже наявного реєстру в адміністратора також є можливість задати або видалити IP-адреси з яких буде дозволений доступ до реєстрових компонентів. Інтерфейс адміністрування платформи оновлює внесені IP-адреси в файлі values.yaml в конфігураційному репозиторії реєстру, який надалі використовується Helm-чартом для розгортання реєстру. Інтерфейс додавання має такий самий вигляд як і при створенні реєстру.

2.2. Платформні, інфраструктурні та інші роути

  1. У розділі "Керування кластером" в адміністратора є можливість задати CIDR для обмеження зовнішнього доступу для платформних та інфраструктурних компонентів. Інтерфейс адміністрування платформи створює запит на зміну (MR) в файлі values.yaml та після затвердження адміністратором cluster-mgmt пайплайн виконує оновлення та додавання необхідних анотацій.

  2. У всі інші роути, які не керуються Helm-чартами, анотації додаються/змінюються за допомогою annotate-routes стейджу в cluster-mgmt пайплайні. Приклад values.yaml:

    global:
  whiteListIP:
    adminRoutes: "192.168.1.64/26 172.16.0.192/27"
    CIDR внесені адміністратором для реєстру повинні також бути додані для платформних компонентів автоматично.

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

У даному розділі наведено перелік компонент системи, які задіяні або потребують змін/створення в рамках реалізації функціональних вимог згідно технічного дизайну рішення.

Таблиця 1

Компонент Службова назва Призначення

Інтерфейс адміністрування платформи

control-plane-console

Внесення налаштувань доступних каналів зв’язку для цільового оточення реєстру

Збереження конфігурації платформи та реєстрів

control-plane-gerrit

Платформний компонент для зберігання конфігурацій реєстру та платформи.

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

edp-library-stages-fork

Пайплайн для розгортання платформи

В таблиці 2 наведені роути, які повинні бути обмежені:

Тип Компонент Роут

Реєстровий

bp-admin-portal

business-process-administration-portal

Реєстровий

admin-portal

admin-portal-kong-proxy

Реєстровий

bp-webservice-gateway

bp-webservice-gateway

Реєстровий

nexus

docker-registry, nexus

Реєстровий

gerrit

gerrit

Реєстровий

hashicorp-vault

hashicorp-vault

Реєстровий

jenkins

jenkins

Реєстровий

officer-portal

officer-portal-kong-proxy

Реєстровий

registry-rest-api *

registry-rest-api

Реєстровий

pgadmin *

pgadmin

Реєстровий

registry-rest-api-external

registry-rest-api-external

Реєстровий

redash

redash-admin, redash-viewer

Платформний

control-plane-console

control-plane-console

Платформний

gerrit

gerrit

Платформний

jenkins

jenkins

Платформний

nexus

nexus

Платформний

ddm-architecture

ddm-architecture

Платформний

external mocks *

sign-widget-mock, trembita-dracs-registry-mock, trembita-edr-registry-mock

Платформний

hashicorp-vault

hashicorp-vault

Платформний

keycloak

keycloak-management-console

Інфраструктурний

noobaa

noobaa-mgmt, s3

Інфраструктурний

openshift-monitoring

alertmanager-main, thanos-querier, prometheus-k8s, grafana

Інфраструктурний

openshift-logging

kibana

Інфраструктурний

openshift-console

console, downloads

Інфраструктурний

openshift-authentication

oauth-openshift

Інфраструктурний

istio

jaeger, kiali

Інфраструктурний

grafana

grafana-monitoring
* у випадку розгортання реєстру в dev режимі

Таким чином, запити з IP-адрес, яких немає в доданих анотаціях будуть відхилятись.