GitHub Actions без AWS ключове: една грешна trust policy отваря чуждо хранилище

За да използвате AWS от GitHub Actions без съхранен access key, добавете GitHub като OIDC доставчик в IAM, създайте роля с ограничена trust policy и я поемайте чрез aws-actions/configure-aws-credentials. Инструкцията на GitHub за AWS OIDC описва обмена на токена от workflow за временни AWS удостоверения без дългоживеещи ключове в GitHub secrets.

Решаващото условие е `sub` в trust policy: то трябва да посочва разрешеното GitHub хранилище и неговия клон или environment. Ако шаблонът обхваща и чуждо хранилище, негов workflow може да поеме същата IAM роля. При права за Amazon S3 това му дава и достъпа до bucket, който ролята разрешава.

Създайте OIDC доставчика и ролята

В IAM регистрирайте доставчик от тип OpenID Connect с адрес https://token.actions.githubusercontent.com и audience sts.amazonaws.com. Създайте роля за Web identity и задайте като federated principal ARN на този доставчик във вашия AWS акаунт. При изпълнение на задачата GitHub издава OIDC токен, а AWS STS сравнява неговите данни с trust policy, преди да издаде временна сесия.

Разделете двете решения в IAM. Trust policy определя кой може да поеме ролята; прикачената permissions policy определя какво може да прави с нея. Ако задачата само качва обекти в определен S3 bucket, дайте ѝ необходимите S3 действия за този bucket и неговите обекти, вместо широки права върху всички ресурси. Успешното удостоверяване не означава, че достъпът до S3 е правилно ограничен.

Запишете точния subject в trust policy

Следващата политика е условен пример за GitHub хранилище primer-org/site-deploy, което издава subject с постоянни идентификатори, и за клон main. Числата и имената са примерни: заменете ги с ARN на своя доставчик и с действителната стойност на `sub` за своя workflow.

{"Version":"2012-10-17","Statement":[{"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","token.actions.githubusercontent.com:sub":"repo:primer-org@111111/site-deploy@222222:ref:refs/heads/main"}}}]}

`StringEquals` изисква точно съвпадение. Стойността на `aud` указва, че токенът е предназначен за AWS STS, а `sub` назовава хранилището и клона, от които ролята може да бъде поета. Част от хранилищата използват формат без идентификаторите след `@`: `repo:primer-org/site-deploy:ref:refs/heads/main`. Изберете формата, който вашето хранилище действително издава; иначе правилно ограничена на вид политика ще отказва заявките.

Постоянните идентификатори са важни и при преименуване на хранилище: те разграничават конкретния собственик и конкретното хранилище от бъдещи притежатели на същите имена. Не добавяйте `@` и примерни числа по предположение. Съпоставете цялата стойност на subject, включително префикса, клона и евентуалната среда.

Свържете workflow и проверете AWS самоличността

Workflow се нуждае от `id-token: write`, ARN на ролята и AWS регион. README на aws-actions/configure-aws-credentials показва входовете `role-to-assume` и `aws-region`, версия `v6.3.0` и командата `aws sts get-caller-identity`. Разрешението `id-token: write` позволява издаване на OIDC токен; само по себе си то не дава права за промени в AWS.

За условния пример създайте `.github/workflows/aws-identity.yml`. Поставете всеки от следващите YAML записи на отделен ред без отстъп; вложените стойности използват компактния flow синтаксис:

• name: AWS OIDC identity check
• on: {push: {branches: [main]}}
• permissions: {id-token: write}
• jobs: {verify: {runs-on: ubuntu-latest, steps: [{uses: aws-actions/[email protected], with: {role-to-assume: arn:aws:iam::123456789012:role/gh-deploy, aws-region: eu-central-1}}, {run: aws sts get-caller-identity}]}}

Заменете примерния ARN с ролята си и посочете използвания AWS регион. При успешно изпълнение `get-caller-identity` показва акаунта и ARN на поетата роля. Това е проверка на сесията, а не доказателство, че ролята има достъп само до предназначения S3 bucket; за него прегледайте и прикачените разрешения.

За отрицателна проверка в контролирано тестово хранилище разрешете временно стартиране и от тестов клон, без стъпка за качване към S3. Запазете `sub` в IAM само за `main` и изпълнете задачата от тестовия клон: поемането на ролята трябва да бъде отказано. Workflow, който се стартира единствено при push към `main`, не може сам да проведе тази проверка от друг клон.

При environment ограничете и клоновете за внедряване

Ако задачата задава `environment: production`, нейният обичаен subject назовава средата вместо `ref:refs/heads/main`. За условното хранилище с постоянни идентификатори това би било `repo:primer-org@111111/site-deploy@222222:environment:production`. Сменете стойността на `sub` в trust policy с реалната стойност за задачата; политиката за клона от предишния пример няма да съвпадне с токен за environment.

Условие за environment ограничава хранилището и средата, но не изброява клоновете, от които е разрешено внедряване. Ако само `main` трябва да достига до production, задайте и deployment branch правило за този GitHub environment. Когато средата допуска друг клон, неговата задача може да получи същия environment subject и да отговори на условието в IAM. Затова защитата на средата е част от конфигурацията на достъпа, а не заместител на точния `sub`.

Широкият wildcard променя кой може да поеме ролята

Указанията на AWS IAM изискват условие за `sub` при GitHub OIDC роля и отхвърлят липсваща или съставена само от wildcard знаци стойност. Това не прави всеки останал шаблон безопасен. Например `StringLike` със стойност `repo:primer-org/*` допуска и други хранилища в организацията, а `repo:primer-org/site-deploy:*` разширява достъпа до различни клонове и среди в същото хранилище.

Шаблон като `repo:*` е още по-широк: той не назовава контролирана организация или хранилище. Ако IAM го приема и ролята разрешава операции с S3 bucket, workflow от чуждо GitHub хранилище с подходящ OIDC токен може да поиска тази роля и нейните права. Точният обхват на достъпа зависи от ефективните разрешения на ролята и от приложимите политики за ресурса.

При намерение само един клон да използва ролята задайте точно `StringEquals` условие за неговия subject. При работа с environment съчетайте точния subject на средата с нейните правила за deployment branches. Така успешният `get-caller-identity` проверява предвидения достъп, а отказът от тестов клон проверява границата, която прекалено широкият wildcard би премахнал.

Прочетете също:

• SPF, DKIM и DMARC: една грешна политика може да спре истинската поща
• GitHub Actions или GitLab CI: macOS може да обърне сметката
• AWS, Azure или Google Cloud: най-големият кредит не е най-достъпният