科学＆テクノロジー

Google Cloud Platform で適切に管理する方法

セキュリティと認証に関連する問題は、すべてのプラットフォームにとって不可欠です。 Google Cloud Platformも例外ではありません。セキュリティガバナンスを適切に管理し、CI/CD 経由で Gitlab などの外部環境から長期の認証情報を管理せずに Google リソースにアクセスするにはどうすればよいでしょうか?この記事の答えは… J-9 マチナーレデータと IA 2024 年 12 月 5 日 |08時30分～14時00分パリ登録する JSON キーを生成するだけでは十分ではありません Google のクラウド API に対する認証の通常の方法は、サービスアカウントのパスワードに似た JSON キーを生成し、それを「安全な」場所に保存することです。私の経験から、十分に安全な場所は存在しないことが分かりました…特に、ある朝「緊急会議: サービスアカウントのパスワードがハッキングされました」というメールを受信した場合はそうです。さらに、これらのキーの保護、保存、配布、ローテーション、監視は面倒な作業となる可能性があるため、この方法はお勧めできません。 Google は、「」を介して認証するより良い方法を推奨しています。 Workload…

執筆 nipponese 更新 2024年11月26日

1732598909
2024-11-25 12:00:00

J-9

マチナーレデータと IA

2024 年 12 月 5 日
|08時30分～14時00分
パリ

登録する

JSON キーを生成するだけでは十分ではありません

Google のクラウド API に対する認証の通常の方法は、サービスアカウントのパスワードに似た JSON キーを生成し、それを「安全な」場所に保存することです。

私の経験から、十分に安全な場所は存在しないことが分かりました…特に、ある朝「緊急会議: サービスアカウントのパスワードがハッキングされました」というメールを受信した場合はそうです。さらに、これらのキーの保護、保存、配布、ローテーション、監視は面倒な作業となる可能性があるため、この方法はお勧めできません。

Google は、「」を介して認証するより良い方法を推奨しています。 Workload Identity フェデレーション”。そこで、セキュリティを向上させ、Google Cloud リソースへのアクセス管理を簡素化するために私が考える最も安全な方法を説明します。最後に、GitLab CI の OpenID Connect (OIDC) 統合について説明します。これを行うために、Gitlab CI/CD パイプラインとリソース間のやり取りを保護するためのシナリオを示します。 Workload Identity フェデレーション » Googleから。 Google Cloud サービスアカウントキーを Gitlab CI 変数に保存しないようにするため。

Workload Identity Federation による認証に重点を置く

まず、Wordkload Identity Federation を介して Google Cloud で Gitlab CI/CD パイプラインを実装し、Google Cloud リソースにアクセスします。

したがって、以下の内容は、Git でアプリケーションのバージョンを管理したい人、および/または Google Cloud などのインフラストラクチャデプロイのために Terraform によってセットアップ (IAC) したい人すべてを対象としています。

要約すると、次のことがわかります。

Workload Identity Federation の概念と、GCP コンポーネントと外部アプリケーション間の相互作用について説明します。
GCP リソースにアクセスするための Workload Identity フェデレーションの構成。
すべての Cloud Storage バケットをリストするための Gitlab での CI パイプラインの作成。

1. Workload Identity の概念

Wordload Identity は、セキュリティの向上を目的として Google が提供するメカニズムです。これを実現するために、Gitlab/GitHub/Cloud などの他のサービスで認証する可能性が提供されます。これにより、Identity and Access Management サービスを使用して Google サービスにアクセスできるようになります。

このメカニズムにより、(変数に格納される従来のキーの場合のように) 有効期間の長い識別情報が不要になります。
サービスアカウントの使用を活用することで、全体的なセキュリティが向上しました。
詳細なスコープ設定: Google と外部アプリケーションの間で、トークンと利用可能な権限の間の詳細な属性マッピングを定義できます。
有効期間の短い認証情報: 有効期間が制限されたトークンの使用 (認証情報は作成後 1 時間で自動的に期限切れになります)。
最小限の管理オーバーヘッド: シークレットを保存または管理する必要はありません。

Workload Identity プールとプロバイダー

Workload Identity プール: 特定の Google Cloud プロジェクトにバインドし、すべてのアカウントサービスアカウントと外部 ID を ID システムとしてグループ化するコンテナとして。
Workload Identity Provider (AWS プロバイダ、GiLab プロバイダ、GitHub プロバイダ): これは、外部サービスのユーザーの ID と Google Cloud サービスとの間の接続を確立するために、いくつかのセキュリティルールを含む ID プロバイダです。これにより、誰が何にアクセスできるかを管理しやすくなります。

言い換えれば、Workload Identity Provider は、Google Cloud 上の外部アプリケーションの統合を目的とした Google Workload Identity Pool の (IDP) です。

セキュリティトークンサービス: Google 認証情報に基づいて Google Cloud リソースにアクセスするための有効期間の短いトークンを生成するサービスです。
サービスアカウント: Compute Engine インスタンスなどのアプリケーションまたはワークロードによって使用される、一意のメールアドレスで識別されるサービスアカウント（特定のアカウントを使用するよりも、サービスアカウントを使用する方が適切です）。
Google Cloud リソース: コンピュータ、ハードドライブ、VM マシンなどの仮想リソースなどのコンポーネントのコレクションです。Google Cloud リソースには、プロジェクト、キーリング、ストレージ、ツールなどが含まれます。

ワークロードは ID プロバイダーによって推定されます。
(アイデンティティプロバイダー) はアカウントの資格情報を送信します。
WorkLoad は、資格情報を Goole サービス (セキュリティトークン) に渡します。
情報がプール (Workload Identity プール) 内にある場合の情報の検証。
資格情報が有効かどうかを示す応答。
アカウントサービスアカウントになりすます、Google にアクセスするためのトークンの送信 (短期)。
一時トークンを使用してサービスアカウントになりすます。
Google Cloud リソースにアクセスします。

こちらもお読みください

Google Cloud Platform ハイパースケーラーでの ML から MLOps へ

構成 Workload Identity フェデレーション

手順 1 : Workload Identity プールの作成

Workload Identity フェデレーションを使用すると、外部 ID を整理して管理できます。

GCP プロジェクトには複数のプールを含めることができ、それぞれのプールで複数の外部 ID プロバイダーとの統合が可能になります。これにより、プロジェクトごとに ID とコントロールのコレクションを作成できます。

gcloud iam workload-identity-pools create
–プロジェクト= » »
–location= »グローバル »
–display-name= »GitLab プロジェクト ID の Workload Identity プール »

: Google Cloud プロジェクトの ID。セキュリティを向上させるには、リソースや CI/CD プロジェクトとは別に、専用の ID 管理プロジェクトを使用します。
: プールに使用する ID

ステップ 2: プールプロバイダーの作成

プロバイダ: Google Cloud と ID プロバイダの関係を記述するエンティティです。たとえば、Gitlab は次の IDP です。 ワークロード ID プール。 これを Google Cloud に統合するには、属性マッピングレベルでプロバイダを構成する必要があります。 属性マッピング » Google 側で、ワークロードを Google Cloud にデプロイするために必要な IAM 承認を取得します。

gcloud iam workload-identity-pools プロバイダー create-oidc
–workload-identity-pool=
–issuer-uri= # 例 « https://gitlab.com »
–プロジェクト= »
–location= »グローバル »
–display-name= » 私の OIDC プロバイダー »
–attribute-mapping= »google.subject=assertion.sub »

属性マッピング : これにより、ID プロバイダから Google Cloud に渡される認証情報の属性がマッピングされます。これが属性マッピングルールです。

google.subjet は、Google Cloud と Assertion.sub で使用される標準属性です。

サービスアカウント

サービスアカウントを作成し、必要なリソースにアクセスするために必要なロールと権限を定義します。

サービスアカウントの作成:

gcloud iam service-accounts create »my-service-account »
–project= »MY_PROJECT »

したがって、Gitlab CI/CD のデモに必要なストレージ管理者ロール「storage.admin」を付与します。

gcloud プロジェクト add-iam-policy-binding « MY_PROJECT »
–member= »serviceAccount:my-service-account@MY_PROJECT.iam.gserviceaccount.com »
–role= »roles/storage.admin »

最後に、サービスアカウントの偽装を使用して、ワークロードが Google リソースにアクセスすることを承認します。これは、サービスアカウントキーよりも安全であるためです。

gcloud iam service-accounts add-iam-policy-binding « my-service-account@MY_PROJECT.iam.gserviceaccount.com »
–project= »MY_PROJECT »
–role= »roles/iam.workloadIdentityUser »
— member= »principalSet://iam.googleapis.com/projects/MY_PROJECT_number/locations/global/workloadIdentityPools/MY_POOL/* »