Безопасное развертывание AWS из Github Actions с помощью OIDC

Давно прошли те времена, когда для развертывания на AWS нужно было хранить долгоживущие ключи доступа в своих CI/CD конвейерах. Узнайте, как использовать OIDC (OpenID Connect) для безопасного развертывания на AWS из Github Actions, а также как использовать GitHub Environments для безопасного развертывания в определенных средах AWS.

Введение

Управление доступом из ваших CI/CD систем к облачным средам безопасным образом часто может быть утомительной задачей. Долгое время одним из распространенных способов сделать это для AWS была установка IAM-пользователя для этой цели, а затем хранение ключей доступа для этого пользователя, например, в GitHub secrets для использования в GitHub Actions. Это требовало много ручной работы, такой как настройка разных пользователей для разных проектов, ротация ключей после определенного периода и т.д.

Используя OIDC, вы можете настроить AWS на доверие к GitHub как к федеративному поставщику идентификационных данных, а затем использовать ID-токены в рабочих процессах Github Actions для аутентификации в AWS и доступа к ресурсам. Вы можете создать отдельные роли IAM для различных целей и позволить рабочим процессам принимать эти роли в гранулированном виде.

Каждое задание в рабочем процессе GitHub Actions может запросить токен OIDC у поставщика OIDC GitHub. Содержимое маркера хорошо описано в документации GitHub. В зависимости от конфигурации задания, а также от того, какое событие запустило рабочий процесс, токен будет содержать различный набор утверждений. Одним из важных утверждений является утверждение sub, которое будет использоваться в наших политиках доверия IAM Role для предоставления разрешения рабочим процессам использовать роль.

Например, если рабочий процесс инициируется толчком к ветке main репозитория с именем repo-org/repo-name, утверждение subject будет установлено на repo:repo-org/repo-name:ref:refs/heads/main. Если задание ссылается на среду GitHub с именем Production, утверждение субъекта будет установлено в repo:repo-org/repo-name:environment:Production.

Полный список возможных утверждений субъектов можно найти в документации GitHub.

Пример настройки

В этом примере мы будем использовать два разных ведра S3 для имитации двух разных сред AWS. Мы создадим два разных рабочих процесса, один из которых будет инициироваться пушами в ветку main, а другой — запросами на исправление.

При запросах на исправление мы хотим иметь возможность читать наши окружения. В реальном примере это может быть задание terraform plan, которое визуализирует любые предлагаемые изменения в окружении. Мы также будем развертывать в среду разработки из запросов на исправление, чтобы ускорить цикл обратной связи. Однако мы НЕ хотим развертывать производственную среду из запросов. Мы также должны быть уверены, что участники не смогут обновить рабочий процесс в рамках запроса на исправление, чтобы включить развертывание в производственную среду.

Для отправки в основную среду мы хотим иметь возможность читать и развертывать в обеих средах. Для развертывания в производственную среду нам также потребуется ручное одобрение администратора хранилища.

В примерах рабочих процессов операции чтения и развертывания будут продемонстрированы с помощью операций загрузки и выгрузки в соответствующие ведра S3.

1. Создайте ведра

Начните с создания двух ведер в вашей учетной записи. Ниже я буду называть их YOUR_DEV_BUCKET и YOUR_PROD_BUCKET.

2. Добавьте GitHub в качестве поставщика идентификационных данных

Чтобы иметь возможность аутентифицироваться в OIDC с GitHub, вам сначала нужно настроить GitHub как федеративного провайдера идентификации в вашей учетной записи AWS. Для этого перейдите в консоль AWS IAM и нажмите на Identity Providers в левой части. Затем нажмите на кнопку Добавить провайдера.

  1. Для типа провайдера выберите OpenID Connect.
  2. Для URL-адреса провайдера введите https://token.actions.githubusercontent.com.
  3. Нажмите на кнопку Получить отпечаток, чтобы получить отпечаток провайдера.
  4. Для Аудитории введите sts.amazonaws.com.

3. Создайте роли и политики

Теперь, когда GitHub настроен как провайдер идентификации, пришло время создать роли и политики, которые будут использоваться в соответствующих рабочих процессах. Вы создадите три роли:

  • Роль читателя: Будет иметь права на чтение в обоих ведрах. Эта роль будет доступна как для событий pull_request, так и для событий push в ветке main.
  • Роль Dev Deploy: Будет иметь права на чтение и запись в ведро dev. Этой роли потребуется рабочий процесс для использования среды Development GitHub.
  • Роль Prod Deploy: Будет иметь права на чтение и запись в ведро prod. Этой роли потребуется рабочий процесс для использования среды Production GitHub.

Роль читателя

Начните с создания новой роли, которая будет использоваться для чтения из ведер. Роль должна быть доступна для обоих рабочих процессов, запускаемых событиями pull_request и push. Чтобы это было возможно, роль должна иметь следующую политику доверия:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "ForAllValues:StringEquals": {
          "token.actions.githubusercontent.com:sub": [
            "repo:ORG_OR_USER_NAME/REPOSITORY:pull_request",
            "repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main"
          ],
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

Входить в полноэкранный режим Выходить из полноэкранного режима

Вам нужно заменить ORG_OR_USER_NAME и REPOSITORY на ваши собственные значения. Для моего примера репозитория eliasbrange/aws-github-actions-oidc это будет "repo:eliasbrange/aws-github-actions-oidc:pull_request".

Затем добавьте IAM-политику для этой роли, которая предоставляет ей разрешение на чтение из ведер.

{
  "Statement": [
    {
      "Action": [
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::YOUR_DEV_BUCKET",
        "arn:aws:s3:::YOUR_PROD_BUCKET"
      ]
    },
    {
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::YOUR_DEV_BUCKET/*",
        "arn:aws:s3:::YOUR_PROD_BUCKET/*"
      ]
    }
  ],
  "Version": "2012-10-17"
}

Вход в полноэкранный режим Выход из полноэкранного режима

Роль развертывания разработки

Создайте еще одну роль, которая будет использоваться для «развертывания» в среду разработки, в данном случае путем загрузки файла в ведро разработки. Эта роль должна требовать, чтобы рабочий процесс использовал среду GitHub под названием Development, поэтому ей потребуется следующая политика доверия:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "ForAllValues:StringEquals": {
          "token.actions.githubusercontent.com:sub": "repo:ORG_OR_USER_NAME/REPOSITORY:environment:Development",
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

Войти в полноэкранный режим Выходить из полноэкранного режима

Дайте ей следующую политику IAM:

{
  "Statement": [
    {
      "Action": [
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::YOUR_DEV_BUCKET"
      ]
    },
    {
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::YOUR_DEV_BUCKET/*"
      ]
    }
  ],
  "Version": "2012-10-17"
}

Войти в полноэкранный режим Выйти из полноэкранного режима

Роль развертывания производства

Создайте последнюю роль, которая будет использоваться для производственных развертываний. Она должна быть похожа на роль разработчика, но с некоторыми изменениями в разрешениях.

Добавьте следующую политику доверия:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "ForAllValues:StringEquals": {
          "token.actions.githubusercontent.com:sub": "repo:ORG_OR_USER_NAME/REPOSITORY:environment:Production",
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

Войти в полноэкранный режим Выходить из полноэкранного режима

Назначьте ей следующую политику IAM:

{
  "Statement": [
    {
      "Action": [
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::YOUR_PROD_BUCKET"
      ]
    },
    {
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::YOUR_PROD_BUCKET/*"
      ]
    }
  ],
  "Version": "2012-10-17"
}

Войти в полноэкранный режим Выйти из полноэкранного режима

4. Создание окружений GitHub

В своем репозитории GitHub создайте две среды, Development и Production. Для Development мы не будем добавлять никаких защитных средств, чтобы мы могли развертывать в него непосредственно из pull request’ов. Однако для среды Production мы добавим несколько правил защиты.

  1. В конфигурации среды в разделе Правила защиты среды установите флажок Требуемые рецензенты и добавьте собственное имя пользователя GitHub.
  2. В конфигурации среды в разделе Deployment branches выберите Selected branches в выпадающем списке и добавьте main в качестве разрешенной ветви.

Приведенные выше правила не позволят участникам изменить фактический рабочий процесс в рамках запроса на внесение изменений для развертывания в производство. Это также заставит рабочие процессы, предназначенные для среды Production, требовать ручного утверждения.

5. Добавьте секреты GitHub

Хотя вы можете использовать секреты, привязанные к каждой среде, я хочу показать, что даже если рабочий процесс имеет доступ к секрету, он не сможет принимать роли, к которым у него не должно быть доступа.

В свой репозиторий GitHub добавьте следующие секреты:

6. Создание рабочих процессов

Пришло время создать рабочие процессы развертывания. Вы создадите в общей сложности три рабочих процесса, один для pull requests, один для pushes to main, а также бонусный рабочий процесс для визуализации того, какое событие рабочего процесса срабатывает, кто имеет доступ к каким IAM-ролям.

Рабочие процессы будут пытаться загрузить файл с именем README.md из ваших ведер, а также загрузить файл из корня репозитория с именем README.md в ведра. Либо измените рабочие процессы для использования другого файла, либо убедитесь, что у вас есть файл README.md в корне хранилища. Чтобы первый запуск рабочих процессов прошел успешно, вам также необходимо загрузить указанный файл в оба ведра.

Рабочий процесс Pull request

Добавьте следующий рабочий процесс в ваш репозиторий:

name: "Pull Request"

# The workflow should only trigger on pull requests to the main branch
on:
  pull_request:
    branches:
      - main

# Required to get the ID Token that will be used for OIDC
permissions:
  id-token: write

jobs:
  read-dev:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets.READ_ROLE }}
          role-session-name: OIDCSession

      - run: aws s3 cp s3://YOUR_DEV_BUCKET/README.md README.md
        shell: bash

  write-dev:
    runs-on: ubuntu-latest
    needs: read-dev
    environment: Development
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets.DEV_DEPLOY_ROLE }}
          role-session-name: OIDCSession

      - run: aws s3 cp README.md s3://YOUR_DEV_BUCKET/README.md
        shell: bash

  read-prod:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets.READ_ROLE }}
          role-session-name: OIDCSession

      - run: aws s3 cp s3://YOUR_PROD_BUCKET/README.md README.md
        shell: bash

Войти в полноэкранный режим Выйти из полноэкранного режима

Это очень простой рабочий процесс, который:

  1. Сначала загружает файл README.md из ведра Development.
  2. Затем загружает README.md из репозитория в ведро Development.
  3. Наконец, загружает файл README.md из ведра Production.

Не очень интересный и не очень полезный рабочий процесс, но он демонстрирует использование различных ролей и окружений.

В обоих заданиях read-dev и read-prod не указано окружение, поэтому ID-токен в этих заданиях будет иметь предметное утверждение repo:ORG_OR_USER_NAME/REPOSITORY:pull_request. Они также оба используют секрет READ_ROLE, который должен указывать на ARN вашей IAM-роли читателя.

В write-dev, есть environment: Development, что означает, что ID-токен будет иметь предметное утверждение repo:ORG_OR_USER_NAME/REPOSITORY:environment:Development. В задании используется секрет DEV_DEPLOY_ROLE вместо READ_ROLE.

Перенос в рабочий процесс main

Добавьте следующий рабочий процесс в ваш репозиторий:

name: "Push"

# The workflow should only trigger on push events to the main branch
on:
  push:
    branches:
      - main

# Required to get the ID Token that will be used for OIDC
permissions:
  id-token: write

jobs:
  read-dev:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets.READ_ROLE }}
          role-session-name: OIDCSession

      - run: aws s3 cp s3://YOUR_DEV_BUCKET/README.md README.md
        shell: bash

  write-dev:
    runs-on: ubuntu-latest
    needs: read-dev
    environment: Development
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets.DEV_DEPLOY_ROLE }}
          role-session-name: OIDCSession

      - run: aws s3 cp README.md s3://YOUR_DEV_BUCKET/README.md
        shell: bash

  read-prod:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets.READ_ROLE }}
          role-session-name: OIDCSession

      - run: aws s3 cp s3://YOUR_PROD_BUCKET/README.md README.md
        shell: bash

  write-prod:
    needs: [read-prod, write-dev]
    runs-on: ubuntu-latest
    environment: Production
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets.PROD_DEPLOY_ROLE }}
          role-session-name: OIDCSession

      - run: aws s3 cp README.md s3://YOUR_PROD_BUCKET/README.md
        shell: bash

Вход в полноэкранный режим Выйти из полноэкранного режима

Почти то же самое, что и предыдущий рабочий процесс, но с добавлением задания write-prod.

  1. Загрузите README.md из ведра Development.
  2. Загрузите README.md из репозитория в ведро Development.
  3. Загрузите README.md из ведра Production.
  4. Загрузите README.md из репозитория в ведро Production.

read-prod использует ту же настройку, что и read-dev, т.е. нет окружения и оба используют секрет READ_ROLE. Задание write-prod аналогично заданию write-dev, но использует окружение: Production и секрет PROD_DEPLOY_ROLE.

Бонусный рабочий процесс

Этот рабочий процесс является бонусным рабочим процессом, который использует матричную стратегию, чтобы показать результат различных комбинаций предметного требования, окружения и роли.

Добавьте следующий рабочий процесс в свой репозиторий:

name: "Bonus"

on:
  pull_request:
    branches:
      - main

  push:
    branches:
      - main

permissions:
  id-token: write

jobs:
  read-dev:
    strategy:
      fail-fast: false
      matrix:
        environment:
          - ""
          - Development
          - Production
        role_secret:
          - READ_ROLE
          - DEV_DEPLOY_ROLE
          - PROD_DEPLOY_ROLE
    runs-on: ubuntu-latest
    environment: ${{ matrix.environment }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets[matrix.role_secret] }}
          role-session-name: OIDCSession

      - run: aws s3 cp s3://YOUR_DEV_BUCKET/README.md README.md
        shell: bash

  write-dev:
    strategy:
      fail-fast: false
      matrix:
        environment:
          - ""
          - Development
          - Production
        role_secret:
          - READ_ROLE
          - DEV_DEPLOY_ROLE
          - PROD_DEPLOY_ROLE
    runs-on: ubuntu-latest
    environment: ${{ matrix.environment }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets[matrix.role_secret] }}
          role-session-name: OIDCSession

      - run: aws s3 cp README.md s3://YOUR_DEV_BUCKET/README.md
        shell: bash


  read-prod:
    strategy:
      fail-fast: false
      matrix:
        environment:
          - ""
          - Development
          - Production
        role_secret:
          - READ_ROLE
          - DEV_DEPLOY_ROLE
          - PROD_DEPLOY_ROLE
    runs-on: ubuntu-latest
    environment: ${{ matrix.environment }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets[matrix.role_secret] }}
          role-session-name: OIDCSession

      - run: aws s3 cp s3://YOUR_PROD_BUCKET/README.md README.md
        shell: bash

  write-prod:
    strategy:
      fail-fast: false
      matrix:
        environment:
          - ""
          - Development
          - Production
        role_secret:
          - READ_ROLE
          - DEV_DEPLOY_ROLE
          - PROD_DEPLOY_ROLE
    runs-on: ubuntu-latest
    environment: ${{ matrix.environment }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: eu-west-1
          role-to-assume: ${{ secrets[matrix.role_secret] }}
          role-session-name: OIDCSession

      - run: aws s3 cp README.md s3://YOUR_PROD_BUCKET/README.md
        shell: bash

Войти в полноэкранный режим Выход из полноэкранного режима

Этот рабочий процесс будет запускаться как push’ами в main, так и pull-запросами. Затем он попытается выполнить чтение и запись в оба ведра с различными комбинациями environment и role_secret.

Результаты

Когда все рабочие процессы будут перенесены в main в вашем репозитории, создайте новую ветку и создайте запрос на исправление. Если все работает правильно, рабочий процесс под названием Pull Request должен выполниться успешно. Рабочий процесс Bonus должен завершиться неудачно для многих комбинаций (и это может занять некоторое время из-за стратегии отката действия configure AWS credentials).

Если вы объедините запрос на притяжение, рабочий процесс под названием Push должен выполниться успешно.

Комбинации рабочих процессов

Взглянув на рабочий процесс Bonus, мы должны увидеть, какие комбинации событий рабочего процесса, среды и роли возможны при имеющейся у нас настройке OIDC. Рабочие комбинации также должны отличаться в зависимости от того, начался ли рабочий процесс с push в main или с pull request.

Для каждого из 4 рабочих процессов у нас должно быть 9 различных комбинаций. Вот эти комбинации:

# Окружение Роль
1 НЕТ ЧИТАТЬ_РОЛЬ
2 НЕТ DEV_DEPLOY_ROLE
3 НЕТ PROD_DEPLOY_ROLE
4 Разработка РОЛЬ ЧИТАТЕЛЯ
5 Разработка DEV_DEPLOY_ROLE
6 Разработка PROD_DEPLOY_ROLE
7 Производство РОЛЬ ЧИТАТЕЛЯ
8 Производство DEV_DEPLOY_ROLE
9 Производство PROD_DEPLOY_ROLE

Запрос на вытягивание

Если мы начнем с рассмотрения pull request, рабочий процесс должен иметь доступ к READ_ROLE, когда окружение NONE (что означает, что предметное утверждение будет repo:ORG_OR_USER_NAME/REPOSITORY:pull_request). Это должно позволить рабочему процессу читать ведра как разработки, так и производства при использовании комбинации no environment и READ_ROLE.

Он также должен иметь возможность использовать среду Development, поскольку для этой среды нет правил защиты. Это должно позволить рабочему процессу и читать, и писать в ведро разработки, когда среда Development и роль DEV_DEPLOY_ROLE.

Из-за правила защиты среды Production, рабочий процесс не должен иметь возможности использовать среду Production вообще, когда он запускается запросами на вытягивание.

работа read-dev
# Среда Роль Результат
1 НЕТ СЧИТАТЬ_РОЛЬ Успех
2 НЕТ DEV_DEPLOY_ROLE Неудача: недействительное утверждение
3 НЕТ PROD_DEPLOY_ROLE Отказ: недействительное утверждение
4 Разработка ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
5 Разработка DEV_DEPLOY_ROLE Успех
6 Разработка PROD_DEPLOY_ROLE Неудача: недействительное утверждение
7 Производство ЧИТАТЬ_РОЛЬ Отказ: правило защиты среды
8 Производство DEV_DEPLOY_ROLE Отказ: правило защиты среды
9 Производство PROD_DEPLOY_ROLE Отказ: правило защиты среды
работа по записи на устройство
# Окружающая среда Роль Результат
1 НЕТ ЧИТАТЬ_РОЛЬ Отказ: недостаточно прав
2 НЕТ DEV_DEPLOY_ROLE Отказ: недействительное утверждение
3 НЕТ PROD_DEPLOY_ROLE Отказ: недействительное утверждение
4 Разработка ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
5 Разработка DEV_DEPLOY_ROLE Успех
6 Разработка PROD_DEPLOY_ROLE Неудача: недействительное утверждение
7 Производство ЧИТАТЬ_РОЛЬ Отказ: правило защиты среды
8 Производство DEV_DEPLOY_ROLE Отказ: правило защиты среды
9 Производство PROD_DEPLOY_ROLE Отказ: правило защиты среды
чтение-прод работа
# Окружение Роль Результат
1 НЕТ СЧИТАТЬ_РОЛЬ Успех
2 НЕТ DEV_DEPLOY_ROLE Неудача: недействительное утверждение
3 НЕТ PROD_DEPLOY_ROLE Отказ: недействительное утверждение
4 Разработка ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
5 Разработка DEV_DEPLOY_ROLE Отказ: недостаточно прав
6 Разработка PROD_DEPLOY_ROLE Отказ: недействительное утверждение
7 Производство ЧИТАТЬ_РОЛЬ Отказ: правило защиты среды
8 Производство DEV_DEPLOY_ROLE Отказ: правило защиты среды
9 Производство PROD_DEPLOY_ROLE Отказ: правило защиты среды
write-prod job
# Окружающая среда Роль Результат
1 НЕТ ЧИТАТЬ_РОЛЬ Отказ: недостаточно прав
2 НЕТ DEV_DEPLOY_ROLE Отказ: недействительное утверждение
3 НЕТ PROD_DEPLOY_ROLE Отказ: недействительное утверждение
4 Разработка ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
5 Разработка DEV_DEPLOY_ROLE Отказ: недостаточное количество разрешений
6 Разработка PROD_DEPLOY_ROLE Отказ: недействительное утверждение
7 Производство ЧИТАТЬ_РОЛЬ Отказ: правило защиты среды
8 Производство DEV_DEPLOY_ROLE Отказ: правило защиты среды
9 Производство PROD_DEPLOY_ROLE Отказ: правило защиты окружающей среды

Push

Продолжая рабочий процесс при срабатывании push в main, мы должны иметь возможность снова использовать READ_ROLE, когда окружение NONE. Это даст доступ на чтение к обоим ведрам для данной комбинации.

Для записи в разработку требуется сочетание окружения Development с DEV_DEPLOY_ROLE.

Наконец, для развертывания на производстве требуется комбинация среды Production с PROD_DEPLOY_ROLE. Это также должно вызвать шаг ручного утверждения для продолжения развертывания.

работа read-dev
# Среда Роль Результат
1 НЕТ СЧИТАТЬ_РОЛЬ Успех
2 НЕТ DEV_DEPLOY_ROLE Неудача: недействительное утверждение
3 НЕТ PROD_DEPLOY_ROLE Отказ: недействительное утверждение
4 Разработка ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
5 Разработка DEV_DEPLOY_ROLE Успех
6 Разработка PROD_DEPLOY_ROLE Неудача: недействительное утверждение
7 Производство ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
8 Производство DEV_DEPLOY_ROLE Отказ: недействительное утверждение
9 Производство PROD_DEPLOY_ROLE Отказ: недействительное утверждение
write-dev job
# Окружение Роль Результат
1 НЕТ ЧИТАТЬ_РОЛЬ Отказ: недостаточно прав
2 НЕТ DEV_DEPLOY_ROLE Отказ: недействительное утверждение
3 НЕТ PROD_DEPLOY_ROLE Отказ: недействительное утверждение
4 Разработка ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
5 Разработка DEV_DEPLOY_ROLE Успех
6 Разработка PROD_DEPLOY_ROLE Неудача: недействительное утверждение
7 Производство ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
8 Производство DEV_DEPLOY_ROLE Отказ: недействительное утверждение
9 Производство PROD_DEPLOY_ROLE Отказ: недействительное утверждение
чтение-прод работа
# Окружение Роль Результат
1 НЕТ СЧИТАТЬ_РОЛЬ Успех
2 НЕТ DEV_DEPLOY_ROLE Неудача: недействительное утверждение
3 НЕТ PROD_DEPLOY_ROLE Отказ: недействительное утверждение
4 Разработка ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
5 Разработка DEV_DEPLOY_ROLE Отказ: недостаточно прав
6 Разработка PROD_DEPLOY_ROLE Отказ: недействительное утверждение
7 Производство ПРОЧИТАТЬ_РОЛЬ Успех
8 Производство DEV_DEPLOY_ROLE Неудача: недействительное утверждение
9 Производство PROD_DEPLOY_ROLE Отказ: недействительное утверждение
write-prod job
# Окружение Роль Результат
1 НЕТ ЧИТАТЬ_РОЛЬ Отказ: недостаточно прав
2 НЕТ DEV_DEPLOY_ROLE Отказ: недействительное утверждение
3 НЕТ PROD_DEPLOY_ROLE Отказ: недействительное утверждение
4 Разработка ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
5 Разработка DEV_DEPLOY_ROLE Отказ: недостаточно прав
6 Разработка PROD_DEPLOY_ROLE Отказ: недействительное утверждение
7 Производство ЧИТАТЬ_РОЛЬ Отказ: недействительное утверждение
8 Производство DEV_DEPLOY_ROLE Отказ: недействительное утверждение
9 Производство PROD_DEPLOY_ROLE Успех

Выводы

Начиная с этого примера, вы теперь должны уметь использовать GitHub OIDC в качестве федеративной идентификации в своих рабочих процессах GitHub Actions, чтобы раз и навсегда избавиться от долгоживущих учетных данных. Вы узнали, как:

  • Включать федеративную идентификацию для GitHub на стороне AWS
  • определять, к каким репозиториям и событиям рабочего процесса разрешен доступ вашим ролям
  • Обеспечивать безопасность производственной среды, требуя дополнительных шагов.

Надеюсь, вы узнали кое-что новое. А теперь идите и создайте что-нибудь потрясающее.

Репозиторий GitHub

У меня есть сопутствующий репозиторий на GitHub для этой статьи в блоге, где вы можете найти сами рабочие процессы, а также конфигурацию terraform для настройки стороны AWS.

Оставьте комментарий

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