web-dev-qa-db-fra.com

L'utilisateur ne dispose pas d'un accès storage.objects.list au compartiment

J'ai créé un compte de service et attribué ces rôles:

Owner
Storage Admin
Storage Object Admin
Tester

Tester est un rôle que j'ai créé à des fins d'apprentissage avec ces autorisations:

storage.buckets.create
storage.buckets.delete
storage.buckets.get
storage.buckets.getIamPolicy
storage.buckets.list
storage.buckets.setIamPolicy
storage.buckets.update
storage.objects.create
storage.objects.delete
storage.objects.get
storage.objects.getIamPolicy
storage.objects.list
storage.objects.setIamPolicy
storage.objects.update
...

Je sais que j'exagère inutilement les autorisations avec ces rôles; mais, ce n'est qu'à des fins de test.

Étant donné que le bucket ne contient qu'un seul fichier et que le compte dispose des autorisations correspondantes, le code Python ci-dessous devrait fonctionner (s'exécutant sur mon ordinateur local):

from google.cloud import storage


if __name__ == '__main__':
    storage_client = storage.Client()
    bucket = storage_client.bucket('my-bucket-name')
    blobs = bucket.list_blobs()
    for blob in blobs:
        print(blob.name)

Mais ce n'est pas le cas:

Traceback (most recent call last):
  File "gcloud/test.py", line 8, in <module>
    for blob in blobs:
  File "/home/user/.local/lib/python3.6/site-packages/google/api_core/page_iterator.py", line 212, in _items_iter
    for page in self._page_iter(increment=False):
  File "/home/berkay/.local/lib/python3.6/site-packages/google/api_core/page_iterator.py", line 243, in _page_iter
    page = self._next_page()
  File "/home/user/.local/lib/python3.6/site-packages/google/api_core/page_iterator.py", line 369, in _next_page
    response = self._get_next_page_response()
  File "/home/user/.local/lib/python3.6/site-packages/google/api_core/page_iterator.py", line 419, in _get_next_page_response
    method=self._HTTP_METHOD, path=self.path, query_params=params
  File "/home/user/.local/lib/python3.6/site-packages/google/cloud/_http.py", line 421, in api_request
    raise exceptions.from_http_response(response)
google.api_core.exceptions.Forbidden: 403 GET LINK: USER does not have storage.objects.list access to BUCKET.

Le compartiment utilise un contrôle d'accès uniforme au niveau du compartiment. Le compte de service que j'utilise est membre de ce compartiment et hérite de cette appartenance de:

Storage Admin
Storage Object Admin
Tester

Quelqu'un peut-il m'expliquer la raison de ce comportement?

Merci

pythongoogle-cloud-platformgoogle-cloud-storage
2
deebug

Personnellement, je crois que dans le développement/les tests, il n'est pas nécessaire d'éviter de sur-attribuer des rôles. Mais si vous attribuez définitivement plusieurs rôles, vous pouvez aussi bien donner un rôle d'administrateur au lieu de plusieurs rôles plus petits (car ils font essentiellement tous les deux le même travail, mais avec des rôles moins importants)

Pour votre problème spécifique ici, je suggère

  1. Supprimer votre ancien compte de service
  2. Créez un nouveau compte de service et attribuez les rôles de storage.admin et storage.object.admin
  3. Utilisez ce compte de service

Il y a un article similaire sur SO, et cela semblait être résolu de la même manière.

Pour les futurs lecteurs: si le problème persiste, désinstallez complètement gcloud-sdk et réinstallez ( en utilisant ce lien ) avec la dernière version.

1
DuDoff

C'est pourquoi j'ai demandé si vous aviez fait passer ce seau à un contrôle d'accès uniforme au niveau du seau ou si vous l'aviez créé. Ma théorie est que vous l'avez fait passer au niveau de compartiment uniforme et déclenché cette clause de non-responsabilité.

Attention: Si vous activez l'accès uniforme au niveau du compartiment, vous révoquez l'accès des utilisateurs qui obtiennent leur accès uniquement via les ACL d'objets. Assurez-vous de lire les considérations lors de la migration d'un compartiment existant avant d'activer un accès uniforme au niveau du compartiment.

C'est pourquoi cela fonctionne lorsque vous ajoutez le rôle manuellement.

Vous pouvez en savoir plus sur le fonctionnement des autorisations d'accès uniformes au niveau du compartiment, ici .

Voici des informations plus pertinentes sur ce qui se passait.

En outre, si vous activez un accès uniforme au niveau du bucket dans le cadre de la création d'un nouveau bucket, le bucket reçoit automatiquement des rôles Cloud IAM supplémentaires. Ce comportement conserve l'autorisation que les objets ont hérité des ACL d'objets par défaut du compartiment. Si vous activez un accès uniforme au niveau du compartiment sur un compartiment existant, vous devez appliquer ces rôles manuellement; vous souhaiterez peut-être appliquer un ensemble de rôles différent si vous avez modifié les listes de contrôle d'accès par défaut des objets du compartiment.

Aussi ceci que je comprends comme une explication de l'erreur que nous obtenons.

Une fois activée, la fonctionnalité ACL suivante cesse:

Les demandes de définition, de lecture ou de modification des ACL de compartiment et d'objet échouent avec 400 erreurs de demande incorrecte.

J'espère que cela t'aides.

2
Stefan G.