OIDC в облако: короткоживущие токены вместо вечных AWS-ключей и пиннинг sub-клейма

Размен: хранимый ключ vs минченный токен

Старая модель хранит долгоживущий облачный кред в GitHub Secrets. У IAM access key нет истечения: он работает, пока кто-то вручную не ротирует или удалит. Если он утечёт — лог-дамп, скомпрометированный Action, скриншот — это стоячий кред с полными правами, что атакующий использует на досуге, и часто узнаёшь о нём от третьей стороны. Ротация ручная, так что на практике эти ключи живут годами.

OIDC инвертирует это. GitHub Actions запускает OIDC identity provider. В рантайме job может запросить подписанный JSON Web Token у GitHub, что утверждает факты о прогоне — какой репо, какой ref, какой воркфлоу, какое окружение — в своих клеймах. Job отдаёт этот JWT облачному token-сервису; облако проверяет подпись GitHub, сверяет клеймы с trust policy, что ты сконфигурировал, и возвращает короткоживущий кред. На AWS вызов — sts:AssumeRoleWithWebIdentity, и возвращаемые креды по дефолту валидны один час (настраивается, ограничено max session duration роли). Нигде не хранится секрет: JWT минтится свежим каждый прогон и бесполезен после истечения.

permissions:
  id-token: write     # ОБЯЗАТЕЛЬНО — даёт job запросить OIDC JWT
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@<запиненный-sha>
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
          aws-region: eu-central-1
          # нет aws-access-key-id / aws-secret-access-key — их не существует

Это право id-token: write — гейт: без него job не может запросить JWT, ровно поэтому ограничиваешь его лишь тем job, что деплоит.

Клейм, что решает всё: sub

Прежде чем писать trust policy (политику доверия роли), спроси себя: что именно проверяет облако? Если ответ — «подпись», у тебя открытая роль. Подпись доказывает лишь, что GitHub Actions сминтил токен — не какой из сотен миллионов репозиториев запустил прогон. Единственное условие, закрывающее эту брешь, — клейм sub.

GitHub подписывает JWT, так что облако знает, что он действительно от GitHub Actions. Но воркфлоу каждого репозитория GitHub получает токен, подписанный тем же эмитентом. Если твой AWS trust policy проверяет лишь «этот токен от OIDC-эмитента GitHub?», то воркфлоу любого пользователя GitHub может запросить твою роль и ассамить её. Контроль, что ограничивает доверие твоим репо, — клейм sub (subject), что кодирует личность прогона, и пинишь его в условии trust policy:

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
    }
  }
}

Строка sub — это замок. repo:my-org/my-repo:ref:refs/heads/main означает, что лишь тот репо, лишь на ветке main, может ассамить роль. Можно сузить ещё (:environment:production) или, для тег-релизов, :ref:refs/tags/*. Классический провал — слишком свободный паттерн: repo:my-org/* даёт любому репо в орг-е ассамить роль, а wildcard вроде repo:* (или полный пропуск условия sub) даёт GitHub Actions всего интернета ассамить её. Пинь и aud: дефолтная аудитория GitHub — сконфигурированное значение, и её проверка не даёт токену, минченному для другой relying party, быть переигранным на твоём STS.