1つのKubernetes YAMLファイルでGCP組織を引き継ぐ方法

開発者がクラウドリソース（データベース、ストレージバケット、仮想マシンなど）を作成する際には、クラウドプロバイダーへの認証に必要な認証情報が必要です。Google Cloud では、多くの場合、サービスアカウントキーが使用されます。これは、開発者の身元と実行が許可されている操作を証明する JSON ファイルです。

サービスアカウントキーの問題点は、それらがファイルであることです。ファイルはコピーされたり、メールで送信されたり、誤ってGitリポジトリにコミットされたり、ノートPCに残されたり、忘れ去られたりすることがあります。

誰かがチームを離れる際、組織はその人物がどのキーを保有していたかを必ずしも把握しているわけではありません。数十人の開発者にわたる認証情報の追跡やローテーションは、大きな運用上の負担となり、セキュリティリスクにもつながります。

業界ではこれを「シークレットの散在（secret sprawl）」と呼んでいます。クラウドの認証情報がマシン、パイプライン、コードベース全体に散在し、監査が困難で、除去するのはさらに難しい状態を指します。

Table of contents

GitOpsが認証情報を排除した方法
貴社のデータリスクを低減するための取り組みを続けていきましょう
ネームスペースへのアクセス権が組織の所有者となる場合
2つの認証システム、1つのチェックの欠如
Googleはこれを「機能」と呼んでいる
修正が難しい理由
AWSやAzureにも同様のリスク
Config Connector を保護する方法

GitOpsが認証情報を排除した方法

Kubernetesコミュニティによるこの問題への解決策が、GitOpsオペレーター（コントローラーとも呼ばれる）です：

開発者は、必要なリソースを記述したYAML設定ファイルを作成し、Gitにコミットして、Kubernetesクラスターに適用します。
クラスター内で実行されているコントローラーがこれらのファイルを読み取り、開発者に代わってクラウドリソースを作成または更新します。

重要な点は、開発者がクラウドの認証情報を一切保持しなくなることです。コントローラーが、自身の認証情報を使用して開発者に代わって認証を行います。

Google版の本システムは「Google Kubernetes Config Connector（KCC）」であり、通常はGoogle Kubernetes Engine（GKE）クラスター内で実行されます。KCCは、Google Cloudリソースを記述した設定ファイルを監視し、対応するGoogle Cloud APIを呼び出してリソースを作成または更新します。

ストレージバケットからオブジェクトを読み取る権限をアプリケーションに付与したい開発者は、次のような IAMPolicyMember リソースを送信できます：

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: my-binding
  namespace: my-team
spec:
  member: "serviceAccount:my-app@my-project.iam.gserviceaccount.com"
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    external: "my-project"

KCCは、プラットフォームチームが管理するGoogleサービスアカウント（通称「KCC GSA」）を使用して、Workload Identityを通じてGoogle Cloudへの認証を行います。KCCは複数のプロジェクト、フォルダ、あるいは組織全体にわたるインフラを管理する場合があるため、このアカウントにはrole/ownerや roles/resourcemanager.organizationAdminなどの広範なロールが付与されることがあります。

開発者がリソースを送信すると、KCCがそれを取得してGoogle Cloud IAMを呼び出します。これにより権限が作成され、開発者がGoogle Cloudの認証情報に触れることはありません。

Every namespace shares KCC's single organization-level identity — **すべてのネームスペースは、KCCの単一の組織レベルのIDを共有します**

この構成は、その本来の目的においてうまく機能しています。つまり、開発者の認証情報が必要なく、すべてがGitで宣言され、プラットフォームチームが管理するサービスアカウントは数十個ではなく1つだけです。これにより、認証情報の乱立という問題は解決されます。

貴社のデータリスクを低減するための取り組みを続けていきましょう

Varonisが毎月配信するポッドキャスト「State of Cybercrime」をぜひお聴きください。注目を集めたサイバー攻撃、シャドーIT、サプライチェーン関連のインシデント、AIセキュリティリスクについて学ぶことができます。

このシリーズを購読して、今後のすべてのエピソードをお見逃しなく。

購読：『State of Cybercrime』

ネームスペースへのアクセス権が組織の所有者となる場合

しかし、この設定は新たな問題も引き起こします。

KCCは、どのKubernetesユーザーがリソースを送信したかに関係なく、独自のサービスアカウントを通じてすべてのGoogle Cloud操作を実行します。そのアカウントに組織レベルの権限がある場合、クラスターへのアクセスが制限されているユーザーでも、間接的にそれらの権限を行使できてしまいます。この手法は「ConfigConfusion」と呼ばれ、セキュリティ研究者のジャスティン・オリアリー氏によって発見されました。

攻撃者が以下を持っている場合：

KCCが監視しているKubernetesネームスペースへのアクセス権。
そのネームスペース内でIAMPolicyMemberリソースを作成する権限。
自身でGoogle Cloudの認証情報や権限を一切持っていない。

攻撃者は、KCCのサービスアカウントが割り当てを許可されているあらゆるGoogle Cloud IAMロール（組織全体に対する`roles/owner`を含む）を、自身に付与することができます。

攻撃自体は、次の1つのコマンドで実行されます:

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
 name: escalation
 namespace: my-team
spec:
 member: "serviceAccount:attacker@attacker-project.iam.gserviceaccount.com"
 role: roles/owner
 resourceRef:
 apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
 kind: Organization
 external: "123456789"

攻撃者はKubernetesを介してこのYAMLを適用します。KCCはこれを読み取り、変更を行う権限を持つ独自のサービスアカウントを使用してGoogle CloudにIAMの変更をリクエストするため、リクエストは受け入れられます。これにより、攻撃者はGoogle Cloudの認証情報を一切保持することなく、Google Cloudの組織を制御できるようになります。

One IAMPolicyMember turns namespace access into organization ownership — **1つの IAMPolicyMember が、ネームスペースへのアクセス権を組織の所有権へと変える**

2つの認証システム、1つのチェックの欠如

なぜこれが機能するのかを理解するには、このリクエストを処理する2つの別々の認証システムに注目する必要があります。

KubernetesのRBACは、ユーザーがクラスター内で何ができるかを制御します。RBACは「このユーザーは、このネームスペース内にIAMPolicyMemberリソースを作成する権限がありますか？」と問いかけます。もし「はい」であれば、その操作を許可します。RBACはGoogle Cloudに関する情報を一切持たず、そのリソースがGoogle Cloud上でどのような動作をするのかについても問いません。
Google Cloud IAMは、サービスアカウントがGoogle Cloud内で何ができるかを制御します。KCCがGoogle Cloudにバインディングの作成を依頼する際、次のように尋ねます。「KCCのサービスアカウントには、このIAMバインディングを設定する権限がありますか？」もし「はい」であれば、操作を許可します。 Google Cloudは、どのKubernetesユーザーがリクエストをトリガーしたかを知らず、そのユーザーがリクエストを行う権限を持つべきだったかどうかも確認しません。

Blog_VTL-GoogleKubernetes_Fig3_V1 (1) — **各システムはリクエストの自分側の部分のみを確認し、全体を確認する者はいません。**

その結果、Kubernetes にはクラスター内でリソースが作成されていることしか認識されず、Google Cloud には KCC のサービスアカウントが変更を行っていることしか認識されません。KCC は、アクセス権限が制限されたユーザーからのリクエストを受け取り、そのユーザーが Google Cloud では持っていない権限を使用してそれを実行することができます。

これは「コンフューズド・デピュティ問題」として知られています。KCCは広範な権限を持ち、権限の少ないユーザーからの指示に基づいて行動しますが、そのユーザーが権限を使用できるかどうかを確認することはありません。

開発者からクラウドの認証情報を排除するという設計上の決定は、有用かつ意図的なものです。しかし、それによって、開発者のKubernetes上のIDと、その開発者に代わって使用されるGoogle Cloudの権限との関連性も失われてしまいます。KCCが動作する際、Google Cloudが認識するのはKCCであり、リクエストを発行した人物ではありません。

Googleはこれを「機能」と呼んでいる

ConfigConfusion に対する Google の回答は、KCC は設計通りに動作しているというものでした。

管理者は、KCCに組織レベルのサービスアカウントを割り当てることを選択し、開発者がKCCが管理するネームスペース内でIAMPolicyMemberリソースを作成できるようにすることを選択しました。Googleの観点からは、これらは設定上の決定であり、KCCは与えられたリクエストを実行するだけです。

この説明は技術的には正確であり、KCCは設定通りに動作しています。

問題は、ドキュメントではこれら2つの決定事項の関係が明確に示されていない点にあります。ほとんどの管理者は、これらを別々に考えています。「このチームはどのKubernetesリソースタイプを作成できるか」と、「KCCのサービスアカウントはGoogle Cloudで何ができるか」です。KCCにおいては、この2つは関連しています。つまり、チームにIAMPolicyMemberリソースを作成する権限を与えることは、そのチームにKCCのGoogle Cloud権限を利用する手段を与えることにもなり得るのです。

KCCに必要な権限を正確に特定するのは難しいため、組織レベルのアクセス権を付与する方が多くの場合、簡単です。これは必ずしも管理上の不備を反映しているわけではなく、結果として生じる権限のギャップが可視化されていない設計の自然な帰結なのです。

修正が難しい理由

最も明白な解決策は、リソースを送信した Kubernetes ユーザーが、リクエストを実行する前に、対応する Google Cloud の権限を持っているかどうかを確認することです。

このチェックを行うには、KubernetesユーザーがGoogle CloudのIDを持っている必要がありますが、KCCはIDを必要としないように設計されています。各ユーザーに対応するIDを付与することは、KCCが提供するために構築されたモデルを損なうことになります。一方、リソースごとにリクエスト元の権限を照会すると、すべての調整サイクルに認証チェックと余分なAPI呼び出しが追加されてしまいます。

したがって、Googleが推奨する緩和策は、各リクエストの承認方法を変更するのではなく、KCCを通じて利用可能な権限を縮小することに重点を置いています。

AWSやAzureにも同様のリスク

この認可の問題は、KCCに限ったものではありません。あるIDからの指示を受け入れ、別のIDを通じてそれを実行するインフラストラクチャオペレーターであれば、どこでも同様のギャップが生じる可能性があります。プラットフォーム間で異なるのは、オペレーターがどの程度の権限を保持しているか、そしてその権限をどの程度容易に制限できるかという点です。

AWS Controllers for Kubernetes（ACK）は、サービスごとにコントローラーを分離しています。IAM、Amazon S3、Amazon EC2にはそれぞれ独自のコントローラーがあり、そのサービスにスコープが限定されたIAMロールが割り当てられています。ユーザーがS3コントローラーのリクエストパスを制御下に置いた場合、S3リソースには影響を与えることができますが、そのロールにはIAMを変更する権限がないため、IAMの変更を行うことはできません。
Azure Service Operator v2では、各 Kubernetes ネームスペースが個別のマネージド ID を使用できるようになっています。これにより、管理者はオペレーター全体の権限を 1 つの ID に集約するのではなく、ネームスペースごとに権限を制限する実用的な手段を得ることができます。

どちらのアプローチも、根底にある「コンフューズド・デピュティ」のリスクを排除するものではありませんが、悪意のあるリクエストがオペレーターに到達する前にその権限を制限することで、潜在的な被害を軽減します。

Config Connector を保護する方法

このリスクを軽減するには、認証のギャップの両側、つまり KCC のサービスアカウントが Google Cloud で実行できる操作と、Kubernetes ユーザーが KCC に処理を依頼できるリソースの両方を制限する必要があります。

以下のチェックリストでは、これら両方の側面を網羅しています。

KCC はネームスペースモードを使用しており、ネームスペースごとにスコープが分離された Google サービスアカウントを使用していますか？
プロジェクト、フォルダ、および組織レベルで KCC の IAM ロールを確認しましたか？
roles/owner や roles/resourcemanager.organizationAdmin などの広範なロールは、厳密に必要とされない限り削除されていますか？
IAMPolicyMember、IAMPolicy、および IAMPartialPolicy リソースを作成する権限は、承認されたプラットフォームチームまたはインフラストラクチャチームに限定されていますか？
KCC によって行われたフォルダおよび組織レベルの IAM 変更、特に承認された GitOps ワークフロー外での変更を監視していますか？

この脆弱な構成は、KCC サービスアカウントと、組織レベルの IAM 権限、および KCC が管理するネームスペースへの広範な書き込みアクセス権を組み合わせています。

いずれの条件も単独で管理することは可能ですが、これらが組み合わさると、Google Cloud の認証情報を必要とせずに悪用できる権限昇格の経路が形成されます。

Varonis による提供および執筆。

出典：https://www.bleepingcomputer.com/news/security/how-one-kubernetes-yaml-can-hand-over-a-gcp-organization/