Зачем использовать OIDC с GitHub Actions?

от автора

Традиционно для доступа к AWS из GitHub Actions использовались постоянные ключи доступа, хранящиеся в секретах репозитория. Это не только неудобно, но и небезопасно. С OIDC GitHub Actions можно запрашивать временные токены, действительные только на время выполнения workflow, что значительно повышает безопасность и упрощает управление доступом.


🛠️ Настройка OIDC в AWS с помощью Terraform

1. Получение TLS-сертификата GitHub

Для настройки провайдера OIDC в AWS необходимо получить отпечаток TLS-сертификата GitHub:

data "tls_certificate" "github" {   url = "https://token.actions.githubusercontent.com/.well-known/openid-configuration" } 

2. Создание OIDC-провайдера в AWS

Используем полученный отпечаток для создания провайдера:

resource "aws_iam_openid_connect_provider" "github" {   url             = "https://token.actions.githubusercontent.com"   client_id_list  = ["sts.amazonaws.com"]   thumbprint_list = [data.tls_certificate.github.certificates[0].sha1_fingerprint] } 

3. Создание IAM роли с доверием к GitHub

Определим политику доверия, разрешающую GitHub Actions из конкретного репозитория и ветки использовать эту роль:

data "aws_iam_policy_document" "github_oidc_assume_role" {   statement {     actions = ["sts:AssumeRoleWithWebIdentity"]     principals {       type        = "Federated"       identifiers = [aws_iam_openid_connect_provider.github.arn]     }     condition {       test     = "StringLike"       variable = "token.actions.githubusercontent.com:sub"       values   = [         "repo:<your-org>/<your-repo>:pull_request",         "repo:<your-org>/<your-repo>:ref:refs/heads/main"       ]     }   } } 

Замените <your-org> и <your-repo> на ваши, либо определите через переменные. Обратите внимание, что дополнительно роль ограничена условием (condition). Это означает, что авторизация произойдет только при открытии PR или при новом слиянии в ветку main. Здесь также поддерживаются другие опции, например, когда добавляется новый тег или релиз, для этого можно использовать опцию ref:refs/tags/*.

Создаём роль с этой политикой:

resource "aws_iam_role" "github_actions" {   name               = "github-actions-role"   assume_role_policy = data.aws_iam_policy_document.github_oidc_assume_role.json }  output "role_arn" {   value = aws_iam_role.github_actions.arn } 

4. Назначение политик доступа

Допустим, вы хотите разрешить GitHub Actions доступ к Amazon ECR:

resource "aws_iam_role_policy_attachment" "ecr_access" {   role       = aws_iam_role.github_actions.name   policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly" } 

⚙️ Настройка GitHub Actions

В вашем .github/workflows/deploy.yml добавьте следующие строки:

permissions:   id-token: write   contents: read  on:   pull_request:   push:     branches:       - main  jobs:   deploy:     runs-on: ubuntu-latest     steps:       - name: Checkout code         uses: actions/checkout@v4        - name: Configure AWS credentials         uses: aws-actions/configure-aws-credentials@v4         with:           role-to-assume: arn:aws:iam::123456789012:role/github-actions-role           aws-region: eu-central-1        - name: Describe ECR         run: aws ecr describe-repositories 

Замените arn:aws:iam::123456789012:role/github-actions-role на ARN вашей IAM роли.

Читать про aws-actions/configure-aws-credentials


✅ Проверка и отладка

После настройки запустите workflow и убедитесь, что он успешно выполняется и имеет доступ к необходимым ресурсам AWS. В случае ошибок проверьте:

  • Правильность ARN роли

  • Совпадение условий в политике доверия с параметрами workflow

  • Наличие необходимых разрешений у роли


ссылка на оригинал статьи https://habr.com/ru/articles/908282/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *