Міграція GCP-проєктів і service accounts без даунтайму звучить як заголовок слайда — рівно до тієї миті, поки аудит не опиняється в тебе в руках. Першого дня я відкрив інвентаризацію service accounts і нарахував 99 акаунтів на вісім проєктів. Більшість жодного разу не переглядали. У декого висів owner-доступ, виданий роками раніше людьми, яких давно немає в компанії. І ніхто в кімнаті не міг сказати, які з них ще живі.
Це була легка частина.
Справжнє завдання: перенести вісім GCP-проєктів зі старого тенанта в керований, між двома організаціями, не зламавши жодного деплою. Dev-команда викочувала по кілька разів на день і обожнювала свою автономію. Керівництву потрібні були governance, комплаєнс, стандарти іменування й контроль білінгу. Моя робота — дати і те, і те, і при цьому не стати для розробників ворогом.
Що нам дісталося
Старий тенант — це те, на що перетворюється платформа, коли росте швидше, ніж хтось встигає її описувати:
- 99 service accounts, більшість без аудиту і з зайвими правами
- owner-ролі, що лишилися від разових задач багаторічної давнини
- ані naming conventions, ані org policies
- проєкти, розкидані по теках без зрозумілого власника
- міжпроєктні мережеві залежності та MySQL-тунелі, яких ніхто не задокументував
Розробникам так подобалося, бо автономія відчувалася як швидкість. Керівництво бачило неперевірену поверхню атаки з дедлайном по комплаєнсу. Мали рацію обидві сторони.
Поетапний підхід: спершу мінімальний радіус ураження
Я не намагався перенести все за один раз. Почав із dev-проєкту. Мінімальний радіус ураження. Якщо шлях міграції виявиться кривим, хай це спливе тут, а не в проді.
Спрацювало — і план затвердів у фази:
- Dev-проєкт, щоб перевірити шлях міграції від початку до кінця.
- П'ять production-ворклоадів з cross-domain доступами, MySQL-тунелями й недокументованими мережевими залежностями.
- Шар аналітики й дашбордів, де жила вся звітність.
- Онбординг усього в захищений тенант зі строгими org policies, стандартами іменування й повним комплаєнсом.
Кожна фаза давала урок, який я застосовував у наступній. На момент переїзду проду я вже знав, де гострі кути.
Найнервовіше: хірургічний IAM hardening
Вичистити 99 service accounts, не зламавши прод, — це та робота, через яку лишаєшся за клавіатурою за північ. Кожен акаунт міг щось зронити, а карти не було.
Тому кожен я розбирав як маленьке розслідування, перш ніж до нього торкнутися:
- якісь існували заради сервісів, виведених з експлуатації два роки тому;
- у якихось були права на проєкти, яких уже не існувало;
- якісь активно смикалися пайплайнами, що запускалися щогодини.
Правило я собі задав просте: спершу зрозуміти, що акаунт реально робить, і лише потім щось прибирати. Не вгадувати, а right-size. Одне хибно відкликане право — і продовий тенант гасне. Service accounts — це тиха поверхня атаки, про яку не думають, поки аудит не змусить. А в цього аудиту були зуби.
CI/CD: автономія з guardrails
Команду, що деплоїть по кілька разів на день, не можна гальмувати, тому pipeline мав давати розробникам автономію і водночас за замовчуванням вмикати security-guardrails. Весь фокус — зробити так, щоб безпечний шлях був найпростішим.
Швидкість розробники зберегли. Просто перестали котити через кустарні скрипти й почали — через стандартизовані пайплайни, всередині яких уже зашиті guardrails. Нікому не треба пам'ятати про комплаєнс, бо пайплайн уже комплаєнтний сам.
Мережа, яку ніхто не описав
Найнепоказніший ризик — мережа. Міжпроєктні залежності, спільна зв'язність і MySQL-тунелі мали пережити переїзд цілими. Саме це ніде не записано й виявляється лише трасуванням — хто з ким насправді розмовляє. І кожен такий зв'язок мусив продовжити працювати тієї ж секунди, щойно проєкт приземлявся в новому тенанті.
Результат
Вісім проєктів перенесено. Нуль даунтайму. Частота деплоїв не змінилася. Команда так само котить по кілька разів на день — тільки тепер через керовані пайплайни. 99 service accounts перетворилися на right-sized, задокументований і policy-compliant набір, а вся платформа живе в тенанті, який проходить аудит, а не боїться його.
Governance без тертя
Ось висновок, до якого я повертаюся знову і знову. Governance, що гальмує команди, — це не governance. Це бюрократія з бейджиком комплаєнсу. На глобальному масштабі виживає лише той governance, якого розробники майже не помічають, бо безпечний шлях у них же й найшвидший.
Дев'яносто дев'ять service accounts — і жодна людина не могла пояснити, що робить бодай половина з них. Якщо це звучить знайомо, то осиротілі акаунти, що просто зараз лежать у ваших проєктах, не чекають зручного моменту. Вони чекають на ваш наступний аудит.