Cloud Storage の認証

Cloud Storage で実行するほとんどのオペレーションは認証される必要があります。唯一の例外は、匿名アクセスが許可されているオブジェクトに対するオペレーションです。allUsers グループに READ 権限がある場合は、オブジェクトに匿名でアクセスできます。allUsers グループには、インターネット上のすべての人が含まれます。

OAuth 2.0

認証

Cloud Storage は、OAuth 2.0 を使って API の認証と認可を行います。認証とは、クライアントの身元を確認するプロセスを指します。認証の詳細は、Cloud Storage へのアクセス方法によって変わりますが、一般的に以下の 2 種類のいずれかになります。

  • サーバー中心のフローでは、認証を行うためのサービス アカウントの認証情報を、アプリケーションが直接保持します。このフローは、アプリケーションがユーザーデータではなくアプリケーション自体のデータを処理する場合に使用します。Google Cloud プロジェクトでは、デフォルト サービス アカウントを使用するか、新しいサービス アカウントを作成できます。

  • ユーザー中心のフローでは、アプリケーションがエンドユーザーから認証情報を取得できます。ユーザーは、認証を完了するためにログインします。このフローは、アプリケーションがユーザーデータにアクセスする必要がある場合に使用します。ユーザー中心のフローが適しているシナリオについては、このページで後述するユーザー アカウント認証情報のセクションをご覧ください。

両方の種類の認証を 1 つのアプリケーションで使用できることができます。認証の詳しい背景情報については、Google Cloud Auth ガイドをご覧ください。

スコープ

承認とは、認証されたユーザーが、指定のリソースに対してどのような権限を持つかを判定するプロセスを指します。OAuth 2.0 では、認証されたユーザーを承認するかどうかを判定するために、スコープを使用します。アプリケーションは認証情報(ユーザー中心の認証フローやサーバー中心の認証フローで取得したもの)と、1 つ以上のスコープを使って、保護されたリソースにアクセスするためのアクセス トークンを Google 承認サーバーに要求します。たとえば、スコープが read-only に設定されたアクセス トークンを持つアプリケーション A にはデータの読み取りのみが許可されますが、スコープが read-write に設定されたアクセス トークンを持つアプリケーション B には、データの読み取りと変更が許可されます。いずれのアプリケーションもオブジェクトとバケットに適用されるアクセス制御リストの読み取りと変更は許可されません。これらの操作を行えるのは、full-control のスコープを持つアプリケーションのみです

説明 スコープの URL
read-only バケットの一覧表示を含め、データを読み取るためのアクセスのみを許可します。 https://www.googleapis.com/auth/devstorage.read_only
read-write データの読み取りと変更のアクセスは許可しますが、IAM ポリシーなどのメタデータへのアクセスは許可しません。 https://www.googleapis.com/auth/devstorage.read_write
full-control IAM ポリシーの変更を含め、データに対する完全アクセス権を許可します。 https://www.googleapis.com/auth/devstorage.full_control
cloud-platform.read-only Google Cloud サービス全体のデータを表示します。Cloud Storage の場合、これは devstorage.read-only と同じです。 https://www.googleapis.com/auth/cloud-platform.read-only
cloud-platform すべての Google Cloud サービスにわたるデータを表示して管理します。Cloud Storage の場合、これは devstorage.full-control と同じです。 https://www.googleapis.com/auth/cloud-platform

gsutil 認証

gsutilgcloud CLI からインストールした場合、認証にはサービス アカウント認証情報を使用する必要があります。

  1. 既存のサービス アカウントを使用するか、新規サービス アカウントを作成し、必要な秘密鍵をダウンロードします。サービス アカウント キーの秘密鍵をダウンロードできるのは、キーが最初に作成されるときのみです。

  2. gcloud auth activate-service-account を使用して、サービス アカウントで認証を行います。

    gcloud auth activate-service-account --key-file KEY_FILE

    ここで KEY_FILE は、サービス アカウント認証情報を含むファイルの名前です。

gcloud auth は、アクセス トークンを取得する際に cloud-platform スコープを使用します。

gsutil を gcloud CLI 以外でインストールした場合は、gsutil のインストール ページで認証方法を確認してください。

クライアント ライブラリの認証

Client libraries can use Application Default Credentials to easily authenticate with Google APIs and send requests to those APIs. With Application Default Credentials, you can test your application locally and deploy it without changing the underlying code. For more information, including code samples, see Google Cloud Auth Guide.

  • Google Cloud

    App Engine または Compute Engine でアプリケーションを実行している場合は、環境内でサービス アカウントの認証情報がすでに用意されているため、それ以上の設定は必要ありません。Compute Engine の場合、サービス アカウントのスコープは、インスタンスを作成した方法に依存します。インスタンスに対するサービス アカウント アクセスのスコープの設定をご覧ください。App Engine では、cloud-platform スコープが使用されます。

  • その他の環境

    ローカルの開発環境または本番環境を初期化するには、Google Cloud サービス アカウントを作成し、鍵をダウンロードして、その鍵を使用するように GOOGLE_APPLICATION_CREDENTIALS 環境変数を設定します。詳しい手順については、Cloud Storage クライアント ライブラリを使用した認証の設定をご覧ください。環境変数を設定する代わりに、サービス アカウント キーを直接コードで使用することもできます。

API の認証

OAuth 2.0 を使って Cloud Storage の XML API または JSON API に対するリクエストを行う場合は、認証が必要なすべてのリクエストの Authorization ヘッダーにアプリケーションのアクセストークンを指定します。アクセス トークンは OAuth 2.0 Playground で生成できます。

  1. OAuth 2.0 PlaygroundCloud Storage API v1 をクリックし、アプリケーションのアクセスレベル(full_controlread_only、または read_write)を選択します。

  2. [Authorize APIs] をクリックします。

  3. メッセージが表示されたら、Google アカウントにログインします。表示されたダイアログで、[許可] をクリックします。

  4. Playground のステップ 2 で、表示された認証コードの [Exchange authorization code for tokens] をクリックします。

  5. アクセス トークンをコピーし、リクエストの Authorization ヘッダーに含めます。

    Authorization: Bearer OAUTH2_TOKEN

以下に、バケット内のオブジェクトを一覧表示するリクエストの例を示します。

JSON API

Objects リソースの list メソッドを使用します。

GET /storage/v1/b/example-bucket/o HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

コマンドラインを使用してリクエストを承認する場合、またはテスト目的でリクエストを承認する場合は、次の構文の curl コマンドを使用できます。

curl -H "Authorization: Bearer OAUTH2_TOKEN" "https://storage.googleapis.com/storage/v1/b/BUCKET_NAME/o"

ローカルテストでは、gcloud auth application-default print-access-token コマンドを使用してトークンを生成できます。

XML API

オブジェクトのリスト リクエストを使用します。

GET / HTTP/1.1
Host: example-bucket.storage.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

コマンドラインを使用してリクエストを承認する場合、またはテスト目的でリクエストを承認する場合は、次の構文の curl コマンドを使用できます。

curl -H "Authorization: Bearer OAUTH2_TOKEN" "https://BUCKET_NAME.storage.googleapis.com"

ローカルテストでは、gcloud auth application-default print-access-token コマンドを使用してトークンを生成できます。

アクセストークンの管理と更新は複雑な作業であり、暗号アプリケーションを直接扱うとセキュリティ上のリスクがあるため、検証済みのクライアントライブラリを使用することを強くおすすめします。

Amazon S3 との相互運用可能なアクセスのために XML API で使用する HMAC キーが必要な場合は、サービス アカウントの HMAC キーの管理をご覧ください。

ユーザー アカウント認証情報

認証のためのユーザー アカウント認証情報は、アプリケーションがユーザーの代わりにデータにアクセスする必要がある場合に使用します。それ以外の場合はサービス アカウント認証情報を使用します。以下は、ユーザー アカウント認証情報を使用できるシナリオの例です。

  • ウェブサーバーアプリケーション
  • インストールされたアプリケーションとデスクトップアプリケーション
  • モバイルアプリ
  • クライアント側の JavaScript
  • 入力が限られたデバイス上のアプリケーション

これらのシナリオの詳細については、OAuth 2.0 のシナリオをご覧ください。

エンドユーザー向けに複数の認証オプションをサポートするアプリケーションを設計している場合は、Firebase 認証を使用します。メールとパスワードによる認証に加えて、Google、Facebook、Twitter、GitHub などの ID プロバイダを使用した連携ログインがサポートされています。別のユースケースで認証システムを設定する方法については、Firebase Authentication の開始方法をご覧ください。

ユーザー中心の認証フローで、エンドユーザーによりアクセス トークンが許可されている場合、そのアクセス トークンは、トークンを許可するユーザーが使用できる権限のみを持ちます。たとえば、jane@gmail.com に example-bucket に対する read-only アクセスが許可されている場合、Jane から read-write アクセス権が付与されたアプリケーションは、彼女に代わって example-bucket に書き込みを行うことはできません。

次のステップ