Застосування правил RLS до модуля ГІС

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

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

Модуль ГІС є однією з підсистем через які відбувається доступ до даних реєстру. В регламенті реєстру доступ до даних реєстру може бути обмежений зокрема rls правилами читання. Наразі модуль ГІС ігнорує ці правила.

Для усунення цього недоліку пропонується додавати правила фільтрації для проксі сервера envoy, побудовані на основі налаштувань rls правил читання регламенту реєстру.

2. Актори та ролі користувачів

Посадові особи

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

Перегляд та пошук гео-даних обмежених правилами RLS

4. Цільовий дизайн

За допомогою Istio EnvoyFilter налаштовується конфігурація Envoy, створеного Istio Pilot для гео-серверу.

Сконфігурований envoy-фільтр перехоплює запити до шарів (layers) для джерел даних яких налаштовано RLS на читання. В такі запити envoy додає умови фільтру RLS на основі атрибутів автентифікованого користувача отриманих з jwt.

На гео-сервер запит надходить вже з фільтром та гео-сервер повертає лише ті дані на які є права у користувача.

Налаштування EnvoyFilter створюються сервіс генератором на основі метаданих RLS та встановлюються чи оновлюються при розгортанні регламенту.

4.1. Сервіс генератор

В сервіс генератор необхідно додати нове значення для параметру module --module=geoserver-rls

При отриманні такого параметру cервіс генератор має згенерувати Istio EnvoyFilter, який, для запитів на яких необхідно перевіряти RLS, бере ключ RLS з JWT-токену і додає створений на його основі CQL_FILTER до параметрів запиту.

Докладний робочий приклад envoy фільтру який додає атрибут з jwt в заголовок запиту - how to extract jwt in envoy

При генерації в першу чергу потрібно знайти всі правила RLS на читання для таблиць та представлень які використовуються в гео-сервері. Правила зберігаються в таблиці ddm_rls_metadata. З них потрібно вибрати ті в яких type = read та check_table містить назву таблиці чи представлення в якій є колонки типу geometry.

Для кожного такого правила потрібно згенерувати код Envoy Filter який його буде застосовувати. В прикладі приведено псевдокод описуючий логіку згідно з якою повинна відбуватись перевірка

Приклад псевдокоду

--Наступні плейсхолдери замінюються на значення з відповідних
--колонок налаштування RLS з таблиці ddm_rls_metadata
--${jwtAttribute}
--${checkTable}
--${checkColumn}

--Якщо це запит на читання з таблиці або view на якому налаштовано rls починається обробка
if request_params("service") = "WFS"
    and request_params("request") = "getFeature"
    and request_params("typeName") = "registry:"+${checkTable} then

    --Отримати значення ${jwtAttribute} із токену
    jwtRLSattribute = get_jwt_payload(${jwtAttribute})

    if jwtRLSattribute is not null then
        --Якщо jwtAttribute не пустий формується фільтр rlscolumn like 'jwtAttrValue%'
        --jwtAttribute може містити масив значень, для
        --кожного значення додається умова через or
        for i in jwtRLSattribute loop
            if i !=0
                rls_filter =rls_filter + "or"
            end
            rls_filter =rls_filter + "${checkColumn} like '"+jwtRLSattribute[i]+"%25'"
        end
        rls_filter ="("+rls_filter +")"
    else
        --Якщо jwtAttribute пустий формується фільтр який не поверне жодного запису
        rls_filter = "1=0"
    end

    if exists request_params("CQL_FILTER") then
        --Якщо в запиті вже був cql фільтр, загортаємо його у дужки і додаємо умову RLS фільтру
        --та заміняємо CQL_FILTER на сформований фільтр в параметрах запиту
        request_params("CQL_FILTER") = "("+request_params("CQL_FILTER")+") and "+rls_filter
    else
        --Якщо в запиті не було cql фільтру просто додаємо свій RLS фільтр у параметри запиту
        request_params("CQL_FILTER") = rls_filter
    end
end

4.2. Публікація регламенту

Якщо реєстр розгорнутий з модулем ГІС, пайплайн публікації регламенту повинен викликати сервіс-генератор з опцією генерації правил RLS до модуля ГІС. Отриманий в результаті генерації ресурс Istio EnvoyFilter повинен бути встановлений або оновлений в оточенні реєстру.

Якщо правила RLS відсутні, то потрібно передбачити видалення Istio EnvoyFilter який міг бути створений в попередніх версіях регламенту.

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

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

Компонент	Службова назва	Призначення / Суть змін
Сервіс Генератор	service-generation-utility	Генерація EnvoyFilter на основі шаблону та налаштувань RLS регламенту
Пайплайн публікації регламенту реєстру	registry-regulations-publication-pipeline	Застосуванням згенерованого EnvoyFilter

Компонент

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

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

Сервіс Генератор

service-generation-utility

Генерація EnvoyFilter на основі шаблону та налаштувань RLS регламенту

Пайплайн публікації регламенту реєстру

registry-regulations-publication-pipeline

Застосуванням згенерованого EnvoyFilter

BE
DEVOPS

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

Розробка шаблону EnvoyFilter
Розширення сервіс генератору можливістю генерувати EnvoyFilter на основі шаблону та налаштувань RLS регламенту.
Розширення пайплайну публікації регламенту застосуванням згенерованого EnvoyFilter