Примітки до релізу 1.9.6

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

Розробка

Функціональність для отримувачів послуг

Надання публічного доступу до даних, та управління ним

Надано можливість відкривати публічний API та контролювати доступ до даних через нього. Тепер неавтентифіковані користувачі можуть отримати доступ до публічних даних Реєстру, а технічні адміністратори мають змогу моніторити та контролювати цей доступ.

Розробник регламенту може налаштовувати доступ до представлень та REST API реєстру для неавтентифікованих користувачів:

  • Додано обробку нового параметра `publicAccess у liquibase (ext+schema).

  • Згенеровано ресурси AuthorizationPolicy, RequestAuthentication, та Service, виділені під public взаємодію.

  • При запиті до platform-gateway за шляхом /public/data-factory/…​ до запиту додається токен public-user, та перенаправлення до сервісу із public rest api. /public/data-factory/…​ додано до whitelist в auth policy.

  • При запиті на public rest api swagger користувач бачить одну групу - public з ендпоінтами exposeSearchConditions public = true.

  • У компоненті registry-configuration, у values.yaml додано створення юзера public-user.

  • Додано NetworkPolicy, яка відкриває доступ з platform-gateway до rest-api-public (в директорію deploy-templates/network-management/templates).

  • Створено kong роут до свагера platform-gateway: /public/data-factory/openapi.

  • Додано можливість відключити публічний доступ для СК на який він був попередньо наданий.

Технічний адміністратор Реєстру може моніторити показники виконання та кількості запитів до публічного API через Grafana-dashboard:

  • Додано створення ресурсів KongPlugin з іменем kong-prometheus-plugin для кожного реєстру, сервіс kong-prometheus-monitoring для збирання метрик, та створення ресурсу ServiceMonitor з іменем kong-service-monitor у неймспейсі openshift-monitoring.

  • Додано підключення дашборду з метриками для kong у values.yaml платформенного компонента monitoring, та конфігмапу з офіційною Grafana Dashboard у директорію dashboаrds компонента monitoring.

Технічний адміністратор Реєстру може налаштовувати, редагувати, блокувати, розблокувати, та видалити доступ до публічних даних Реєстру через адмін-консоль Control Plane:

  • Додано секцію для конфігурації публічного API в registry-configuration.

Технічний адміністратор Реєстру може налаштовувати доступ до OpenAPI специфікації:

  • Додано кешування роуту /public/data-factory/openapi.

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

Технічний адміністратор Реєстру може налаштовувати та редагувати рейт-ліміти на кількість запитів до публічних даних реєстру через адмін-консоль Control Plane:

  • Налаштування додано рейт-лімітів у попап "Надати публічний доступ".

  • Додано обробку параметрів у GoLang.

  • Додано обробку значень рейт-лімітів у ingress.

Функціональність електронних підписів

Надано можливість перевіряти валідність підпису КЕП та його джерела, коли підпис надійшов у бізнес-процес по API разом із даними (контейнер типу Asics або CAdES).

Розробник Регламенту тепер має делегат для перевірки валідності підпису даних та архіву файлів, що містять підпис:

  • Імплементовано необхідні ендпоінти в digital-signature-ops та ddm-dso-client.

  • Розроблено делегат та element template.

Розробник Регламенту тепер має відповідні JUEL-функції для отримання деталей про підписанта даних та архіву файлів, що містять підпис, та отримання контенту підписаних даних та архіву файлів, що містять підпис:

  • Розроблено JUEL-функцію signature_details.

  • Розроблено JUEL-функцію signature_content.

Розробник Регламенту тепер має референтний приклад можливості перевіряти валідність підпису КЕП і ким підписано контент:

  • Створено референтний Бізнес-Процес, як приклад валідації.

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

Отримувач та надавач послуг може автентифікуватись на користувацькому порталі за допомогою хмарного ключа:

  • Додано можливість рендеру QR-коду в компоненті SignatureWidget для сторінок KeyCloak.

Отримувач та надавач послуг може підписувати дані, внесені через форми на користувацькому порталі, за допомогою хмарного ключа:

  • Додано можливість рендеру QR-коду в компоненті SignatureWidget для кабінету надавача послуг.

Надано можливість використання Дія.Підпис для автентифікації та підпису.

Отримувач послуг, що має статус ФО або ФОП, може використовувати Дія.Підпис для підпису даних:

  • Представник ФОП чи ЮО отримає "помилку валідації" при спробі підпису за допомогою Дія.Підпис.
Єдина автентифікація надавачів послуг для групи Реєстрів:

  • Для адміністраторів Реєстрів розроблено інструкцію з об’єднання Реєстрів у групу та налаштуванню автентифікації для надавачів послуг в цій групі реєстрів.

Функціональність для надавачів послуг

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

Налаштування каналів зв’язку в кабінеті надавача послуг.

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

  • У user-settings-service при відправці повідомлення у user-notifications топік додано маркер рілма користувача, для якого відправляється повідомлення (CITIZEN/OFFICER).

  • Для channel-confirmation оновлено шаблон додатковою розвилкою в залежності від ролей користувача у змінній recipientRoles (якщо ролі contains citizen - вивід для кабінету отримувача послуг, якщо ролі contains officer - вивід для кабінету надавача послуг.

  • Для надавачів послуг закрита робота з каналом Дія.

Надавач послуг може бачити налаштування каналу зв’язку "Електронна пошта":

  • Додано відображення налаштувань електронної пошти у порталі надавача послуг.

Надавач послуг може вносити електронну адресу у канал зв’язку "Електронна пошта" у профілі Кабінету надавача послуг та отримати одноразовий пароль (OTP) для підтвердження:

  • Заборонено використання спеціальних символів на початку та в кінці електронної адреси.

Надавач послуг може деактивувати/активувати канал зв’язку "Електронна пошта" з раніше внесеною адресою електронної пошти у профілі Кабінету надавача послуг. Також, він може використати одноразовий пароль (OTP) щоб підтвердити зміну елетронної адреси.

Електронна пошта та нотифікації у кабінеті посадової особи.

Розробник Регламенту може моделювати відправку повідомлень у канал зв’язку email та inbox надавача послуг:

  • Відповідні зміни додано в делегат та element template.

  • Додано обробку рілма користувача у notification-service.

Надавач послуг може отримувати та переглядати inbox повідомлення у відповідному Кабінеті користувача:

  • Додано відображення inbox для повідомлень у кабінеті надавача послуг.

Отримувач послуг та надавач послуг можуть вивантажувати файли з EditGrid в один клік у своїх відповідних користувацьких порталах.

Функціональність для команд розробки

Спрощення внесення та застосування змін у UI-форми та Бізнес-Процеси.

Розробник Регламенту може створювати/копіювати/редагувати/видаляти UI-форми в мастер-версії для швидшого застосування змін. Також, він може переглядати результат публікації змін, внесених до мастер-версії, у розділі "Огляд версії":

  • Додано примусову синхронізацію з remote при читанні 1 файлу в репозиторії HeadFileRepositoryImpl.

  • Створено компонент для управління UI формами (створення, редагування, копіювання, видалення) в мастер версії.

  • Створено POST ендпоінт для створенню форми у мастер-версії.

  • Створено PUT ендпоінт для редагування форм у мастер-версії.

  • Створено DELETE ендпоінт для редагування форм у мастер-версії.

  • Додано логіку для створення та редагування UI форм в мастер-версію.

  • Налаштовано пайплайн перевірки регламенту на роботу тільки з публічними змінами Gerrit (exclude Private changes).

  • Додано права сервіс акаунту RRM на виконання update by submit операції в Gerrit.

  • Додано header Access-Control-Expose-Headers: ETag для не PROD_LIKE середовищ cicd2-кластера.

  • Створено HEAD метод для форм у мастер-версії та версії кандидаті.

  • Додано логіку для видалення UI форм в мастер-версію.

  • Додано відображення результату публікації змін, внесених до мастер версії на головній сторінці.

Моделювальник Регламенту може створювати/копіювати/редагувати/видаляти бізнес-процеси в мастер-версії для швидшого застосування змін:

  • Розроблено POST ендпоінт для створення Бізнес-Процесу у мастер-версії.

  • Розроблено відповідні компоненти для створення Бізнес-Процесу в мастер-версії та простого створення версії-кандидата.

Розробник Регламенту може бачити чи конфлікти з мастер-версією в огляді версії-кандидата для кожної зміненої складової регламенту. Також, він має можливість часткового відкату окремих складових версії-кандидату до стану мастер-версії для спрощення вирішення конфліктів:

  • Додано необхідні ендпоінти в registry-regulation-management.

  • Додано зміни на сторінку з відображенням версії-кандидата.

Розроблено інструкцію для тестування та перегляду внесених змін до моделі даних версії-кандидата в ізоляції без необхідності їх інтеграції в мастер-версію.

Технічні можливости для адмінстраторів реєстрів та адміністратора платформи

Керування параметрами реєстра через візуальний інтерфейс. Налаштування параметрів автентифікації та підпису даних через віджет, параметрів підпису через id.gov.ua для отримувачів послуг та автентифікація отримувачів послуг з Дія.Підпис.

Адміністратор реєстру може налаштовувати віджет як спосіб автентифікації для отримувачів послуг. Також, він може налаштовувати спосіб підпису даних для отримувача послуг:

  • Додано параметри по налаштуванню автентифікації надавачів послуг у Control Plane при створенні та редагуванні Реєстру.

  • Додано параметри по налаштуванню автентифікації отримувача послуг в темплейти Реєстрів.

  • Додано параметри по citizen auth flow в конфігурацію автентифікатора.

  • Додано новий параметр authType (тип автентифікації) в конфігурацію автентифікатора.

  • Додано секцію з параметрами віджету підпису для отримувачів послуг.

  • Додано в темплейт Реєстру значення для віджету підпису для отримувачів послуг.

  • Додати параметри з віджету підпису для отримувачів послуг в common-web-app.

  • Винесено в окремий параметр налаштування для віджету підпису для кабінету громадян.

Користувач кабінету може автентифікуватися в кабінеті способом, налаштованим Адміністратором на рівні реєстру. Кабінет користувача не змінюється незалежно від обраного способу автентифікації:

  • Додано новий тип автентифікації (platform-id-gov-ua).

  • Змінено логіку формування provider user id для уніфікації даних користувача.

Отримувач послуг, що має статус ФОП, або представника ФОП чи ЮО, має можливість автентифікуватись у кабінеті використовуючи КЕП у сервісі id.gov.ua:

  • Розширено правила валідації підтримкою представників ЮО у іd-gov-ua authenticator.

Отримувач послуг, що має статус ФО або ФОП, має можливість автентифікуватись у кабінеті використовуючи BankID у сервісі id.gov.ua, залежно від обраного режиму автентифікації. Також, він може автентифікуватись у кабінеті використовуючи Дія-підпис у сервісі id.gov.ua з врахуванням обраного режиму автентифікації:

  • Розширено правила валідації підтримкою ФОП у іd-gov-ua authenticator.

  • Активовано опцію "Авторизуватись з id.gov.ua" при виборі режиму "Для бізнесу" на сторінці автентифікації.

Отримувач послуг може підписувати дані файловим та апаратним КЕПом у віджеті підпису, сконфігурованому з id.gov.ua.

Адміністратор може оновлювати сертифікати Акредитованого Центру Сертифікації Ключів для Платформи та Реєстру через Control Plane без зміни ключа послуг:

  • Розділено UI елементи по групах та налаштувати валідацію на рівні Платформи.

  • Розділено UI елементи по групах та налаштувати валідацію на рівні Реєстру.

  • Додано поточну дату та час до імені файлу в Gerrit.

  • Налаштовано перезавантаження компоненту DSO після оновлення секретів ключів.

Адміністратор Реєстру може редагувати параметри вибраної версії Реєстру. Також, він може налаштовувати розмір пула в rest-api і кafka-api:

  • Додано поля для налаштування kafkaApi та restApi параметрів

  • Додано параметр data-platform.datasource.maxPoolSize до ddm-starter-database.

  • Додано рестарт сервісів rest-api та kafka-api при зміні конфіг-мапи

Введено підтримку для розподілення рівнів доступу користувачів за ієрархічною моделлю Row-level security (RLS). Згідно налаштування RLS з мета-даних (регламенту), сервіс зчитує jwtAttribute з токена поточного користувача, і використовує результат для внесення додаткового параметра запиту в гео-сервері.

Користувач може мати доступ до даних з гео-серверу відповідно до свого рівня доступу в RLS:

  • Створено envoy filter.

  • Розроблено темплейт з envoy filter у service generation utility.

Оновлено інструкцію для адміністратора Платформи по розгортанню Платформи на кластері в vSphere.

Інші впровадження

  • Istio оновлено до версії 1.18.x.

  • KeyCloak оновлено до версії 20.0.3, keycloak-operator оновлено до версії 1.15.0.

  • Gerrit-operator оновлено до останньої EDP-версії.

  • Jenkins-operator оновлено до останньої EDP-версії.

  • Назву Кабінет посадової особи змінено на Кабінет користувача.

  • Делегати пошуку користувачів у Кейклоак помічено як Deprecated.

  • Оновлено user-integration-test, які використовують користувача "auto-user-officer-duplicate".

  • Стабілізовано BPMN парсинг.

  • Впроваджено тоггл на відключення очищення formdata у Redis.

  • Вирівнено версії для збірки інсталеру.

  • Видалено файли, що не привʼязані до жодного активного БП з lowcode-file-storage.

  • Оновлено trembita-edr-registry-mock до останньої build/1.3.0-SNAPSHOT.80 версії у external-integration-mocks репозиторії.

  • Перероблено механізм релоаду після зміни конфіг мапи environment js на релоадер.

  • Додано анотацію @Step до степів у data-factory-integration-tests.

  • Для апдейту деплоймента/стейтфул сет при оновленні секретів та конфіг мап використовується компонент reloader.

  • Перейменовано крок create-redash-snippets в пайплайні публікації на restore-redash-admin-state.

  • Оптимізовано копіювання докер імеджів у центральний нексус при розгортанні інсталеру.

  • Оновлено версію Feign-annotation-error-decoder.

  • Для управління міграціями даних БД "camunda", перейшли до liquibase.

  • Додано можливість вимикати валідацію автозгенерованного поля, якщо його явно передає користувач.

  • Виправлено нестабільні локальні тести у rest-api-core.

  • Оновлено БЕ бібліотеки після переходу на новий feign-annotation-error-decoder.

  • Для рестарту bpms та ddm-notification-service при оновленні secrets/configmaps, які менеджить external-secrets operator, використовується компонент reloader.

  • Винесено всі Kong CRD у cp-installer.

  • Додано помилку при ситуації коли в IdGovUaOfficerAuthenticator знайдено більше одного користувача за параметрами.

  • Оновлено версії платформенних компонентів в CodeBase.

Завантаження файлів під час обміну повідомленнями.

При завантаженні отримувачем чи надавачем послуг даних з csv-файлу масивом в дата-фабрику відбувається попередня валідація даних для більш швидкого виявлення помилок:

  • Розроблено генерацію ендпоінта для валідації csv файлу.

Отримувач та надавач послуг в рамках Бізнес-Процесу може завантажувати csv-файл з кількістью записів >50 для збереження/дозбереження даних в дата-фабрику:

  • liquibase-ddm-ext розширено новими тегами.

  • service-generation-utility розширено генерацією kafka лісенерів.

  • Розроблено делегат на відправку повідомлень в Kafka для csv батч-лоаду.

  • Розроблено лісенер у bpms що читає повідомлення з Kafka та повідомляє БП про завершення обробки csv файлу

  • Розроблено референтний приклад використання batch-load з можливістю завантажувати більше ніж 50 рядків.

Розроблено новий компонент DataImport, що дозволяє розробнику регламенту налаштовувати імпорт даних з csv-файлу в Бізнес-Процес.

Регресійні дефекти

Ці оновлення включають ряд виправлень та покращень.

Список регресійних дефектів. Натисніть, щоб розгорнути або згорнути.
Регресійні дефекти PST:

  • Не створюється MR у Gerrit на оновлення кластера, якщо немає різниці між Інсталерами та є виправлення при розгортанні платформи.

  • Підтягуються зміни з попереднього відхиленого запита у Control Plane.

  • Помилки в поді admin-console-operator на всіх кластерах.

  • Задача compact-blobstore-default у платформному Nexus налаштований на пустий blob storage.

  • При редагуванні Опису реєстру створюється порожній МР на оновлення.

  • Оновився client secret після оновлення версії keycloak-operator.

  • На cicd2 пода vault-tenant-integration завжди в статусі Init:0/1 на всіх середовищах.

  • Support-активності з міграції ДП УСС на новий кластер.

  • Не працює налаштування розкладу створення бекапів реєстру.

  • Не працює взаємодія між реєстрами.

  • Неправильне редагування значення (value) для полів "Змінні оточення".

  • Немає можливості налаштувати взаємодії із зовнішніми системами та трембіта реестрами які мають автентифікацію.

  • Після підтвердження оновлення платформи через Control Plane консоль створюється 2 дублікати запиту.

  • Розгортання платформи 1.9.3 на отточенні ДП УСС.

  • Доступ до keycloak адмін консолі не закритий для користувачів ззовні.

  • Помилка на UI при створенні МР в Керуванні Платформою.

  • Після вимкнення DNS налаштувань з кабінетів Officer та Citizen отримаємо помилку 404 при відкритті роута.

  • Створюється дублікат МР у Герріт при редагуванні реєстру або платформи.

Регресійні дефекти ST2:

  • Існує можливість створити у gerrit change, котрий сприймається системою як активний і змерджений одночасно.

  • Створюється новий патчсет та запускається код-ревью пайп при натисканні кнопки "Зберегти зміни", навіть якщо змін внесено не було.

  • Некоректна робота валідації на стейджі "registry-regulations-validation" під час деплою регламенту з внутрішніми посиланнями на nexus у data-model.

  • Створюється пустий МР під час оновлення облікових даних для типу автентифікації надавачів послуг, що може вводити у оману адмістратора.

  • Автотести дивляться на останні "submitted" ченжі у Gerrit на огляді змін у мастер в admin-tools, а система проставляє дату останніх "Updated" змін у мастер в admin-tools.

  • Помилка 415 Payload Too Large при спробі завантажити файл розміром більше 1МВ.

  • При подвійному кліку по кнопці "Підтвердити" чи "Відхилити" в МР оновленні платформи "Керування платформою" система генерує 500 помилку та відображає системний код оновлення.

  • В Керуванні Платформою → налаштування ДНС не працює посилання "Інструкція з зовнішньої конфігурації". Помилка At least one or more documents was not found in provided ids list, якщо користувач зберіг файл у основному процесі і далі через call-activity викликає підпроцес, де намагається відобразити файл.

  • Немає логів json формату та plain text у Kibana від запитів на Kong.

  • Існує можливість валідно завершити БП з КЕП через Дія підпис, зчитавши та підписавши 1-ий QR-code іншим користувачем, а 2-ий QR-code підписавши ініціатором БП.

  • Помилка під час підписання задач БП прод ключами з увімкненим Istio.

  • При подвійному натисканні по кнопці "Підтвердити" у всіх розділах "Редагувати реєстр" система генерує 500 помилку та рендерить білий екран с роутами git.

  • Падає деплой регламенту при додаванні другого ченджсету з addColumn для однієї таблиці.

  • На інтерфейсі не відображається, що доступи були заблоковані у блоці "ДОСТУП ДЛЯ РЕЄСТРІВ ПЛАТФОРМИ ТА ЗОВНІШНІХ СИСТЕМ".

  • Не змінюється статус у блоці "ДОСТУП ДЛЯ РЕЄСТРІВ ПЛАТФОРМИ ТА ЗОВНІШНІХ СИСТЕМ" після успішного додавання інтеграції.

  • Неможливо додати кейклоак ДНС в налаштуваннях платформи.

  • В Адмін Порталі при редагуванні скриптів користувача конфьюзить наявність кількох однакових кнопок "Зберегти".

  • Новостворенний БП має за замовчуванням властивість isExecutable="false".

  • Під час налаштування конфігурації "ДАНІ ПРО КЛЮЧ" (Тип носія: Апаратний носій) на платформі система не рендерить шаблон з параметрами у полі "INI конфігурація".

  • Помилка com.iit.certificateAuthority.endUser.libraries.signJava.EndUserException: Wrong signature під час підпису форми, де у компоненті number введене дробне число більше 9 999 999.99.

  • Під час переходу до реєстру у КП система генерує 500 помилку та рендерить білий екран з помилкою "yaml: unmarshal errors".

  • Авторизація на сitizen-portal при активній табі "Для громадян" через сервіс id.gov.ua ключем ФОП генерує запис у KeyCloak з атрибутом edrpou.

  • Налаштування DNS для кабінету отримувача послуг не додаються у values.yaml у КП.

  • В Адмін Порталі у переліку БП є нефункціональна кнопка скачування схеми БП.

  • Помилка у digital-doc-service Document not found errorDocument not found error при сабміті форми з файлом.

  • Відсутній fullname опис у попапі у officer-citizen порталах.

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

Регресійні дефекти ST1:

  • Не обробляється завантаження файлів з розширенням у аперкейсі.

  • Не вивантажується файл який був збережанний делегатом dataFactoryConnectorBatchCreateDelegateV2.

  • При використанні бібліотеки moment з оновленим компонентом DateTime не працює задання мінімальної та максимальної дати.

  • Контекстне меню в рядку таблиці пропадає при застосуванні горизонтального скролу.

  • Відсутній префікс /nexus для білд пайлайну liquidbase schema ext.

  • Тег add column працює некорректно, якщо в таблиці присутня колонка із типом CHAR.

  • Назва групи в bp-grouping.yml розділена "\" якщо вона більше 73 символів при створенні через АП.

  • Колір валідаційних помилок має бути червоним.

  • Відстань між заголовком на полем замаленька у розділі "АВТЕНТИФІКАЦІЯ НАДАВАЧІВ ПОСЛУГ" Control Plane.

  • Велика відстань між лейбою та дропдауном у компоненті Select (стилізованому).

  • Не призупиняються крон джоби бекапів після видалення розкладу.

  • В Citizen Порталі виправити елементи інтерфейсу по налаштуванню каналів зв’язку відповідно до мокапів.

  • Невірно відпрацьовує поведінка кнопки "До профілю" у сітізен порталі.

  • Поле "Електронна адреса" невірно предзаповнено у сітізен порталі.

  • Якщо сервер не відповідає користувач отримує невірну помилку.

  • Сервіси зовнішніх систем не повинні ходити на поду app=registry-rest-api.

  • При більше ніж трьох символах розміру типу поля в ліквідбейзі падає білд дата моделі.

  • Необхідно використувувати пагінацію для видалення redash дашбордів.

  • Whitelabel error при переході на Camunda Dashboard.

  • Відстань між текстом та кнопками у поп-апі "Скасувати зміни?" не відповідає мокапу.

  • Переробити генерацію назв сервісів для єкспоуз серч кондішенів.

  • Невірно відпрацьовує кнопка "Повернутись" у профілі користувача сітізен порталу.

  • При додаванні автентифікації користувача через idgovua після деплою видаляється identity provider для id-gov-ua officer.

  • Select component pre-population працює некоректно.

  • Додати до ресурсу id-gov-ua-officer параметри для селфрегістрації.

  • При переході за прямим посиланням rpm.diia.org.ua/themes відбувається перенаправлення до officer-portal-root.pzm-stage.svc:8080/themes/.

  • Використання адреси електронної пошти з допустимим символом "." призводить до виникнення валідаційної помилки.

  • Немає локалізації масок компонента Date/Time всередині компонента Edit Grid на перегляді списку.

  • Для SC, які повертають файли та використовуються зовнішніми системами або публічними API, повертати null для файлів.

Безпека

У релізі 1.9.6 було покращено декілька аспектів, що стосуються безпеки. Основні зміни включають:

Список покращень безпеки. Натисніть, щоб розгорнути або згорнути.

  • Розширено Go/Javascript Jenkins agents плагіном cyclonedx.

  • Додано 4 dast stages до пайплайна proxy-mode: dast-api-scan-user-settings-service, dast-api-scan-excerpt-service, dast-api-scan-process-history-service, dast-api-scan-registry-rest.

  • Додано перевірки з безпеки до пайплайнів MASTER-Build redash-chart та redash.

  • Видалено список ключів, що не використовуються, в AWS.

  • Додано service-mesh-компоненти до процесу перевірки безпеки.

  • Видалено компонент telemetr-client, що передає телеметрію на сервери RedHat.

  • Додано cyclonedx-maven-plugin до всіх POM файлів Java-проєктів.