Клонування образу VPN-сервера без клонування його ідентичності

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

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

Спершу вирішіть, яку з двох операцій ви виконуєте

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

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

Тож перше рішення — це речення, записане до того, як образ покине складальний хост: ця копія відновлює шлюз A або ця копія стає шлюзом B. Усе подальше — це облік щодо цього речення. Якщо ніхто не може його написати, копія не готова до збирання.

Багаторазові вхідні дані, ідентичність і повноваження, стан розгортання

Кошик багаторазового використання — найпростіший: пакети, перевірена конфігурація без секретів, шаблони служб, налаштування зміцнення. Саме в цьому образ справді хороший, і його можна відтворювати без обмежень.

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

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

Що має отримати новий вузол і від кого

Вузол, яким керують незалежно, має отримувати власні облікові дані через затверджений процес реєстрації, а операція підпису має відбуватися там, де живе ключ підпису, а не на новому хості. Запишіть, яку ідентичність можна відкликати, не заважаючи іншим вузлам; якщо відповідь «усі», то в проєкті одна ідентичність видає себе за дві.

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

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

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

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

Що копія образу тихо несе із собою

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

Перевіряйте вміст образу та вхідні дані розгортання як два окремі питання. Образ відповідає на «що всередині цього артефакту», а вхідні дані — на «чим стане цей екземпляр під час першого завантаження». Чистий образ зі скриптом початкового завантаження, що приносить спільний ключ, добре відповідає на перше питання і погано на друге.

Тримайте образи відновлення, які законно містять секрети, обмеженими для тих, кому вони потрібні, і записуйте, де вони зберігаються. Альтернатива — образ, зручний тим, що працює без жодного розгортання, — це той самий образ, що дає будь-кому, хто його знайде, ідентичність шлюзу. Лише одне з цих двох завдань з'являється в журналі збирання.

Перевірки допуску перед виробництвом

Перш ніж вузол прийме трафік, підтвердьте чотири речі: ідентичність, яку він пред'являє, клієнтів, яких він прийме, ресурси, до яких йому дозволено дістатися, і зворотний шлях для адрес, які він роздає.

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

Потім перевірте негативний випадок, який якраз і ловить аварії: чи має новий вузол адміністративний або клієнтський доступ, призначений для оригіналу? Скопійована конфігурація може нести зайвий запис клієнта, успадкований маршрут керування або директиву push, що мала сенс на першому хості.

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