サービスアカウントを作成し、次の役割を割り当てました。
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
...
私はこれらの役割で権限を不必要に過剰に実行していることを知っています。ただし、これはテスト用です。
バケットには単一のファイルのみが含まれ、アカウントには対応する権限があるため、以下の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
誰かがこの動作の背後にある理由を私に説明できますか?
ありがとう
私は個人的には、開発/テストを行うことで、過剰な役割を回避する必要はないと考えています。ただし、複数の役割を確実に与える場合は、複数の小さい役割ではなく管理者の役割を与えることもできます(基本的には両方とも同じ役割を果たしますが、役割は少なくなります)。
ここであなたの特定の問題について、私はお勧めします
storage.admin
とstorage.object.admin
の役割を付与しますSOには similar post があり、それは同様の方法で解決されたようです。
今後の読者向け:問題が解決しない場合は、gcloud-sdk
を完全にアンインストールし、最新バージョンで再インストール( このリンクを使用 )してください。
そのため、このバケットを均一なバケットレベルのアクセス制御に切り替えるか、作成したかを尋ねました。私の理論では、あなたはそれを均一なバケットレベルに切り替えて、この免責事項を引き起こしました。
注意:均一なバケットレベルのアクセスを有効にすると、オブジェクトACLのみを介してアクセス権を取得したユーザーからのアクセス権が取り消されます。均一なバケットレベルのアクセスを有効にする前に、既存のバケットを移行するときの考慮事項を必ずお読みください。
そのため、手動でロールを追加するときに機能します。
均一なバケットレベルのアクセス許可がどのように機能するかについては、 here を参照してください。
ここに何が起こっていたかに関連する情報があります。
また、新しいバケットの作成の一環として均一なバケットレベルのアクセスを有効にすると、バケットは自動的に追加のCloud IAM役割を受け取ります。この動作は、バケットのデフォルトオブジェクトACLから継承されたオブジェクトの権限を維持します。既存のバケットで均一なバケットレベルのアクセスを有効にする場合は、そのような役割を手動で適用する必要があります。バケットのデフォルトオブジェクトACLを変更した場合は、別の役割のセットを適用することができます。
また、これは、発生しているエラーの説明として理解しています。
有効にすると、次のACL機能が停止します。
バケットとオブジェクトのACLを設定、読み取り、または変更するリクエストは、400 Bad Requestエラーで失敗します。
お役に立てれば。