Де розривається ізоляція тенантів у спільному кластері
Ізоляція в спільному кластері частіше декларативна, ніж реальна.
Простір імен розводить імена об'єктів і права на них, але не мережу, не диски й не бази: доки не увімкнено мережеві політики, поди одного клієнта спокійно звертаються до сервісів іншого, а сервісні облікові записи за замовчуванням отримують більше прав, ніж потрібно сервісу.
Найдорожча точка відмови — дані. Спільна база з ознакою орендаря в рядках тримається на одній умові: кожен запит фільтрує за цією ознакою.
Один незакритий звіт, один спільний кеш без префікса орендаря або один змонтований том із сусіднього простору імен — і клієнт бачить чужі записи. Витік розкривається не одразу, а під час розбору інциденту.
Конфлікт ресурсів виглядає інакше. Без квот і обмежень пакетне вивантаження або переіндексація з'їдає дискові операції та мережу на вузлі; сусідні сервіси починають віддавати помилки за тайм-аутами, а планувальник під тиском витісняє поди не того, хто шумить. Винуватець продовжує працювати, страждають інші.
Окремо рвуться межі середовищ. Тестовий контур у тому самому кластері зі спільним балансувальником, чергами та сховищем секретів означає, що прогон міграцій на стенді проходить по робочій базі. Далі розбираємо, як це закривається — за рівнями мережі, доступу та даних.
Що змінюється після розділення середовищ: ефект у показниках
Ізоляція будується на трьох рівнях: окремий namespace з квотами за процесором і пам'яттю, мережеві політики із забороною за замовчуванням і виділена схема або інстанс бази в кожного тенанта.
Kubernetes дає для цього готові примітиви, тому межі описуються декларативно й відтворюються без ручних правок.
Перший наслідок видно на старті проєкту: середовище під нового клієнта розгортається із шаблону разом із квотами, мережевими правилами та міграціями бази.
Час виведення клієнта скорочується з днів ручного клонування до десятків хвилин, і він більше не зростає разом із кількістю тенантів.
Другий — час відновлення. Збій локалізовано в одному namespace, тому відкат образу або накат резервної копії бази стосується лише постраждалого контуру. Відновлення вимірюється хвилинами й не залежить від того, скільки клієнтів живе поруч.
Третій — частка інцидентів із впливом на сусідів. Квоти зрізають сплеск споживання, а політики не пропускають трафік між тенантами: «галасливий сусід» перестає ронити спільний вузол.
Заодно зникає цілий клас відмов — конфлікт версій схеми під час міграції та доступ до чужої таблиці через спільне з'єднання.
Четвертий — передбачуваність релізів. Викочування йде за тенантами: помилку видно на одному контурі, інші залишаються на попередній версії, і графік випуску більше не залежить від чужого.
Варіанти ізоляції тенантів: спільні простори чи окремі контури
Ізоляція тенантів — не бінарний вибір між «усе в одному» та «окрема інфраструктура на кожного». Між цими крайнощами є робочі рівні, і різниця між ними в тому, що саме розділяється: об'єкти, мережа, база даних чи контур повністю. Нижче — три варіанти, між якими реально вибирають на старті проєкту.
Найлегший рівень — простори імен у Kubernetes: вони розділяють об'єкти, але не мережу й не базу даних, тому їх обов'язково доповнюють політиками доступу та окремими обліковими записами. Така схема тримає десятки невеликих тенантів, доки до розділення не висувають формальних вимог.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Спільні простори імен | десятки невеликих тенантів в одному контурі, вимоги до розділення формальні | ліміти ресурсів і політики доступу налаштовуються вручну, помилка в правилах відкриває доступ до чужих даних, а активний сусід забирає ресурси |
| Змішана схема | частина тенантів потребує посиленої ізоляції, частина — ні | два набори шаблонів і регламентів: підтримка дорожча, аудит ведеться окремо |
| Виділений контур | регульовані дані, великі замовники, окремі вимоги до мережі та бази | вища вартість експлуатації: оновлення та резервне копіювання тиражуються на кожен контур |
На практиці змішана схема частіше виявляється робочим станом, а не компромісом: ядро живе в спільному контурі під жорсткими політиками, чутливі тенанти виносимо в окремі групи просторів із власними лімітами.
Перехід між рівнями проєктуємо заздалегідь — тоді винесення тенанта у виділений контур стає плановою операцією, а не переписуванням інфраструктури.
Порядок впровадження: від аудиту до передачі в експлуатацію
Порядок робіт вибудувано так, щоб ізоляція з'являлася на живій системі без зупинки продукту. Спочатку фіксуємо поточний стан, потім проєктуємо цільову схему й перевіряємо її на стенді — робочі навантаження переносимо лише після цього. Кожен етап завершується артефактом, який можна перевірити й передати далі.
- Аудит конфігурації. Знімаємо фактичний стан: які простори імен існують, хто до них підключений, де перетинаються мережеві політики й як сервіси ходять до баз. На виході — перелік розбіжностей між документацією та реальністю.
- Карта залежностей. Розмічаємо зв'язки між сервісами, спільними сховищами та зовнішніми системами. Вона показує, що не можна розділити напряму й де потрібен проміжний шар доступу.
- Проєкт схеми ізоляції. Задаємо межі тенантів на трьох рівнях: простори імен для обчислень, мережеві політики для трафіку, окремі схеми й облікові записи для даних.
- Пілотний стенд. Збираємо копію контуру на обмеженому наборі сервісів і прогоняємо негативні сценарії: доступ із чужого простору імен, спільний том, перевикористаний секрет.
- План міграції. Розбиваємо перенесення на хвилі за зв'язністю сервісів, для кожної задаємо порядок, точку відкату й вікно робіт. Хвиля не стартує, доки попередня не пройшла перевірку.
- Приймання та передача. Прогоняємо узгоджений набір перевірок, фіксуємо результат і передаємо схему черговій зміні разом із регламентами та розбором типових інцидентів.
Після передачі залишається не лише робоча ізоляція, а й документація: карта залежностей, політики доступу, порядок підключення нового тенанта. Чергова зміна знає, що робити в разі спроби перетину меж, а зміни проходять через той самий процес, що й перший запуск.
Що залишається у команди: конфігурації, схеми та регламенти
Передаємо не «доступ до панелі», а робочий комплект, за яким ваша команда сама підніме нового орендаря, розбере інцидент і поверне систему у відомий стан.
Кожен пункт перевіряємо на живому контурі разом із вашими інженерами — на прийманні видно, чи працює документ чи написаний для звіту.
- Шаблони розгортання — параметризовані описи стенда: змінні на орендаря, квоти, окремий контур, спільні сервіси. Новий клієнт піднімається зміною параметрів, без правок логіки.
- Опис схеми розділення — карта меж: де проходять простори імен, мережеві політики й окремі бази, які ресурси свідомо спільні та чому це не створює перетинів.
- Політики доступу — ролі й права за кожною зоною, порядок видачі та відкликання, зберігання й ротація секретів, правило «доступ за заявкою з обґрунтуванням».
- Інструкції черговій зміні — типові сценарії: як переконатися, що дані орендарів не перетинаються, що дивитися при скарзі на чужі дані, кому ескалювати й у який строк.
- Порядок відкату — точки повернення, склад відкатуваного (схема даних, політики, конфігурації), послідовність кроків і перевірка після відновлення.
- Регламент змін — як правка в спільній частині проходить погодження, які перевірки обов'язкові до викочування й хто відповідає за регрес.
Усе лежить у репозиторії поруч із кодом, версіонується й змінюється тією самою зміною, що й конфігурація. Інакше за пів року інструкція розійдеться з фактичним станом — і черговий ухвалює рішення за застарілою схемою.
Як це виглядало на практиці: розділення середовищ зі спільними базами
Замовник — платформа з кількома напрямами — тримав усі середовища в одному кластері PostgreSQL: спільна база, спільний пул з'єднань і один обліковий запис із доступом і до бойових даних, і до тестових контурів.
Тривала міграція одного напряму блокувала таблиці, які читали інші, а помилка в тестовому середовищі доїжджала до реальних даних. Виправлення коштувало годин простою всього кластера.
Розділення почали з доступу, а не з копіювання даних: кожному напряму — свої схеми й роль із правами лише на них, застосункам — окремі рядки підключення замість спільного пулу. Перенесення йшло за планом — спочатку некритичні контури, потім читання, потім запис.
Схема на кожному кроці залишалася зворотно сумісною, тому старий і новий код працювали паралельно, без зупинки сервісів.
Що показали метрики
Перехресних звернень до чужої бази — із сотень на добу до нуля. Час відновлення після помилки розгортання скоротився з кількох годин до десятка хвилин: відкочується лише середовище одного напряму. Блокування таблиць між командами зникли — міграції більше не чекають чужих релізів.
Нове середовище перестало бути окремим проєктом: раніше під нього піднімали копію кластера, тепер — базу за хвилини. Обсяг резервних копій при цьому не зріс, а відновлення одного середовища не вимагає розгортати все повністю.
Чим мережеве обмеження відрізняється від розмежування прав у базі?
Мережеві правила відповідають на питання, хто з ким може з'єднуватися: вони дозволяють або блокують трафік між контурами тенантів та їхніми сервісами. Але всередині дозволеного маршруту вони не бачать, чиї дані в запиті, — правило пропускає будь-яке звернення, яке дійшло до бази.
Права на рівні даних працюють зі змістом. Ролі й доступи обмежують, які таблиці та операції доступні сервісу, а фільтрація рядків за ідентифікатором тенанта не дає повернути чужі записи навіть за коректного з'єднання.
Роль видається не абстрактному користувачу, а конкретному сервісу в конкретному контурі — тоді помилка в одному обробнику не перетворюється на вивантаження всієї бази.
| Рівень захисту | Що закриває | Де не допомагає |
|---|---|---|
| Мережевий контур | З'єднання між контурами тенантів | Не розрізняє запити всередині дозволеного каналу |
| Ролі й доступи | Які операції доступні сервісу | Сервіс із правильними правами йде не до своїх даних |
| Права в базі | Фільтрація рядків і схем за тенантом | Не працює при спільному обліковому записі |
| Ключі шифрування | Читання чужих даних із копії | Не замінює перевірку прав |
Один рівень майже завжди протікає: мережа не зупинить запит без фільтра за тенантом, а права в базі не допоможуть, якщо сервіс підключений до спільного облікового запису.
Тому рівні захисту збирають у комбінацію заходів — окремий контур, свої ролі, фільтрація на рівні даних, окремі ключі шифрування. Кожну спробу вийти за межу перевіряємо тестом: звернення з чужого контуру має падати, а не тихо проходити.
Типові технічні сумніви перед стартом
Перед стартом виринають сумніви не про саму ізоляцію, а про сумісність із тим, що вже працює: спільна база, видані права, зростання парку середовищ і ціна зворотного переїзду. Нижче — відповіді на ті заперечення, які найчастіше гальмують рішення.
У нас одна база на всіх — дані реально розвести?
Розводимо не «в лоб»: спільний кластер, окрема схема й роль на тенанта, доступ лише через сервісний обліковий запис із прив'язкою до ідентифікатора тенанта. Тенантів із жорсткими вимогами виносимо на окремий вузол першими. Шар доступу до даних уже знає, чий це запит, — правки мінімальні.
Права вже видані широко — усе зламається?
Спочатку інвентаризація: хто й до чого реально звертається. Потім вузькі ролі та збір звернень, а старі вимикаємо, коли за ними не залишилося трафіку. Перетини закриваємо мережевою політикою — навіть за надлишкової ролі виклик між просторами імен не проходить.
Середовищ стає більше — керувати не стане складніше?
Навпаки: простори імен, мережеві політики, схеми й ролі описуються декларативно та розкочуються з одного шаблону. Нове середовище — це параметр, а не ручне складання, тому зростання кількості середовищ перестає бути джерелом розбіжностей.
Що як доведеться повернутися до попередньої схеми?
Зворотний шлях проєктуємо заздалегідь: ізоляція не видаляє дані, а змінює межі доступу. Повернення — це зняття політик і злиття схем зі збереженням ідентифікаторів, і ми перевіряємо його на копії до старту. Формат зберігання під час переїзду не змінюється — лише те, хто й як до нього звертається.
Обговоримо вашу задачу й повернемося з планом
Точність оцінки ізоляції тенантів залежить від вихідних даних: за описом «у двох словах» вийде вилка, де верхня межа вдвічі вища за нижню. Якщо надішлете вхідні зі списку нижче, повернемося з оцінкою обсягу робіт і планом етапів, а не з діапазоном навмання.
- карту поточного контуру: які сервіси де розгорнуті й як розділені середовища — розробка, приймальне, продуктивне;
- як ізоляція влаштована зараз: спільна база й спільна мережа, окремі простори імен на тенанта чи змішана схема;
- склад даних за тенантами та їхня чутливість: персональні, платіжні, регуляторні — від цього залежить жорсткість меж;
- профіль навантаження й зростання: скільки тенантів зараз, скільки очікується, де піки;
- обмеження на зміни: клієнтські інтеграції, релізний цикл, допустиме вікно простою;
- матрицю доступів: хто з вашої команди й зовнішніх підрядників залишається в контурі та з якими правами;
- історію інцидентів: чи були випадки взаємного впливу тенантів або витоків через спільний шар.
На дзвінку уточнюємо постановку задачі та межі довіри між тенантами, вимоги регулятора й критерії приймання — те, що в листуванні трактується двозначно. У відповідь віддаємо схему робіт: порядок етапів, зміст кожного, точки перевірки та спосіб фіксації результату.
Далі — старт співпраці: погоджуємо склад першої черги та ролі в команді, почнемо з обстеження контуру.
