how/cicd

OIDC: GitHub Actions в AWS без долгоживущих ключей

Workflow получает короткий JWT от GitHub, обменивает его на временные STS-creds, запускает Terraform - и через час всё это просто исчезает. Никаких access-key секретов.

Стандартный способ дать CI доступ к AWS - это положить AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY в GitHub Secrets. И это плохо по нескольким причинам:

ключи живут годами и почти никогда не ротируются;
они IAM-user'а с админ-правами (часто);
утечка одного access key = вход в AWS как root этого юзера;
логи action'ов могут случайно их вывести, особенно через кривой third-party action.

OIDC заменяет эту схему на короткоживущий обмен. Идея: GitHub умеет выпускать JWT с информацией о репозитории, ветке и workflow. AWS умеет верить этому JWT (если ты настроил доверие) и возвращать временные credentials. Все секреты живут не дольше одного запуска CI.

Жми ▶ - пошагово.

step 1/6·00 · классика: ключи в GitHub Secrets

§ шаги

IAM user tf-ci создан в AWS, у него есть access key, ключ скопирован в GitHub Secrets. В workflow:
yaml
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
Терраформ подхватит их и пойдёт работать с AWS. Это работает. И это проблема:
- ключ живёт годами. Если он утёк год назад через лог-action - никто этого не знает, но злоумышленник уже внутри.
- ротация - отдельный процесс с человеком в loop'е. Обычно никто её не делает.
- user'у обычно дают широкие права, потому что лень разбираться, что именно нужно Terraform'у.
Поэтому в продакшне эта схема считается legacy.

итого

Что важно запомнить:

audience в trust-policy - это sts.amazonaws.com. GitHub подписывает JWT этим audience. AWS проверяет совпадение - если в JWT другой audience, отказ.
sub в JWT содержит строку вида repo:my-org/my-repo:ref:refs/heads/main. Trust policy в IAM role обычно ограничивает: «только этот repo и только эта ветка». Так PR из форка не получит доступ.
AWS возвращает STS temp credentials с TTL до 12 часов (по умолчанию час, ограничено максимумом role'а). После TTL они не работают. Никакой ротации с твоей стороны.
Permissions IAM-role'а должны быть узкими: ровно то, что Terraform-проект меняет. Никакого AdministratorAccess - если CI скомпрометирован, blast-radius ограничен этой ролью.
Тот же pattern работает с GCP (Workload Identity Federation), Azure (Workload Identity), HashiCorp Vault (JWT auth). GitHub OIDC - стандарт OpenID Connect, не AWS-specific.
Перейти со старой схемы на OIDC можно постепенно: настроить новую роль, поменять workflow, удалить access keys после первого успешного прогона. Никакого «всё или ничего».

Дальше: tf-policy-gate про то, как ещё больше сузить безопасность через policy-engine между plan и apply.

§ копнуть в базу знаний

§ попробовать руками

§ шаги

IAM user tf-ci создан в AWS, у него есть access key, ключ скопирован в GitHub Secrets. В workflow:

yaml

env:

  AWS_ACCESS_KEY_ID:     ${{ secrets.AWS_ACCESS_KEY_ID }}

  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Терраформ подхватит их и пойдёт работать с AWS. Это работает. И это проблема:

ключ живёт годами. Если он утёк год назад через лог-action - никто этого не знает, но злоумышленник уже внутри.
ротация - отдельный процесс с человеком в loop'е. Обычно никто её не делает.
user'у обычно дают широкие права, потому что лень разбираться, что именно нужно Terraform'у.

Поэтому в продакшне эта схема считается legacy.