各種のユースケースをサポートする認証情報の種類

概要

gsutil は現在、複数の種類の認証情報 / 認証に対応しています。以下では、これらの認証情報の種類について詳しく説明します。また、Cloud SDK で認証情報を構成して使用する方法についても簡単に説明します。

gsutil の Cloud SDK ディスリビューションによる認証情報の構成と使用

gsutil を Cloud SDK 経由でインストールし、使用している場合(gcloud)、Cloud SDK が ~/.config/gcloud の下にあるファイルに認証情報を保存します。ユーザーはこのファイルを編集できません。認証情報を操作するには、gcloud auth コマンドを実行する必要があります。複数の認証情報を設定する必要がある場合(たとえば、1 つをユーザー アカウントに使用し、もう 1 つをサービス アカウントに使用する場合)、gcloud auth コマンドを使用して認証情報を切り替えます。詳細については、https://cloud.google.com/sdk/gcloud/reference/auth をご覧ください。

gcloud auth で認証情報が構成されると、ユーザーに boto 構成ファイルがあるかどうかにかかわらず、これらの認証情報が使用されます(BOTO_CONFIG 環境変数に別のパスが指定されていない限り、この構成ファイルは、~/.boto にあります)。ただし、gcloud 認証情報ストアにない Cloud Storage 以外の認証情報(たとえば、S3 アカウントの HMAC 認証情報)が必要になると、gsutil は boto 構成ファイルで認証情報を探します。

サポートされる認証情報の種類

gsutil では、いくつかの種類の認証情報をサポートしています。先ほどの説明のように、使用している gsutil のディストリビューションによって使用可能な認証情報が異なります。

OAuth2 ユーザー アカウント:

このタイプの認証情報は、特定のユーザーの代わりにリクエストを認証する場合に使用できます(gsutil で最もよく利用されます)。これは、gcloud init の実行時に作成されるデフォルトの認証情報です。この認証情報タイプは、gsutil のスタンドアロン バージョンではサポートされていません。OAuth2 認証の詳細については、https://developers.google.com/accounts/docs/OAuth2#scenarios をご覧ください。

HMAC:

このタイプの認証情報は、HMAC 認証を使用しているプログラムで使用されます。この認証方法は、他のクラウド ストレージ サービス プロバイダでサポートされています。また、この種類の認証情報は、HMAC 認証情報に対応しているサービス プロバイダ間でデータを移動する場合にも使用されます。これは、gsutil config -a の実行時に作成される認証情報です。

Cloud Storage と別のサービス プロバイダの両方に HMAC 認証情報を設定できます。また、Cloud Storage に OAuth2 ユーザー アカウントの認証情報を設定し、別のサービス プロバイダに HMAC 認証情報を設定することもできます。この設定を行うには、gcloud init コマンドを実行した後に、生成された ~/.boto 構成ファイルを編集し、他の認証情報を追加できる場所のコメントを探します。

HMAC 認証の詳細については、Cloud Storage の HMAC キーをご覧ください。

OAuth2 サービス アカウント:

これは、(ユーザーの代わりにではなく)サービスまたはアプリケーションの代わりに認証を行う場合に使用できる認証情報です。たとえば、夜間の cron ジョブで gsutil を実行し、データのアップロード / ダウンロードを実行する場合、サービス アカウントを使用すると、従業員の認証情報に依存することなく、cron ジョブを実行できます。このタイプの認証情報が構成されるのは、--cred-file フラグを指定して gcloud auth login を実行する場合(または、gsutil のスタンドアロン バージョンの使用中に gsutil config -e を実行する場合)です。

通常、この認証情報タイプは使用しないでください。高度な権限を持つ認証情報をローカル環境に保存する必要があるため、セキュリティ リスクが生じる可能性があります。サービスまたはアプリケーションの代わりに認証を行う場合は、サービス アカウントの権限借用や Workload Identity 連携を使用することをおすすめします。

デフォルトでは、API アクセスの場合、サービス アカウントはオーナーではなく編集者と見なされます。デフォルトのオブジェクト / バケット ACL では、編集者に OWNER アクセス権が設定されていますが、定義済み ACL オプションでは編集者から OWNER アクセス権が削除されています。このため、予期しない結果が生じる可能性があります。この問題を回避するには、「gsutil acl set <predefined-ACL>」ではなく「gsutil acl ch」を使用してバケットの権限を変更します。

gsutil で使用するサービス アカウントを設定するには、サービス アカウント キーを使用してサービス アカウントを承認するをご覧ください。

OAuth2 サービス アカウントの詳細については、サーバー間アプリケーションに OAuth 2.0 を使用するをご覧ください。

Compute Engine の内部サービス アカウント:

この種類のサービス アカウントは、App Engine または Compute Engine でホストされたアカウントで使用されます。この認証情報は、gcloud compute instances create コマンドを実行すると Compute Engine で自動的に作成されます。この認証情報は --scopes フラグで制御できます。

Compute Engine でのワークロードの認証にサービス アカウント認証情報を使用する方法については、https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances をご覧ください。

App Engine サービス アカウントの詳細については、https://developers.google.com/appengine/docs/python/appidentity/overview をご覧ください。

サービス アカウントの権限借用

サービス アカウントの権限借用は、特定のリソースに短期間のアクセス権を付与する必要がある場合に便利です。たとえば、通常は読み取り専用であり、信頼されたサービス アカウントによって一時的に書き込みアクセスを付与する、機密性の高いデータのバケットがある場合です。

権限借用に使用するサービス アカウントを指定するには、gsutil -igsutil config -e を実行して boto 構成ファイル(gcloud config set auth/impersonate_service_account [service_account_email_address])を編集します。

権限借用を行うには、元の認証情報にターゲット サービス アカウントの roles/iam.serviceAccountTokenCreator を付与する必要があります。詳細については、https://cloud.google.com/docs/authentication/use-service-account-impersonation をご覧ください。

外部アカウント認証情報(Workload Identity 連携):

Workload Identity 連携を使用すると、アマゾン ウェブ サービス(AWS)、Microsoft Azure、または OpenID Connect(OIDC)か SAML 2.0 をサポートする任意の ID プロバイダから Google Cloud リソースにアクセスできます。

詳細については、https://cloud.google.com/iam/docs/workload-identity-federation をご覧ください。