Resolva problemas de autorização com uma conta de serviço Google

Esta página mostra-lhe como resolver problemas de autorização que ocorrem quando usa o Config Sync com uma conta de serviço Google.

Acesso de leitura em falta

Quando usa uma conta de serviço Google (spec.git.gcpServiceAccountEmail, spec.oci.gcpServiceAccountEmail ou spec.helm.gcpServiceAccountEmail) para se autenticar no Cloud Source Repositories ou no Artifact Registry, a conta de serviço Google requer o seguinte acesso de leitor:

  • Cloud Source Repositories: roles/source.reader
  • Artifact Registry: roles/artifactregistry.reader

Se a conta de serviço não tiver estas funções, git-sync ou oci-sync ou helm-sync falha com erros semelhantes aos seguintes:

failed to pull image us-docker.pkg.dev/...: GET https://us-docker.pkg.dev/v2/token?scope=repository...: DENIED: Permission \"artifactregistry.repositories.downloadArtifacts\" denied on resource \"projects/.../locations/us/repositories/...\" (or it may not exist)

"Err":"failed to render the helm chart: exit status 1, stdout: Error: failed to download ...

Para corrigir este problema, conceda à conta de serviço o acesso de leitor correto.

Associação de política IAM em falta com a federação de identidades do Workload para o GKE

Quando usar uma conta de serviço Google para autenticação, é necessária uma associação de políticas do IAM entre a conta de serviço Google e a conta de serviço Kubernetes. Se a associação da política IAM estiver em falta, recebe o seguinte erro:

KNV2004: unable to sync repo Error in the git-sync container: ERROR: failed to call ASKPASS callback URL: auth URL returned status 500, body: "failed to get token from credentials: oauth2/google: status code 403: {\n \"error\": {\n \"code\": 403,\n \"message\": \"The caller does not have permission\",\n \"status\": \"PERMISSION_DENIED\"\n }\n}\n"

Para corrigir o problema, crie a seguinte associação de política de IAM:

gcloud iam service-accounts add-iam-policy-binding \
   --role roles/iam.workloadIdentityUser \
   --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
   GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Substitua o seguinte:

  • PROJECT_ID: se estiver a usar a Workload Identity Federation para o GKE, adicione o ID do projeto da sua organização. Se estiver a usar a Workload Identity Federation da frota para o GKE, pode usar dois IDs de projetos diferentes. Em serviceAccount:PROJECT_ID, adicione o ID do projeto da frota na qual o cluster está registado. Em GSA_NAME@PROJECT_ID, adicione um ID do projeto para qualquer projeto que tenha acesso de leitura ao repositório nos Cloud Source Repositories.

  • KSA_NAME: a conta de serviço do Kubernetes para o reconciliador. Para repositórios de raiz, se o nome RootSync for root-sync, KSA_NAME é root-reconciler. Caso contrário, é root-reconciler-ROOT_SYNC_NAME.

    Para repositórios de espaços de nomes, se o nome RepoSync for repo-sync, KSA_NAME é ns-reconciler-NAMESPACE. Caso contrário, é ns-reconciler-NAMESPACE-REPO_SYNC_NAME.

  • GSA_NAME: a conta de serviço da Google personalizada que quer usar para estabelecer ligação aos Cloud Source Repositories. Certifique-se de que a conta de serviço Google que selecionar tem a função de source.reader.

A criação desta associação de políticas requer a autorização iam.serviceAccounts.setIamPolicy.

Certifique-se de que a federação do Workload Identity da frota para o GKE está ativada nos seus clusters registados. Para mais informações, consulte o artigo Registe um cluster. Se o cluster estiver num projeto diferente do projeto anfitrião da frota, tem de associar a conta de serviço Google à conta de serviço Kubernetes no projeto anfitrião da frota.

Âmbito cloud-platform em falta para aceder aos Cloud Source Repositories

Quando concede acesso a uma conta de serviço Google ao seu repositório Git nos Cloud Source Repositories, o âmbito de leitura tem de ser incluído nos âmbitos de acesso para os nós no cluster.

O âmbito de leitura pode ser adicionado incluindo cloud-source-repos-ro na lista --scopes especificada no momento da criação do cluster ou usando o âmbito cloud-platform no momento da criação do cluster. Por exemplo:

gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform

Se o âmbito só de leitura estiver em falta, é apresentado um erro semelhante ao seguinte:

Error in the git-sync container: {"Msg":"unexpected error syncing repo, will retry","Err":"Run(git clone -v --no-checkout -b main --depth 1 https://source.developers.google.com/p/PROJECT_ID/r/csr-auth-test /repo/source): exit status 128: { stdout: \"\", stderr: \"Cloning into '/repo/source'...\\nremote: INVALID_ARGUMENT: Request contains an invalid argument\\nremote: [type.googleapis.com/google.rpc.LocalizedMessage]\\nremote: locale: \\\"en-US\\\"\\nremote: message: \\\"Invalid authentication credentials. Please generate a new identifier: https://source.developers.google.com/new-password\\\"\\nremote: \\nremote: [type.googleapis.com/google.rpc.RequestInfo]\\nremote: request_id: \\\"fee01d10ba494552922d42a9b6c4ecf3\\\"\\nfatal: unable to access 'https://source.developers.google.com/p/PROJECT_ID/r/csr-auth-test/': The requested URL returned error: 400\\n\" }","Args":{}}

Âmbito storage-ro em falta para aceder ao Artifact Registry

Quando usa o Artifact Registry, as camadas de imagens são mantidas em contentores do Cloud Storage. Quando concede acesso a uma conta de serviço Google à sua imagem OCI ou gráfico Helm no Artifact Registry, o âmbito só de leitura tem de ser incluído em access scopes para os nós no cluster.

O âmbito de leitura pode ser adicionado incluindo storage-ro na --scopes lista especificada no momento da criação do cluster ou usando o âmbito cloud-platform no momento da criação do cluster. Por exemplo:

gcloud container clusters create CLUSTER_NAME --scopes=cloud-platform

Se o âmbito só de leitura estiver em falta, é apresentado um erro semelhante ao seguinte:

Error in the oci-sync container: {"Msg":"unexpected error fetching package, will retry","Err":"failed to pull image us-docker.pkg.dev/...: GET https://us-docker.pkg.dev/v2/token?scope=repository%3A...%3Apull\u0026service=us-docker.pkg.dev: UNAUTHORIZED: failed authentication","Args":{}}

A mensagem de erro pode não incluir os detalhes completos do que causou o erro, mas fornece um comando que imprime os registos do contentor git-sync, que podem ter mais informações.

Se ativou as APIs RootSync ou RepoSync, execute o seguinte comando:

kubectl logs -n config-management-system -l app=reconciler -c git-sync

Se não tiver ativado as APIs RootSync ou RepoSync, execute o seguinte comando:

kubectl logs -n config-management-system -l app=git-importer -c git-sync

As APIs RootSync e RepoSync estão ativadas por predefinição se tiver usado a Google Cloud consola ou a CLI do Google Cloud para instalar o Config Sync e não as pode desativar.

O que se segue?