【问题标题】:User does not have storage.objects.list access to bucket用户没有存储桶的 storage.objects.list 访问权限
【发布时间】:2019-12-20 09:24:27
【问题描述】:

我创建了一个服务帐户并分配了以下角色:

Owner
Storage Admin
Storage Object Admin
Tester

Tester 是我为学习目的创建的角色,具有以下权限:

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

我知道我不必要地过度使用这些角色的权限;但是,这只是为了测试目的。

考虑到bucket只包含一个文件并且账户有相应的权限,下面的Python代码应该可以工作(在我的本地计算机上运行):

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)

但它没有:

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.

桶使用统一的桶级访问控制。我正在使用的服务帐户是此存储桶的成员,它从以下位置继承此成员资格:

Storage Admin
Storage Object Admin
Tester

有人能解释一下这种行为背后的原因吗?

谢谢

【问题讨论】:

  • 你是把这个桶切换到“统一桶级访问控制”还是这样创建的?
  • @StefanG。如果我不手动分配权限(gsutil acl ch -u),这两种情况都不起作用。如果该用户已经继承了角色,为什么我必须手动授予权限?例如 serviceuser1 已经继承了角色 Storage Object Admin。但我仍然需要单击“添加成员”并手动赋予该角色以使其正常工作。
  • gcloud 使用的是什么帐号? gcloud auth list
  • @mirana 我有 2 个凭据帐户:一个是我的 gmail 帐户,另一个是活动帐户。我通过gcloud iam service-accounts keys create 为服务用户创建了密钥并使用gcloud auth activate-service-account 激活。
  • @mirana 好的,我删除了旧的服务帐户,创建了一个只有存储对象管理员角色的新服务帐户,为其创建了密钥,设置帐户并激活。目前,一切正常。谢谢 :) 请提交您的评论作为答案。

标签: python google-cloud-platform google-cloud-storage


【解决方案1】:

我个人认为在开发/测试中没有必要回避过度授予角色。但是,如果您确定要赋予多个角色,不妨赋予一个管理员角色而不是多个较小的角色(因为本质上它们都在做同样的工作,但角色较小)

对于您在这里的具体问题,我会建议

  1. 删除您的旧服务帐号
  2. 创建一个新的服务帐户并授予storage.adminstorage.object.admin 的角色
  3. 使用此服务帐号

在 SO 上有一个 similar post,这似乎以类似的方式解决。

对于未来的读者:如果问题仍然存在,请完全卸载 gcloud-sdk 并使用最新版本重新安装 (using this link)。

【讨论】:

    【解决方案2】:

    这就是为什么我问您是否将此存储桶切换到统一存储桶级访问控制或创建它。我的理论是您将其切换到统一存储桶级别并触发了此免责声明。

    警告:如果您启用统一存储桶级访问权限,您将撤消仅通过对象 ACL 获得访问权限的用户的访问权限。在启用统一存储桶级访问之前,请务必阅读迁移现有存储桶时的注意事项。

    这就是手动添加角色时它起作用的原因。

    您可以阅读更多关于统一存储桶级访问权限如何工作的信息,here

    这里有更多与正在发生的事情相关的信息。

    此外,如果您在创建新存储桶时启用统一存储桶级访问权限,则该存储桶会自动接收额外的 Cloud IAM 角色。此行为维护对象从存储桶的默认对象 ACL 继承的权限。如果您在现有存储桶上启用统一存储桶级别访问,则必须手动应用任何此类角色;如果您更改了存储桶的默认对象 ACL,则可能需要应用一组不同的角色。

    我也将其理解为对您遇到的错误的解释。

    启用后,以下 ACL 功能将停止:

    设置、读取或修改存储桶和对象 ACL 的请求失败并显示 400 错误请求错误。

    希望这会有所帮助。

    【讨论】:

    • 我看到了该警告,并创建了一个具有统一级别访问权限的新存储桶以进行测试。我的服务用户再次继承了角色,但它仍然给我同样的错误。如果我返回并手动将其添加为具有已继承的相同角色的成员,则一切正常。
    【解决方案3】:

    我在创建之前尝试检查我的项目中是否已经存在存储桶时遇到了这个问题,在我的情况下,这并不是说角色问题,因为我的服务帐户有一个存储管理员、存储对象管理员和创建者角色但是事实证明,我试图检查存在/创建的存储桶名称(从我的 python 代码中)不是全局唯一的。当我将存储桶的名称更改为全局唯一的名称时,错误就消失了。

    【讨论】:

      【解决方案4】:

      这对我有用:

      gsutil defacl ch -u \
          <project-number-compute>@developer.gserviceaccount.com:OWNER \
          gs://bucket
      

      查看更多:https://cloud.google.com/storage/docs/gsutil/commands/defacl

      【讨论】:

        猜你喜欢
        • 2021-05-01
        • 2020-11-17
        • 2020-11-11
        • 2018-02-22
        • 1970-01-01
        • 2023-02-21
        • 1970-01-01
        • 2020-12-03
        • 1970-01-01
        相关资源
        最近更新 更多