Résoudre les problèmes d'autorisation avec un compte de service Google

Cette page explique comment résoudre les problèmes d'autorisation qui surviennent lors de l'utilisation de Config Sync avec un compte de service Google.

Accès lecteur manquant

Lorsque vous utilisez un compte de service Google (spec.git.gcpServiceAccountEmail, spec.oci.gcpServiceAccountEmail ou spec.helm.gcpServiceAccountEmail) pour vous authentifier auprès de Cloud Source Repositories ou d'Artifact Registry, le compte de service Google doit disposer de l'accès lecteur suivant :

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

Si le compte de service ne dispose pas de ces rôles, git-sync, oci-sync ou helm-sync échoue avec des erreurs semblables à ce qui suit :

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 ...

Pour résoudre ce problème, accordez au compte de service l'accès approprié au lecteur.

Liaison de stratégie IAM manquante avec Workload Identity

Lorsque vous utilisez un compte de service Google pour l'authentification, une liaison de stratégie IAM est requise entre le compte de service Google et le compte de service Kubernetes. Si la liaison de stratégie IAM est manquante, vous obtenez l'erreur suivante :

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"

Pour résoudre le problème, créez la liaison de stratégie IAM suivante :

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

Remplacez les éléments suivants :

  • PROJECT_ID : si vous utilisez GKE Workload Identity, ajoutez l'ID de projet de votre organisation. Si vous utilisez Workload Identity de votre parc, vous pouvez utiliser deux ID de projet différents. Dans serviceAccount:PROJECT_ID, ajoutez l'ID de projet du parc dans lequel votre cluster est enregistré. Dans GSA_NAME@PROJECT_ID, ajoutez un ID de projet pour tout projet disposant d'un accès en lecture au dépôt dans Cloud Source Repositories.

  • KSA_NAME : compte de service Kubernetes pour le rapprochement. Pour les dépôts racine, si le nom RootSync est root-sync, KSA_NAME est défini sur root-reconciler. Sinon, il est défini sur root-reconciler-ROOT_SYNC_NAME.

    Pour les dépôts d'espaces de noms, si le nom RepoSync est repo-sync, KSA_NAME est défini sur ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME.

  • GSA_NAME : compte de service Google personnalisé que vous souhaitez utiliser pour vous connecter à Cloud Source Repositories. Assurez-vous que le compte de service Google que vous sélectionnez dispose du rôle source.reader.

La création de cette liaison de stratégie nécessite l'autorisation iam.serviceAccounts.setIamPolicy.

Assurez-vous que l'identité de charge de travail du parc est activée sur vos clusters enregistrés. Pour en savoir plus, consultez la page Créer un cluster. Si votre cluster se trouve dans un projet différent du projet hôte du parc, vous devez lier le compte de service Google au compte de service Kubernetes dans le projet hôte de parc.

Champ d'application cloud-platform manquant pour accéder à Cloud Source Repositories

Lorsque vous autorisez un compte de service Google à accéder à votre dépôt Git dans Cloud Source Repositories, le champ d'application en lecture seule doit être inclus dans les niveaux d'accès pour les nœuds du cluster.

Le champ d'application en lecture seule peut être ajouté en incluant cloud-source-repos-ro dans la liste --scopes spécifiée lors la création du cluster ou en utilisant le champ d'application cloud-platform au moment de la création du cluster. Exemple :

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

Si le champ d'application en lecture seule est manquant, vous obtenez une erreur semblable à celle-ci :

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

Champ d'application storage-ro manquant pour accéder à Artifact Registry

Lorsque vous utilisez Artifact Registry, les couches d'image sont conservées dans des buckets Cloud Storage. Lorsque vous autorisez un compte de service Google à accéder à votre image OCI ou à votre chart Helm dans Artifact Registry, le champ d'application en lecture seule doit être inclus dans les niveaux d'accès pour les nœuds du cluster.

Le champ d'application en lecture seule peut être ajouté en incluant storage-ro dans la liste --scopes spécifiée lors la création du cluster ou en utilisant le champ d'application cloud-platform au moment de la création du cluster. Exemple :

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

Si le champ d'application en lecture seule est manquant, vous obtenez une erreur semblable à celle-ci :

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

Le message d'erreur peut ne pas inclure tous les détails sur la cause de l'erreur, mais il fournit une commande qui imprime les journaux du conteneur git-sync qui peuvent contenir plus d'informations.

Si vous avez activé les API RootSync ou RepoSync, exécutez la commande suivante :

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

Si vous n'avez pas activé les API RootSync ou RepoSync, exécutez la commande suivante :

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

Les API RootSync et RepoSync sont activées par défaut si vous utilisez la console Google Cloud ou Google Cloud CLI pour installer Config Sync et que vous ne pouvez pas le désactiver.

Étapes suivantes