Авторизация без ключа из GCP в GitHub Действия в GCP с использованием IdP
3 декабря 2022 г.Давайте поговорим об авторизации без ключа из GitHub Actions в GCP с использованием IdP. Как мы должны авторизоваться в GCP из GitHub Actions (не имеет значения, используем ли мы наши бегуны или бегуны GitHub)? Что, если мы используем terraform для настройки GCP и GitHub Actions для наших операций автоматизации?
Самый простой и не самый безопасный способ — создать базовый ключ сервисной учетной записи GCP (JSON) с определенным разрешением и авторизацией. Это отличный способ начать. Давайте посмотрим, как это работает:
Очень просто, но что, если:
- Ключ сервисного аккаунта будет скомпрометирован?
- Мы хотим ограничить источники, из которых можно использовать ключ.
- Мы хотим автоматически повторно выпустить ключ нового сервисного аккаунта.
У Google есть отличное решение — Workload Identity Federation
<цитата>Традиционно приложения, работающие за пределами Google Cloud, использовали ключи сервисного аккаунта для доступа к ресурсам Google Cloud. Ключи служебных учетных записей — это надежные учетные данные, которые могут представлять угрозу безопасности, если ими неправильно управлять.
С помощью объединения удостоверений вы можете использовать управление идентификацией и доступом (IAM) для предоставления внешних удостоверений Роли IAM, включая возможность олицетворения сервисных аккаунтов. Это позволяет вам получать доступ к ресурсам напрямую, используя токен краткосрочного доступа< /a> и устраняет проблемы обслуживания и безопасности, связанные с ключами сервисных аккаунтов.
Федерацию удостоверений рабочей нагрузки можно использовать с помощью:
- SAML 2.0
- Любой поставщик удостоверений, поддерживающий OpenID Connect (OIDC), например Microsoft Azure.
- Веб-сервисы Amazon (AWS)
n поставщик пула удостоверений рабочей нагрузки – это сущность, описывающая отношения между Google Cloud и внешним поставщиком удостоверений, например следующие:
- АМС
- Azure Active Directory
- Локальные службы федерации Active Directory (AD FS)
- Окта
- Кластеры Kubernetesn
Но давайте посмотрим, как использовать эту авторизацию без ключа в сочетании с GitHub Actions.
На стороне Google Cloud
<цитата>Мы будем выполнять все действия с помощью terraform, но вы также можете использовать UI GCP.
Сначала создадим пул идентификаторов рабочей нагрузки:
resource "google_iam_workload_identity_pool" "github_actions" {
provider = google-beta
project = "my-gcp-project"
workload_identity_pool_id = "github-actions"
display_name = "GitHub Actions pool"
description = "Workload Identity Pool managed by Terraform"
disabled = false
}
Затем нам нужно создать провайдера пула удостоверений рабочей нагрузки (многие провайдеры могут быть назначены одному пулу удостоверений рабочей нагрузки):
resource "google_iam_workload_identity_pool_provider" "github_actions" {
provider = google-beta
project = "my-gcp-project"
workload_identity_pool_id = google_iam_workload_identity_pool.github_actions.workload_identity_pool_id
workload_identity_pool_provider_id = "github-actions"
display_name = "GitHub Actions provider"
description = "Workload Identity Pool Provider managed by Terraform"
attribute_condition = "attribute.repository_owner=="arslanbekov""
attribute_mapping = {
"google.subject" = "assertion.sub"
"attribute.actor" = "assertion.actor"
"attribute.aud" = "assertion.aud"
"attribute.repository" = "assertion.repository"
"attribute.repository_owner" = "assertion.repository_owner"
}
oidc {
allowed_audiences = []
issuer_uri = "https://token.actions.githubusercontent.com"
}
}
Обратите внимание на параметр attribute_condition. Это условие, с помощью которого мы можем запретить действия, которые не подпадают под наш фильтр.
<цитата>Вы можете увидеть все доступные значения в официальном документация GitHub.
Также нам понадобится сервисный аккаунт (не волнуйтесь, ключи нам нигде не понадобятся), я не стал описывать его в коде терраформа для простоты, думаю, что вы легко можете это сделать самостоятельно, либо с помощью CLI gcloud :< /p>
gcloud iam service-accounts create SA_NAME
--description="DESCRIPTION"
--display-name="DISPLAY_NAME"
После того, как у нас будет учетная запись службы электронной почты, ей нужно будет присвоить роль roles/iam.workloadIdentityUser
resource "google_service_account_iam_member" "wif-sa" {
service_account_id = "projects/my-gcp-project/serviceAccounts/example-sa@my-gcp-project.iam.gserviceaccount.com"
role = "roles/iam.workloadIdentityUser"
member = "principalSet://iam.googleapis.com/${google_iam_workload_identity_pool.github_actions.name}/*"
}
Не забудьте заменить my-gcp-project и example-sa@my-gcp-project.iam .gserviceaccount.com**
После применения этого терраформирования на выходе у вас будет два значения (пожалуйста, сохраните их, они понадобятся вам позже):
output "pool_name" {
description = "Pool name"
value = google_iam_workload_identity_pool.github_actions.name
}
output "provider_name" {
description = "Provider name"
value = google_iam_workload_identity_pool_provider.github_actions.name
}
Пример вывода:
pool_name = "projects/${redacted_number}/locations/global/workloadIdentityPools/github-actions"
provider_name = "projects/${redacted_number}/locations/global/workloadIdentityPools/github-actions/providers/github-actions"
GCP_WORKLOAD_IDENTITY_PROVIDER_NAME(необходимо указать полную строку, например:projects/123456789/locations/global/workloadIdentityPools/github-actions/providers/github-actions)< /li>GCP_WORKLOAD_IDENTITY_SA_EMAIL(адрес электронной почты сервисного аккаунта, который мы создали ранее и указали в терраформе)
Пример рабочего процесса GitHub:
name: "Example Workload Identity"
on:
push:
branches:
- "master"
jobs:
run:
name: "Workload Identity Job"
permissions:
id-token: write
contents: read
runs-on: "ubuntu-latest"
steps:
- name: "Auth in GCP"
id: "auth"
uses: "google-github-actions/auth@v1"
with:
token_format: "access_token"
workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDENTITY_PROVIDER_NAME }}
service_account: ${{ secrets.GCP_WORKLOAD_IDENTITY_SA_EMAIL }}
- name: "Docker login"
run: |
echo '${{ steps.auth.outputs.access_token }}' | docker login -u oauth2accesstoken --password-stdin https://gcr.io
Наконец, мы можем авторизоваться в докере access_token, который будет в выводе шага id: auth.
Если вам нужно взаимодействие с gsutils — то это тоже доступно после авторизации.
Выводы
Переходя на авторизацию через поставщика удостоверений рабочей нагрузки, мы достигаем возможности ограничить доступ из определенных источников для авторизации. Мы также не заботимся о ротации ключей и можем контролировать срок службы ключа.
Ссылки
- https://github.com/arslanbekov/wif-gcp-terraform (вы можете найти весь код, описанный terraform в этой статье в этом репозитории)
- https://github.com/arslanbekov/wif-gcp-github-actions (пример аутентификации github-actions)
:::информация Также опубликовано здесь.
:::
Оригинал