Ошибка google-github-actions/get-gke-credentials: требуются разрешения "container.clusters.get"
Действие завершается сбоем из-за следующей ошибки... «Ошибка google-github-actions/get-gke-credentials: требуются разрешения «container.clusters.get»». Я не использую сервисную учетную запись.
Я использую опцию «Прямая федерация идентификации рабочей нагрузки», как описано в действии google-github-actions/auth. Я также создал свой пул удостоверений рабочей нагрузки и поставщика в соответствии с их инструкциями. Во всей справке, которую я читаю, говорится об учетных записях служб, но действие аутентификации ясно показывает, что опция «Прямая федерация идентификации рабочей нагрузки» не требует учетной записи службы.
из документации google-github-actions/auth...
service_account: (Optional) Email address or unique identifier of the Google Cloud service account for which to impersonate and generate credentials.
Without this input, the GitHub Action will use Direct Workload Identity Federation
Действие YAML
name: deploy-k8s-manifests
on:
push:
branches:
- dev
paths:
- 'k8s/**'
jobs:
deploy:
runs-on: ubuntu-latest
# Add "id-token" with the intended permissions.
permissions:
contents: 'read'
id-token: 'write'
steps:
- name: Get code
uses: actions/checkout@v4
- name: Authenticate with GCP
id: 'auth'
uses: google-github-actions/auth@v2
with:
project_id: 'my-project'
workload_identity_provider: 'projects/299900345299/locations/global/workloadIdentityPools/github/providers/my-provider'
- name: Get GKE credentials
id: 'get-credentials'
uses: google-github-actions/get-gke-credentials@v2
with:
cluster_name: 'preprod'
location: 'us-central1'
- name: Do anything with kubectl
run: kubectl get pods
Вывод журнала
Authenticate with GCP
Run google-github-actions/auth@v2
Created credentials file at "/home/runner/work/my-project/my-project/gha-creds-c9c4d62169250d9a.json"
Get GKE credentials
Run google-github-actions/get-gke-credentials@v2
Error: google-github-actions/get-gke-credentials failed with: required "container.clusters.get" permission(s) for "projects/my-project/locations/us-central1/clusters/preprod".
Любая помощь будет оценена.
Ответы 1
Хорошо, я наконец-то заработал, а сервисной учетной записи нет! Следующая ссылка оказалась наиболее полезной и заполнила пробелы, которые мне не хватало в назначении ролей IAM для элементов WIF. Я считаю обязательным чтение для аутентификации GKE с помощью GitHub Actions — https://cloud.google.com/iam/docs/workload-identity-federation-with-deployment-pipelines#github-actions
Чтобы запустить что-то простое, например «kubectl get pods», после аутентификации, мне нужно было добавить «roles/container.clusterViewer» и «roles/container.admin» к… чему-то (читайте дальше). Я уверен, что roles/container.admin было излишним, но это работает. Я добавил эти роли к тому, что я называю «сценарием WIF» с помощью следующих двух команд...
gcloud projects add-iam-policy-binding my-project \
--role "roles/container.clusterViewer" \
--member "principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.repository/my-repo"
gcloud projects add-iam-policy-binding my-project \
--role "roles/container.admin" \
--member "principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.repository/my-repo"
Больше всего меня сбивает с толку значение члена в приведенных выше командах. Чтобы помочь, участником может быть адрес электронной почты пользователя (например, --member «user: EMAIL»), что очень легко понять, как кому-то, кому можно назначать роли. Однако в данном конкретном случае член — это то, что я бы назвал «сценарием WIF». Вот как я думаю о приведенных выше командах gcloud, и непонимание этого было моим самым большим блоком в уме: «Когда вызов проходит через указанный пул федерации идентификации рабочей нагрузки, И токен, который Github Actions отправляет вместе с ним, содержит свойство «репозитория» со значением «my-repo», ответьте учетными данными, содержащими следующие роли)». Мы привязываем конкретный сценарий, используя определенный пул WIF, к роли. Тот факт, что имя репо связано с «attribute.repository», происходит из «Сопоставления атрибутов» поставщика WIF...
Соответствующий раздел, который вам нужен по ссылке выше, — https://cloud.google.com/iam/docs/workload-identity-federation-with-deployment-pipelines#authenticate. Когда я впервые наткнулся на СУБЪЕКТ, ГРУППУ и АТРИБУТ, я был очень сбит с толку, не понимая, какого черта я должен был назначить роль. Теперь я это понимаю...
- действие google-github-actions/auth отправляет запрос в GCP, содержащий токен (со значениями, которые GitHub Actions предоставляет для этого конкретного вызова, описанного здесь - https://docs.github.com/en/actions/deployment/security). -hardening-your-deployments/about-security-hardening-with-openid-connect#понимание-oidc-токена)
- вы привязываете роли/разрешения IAM к участнику, описанному как вызов вашего пула WIF, содержащего определенные значения («репозиторий» = «my-repo» в моем примере выше)
- последующие команды GKE имеют роли/разрешения, привязанные к этому «сценарию WIF».
Никакая учетная запись службы не задействована, только конкретный вызов от GitHub Actions и некоторые кратковременные учетные данные, возвращаемые из GCP.
С помощью поставщика удостоверений рабочей нагрузки вы сопоставляете правило с учетной записью службы (в Google Cloud). Эта учетная запись службы олицетворяет удостоверение рабочей нагрузки, и для выполнения действий она должна иметь правильную роль в вашем проекте. Предоставьте правильные разрешения, и все будет работать!