オープンソースのツールを利用して GKE 向けの Workload Identity を容易に活用

※この投稿は米国時間 2023 年 3 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud には、Google Kubernetes Engine（GKE）ワークロードが、認証情報の公開を最小限に抑えながら安全に Google API に対する認証を行えるようにする優れた手法が用意されています。ここでは、kaniko というツールを使用してこの手法を解説します。

kaniko とは？

kaniko は、Docker デーモンに簡単にアクセスできず、基盤となるマシンへのルートアクセス権がない場合に、Kubernetes Pod からコンテナ イメージをビルドして push するためのオープンソース ツールです。kaniko はユーザー空間でビルドコマンドすべてを実行し、Docker デーモンにまったく依存しません。このため、継続的インテグレーション（CI）パイプライン ツールキットで人気のツールとなっています。

安全性と利便性の板挟み

Secret Manager のシークレットなど、Google Cloud のサービスに GKE ワークロードからアクセスする状況を考えてみましょう。今回の例では、コンテナ イメージをビルドして Google の Container Registry（GCR）に push します。しかし、そのためには Cloud IAM によって管理される Google サービス アカウント（GSA）の認証が必要です。これは、Pod の ID を提供し、独自の Kubernetes Role-Based Access Control（RBAC）に従う Kubernetes サービス アカウント（KSA）とは異なります。では、GKE ワークロードへのアクセスを前述した Google Cloud サービスに安全な方法で提供するにはどうすればよいでしょうか。

1: Compute Engine サービス アカウントを使用する

最初のオプションは、ノードプールによって使用される IAM サービス アカウントの利用です。デフォルトでは、これは Compute Engine のデフォルトのサービス アカウントです。この手法の欠点は、サービス アカウントの権限がすべてのワークロードで共有されるため、最小権限の原則が守られないことです。このため、ワークロードへのアクセスを提供する際は、最小権限のロールでカスタム サービス アカウントを使用し、よりきめ細かなアプローチを採用することをおすすめします。

2: サービス アカウント キーを Kubernetes シークレットとして使用する

より安全性の高い 2 番目のオプションは、必要な権限で Google SA のアカウントキーを生成し、Kubernetes シークレットとして Pod にマウントするという十分なテストを重ねた実証済みの手法です。イメージをビルドして GCR に push する Pod のマニフェストは、以下のようになります。

環境変数 GOOGLE_APPLICATION_CREDENTIALS には、Pod 内のパス / シークレットにマウントされている Google Cloud の認証情報の JSON ファイルへのパスを指定します。このサービス アカウント キーを介して、Kubernetes Pod はビルドのコンテキスト ファイルにアクセスし、イメージを GCR に push できます。

この手法の欠点は、期限切れになることのない有効なキーが存在し続けるため、漏えいや盗難のリスクが常につきまとい、誤って一般公開のコード リポジトリに公開される可能性があることです。

3: Workload Identity を使用する

3 番目のオプションは、Workload Identity を使用して Google SA と Kubernetes SA の間にリンクを提供するというものです。これにより、KSA は Google Cloud ネイティブのサービスおよびリソースとやり取りする際に GSA として機能するようになります。この手法では引き続き IAM からきめ細かいアクセス制御を提供でき、サービス アカウント キーを生成する必要が一切ないため、安全性と利便性のバランスを取ることができます。

セットアップ

GKE クラスタで Workload Identity を有効化し、ノードプールのメタデータ サーバーを構成する必要があります。また、GSA（ここでは「kaniko-wi-gsa」）も必要です。これに必要なロールを適切に割り当ててください。

Kubernetes 側で KSA（ここでは「kaniko-wi-ksa」）を作成し、以下のバインディングを割り当てます。これにより、必要な Google Cloud サービスにアクセスする権限を持つ GSA の権限を借用できます。

最後に、KSA のアノテーションとして GSA の完全なメールアドレスを指定します。

以下は、同じイメージビルド ジョブの Pod マニフェストですが、代わりに Workload Identity が使用されています。

Workload Identity を使用する場合、初期セットアップの手順は少し増えますが、セキュリティ アカウント キーを生成したりローテーションしたりする必要はありません。

別の Google Cloud プロジェクトでサービスにアクセスする必要がある場合

GKE クラスタがあるものとは別の Google Cloud プロジェクトに置かれている中央のコンテナ レジストリにイメージを push する必要がある場合があります。この場合も Workload Identity を利用できるでしょうか。

もちろんご利用いただけます。GSA および必要な IAM バインディングは外部の Google Cloud プロジェクトから作成されますが、Workload Identity のプールと GKE ワークロードの実行元である KSA を引き続き参照できます。

次のステップ

kaniko を使用して、Google API に対する認証を行う際に Workload Identity がアクセスの安全性を高める仕組みについてご説明しました。推奨されるセキュリティ対策を参考にして GKE クラスタを強化し、ノードサービス アカウントの使用や Kubernetes シークレットとしてのサービス アカウント キーのエクスポートを回避しましょう。