Resolver problemas de permissão com uma conta de serviço do Google

Nesta página, mostramos como resolver problemas de permissão que ocorrem ao usar o Config Sync com uma conta de serviço do Google.

Sem acesso ao leitor

Ao usar uma conta de serviço do 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 do Google exige 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 esses papéis, git-sync, oci-sync ou helm-sync vão falhar 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 esse problema, conceda à conta de serviço o acesso correto de leitor.

Vinculação de política do IAM ausente com a Identidade da carga de trabalho

Ao usar uma conta de serviço do Google para autenticação, é necessário vincular uma política de IAM entre a conta de serviço do Google e a conta de serviço do Kubernetes. Se a vinculação de política do IAM estiver ausente, você receberá 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 vinculação de política do 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:

  • PROJECT_ID: se você estiver usando a Identidade da carga de trabalho do GKE, adicione a ID do projeto da sua organização. Se você usa a Identidade da carga de trabalho da frota, é possível utilizar duas IDs de projetos diferentes. Em serviceAccount:PROJECT_ID, adicione a ID do projeto da frota em que o cluster está registrado. Em GSA_NAME@PROJECT_ID, adicione uma ID para qualquer projeto que tenha acesso de leitura ao repositório no Cloud Source Repositories.

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

    Para repositórios de namespace, se o nome RepoSync for repo-sync, KSA_NAME será ns-reconciler-NAMESPACE. Caso contrário, será ns-reconciler-NAMESPACE-REPO_SYNC_NAME.

  • GSA_NAME: a conta de serviço personalizada do Google que você quer usar para se conectar ao Cloud Source Repositories. Verifique se a conta de serviço do Google selecionada tem o papel source.reader.

A criação dessa vinculação de política requer a permissão .iam.serviceAccounts.setIamPolicy

Verifique se a Identidade da carga de trabalho da frota está ativada nos clusters registrados. Para mais informações, consulte Registrar um cluster. Se o cluster estiver em um projeto diferente do projeto host da frota, será necessário vincular a conta de serviço do Google à conta de serviço do Kubernetes no projeto host da frota.

Escopo cloud-platform ausente para acessar o Cloud Source Repositories

Ao conceder a uma conta de serviço do Google acesso ao repositório Git no Cloud Source Repositories, o escopo somente leitura precisa ser incluído nos escopos de acesso dos nós no cluster.

O escopo somente leitura pode ser adicionado incluindo cloud-source-repos-ro na lista --scopes especificada no momento da criação do cluster ou usando o escopo cloud-platform no momento da criação do cluster. Exemplo:

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

Se o escopo somente leitura estiver ausente, você verá um erro semelhante a este

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":{}}

Escopo storage-ro ausente para acessar o Artifact Registry

Ao usar o Artifact Registry, as camadas de imagem são mantidas nos buckets do Cloud Storage. Ao conceder a uma conta de serviço do Google acesso à imagem OCI ou Helm Chart no Artifact Registry, o escopo somente leitura precisa ser incluído em escopos de acesso para os nós no cluster.

O escopo somente leitura pode ser adicionado incluindo storage-ro na lista --scopes especificada no momento da criação do cluster ou usando o escopo cloud-platform no momento da criação do cluster. Exemplo:

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

Se o escopo somente leitura estiver ausente, você verá um erro semelhante a este

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":{}}

Talvez a mensagem de erro não inclua todos os detalhes do que causou o erro, mas ela fornecerá um comando que imprime os logs do contêiner git-sync que podem ter mais informações.

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

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

Se você não ativou 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 são ativadas por padrão se você usou o console do Google Cloud ou a CLI do Google Cloud para instalar o Config Sync e não pode desativá-lo.

A seguir