Миграция 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 — и ни один человек не мог объяснить, что делает хотя бы половина из них. Если это звучит знакомо, то осиротевшие аккаунты, что прямо сейчас лежат в ваших проектах, не ждут удобного момента. Они ждут вашего следующего аудита.