Cloud IAM — это система Google Cloud, которая отвечает на один вопрос: «кто и что может делать». Хотите прочитать файл из хранилища, запустить машину, отправить сообщение в тему — каждый раз GCP сверяется: а разрешено ли вам это.

Звучит как скучная бюрократия, но именно тут происходит большинство аварий в облаке. Чаще всего ломают не сложным взломом, а потому что кому-то выдали слишком много прав или JSON-ключ сервисного аккаунта попал в открытый репозиторий. Полчаса на понимание IAM выгоднее, чем потом разбирать инцидент.

Пользователи против сервисных аккаунтов

Первое различие, в котором путаются новички, — кому вообще выдают доступ.

Пользователь — это человек: аккаунт Google или корпоративная учётка через federation. Люди заходят в консоль, что-то настраивают, смотрят.

Сервисный аккаунт (service account) — учётная запись для программ и виртуальных машин, а не для человека. Её задача — дать доступ вашему коду. Аналог роли, которую «надевает» сервис, в AWS.

Ключевое правило: для программ, серверов и автоматизации используют сервисные аккаунты, а не личные учётки.

Роли и привязки

В Cloud IAM права выдаются через пару «роль + привязка».

Роль (role) — набор разрешений. Есть три уровня зрелости:

  • примитивные — Owner, Editor, Viewer на весь проект (широкие, для практики почти всегда слишком грубые);
  • предопределённые (predefined) — узкие сервисные роли вида roles/storage.objectAdmin (объекты в хранилище), roles/cloudsql.client (подключение к базе), roles/pubsub.publisher (публикация в тему). Это то, что нужно на практике;
  • пользовательские (custom) — свой набор разрешений, когда предопределённых не хватает.

Привязка (binding) — назначение «кому — какую роль — на каком ресурсе». Роль выдают на организацию, папку, проект или отдельный ресурс, и права наследуются вниз: роль на проект действует на все ресурсы внутри него. Обычно доступ выдают на уровне проекта.

gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:orders-app@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

Доступ без ключей: metadata и Workload Identity

Главное правило: ваш код не должен носить с собой ключи. Как приложение получает доступ, зависит от того, где оно работает:

  • На виртуальной машине Compute Engine к ней привязывают сервисный аккаунт, и приложение получает временный токен прямо из сервера метаданных — без секретов в коде. Библиотеки Google находят его автоматически.
  • В GKE используют Workload Identity — механизм, который связывает Kubernetes ServiceAccount с сервисным аккаунтом GCP, и под получает временный токен по той же модели.
  • Извне облака (например, из CI не в GCP) раньше использовали JSON-ключ сервисного аккаунта — но это долгоживущий секрет и главный источник утечек. Современный способ — Workload Identity Federation: внешняя система (GitHub Actions, другой облачный провайдер) обменивает своё удостоверение на временный токен GCP без вечного ключа. Если ключ всё же нужен, его держат в защищённом хранилище, а не в git, и ротируют.

Правило: внутри облака — привязанный сервисный аккаунт и метаданные; federation вместо JSON-ключа; сам ключ — только там, где иначе никак.

Least privilege — минимум прав

Главный принцип всей безопасности: давать ровно столько прав, сколько нужно, и ни ролью больше.

Самый частый дефект новичка — выдать сервисному аккаунту Editor на весь проект «чтобы просто заработало». Так делают, чтобы не возиться, — и именно это потом превращается в инцидент: одна утёкшая учётка открывает весь проект.

На практике least privilege — итеративный процесс: начните узко (только нужные предопределённые роли), запустите, посмотрите по отказам, чего не хватает, добавьте недостающую роль. Инструмент рекомендаций (IAM Recommender) подсказывает, какие выданные права реально не используются, — их стоит убирать.

Где это применяется

Cloud IAM — это слой «кто что может делать» поверх сетевого слоя «кто до кого вообще может достучаться». Вместе они дают полноценную защиту: минимальная сеть плюс минимальные права.

Где вы столкнётесь с IAM сразу:

  • Любой ваш сервис (виртуальные машины, функции, контейнеры) получает доступ через привязанный сервисный аккаунт.
  • Конвейеры доставки кода работают через Workload Identity Federation, а не через зашитые JSON-ключи.
  • Секреты и шифрование — соседняя тема: где хранить пароли, в безопасности и наблюдаемости.

Типичные ошибки новичков:

  • Класть JSON-ключ сервисного аккаунта в код или git вместо привязки аккаунта к машине.
  • Выдавать Editor/Owner широко «чтобы заработало», а потом забыть сузить до предопределённых ролей.
  • Плодить JSON-ключи там, где работает Workload Identity Federation.

Что учить дальше: где хранят секреты и как шифруют данные — в безопасности и наблюдаемости; как роли описываются в инфраструктуре-как-коде — в Terraform. Модель близка к IAM в AWS — роли и временные токены вместо вечных ключей устроены аналогично.