各種のユースケースをサポートする認証情報の種類
概要
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 -i
、gsutil 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 をご覧ください。