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

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

В поточній версії Платформи реєстрів не передбачено процесу керування налаштуваннями підсистеми бекапування реєстрів. Для впровадження такої функціональності пропонується поліпшення інтерфейсу адмін-консолі, використовуючи яку адміністратор реєстру може налаштовувати розклад та час зберігання резервних копій реєстру.

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

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

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

  • Введення розкладу резервного копіювання через адмін-консоль

  • Налаштування часу зберігання резервних копій через адмін-консоль

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

  • Введення розкладу резервного копіювання в unix-cron форматі задається адміністратором

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

  • Налаштування розкладу резервного копіювання та часу зберігання резервних копій не є обовʼязковим при створенні реєстру

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

  • Введений розклад повинен відповідати unix-cron формату та валідуватись адмін-консоллю

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

  • Автоматичне створення резервних копій можна вимкнути або ввімнути за допомогою перемикача

  • При введені розкладу резервного копіювання адмін-консоль повинна показати коли відбудуться наступні три запуски резервного копіювання

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

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

  • Адмін-консоль повинна показувати дату останньої успішної резервної копії та термін її видалення

  • За замовчуванням тайм-зона Europe/Kiev встановлюється у values.yaml та на рівні поди з Jenkins, як змінна середовища

  • При вимкнені резервного копіювання існуючі резервні копії не видаляються

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

Поточний технічний дизайн

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

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

На даній діаграмі зображено залучені для реалізації вимог сервіси та взаємодію між ними. Додатково зображено важливі особливості, які необхідно брати до уваги в рамках реалізації.

remote-file-transfer

Розклад резервних копій та час зберігання резервних копій передаються в values.yaml

global:
  timeZone: Europe/Kiev
  .....
  registryBackup:
    enabled: true
    schedule: "30 19 * * *"
    expiresInDays: 3

та в анотацію registry-parameters/values codebase ресурсу реєстру. Оператор повинен зреагувати на зміну в codebase CR та тригернути job provisioner, який перестворить Create-registry-backup джобу з новими параметрами. Приклад налаштування розкладу в Jenkins:

30 19 * * *

Інтерфейс керування

Приклад заповнення параметрів резервного копіювання. Якщо розклад заповнений коректно, то показуємо наступні дати виконання.

schedule 2
Розгорніть, щоб побачити більше мокапів

  • Початковий стан. Резервне копіювання вимкнено:

    schedule 1

  • Попередні резервні копії існують в системі. Виводимо дату створення копії та кількість днів до її видалення:

    schedule 3

Високорівневий план розробки

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

  • BE / DevOps

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

  • Розширення функционалу codebase оператора тригером jenkins job provisioner після оновлення codebase CR

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

  • Розробка groovy-функцій в jenkins job provisioner по оновленню параметрів в Create-registry-backup job.

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

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

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

Безпека

Бізнес Дані

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

Опис

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

Цілісність

Доступність

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

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

Відсутня

Висока

Висока

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

schedule TM

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

Ризик

Засоби контролю безпеки

Реалізація

Пріорітет

Віддалене виконання команди (RCE). Значення expiresInDays без санітізації комітається в геріт з інтерфейсу адмін консолі. Під час запуску процедури резервного копіювання значення передається в скрипт backup-registry.sh як аргумент знову без санітізації що дає змогу виконати будь-яку системну команду на провіженері

  • Реалізувати механізм позитивної валідації для форми "Розклад" на фронтенді

  • Реалізувати механізм позитивної валідації для даних з форми "Розклад" на бекенді

  • Реалізувати механзм строгої типізації та валідації для даних expiresInDays на фронтенді

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

  • Реалізувати механізм санітізації аргументів в скрипті backup-registry.sh

Частково враховано в початковому дизайні. Залишилось реалізувати механізм санітізації аргументів в скрипті backup-registry.sh

Критичний

Відмова в обслуговуванні через вичерпання обчислювальних ресурсів (DOS) шляхом задання розкладу виконання резервного копіювання кожну хвилину

  • Розробити обмеження для розкладу виконання резервного копіювання як мінімум один раз на годину.

Не враховано в початковому дизайні

Високий

Ризик втрати даних при занадто малому терміну зберігання резервних копій

  • Розробити мінімальний ліміт для терміну зберігання резервних копій рівний 7 дням.

Не враховано в початковому дизайні

Високий

Ризик втрати даних при відсутності увімкненого резервного копіювання за замовчуванням. (Secure by default)

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

Не враховано в початковому дизайні

Високий

Відмова від авторства. Відсутність аудит логу і інформації хто займався конфігурацією резервного копіювання.

  • Цільовий сервіс має логувати усі запити та надсилати їх до централізованої системи логування та моніторингу.

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

  • Система логування має використовувати уніфікований час та часову зону.

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

  • Логи не мають містити чутливої інформації або вона повинна бути заплутана (obfuscated) відповідним чином

Не враховано в початковому дизайні

Середній

Ризик витоку даних при використання зовнішнього простору домених імен

  • Перевести всю внутрішню міжсервісну комунікацю на приватні домені імена.

Частково враховано в початковому дизайні. Деякі сервіси можуть використовувати зовнішні адреси. Потрібно перевести усі сервіси на комунікацію всередині приватної мережі

Середній

Вимоги з безпеки: Налаштування мережевих політик безпеки

  • Налаштувати мережеві політики таким чином щоб вони відповідали принципу найменших прівілеїв.

Враховано в початковому дизайні

Середній

Глосарій та акроніми

Термін Опис

СR

Custom Resource