Anthropic ClaudeDevOps・インフラ⭐ リポ 0品質スコア 50/100

google-cloud-recipe-auth

Name: google-cloud-recipe-auth
Author: google

Google Cloudのサービスおよび APIへの認証・認可に関する専門的なガイダンスを提供します。人間ユーザー、サービスアカウント、Application Default Credentials（ADC）の活用方法から、セキュアなアクセスのベストプラクティスまでを網羅しています。

description の原文を見る

Provides expert guidance on authenticating and authorizing to Google Cloud services and APIs, covering human users, service identities, Application Default Credentials (ADC), and best practices for secure access.

SKILL.md 本文

Google Cloud への認証

認証とは、あなたが誰であるかを証明するプロセスです。Google Cloud では、プリンシパル（ユーザーやサービスなどの識別情報）として表現されます。これは認可（何ができるかを決定する）の前のステップです。

認証

エージェント向けの質問事項

具体的なソリューションを提供する前に、ユーザーに以下を確認してください：

誰または何が認証していますか？（人間の開発者、ローカルスクリプト、または本番環境で実行されているアプリケーション？）
コードはどこで実行されていますか？（ローカルノートパソコン、Compute Engine、GKE、Cloud Run、または AWS/Azure などの他のクラウド？）
ターゲットは何ですか？（Storage/BigQuery などの Google Cloud API、またはあなたが構築したカスタムアプリケーション？）
高レベルのクライアントライブラリを使用していますか？（例えば Python、Go、Node.js ライブラリは通常 ADC を自動的に処理します）

人間による認証

ユーザーが Google Cloud にアクセスするには、Google Cloud が認識できる識別情報が必要です。

ユーザーアイデンティティのタイプ

Google Cloud は、社内ワークフォース（開発者、管理者、従業員）向けの識別情報を設定するための複数の方法をサポートしています：

Google が管理するアカウント：Cloud Identity または Google Workspace を使用してマネージドユーザーアカウントを作成できます。これらはマネージドアカウントと呼ばれます。なぜなら、あなたの組織がそのライフサイクルと設定を制御するためです。
Cloud Identity または Google Workspace を使用したフェデレーション：ユーザーが既存のアイデンティティと認証情報を使用して Google サービスにサインインできるよう、アイデンティティをフェデレーションできます。ユーザーは外部のアイデンティティプロバイダー（IdP）に対して認証されますが、Google Cloud Directory Sync（GCDS）や Active Directory または Microsoft Entra ID などの外部の信頼できるソースを使用して、アカウントを Google Cloud に同期させておく必要があります。
ワークフォース識別フェデレーション：外部 IdP を使用してワークフォースを認証および認可し、IAM を直接使用できます。標準的なフェデレーションとは異なり、既存の IdP から Google Cloud アイデンティティにユーザーアイデンティティを同期する必要はありません。同期なしの属性ベースのシングルサインオンをサポートしています。

開発者と管理者向けのアクセス方法

開発および管理中に Google Cloud リソースと API と対話するために使用されます。

Google Cloud コンソール：主要な Web インターフェース。Google アカウント（Gmail または Google Workspace）を使用して認証します。
gcloud CLI（gcloud auth login）：CLI 自体を認証するために使用され、管理コマンドを実行できます（例：gcloud compute instances list）。ローカルに保存された認証情報（OAuth 2.0 リフレッシュトークンなど）を使用します。
App Default Credentials（ADC）を使用したローカル開発（gcloud auth application-default login）：これは CLI 認証とは異なります。Google Cloud クライアントライブラリ（Python、Java など）がローカルノートパソコンでコードを実行するときに「あなた」として機能するために使用するローカル JSON ファイルを作成します。
サービスアカウント偽装：セキュリティ上の理由から、開発者はサービスアカウントキーを完全にダウンロードすることを避けるべきです。代わりに、人間として認証し（gcloud auth login）、サービスアカウント偽装を使用して CLI コマンドを実行するか、短期の認証情報を生成すべきです。これはローカル開発とトラブルシューティングにおける重要なベストプラクティスです。

エンドユーザーと顧客向け

開発者ではない人間が、Google Cloud にデプロイされた Web アプリケーションにアクセスする必要がある場合に使用されます。注：これらはワークフォース識別情報とは異なります。

Identity-Aware Proxy（IAP）：Web アプリケーション向けの中央認可レイヤーとして機能します。Web リクエストをインターセプトし、ユーザーのアイデンティティ（Google Workspace、Cloud Identity、または外部プロバイダー経由）を検証したうえで、アプリケーションにリクエストを到達させます。VPN なしで内部アプリを保護したり、顧客ポータルをセキュアにしたりするために使用されることが多いです。
Identity Platform：カスタムビルトアプリケーションのコードにコンシューマーサインイン（メール/パスワード、電話、ソーシャル）を直接追加するための Customer Identity and Access Management（CIAM）ソリューション。

サービス間認証

本番環境でコードを実行する場合、人間のユーザーアカウントではなく、サービスアカウントを使用すべきです。

サービスアカウントとサービスエージェント

サービスアカウント：非人間ユーザー向けの特別な識別情報。独自のメールアドレスを持つ「ロボット識別情報」のようなものです。
サービスエージェント：Google が管理するサービスアカウント。Pub/Sub などのサービスがあなたのリソースに代わってアクセスするために使用されます。

ベストプラクティス：サービスアカウントの接続

サービスアカウントキー（危険な JSON ファイル）を使用する代わりに、カスタムサービスアカウントを Google Cloud リソースに接続すべきです。リソースの環境はローカルメタデータサーバー経由でトークン（短期のデジタルオブジェクト）を提供します。

Compute Engine：VM 作成時にサービスアカウントを割り当てます。
Cloud Run：サービス設定でサービスアカウントを割り当てます。

特別なケースと高度なトピック

Kubernetes Engine（GKE）

GKE 用 Workload Identity Federation を使用して、Kubernetes アイデンティティを IAM プリンシパル識別子にマップします。これにより、特定の Kubernetes ワークロードに特定の Google Cloud API へのアクセス権を付与できます。詳細については、ここをご覧ください。

外部ワークロード（Workload Identity Federation）

Google Cloud 外部で実行されているコード（AWS、Azure、オンプレミスなど）の場合、キーを使用しないでください。代わりに、Workload Identity Federation を使用して、外部トークン（AWS IAM ロールなど）を短期の Google Cloud アクセストークンと交換します。

API キー

API キーは、公開データ（Google Maps など）または**Vertex AI Express Mode**などの簡略化されたアクセス用に使用される暗号化された文字列です。これにより、複雑なセットアップなしで Gemini モデルを高速にテストできます。人間とサービス（Cloud Run ベースの AI エージェントなど）の両方が、サポートされているサービスに対して API キーを使用できます。

注：API キーはセキュリティリスクを最小化するために、特定の API とプロジェクトに制限すべきです。Secret Manager などのシークレットマネージャーに API キーを保存して、予期しない公開を防いでください。

OAuth 2.0 アクセススコープ

IAM は認可を処理する最新の方法ですが、レガシーな Compute Engine VM と GKE ノードプールはなお IAM と並行してアクセススコープに依存しています。VM のスコープが制限されている場合、接続されたサービスアカウントが正しい IAM 権限を持っていても API 呼び出しに失敗します。接続されたサービスアカウントが予期せず失敗している場合は、まずこれを確認してください。

短期認証情報

偽装とセキュアなサービス間通信の基盤となるメカニズムは、IAM Service Account Credentials API です。この API は短期のアクセストークン、OpenID Connect（OIDC）ID トークン、または自己署名 JSON Web Token（JWT）を動的に生成し、静的な認証情報の必要性を排除します。

認可

認証後、Google Cloud は Identity and Access Management（IAM） を使用して、認証されたプリンシパルが何ができるかを決定します。

Allow Policy：プリンシパルをロールにリソース上でバインドするレコード。
事前定義ロール：roles/storage.objectViewer や roles/bigquery.dataEditor などの既成ロール。常にまずこれらを使用してみてください。
カスタムロール：事前定義ロールが広すぎる場合に、特定の権限のユーザー定義コレクション。

例

人間からサービスへ（ローカル Python 開発）

認証：gcloud auth application-default login を実行して、ローカル認証情報（ADC）を作成します。
認可：バケットに対してメールアドレスに roles/storage.objectViewer ロールを付与します。
コード：Python storage.Client() を使用します。ADC を介してローカル認証情報を自動的に検出します。注：ADC は特定の順序で検索します。まず GOOGLE_APPLICATION_CREDENTIALS 環境変数を確認し、次にローカルの gcloud JSON ファイル、最後に接続されたサービスアカウントメタデータサーバーです。

サービス間（Cloud Run から Cloud SQL へ）

認証：カスタムサービスアカウントを Cloud Run サービスに接続します。
認可：プロジェクトに対してそのサービスアカウントに roles/cloudsql.client ロールを付与します。
コード：Cloud Run 環境が接続ドライバーにトークンを自動的に提供します。

カスタムアプリケーションの呼び出し（OIDC）

別のサービスから非公開の Cloud Run サービスを呼び出す場合、呼び出し元は Google 署名のOpenID Connect（OIDC）ID トークンを生成し、Authorization: Bearer <TOKEN> ヘッダーで渡します。

検証チェックリスト

ユーザーはローカルでコードを実行していますか？gcloud auth application-default login またはサービスアカウント偽装を提案してください。
ユーザーはローカルでサービスアカウントキーを使用しようとしていますか？これを強く非推奨とし、偽装を推奨してください。
ユーザーは本番環境で実行していますか？カスタムの最小権限サービスアカウントを接続すること、キーを使用しないことを推奨してください。
ユーザーは Compute Engine デフォルトサービスアカウントに依存していますか？代わりにカスタムサービスアカウントを作成することを推奨してください。
ユーザーは別のクラウドで実行していますか？Workload Identity Federation を推奨してください。
ユーザーはカスタムアプリを呼び出していますか？OIDC ID トークンを推奨してください。
ユーザーは API キーを制限していますか？適切なAPI キー制限をチェックしてください。

参考資料

ライセンス: Apache-2.0(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

詳細情報

作者: google
リポジトリ: google/skills
ライセンス: Apache-2.0
最終更新: 不明

GitHubで原本を見る →フィードバックを送る

Source: https://github.com/google/skills / ライセンス: Apache-2.0