Настройка OpenID Connect в HashiCorp Vault

Обзор

OpenID Connect (OIDC) позволяет рабочим процессам GitHub Actions проходить проверку подлинности в HashiCorp Vault для получения секретов.

В этом руководстве представлен обзор настройки HashiCorp Vault для доверия OIDC GitHub в качестве федеративного удостоверения, а также демонстрируется использование этой конфигурации в действии hashicorp/vault-action для получения секретов из HashiCorp Vault.

Необходимые компоненты

• Основные понятия о том, как GitHub использует OpenID Connect (OIDC) и его архитектуру и преимущества, см. в разделе OpenID Connect.

• Прежде чем продолжить, необходимо спланировать стратегию безопасности, чтобы обеспечить выдачу маркеров доступа только предсказуемым способом. Чтобы управлять тем, как поставщик облачных служб выдает маркеры доступа, необходимо определить по крайней мере одно условие, запретив недоверенным репозиториям запрашивать маркеры доступа к облачным ресурсам. Дополнительные сведения см. в разделе OpenID Connect.

• Если вы используете это руководство по GHE.com, понять, что необходимо заменить определенные значения в следующей документации. См . раздел AUTOTITLE.

Добавление поставщика удостоверений в HashiCorp Vault

Чтобы использовать OIDC с HashiCorp Vault, необходимо добавить конфигурацию доверия для поставщика OIDC GitHub. Дополнительные сведения см. в документации HashiCorp Vault.

Чтобы настроить сервер Vault для приема токенов JSON Web Token (JWT) для проверки подлинности, выполните следующие действия:

1. Включите метод JWT auth и используйте write для применения конфигурации к Vault. Для параметров oidc_discovery_url и bound_issuer используйте https://token.actions.githubusercontent.com. Эти параметры позволяют серверу Vault проверить полученные веб-токены JSON (JWT) в ходе процесса проверки подлинности.

   Shell

   vault auth enable jwt
   

   Shell

   vault write auth/jwt/config \
     bound_issuer="https://token.actions.githubusercontent.com" \
     oidc_discovery_url="https://token.actions.githubusercontent.com"
   

   Примечание.

   Если для предприятия был задан уникальный URL-адрес издателя с помощью REST API (как описано в OpenID Connect), значения для bound_issuer и oidc_discover_url должны соответствовать этому уникальному URL-адресу. Например, для предприятия с именем octocat , использующего уникальный URL-адрес издателя, bound_issuer и oidc_discovery_url необходимо задать значение https://token.actions.githubusercontent.com/octocat.

2. Настройте политику, которая предоставляет доступ только к определенным путям, которые будут использоваться рабочими процессами для извлечения секретов. Сведения о расширенных политиках см. в документации по политикам HashiCorp Vault.

   Shell

   vault policy write myproject-production - <<EOF
   # Read-only permission on 'secret/data/production/*' path
   
   path "secret/data/production/*" {
     capabilities = [ "read" ]
   }
   EOF
   

3. Настройте роли для группирования разных политик. Если проверка подлинности выполнена успешно, эти политики присоединяются к полученному маркеру доступа к Vault.

   Shell

   vault write auth/jwt/role/myproject-production -<<EOF
   {
     "role_type": "jwt",
     "user_claim": "actor",
     "bound_claims": {
       "repository": "user-or-org-name/repo-name"
     },
     "policies": ["myproject-production"],
     "ttl": "10m"
   }
   EOF
   

•         `ttl` определяет допустимость полученного маркера доступа.
  

• Убедитесь, что параметр bound_claims определен для ваших требований к безопасности и имеет по крайней мере одно условие. При необходимости можно также задать параметр bound_subject, а также параметр bound_audiences.
• Чтобы проверить произвольные утверждения в полученных полезных данных JWT, параметр bound_claims содержит набор утверждений и их обязательные значения. В приведенном выше примере роль будет принимать все входящие запросы проверки подлинности из репозитория repo-name, принадлежащего учетной записи user-or-org-name.
• Сведения обо всех доступных утверждениях, поддерживаемых поставщиком OIDC GitHub, см. в разделе OpenID Connect.

Дополнительные сведения см. в документации HashiCorp Vault.

Обновление рабочего процесса GitHub Actions

Чтобы обновить рабочие процессы для OIDC, необходимо внести два изменения в YAML:

1. Добавьте параметры разрешений для маркера.
2. Используйте действие hashicorp/vault-action для обмена токена OIDC (JWT) на облачный токен доступа.

Чтобы добавить интеграцию OIDC в рабочие процессы с целью разрешить доступ к секретам в хранилище, необходимо добавить следующие изменения кода:

• Предоставьте разрешение на получение токена от поставщика OIDC GitHub:
  • Рабочему процессу требуются параметры permissions: со значением id-token для write. Это позволяет получать токен OIDC из каждого задания в рабочем процессе.
• Запросите токен JWT от поставщика OIDC GitHub и предоставьте его в HashiCorp Vault для получения маркера доступа:
  • Вы можете использовать действие hashicorp/vault-action для извлечения JWT и получения маркера доступа из Vault, или использовать набор средств действий для извлечения маркеров для вашего задания.

В этом примере показано, как использовать OIDC с официальным действием для запроса секрета из HashiCorp Vault.

Добавление параметров разрешений

Для выполнения задания или рабочего процесса требуется permissions параметр, позволяющий id-token: write поставщику OIDC GitHubсоздать веб-токен JSON для каждого запуска.

Подробные сведения о необходимых разрешениях, примерах конфигурации и расширенных сценариях см. в разделе Справочник по OpenID Connect.

Запрос маркера доступа

Действие hashicorp/vault-action получает JWT от поставщика OIDC GitHub, а затем запрашивает маркер доступа из экземпляра HashiCorp Vault для получения секретов. Для получения дополнительной информации см. HashiCorp Vault GitHub Action documentation.

В этом примере показано, как создать задание, запрашивающее секрет из HashiCorp Vault.

•         `VAULT-URL` — замените на URL-адрес HashiCorp Vault.
  

•         `VAULT-NAMESPACE` — замените на пространство имен, заданное в HashiCorp Vault. Например: `admin`.
  

•         `ROLE-NAME` — замените на роль, заданную в отношении доверия HashiCorp Vault.
  

•         `SECRET-PATH` — замените на путь к секрету, извлекаемому из HashiCorp Vault. Например: `secret/data/production/ci npmToken`.
  

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
jobs:
  retrieve-secret:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Retrieve secret from Vault
        uses: hashicorp/vault-action@9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b
        with:
          method: jwt
          url: VAULT-URL
          namespace: VAULT-NAMESPACE # HCP Vault and Vault Enterprise only
          role: ROLE-NAME
          secrets: SECRET-PATH

      - name: Use secret from Vault
        run: |
          # This step has access to the secret retrieved above; see hashicorp/vault-action for more details.

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
jobs:
  retrieve-secret:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Retrieve secret from Vault
        uses: hashicorp/vault-action@9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b
        with:
          method: jwt
          url: VAULT-URL
          namespace: VAULT-NAMESPACE # HCP Vault and Vault Enterprise only
          role: ROLE-NAME
          secrets: SECRET-PATH

      - name: Use secret from Vault
        run: |
          # This step has access to the secret retrieved above; see hashicorp/vault-action for more details.

          `VAULT-NAMESPACE` необходимо задать для развертывания Vault Enterprise (включая HCP Vault). Дополнительные сведения см. в статье [Пространство имен Vault](https://www.vaultproject.io/docs/enterprise/namespaces).

Отзыв маркера доступа

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

1. Задайте для параметра exportToken значение true (по умолчанию: false). При этом маркер доступа выпущенного Vault экспортируется в виде переменной среды: VAULT_TOKEN.
2. Добавьте шаг, чтобы вызвать API Vault отзыва маркера (самостоятельно), чтобы отозвать маркер доступа.

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
jobs:
  retrieve-secret:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Retrieve secret from Vault
        uses: hashicorp/vault-action@9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b
        with:
          exportToken: true
          method: jwt
          url: VAULT-URL
          role: ROLE-NAME
          secrets: SECRET-PATH

      - name: Use secret from Vault
        run: |
          # This step has access to the secret retrieved above; see hashicorp/vault-action for more details.

      - name: Revoke token
        # This step always runs at the end regardless of the previous steps result
        if: always()
        run: |
          curl -X POST -sv -H "X-Vault-Token: ${{ env.VAULT_TOKEN }}" \
            VAULT-URL/v1/auth/token/revoke-self

# Этот рабочий процесс использует действия, которые не сертифицированы GitHub.
# Они предоставляются сторонним поставщиком, и на них распространяются
# отдельные условия обслуживания, политика конфиденциальности и поддержка
# документации.
jobs:
  retrieve-secret:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Retrieve secret from Vault
        uses: hashicorp/vault-action@9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b
        with:
          exportToken: true
          method: jwt
          url: VAULT-URL
          role: ROLE-NAME
          secrets: SECRET-PATH

      - name: Use secret from Vault
        run: |
          # This step has access to the secret retrieved above; see hashicorp/vault-action for more details.

      - name: Revoke token
        # This step always runs at the end regardless of the previous steps result
        if: always()
        run: |
          curl -X POST -sv -H "X-Vault-Token: ${{ env.VAULT_TOKEN }}" \
            VAULT-URL/v1/auth/token/revoke-self

Дополнительные материалы

• Использование OpenID Connect с многократно используемыми рабочими процессами
• Справочник по локальным запускам