IAM

Cloud IAM определяет, кто что может делать с какими ресурсами. FullStack JS-команды сталкиваются с IAM, когда CI деплоит в AWS/GCP/Azure, когда Lambda или Cloud Run вызывают S3 или Pub/Sub, и когда люди заходят в консоли через SSO. Сильный дизайн разделяет human и workload identities и даёт least privilege через scoped roles.

| Принцип | Практика | |---------|----------| | Least privilege | Узкие policies на сервис и окружение | | Short-lived creds | OIDC из GitHub Actions, не долгие keys | | Separation | Dev-роли не меняют production data | | Audit | CloudTrail / audit logs на смену policies |

Предпочитайте role assumption и managed identities вместо access keys в `.env` или слоях Docker. Ротируйте секреты и проверяйте wildcard `*` в policies runtime-сервисов.

На интервью: human vs workload identity, OIDC federation для CI, permission boundaries, break-glass admin и риски слишком широких S3 или DynamoDB policies.

Типовые ошибки: общие admin keys в CI; одна mega-role на все microservices; IAM user keys во frontend-репозиториях; отсутствие тестов deny-сценариев и recovery при lock-out.

Компромисс — трение деплоя (много мелких roles) против blast radius при утечке credentials или компрометации сервиса.

Чеклист:

• Workload roles на каждый deploy target и сервис.
• CI через OIDC federation без static keys.
• Регулярный review policies; убирайте wildcards.
• Логи и алерты на privilege escalation.