advanced

IAM

Назначайте права через projects, service accounts, roles, workload identity и organization policies с least privilege.

GCP IAM задаёт, кто что может делать с ресурсом: identities, roles и policies. FullStack-командам важно разделить людей и workloads: инженеры — через группы и короткоживущие credentials, а Cloud Run, pod'ы GKE и CI — через отдельные service account с узкими custom roles.

| Identity | Типичное использование | |----------|------------------------| | User / group | Доступ инженеров через Google groups | | Service account | Runtime и automation | | Workload Identity | Pod Kubernetes → GCP API без JSON-ключей |

					gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:api-runner@my-project.iam.gserviceaccount.com" \
  --role="roles/cloudsql.client"

Берите predefined roles, где хватает; иначе — custom roles с least privilege. Аудит — Policy Analyzer и Cloud Audit Logs.

На интервью: ключи service account vs Workload Identity; least privilege; иерархия project/folder/org; conditional IAM; CI ломается от слишком широких ролей.

Типовые ошибки: JSON-ключи в репозитории или на ноутбуке; один «супер-admin» SA на все микросервисы; `Editor` вместо роли под задачу.

Компромисс — скорость от широких прав против blast radius, аудируемости и compliance.

Чеклист:

Без долгоживущих ключей в коде приложения.
Service account на workload с минимальными ролями.
Workload Identity в GKE, attached SA в Cloud Run.
IAM bindings — в code review как бизнес-логика.