GCP Secret Manager: повний посібник з керування секретами

GCP Secret Manager: коли секрети живуть у коді

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

Частина значень при цьому дублюється: одне й те саме змінюють у трьох файлах і забувають про четвертий.

Ціна такої картини проявляється не одразу.

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

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

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

GCP Secret Manager закриває цю прогалину: значення зберігаються централізовано, видаються за правами, версіонуються й потрапляють у журнал звернень. Нижче розбираємо, як це влаштовано і що змінюється в щоденній роботі.

Що дає централізоване зберігання секретів

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

Централізоване зберігання секретів зводить усе до одного джерела: сервіс читає значення за посиланням у момент запуску й не зберігає його в себе.

Google Cloud Secret Manager видає секрет за іменем, а доступ регулюється не файлом, а прив'язкою прав облікового запису.

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

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

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

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

Варіанти організації доступу: порівняння підходів

Спосіб доставлення секрету в застосунок зазвичай обирають за інерцією: що було під рукою на старті, те й залишається в продакшені.

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

Кероване сховище на кшталт GCP Secret Manager закриває версіонування, права на рівні сервісного акаунта й аудит звернень — але тільки якщо застосунок уміє читати значення під час роботи, а не на етапі збірки образу.

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

Тоді ротація не потребує перезапуску сервісу, а змінна, що витекла, перестає бути проблемою за кілька хвилин.

Етапи впровадження: від аудиту до передачі

Роботу ведемо етапами, бо секрети — це доступи до продуктивного середовища, і тут немає місця підходу «спочатку спробуємо, потім подивимося».

Порядок вибудовано так, щоб на кожному кроці була точка відкату: спочатку повна картина, потім модель доступу і лише після цього зміни в проді. Нижче — послідовність, за якою впроваджуємо GCP Secret Manager.

1. Інвентаризація секретів: збираємо всі місця, де зараз лежать ключі, — конфігураційні файли, змінні середовища, репозиторії, листування та нотатки інженерів. На виході реєстр із власником, призначенням, строком життя та критичністю кожного запису.
2. Проєктування політик доступу: розмічаємо, кому і на що потрібні права, розводимо читання й адміністрування, прив'язуємо доступ до сервісних облікових записів, а не до людей. Окремо фіксуємо, хто може створювати нові версії та видаляти старі.
3. Планування міграції: переносимо секрети партіями за сервісами, з подвійним читанням на перехідний період, щоб застосунок підхоплював значення з нового сховища й не залежав від старого джерела.
4. Налаштування ротації: задаємо період зміни значень і правила зберігання попередніх версій — планова ротація не повинна ламати працюючий сервіс і зобов'язана залишати вікно для відкату.
5. Перевірка ротації відмовою: змінюємо значення на живому стенді й дивимося, чи підхопилося воно без ручного втручання. Окремо перевіряємо поведінку сервісу за тимчасово недоступного сховища.
6. Передача в експлуатацію: віддаємо реєстр секретів, схему доступу, розклад ротації та порядок дій під час інциденту. Фіксуємо відповідальних і точку, куди звертатися за зміни контуру.

Комплект документації, схем і регламентів

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

• Опис сховищ і секретів — призначення, власник, середовище, споживачі. Видно, що тримає прод, а що можна чистити без ризику.
• Матриця ролей — таблиця «роль / що читає / що змінює / хто видає доступ»: сервісні облікові записи отримують читання лише свого секрету.
• Схема доступу сервісів — як застосунок отримує значення, де перевіряються права, що відбувається під час відкликання, з позначеними точками відмови.
• Регламент ротації — періодичність, порядок перемикання «спочатку новий, потім відкликання старого», відповідальний і спосіб перевірити, що споживачі підхопили значення.
• Процедура аварійного відкликання — покроковий порядок під час витоку: що блокувати першим, як перевипустити й переконатися, що старі значення більше не працюють.
• Інструкція з підключення нового сервісу — як завести секрет і видати доступ за матрицею, не читаючи внутрішнє листування.
• Аудит і спостереження — які записи журналу дивитися, щоб помітити зайві читання або доступ поза регламентом.

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

Кейс: ротація ключів доступу без зупинки сервісів

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

Ротація одного ключа займала 3–4 дні: інженер змінював значення, перезапускав застосунки по черзі й обходив команди, щоб ніхто не забув оновити локальний файл. За квартал накопичилося 14 чинних ключів, власники яких уже не працювали в проєкті.

Що змінили

Секрети перенесли в GCP Secret Manager і перевели застосунки на читання значення під час старту з періодичним оновленням із сховища — перезапуск для зміни ключа більше не потрібен.

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

Результат

Попередня версія секрету залишається доступною, тому відкат у разі збою — це перемикання посилання, а не відновлення з резервної копії. Журнали доступу показують, який застосунок і коли читав секрет, — розбір інциденту перестав упиратися в опитування команди.

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

Чим відрізняється кероване сховище від змінних середовища?

Змінні середовища — це знімок конфігурації на момент старту процесу: значення потрапляє в опис пода, у дамп пам'яті та в логи налагодження. Поки стенд один і секрет один, це непомітно.

Щойно стендів три, а доступ до бази потрібен чотирьом сервісам, відмінності проявляються за чотирма осями.

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

Журнал читань закриває розслідування: видно, який сервіс і під яким обліковим записом брав секрет — з маніфестів це не відновити.

При цьому змінні середовища не погані самі по собі: адресу сервісу простіше тримати в маніфесті, а у сховище — Secret Manager або аналог — виносити лише те, що дає доступ до даних.

Технічні сумніви: ізоляція, відкликання, аудит

Сумніви щодо ізоляції та відкликання спливають не на старті, а коли секретами користуються кілька команд і середовищ одночасно. Нижче — відповіді на чотири питання, які ставлять найчастіше, перш ніж перенести в Secret Manager робочі ключі.

Хто бачить вміст і чи можна шифрувати власними ключами?

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

Що потрапляє в журнал доступу?

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

Як бути з резервним копіюванням і відкатом?

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

Обговоримо вашу задачу: з чого почати

Щоб оцінка була предметною, а не «плюс-мінус квартал», перша розмова починається з розбору поточної схеми. Нам достатньо опису того, як секрети живуть зараз: де лежать ключі до баз, платіжних і зовнішніх сервісів, хто їх читає і що відбувається під час зміни.

Так ми розуміємо обсяг робіт із перенесення в GCP Secret Manager і повертаємося з планом та оцінкою строків у робочих днях.

Що надіслати до зустрічі:

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

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

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

Строки надходять із розбивкою за етапами — видно, що займають наші інженери, а що залежить від вашої команди.