Модуль 2.1: GCP Identity, IAM та ієрархія ресурсів

Складність: [MEDIUM] | Час на виконання: 2 год | Передумови: Cloud Native 101

Чому цей модуль важливий

У вересні 2020 року фінтех-компанія виявила, що все їхнє виробниче середовище Google Cloud було скомпрометоване. Причиною став не складний експлуатант чи вразливість нульового дня. Розробник “тимчасово” створив сервісний акаунт із правами власника проєкту (Project Owner) для відлагодження проблеми з Cloud Storage. Ключ цього акаунта потрапив у приватний репозиторій GitHub, який на короткий час став публічним. Автоматичні сканери вкрали ключ за лічені хвилини. Зловмисники викрали фінансові записи клієнтів та запустили майнінг криптовалюти у кількох регіонах. Збитки склали $2.3 мільйона.

Цей інцидент розкриває фундаментальну істину безпеки Google Cloud Platform (GCP): ієрархія ресурсів — це ваш радіус ураження, а IAM — це пульт керування всім. У GCP кожна дія — створення віртуальної машини, читання об’єкта зі сховища, деплой сервісу — проходить через IAM. Якщо ваш IAM налаштований погано, жодні інші заходи безпеки не допоможуть.

У цьому модулі ви дізнаєтеся, як GCP організовує ресурси в ієрархію (Організація, Папки та Проєкти), як політики IAM успадковуються і як налаштувати контроль доступу за принципом найменших привілеїв. Найголовніше — ви навчитеся правильно працювати із сервісними акаунтами, оскільки вони є головним вектором атак у хмарі.

Ієрархія ресурсів: Ваш організаційний креслення

Перш ніж зрозуміти IAM, треба зрозуміти, де живуть його політики. У GCP ресурси організовані в сувору ієрархію, і політики успадковуються зверху вниз. Це головна відмінність від AWS, де кожен акаунт здебільшого ізольований.

Чотири рівні:

Organization (Організація): Кореневий вузол. Створюється автоматично, коли ви підключаєте свій домен компанії. Політики, встановлені тут, діють на все всередині компанії.
Folders (Папки): Дозволяють групувати проєкти за командами або середовищами (напр., папка “Engineering” або “Production”).
Projects (Проєкти): Основна одиниця володіння ресурсами. Кожен ресурс (ВМ, база даних) належить рівно одному проєкту. Проєкт — це межа для білінгу та API.
Resources (Ресурси): Самі сервіси, які ви створюєте: віртуальні машини, бакети сховища, топіки Pub/Sub.

Принципали та Ролі IAM

Хто може діяти? (Principals)

В GCP ідентифікатором може бути:

Google Account: людина (user:alice@example.com).
Service Account: програма або віртуальна машина.
Google Group: група людей (рекомендовано для зручності управління).
Google Workspace Domain: усі користувачі організації.

Три типи ролей:

Basic Roles (Базові): Owner, Editor, Viewer. Це застарілі ролі. Вони занадто широкі (напр., Editor може видалити майже будь-яку базу даних) і не повинні використовуватися в продакшні.
Predefined Roles (Наперед визначені): Створюються Google для конкретних задач (напр., roles/storage.objectViewer — тільки читання файлів). Використовуйте їх щодня.
Custom Roles (Власні): Коли наперед визначені ролі не підходять, ви можете зібрати роль із конкретних дозволів самостійно.

Сервісні акаунти: Ідентичність машин

Сервісні акаунти (Service Accounts) — це “машинні користувачі”. Вони використовуються вашими додатками для доступу до API Google.

Критичне попередження: Стандартний сервісний акаунт Compute Engine автоматично отримує роль Editor. Це величезна діра в безпеці. Завжди створюйте власні сервісні акаунти з мінімальними правами для кожної задачі.

Типові помилки

Помилка	Чому це стається	Як виправити
Роль `Editor` для розробників	Здається зручним “девелоперським” рівнем	Використовуйте наперед визначені ролі для конкретних сервісів
Створення ключів (JSON)	Зовнішні інструменти просять файл ключа	Використовуйте Workload Identity Federation (для CI/CD) або імперсонацію
Права на рівні Організації	Щоб “усюди працювало”	Надавайте доступ на найнижчому можливому рівні (проєкт або ресурс)
Використання особистих пошт	Швидше додати колегу напряму	Створюйте Google Groups. Коли людина йде з компанії, ви просто видаляєте її з групи

Тест

1. Ви надали користувачу роль Storage Admin на рівні Організації. Потім ви спробували забрати це право в конкретному проєкті. Чи спрацює це?

Ні. Політики IAM в GCP є адитивними (додаються). Ви не можете забрати право на нижчому рівні, якщо воно надане на вищому. Для цього існують спеціальні Deny Policies або обмеження на рівні Організації.

2. Чому не варто використовувати стандартний сервісний акаунт Compute Engine?

Тому що за замовчуванням він має права Editor на весь проєкт. Будь-яка віртуальна машина з цим акаунтом зможе видаляти бази даних, міняти мережі та читати секрети.

Практична вправа: Створення сервісного акаунта

Створіть проєкт або оберіть існуючий.

Створіть сервісний акаунт через CLI:

gcloud iam service-accounts create my-data-sa --display-name="SA для роботи з даними"

Надайте йому роль тільки на читання Cloud Storage:

gcloud projects add-iam-binding PROJECT_ID \
  --member="serviceAccount:my-data-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

Перевірте права:
Terminal window
```
gcloud projects get-iam-policy PROJECT_ID
```

Наступний модуль

Переходьте до Модуля 2.2: Мережі VPC — ви дізнаєтеся, як працює глобальна мережа GCP, чим вона відрізняється від AWS та як налаштувати Shared VPC.