web-dev-qa-db-fra.com

gsutil ServiceException: 401 appelant anonyme n'a pas d'accès storage.objects.list au compartiment même si je suis connecté à gcloud

J'essaie de créer une application interne pour télécharger des fichiers sur Google Cloud. Je ne veux pas que chaque utilisateur ou cette application se connecte, j'utilise donc un compte de service. Je me connecte au compte de service et tout va bien, mais lorsque j'essaie de le télécharger, l'erreur suivante est générée: ServiceException: 401 Un appelant anonyme n'a pas storage.objects.list accès au compartiment

 This is the error that I get

Comme vous pouvez le voir, je suis connecté avec un compte de service et mon compte et (ni service, ni personnel) fonctionne

google-cloud-storagegcloudgsutil
2
Daniel Tranca

Je ne peux penser qu'à quelques petites choses qui pourraient vous faire voir cette erreur:

  1. Peut-être avez-vous un alias configuré pour une installation autonome de gsutil (qui ne partage pas les informations d'identification avec gcloud)?
    Modifier: il est également possible que vous appeliez le mauvais point d’entrée gsutil - assurez-vous d’utiliser <path-to-cloud-sdk>/google-cloud-sdk/bin/gsutil et non <path-to-cloud-sdk>/google-cloud-sdk/platform/gsutil/gsutil. Le chemin platform ne saura pas automatiquement quelles sont vos options d'authentification gcloud configurées.
  2. Peut-être que vos identifiants de compte de service ont été déplacés/sont invalides maintenant? Si votre fichier boto fait référence à un chemin de fichier de clés et que le fichier de clés a été déplacé, cela peut se produire.

  3. Peut-être que le fichier gcloud boto (créé par gcloud pour être utilisé avec gsutil lors de l'exécution de gcloud auth login) a disparu. Vous pouvez exécuter gsutil version -l pour voir s’il est affiché dans votre chemin de configuration. Si le fichier boto de gcloud est présent, vous devriez voir une ligne semblable à ceci:

    chemin (s) de configuration: /Users/Daniel/.config/gcloud/legacy_credentials/[email protected]/.boto

Vous pouvez exécuter gsutil version -l pour obtenir un peu plus d’informations et examiner les possibilités ci-dessus. En particulier, ces attributs de sortie seront probablement les plus utiles: using cloud sdk, pass cloud sdk credentials to gsutil, config path(s) et gsutil path.

3
mhouglum

Votre compte de service dispose-t-il réellement de la permission requise ? Le rôle (s) qui vous donnera cette autorisation sont roles/storage.objectViewer/roles/storage.objectAdmin/roles/storage.admin.

Veuillez vous assurer que le compte de service dispose réellement des autorisations dans votre console Cloud, puis cela devrait fonctionner.

--- METTRE À JOUR ---

Puisque vous avez la bonne autorisation dans le compte, il est probable que le compte correct n'a pas été utilisé dans la commande gsutil. Cela peut arriver si vous avez plusieurs installations de votre outil gsutil, veuillez vous assurer que votre gsutil a le chemin correct pointé vers un fichier .BOTO. Un problème similaire a été signalé sur github repo . Vous pouvez voir si la solution fonctionne.

En fin de compte, vous pouvez utiliser une nouvelle machine/vm avec une nouvelle installation pour le tester et voir s'il fonctionne. Vous pouvez le faire facilement en accédant à la console Cloud et en utilisant le Cloud Shell . Aucune installation réelle nécessaire, devrait être très simple à tester.

Cela devrait fonctionner et cela isolera fondamentalement votre problème (par rapport à celui d'une installation multiple) sur votre ordinateur d'origine. Après cela, il vous suffit de faire une nouvelle installation pour y remédier.

1
Ying Li