クラスタのセキュリティを強化する

Autopilot Standard

Kubernetes の開発ペースは速く、新たなセキュリティ機能がしばしば登場します。このページでは、Google Kubernetes Engine クラスタを強化するための最新ガイダンスを実践する方法について説明します。

このガイドでは、クラスタの作成時にお客様の操作が必要となる価値のあるセキュリティ対策を優先します。重要性の低い機能、デフォルトでセキュアな設定、作成後に有効にできる項目についてはドキュメントの後半でご説明します。セキュリティトピックの概要については、セキュリティの概要をお読みください。

セキュリティ状況の分析を使用すると、こうした推奨事項の多くと、よくある構成の誤りが自動的に確認されます。

下記の推奨事項は CIS GKE ベンチマークの推奨事項に関するもので、これが指定されています。

GKE インフラストラクチャを適切なタイミングでアップグレードする

CIS GKE ベンチマークの推奨事項: 6.5.3。ノードの自動アップグレードが GKE ノードに対して有効になっていることを確認する

セキュリティを向上させる最も簡単な方法の 1 つに、Kubernetes のバージョンを最新の状態に保つことがあります。Kubernetes は頻繁に新しいセキュリティ機能を導入し、セキュリティパッチを提供しています。

セキュリティパッチの詳細については、GKE セキュリティに関する情報を参照してください。

Google Kubernetes Engine では、コントロールプレーンへのパッチやアップグレードが自動的に行われます。ノードの自動アップグレードでも、クラスタ内のノードが自動的にアップグレードされます。

ノードの自動アップグレードを無効にする場合は、自身の都合に合わせて、毎月アップグレードすることを推奨します。古いクラスタでは、ノードの自動アップグレードを有効にする設定にしたうえで、重要なパッチについて GKE セキュリティ情報に厳密に従ってください。

詳細は、ノードの自動アップグレードをご覧ください。

コントロールプレーンとノードへのネットワークアクセスを制限する

CIS GKE ベンチマークの推奨事項: 6.6.2. VPC ネイティブクラスタを優先する、6.6.3. マスター認証ネットワークが有効であることを確認する、6.6.4.クラスタが非公開エンドポイント有効と公開アクセス無効で作成されていることを確認する、6.6.5. クラスタがプライベートノードで作成されていることを確認する

クラスタコントロールプレーンとノードのインターネットへの公開を制限する必要があります。これらの設定は、クラスタ作成時のみ行えます。

GKE のクラスタコントロールプレーンとノードには、任意の IP アドレスからアクセスできる、インターネット上でルーティング可能なアドレスがデフォルトで付与されています。

GKE のクラスタコントロールプレーンについては、限定公開クラスタの作成をご覧ください。ネットワークレベルの保護を提供できる限定公開クラスタには、次の 3 種類があります。

パブリックエンドポイントアクセスが無効: コントロールプレーンとノードの両方へのインターネットアクセスをすべて防ぐ、最も安全なオプションです。Cloud Interconnect と Cloud VPN を使用してオンプレミスネットワークから Google Cloud への接続を構成している場合に適しています。これらを用いれば、企業ネットワークとクラウド VPC を効率的に接続できます。
パブリックエンドポイントアクセスが有効、承認済みネットワークが有効（推奨）: このオプションにより、定義するソース IP アドレスからコントロールプレーンへのアクセスが制限されます。これは、既存の VPN インフラストラクチャがない場合や、リモートユーザーや支社が企業 VPN や Cloud Interconnect / Cloud VPN を使用せずに公共のインターネット経由で接続する場合に適しています。
パブリックエンドポイントアクセスが有効、承認済みネットワークが無効: この設定はデフォルトで、インターネット上の誰でもコントロールプレーンにネットワーク接続できるようにします。

ノードへの直接的なインターネットアクセスを無効にするには、クラスタの作成時に gcloud CLI オプションで --enable-private-nodes を指定します。

これにより GKE が内部 IP アドレスを持つノードをプロビジョニングするように指示するため、公共のインターネット経由でノードに直接アクセスすることはできません。

クラスタで少なくとも承認済みネットワークとプライベートノードを使用することをおすすめします。これにより、以下がコントロールプレーンにアクセス可能になります。

承認済みネットワークで許可された CIDR。
クラスタの VPC 内のノード。
Google がお客様のコントロールプレーンを管理するために本番環境で実行する内部ジョブ。

これは、クラスタ作成時の次の gcloud フラグに対応します。

--enable-ip-alias
--enable-private-nodes
--enable-master-authorized-networks

最小権限のファイアウォールルールを使用する

ファイアウォールルールに最小権限の原則を使用することで、意図しないアクセスのリスクを最小限に抑える

GKE は、システム機能を有効にし、適切なセキュリティ対策を適用するために、デフォルトの VPC ファイアウォールルールを作成します。自動作成されるファイアウォールルールの一覧については、自動的に作成されるファイアウォールルールをご覧ください。

GKE は、これらのデフォルトのファイアウォールルールを優先度 1000 で作成します。デバッグ用の allow-all ファイアウォールルールなど、優先度の高く制限の緩いファイアウォールルールを作成すると、クラスタが意図しないアクセスを受けるリスクがあります。

グループ認証

CIS GKE ベンチマークの推奨事項: 6.8.3. RBAC 向け Google グループで Kubernetes RBAC ユーザーを管理することを検討する

グループを使用してユーザーを管理する必要があります。グループを使用すると、ID 管理システムと ID 管理者を使用して ID を制御できます。グループメンバーシップを調整するだけで、メンバーをグループに追加または削除するたびに RBAC の構成を更新する必要がなくなります。

Google グループを使用してユーザー権限を管理するには、クラスタで RBAC 用 Google グループを有効にする必要があります。これにより、同じ権限を持つユーザーを簡単に管理でき、ID 管理者は、ユーザーの一貫した一元管理ができるようになります。

RBAC 向け Google グループを有効にする手順については、RBAC の Google グループをご覧ください。

コンテナノードを選択する

次のセクションでは、安全なノード構成の選択について説明します。

シールドされた GKE ノードを有効にする

CIS GKE ベンチマークの推奨事項: 6.5.5。シールドされた GKE ノードが有効になっていることを確認する

シールドされた GKE ノードは強固で検証可能なノード ID と完全性を備え、GKE ノードのセキュリティが高められているので、すべての GKE クラスタでこれを有効にすることをおすすめしています。

シールドされた GKE ノードは、クラスタの作成時または更新時に有効にできます。シールドされた GKE ノードを有効にするときは、セキュアブートも有効にしてください。サードパーティの未署名のカーネルモジュールが必要な場合は、セキュアブートを使用しないでください。シールドされた GKE ノードを有効にする方法と、シールドされた GKE ノードを使用してセキュアブートを有効にする方法については、シールドされた GKE ノードの使用をご覧ください。

containerd ランタイムで強化されたノードイメージを選択する

containerd を含む Container-Optimized OS（cos_containerd）イメージは、containerd を含む Container-Optimized OS イメージのバリアントであり、メインのコンテナランタイムとして Kubernetes に直接統合されています。

containerd は Docker のコアランタイムコンポーネントで、Kubernetes Container Runtime Interface（CRI）にコアコンテナ機能を提供するように設計されています。完全な Docker デーモンよりもはるかに簡潔なので、攻撃対象領域が小さくなります。

クラスタで cos_containerd イメージを使用するには、コンテナイメージをご覧ください。

cos_containerd イメージは、コンテナを実行するためにカスタムビルドされ、最適化され、強化されていることから、GKE の推奨イメージです。

GKE 用 Workload Identity 連携を有効にする

CIS GKE ベンチマークの推奨事項: 6.2.2。専用の Google Cloud サービスアカウントと Workload Identity を優先的に使用する

Google Cloud APIs に対する認証に推奨される方法は、GKE 用 Workload Identity 連携です。

GKE 用 Workload Identity 連携は、メタデータ隠蔽機能の使用に代わるものであるため、この 2 つのアプローチに互換性はありません。メタデータ隠蔽機能によって保護される機密メタデータは、GKE 用 Workload Identity 連携によっても保護されます。

GKE Sandbox によるワークロード分離の強化

CIS GKE ベンチマークの推奨事項: 6.10.4。信頼できないワークロードの場合は特に、ワークロードの分離を強化するために GKE Sandbox の使用を検討する

GKE Sandbox は、セキュリティに新たなレイヤを追加し、悪意のあるコードからクラスタノードのホストカーネルを保護します。

サンドボックス環境でコンテナを実行すると、ほとんどのコンテナエスケープ攻撃（ローカル権限昇格攻撃とも呼ばれる）を軽減できます。過去のコンテナエスケープの脆弱性については、セキュリティに関する公開情報をご覧ください。このタイプの攻撃では、攻撃者はコンテナのホスト VM にアクセスします。このため、同じ VM 上の他のコンテナにもアクセスされる可能性があります。GKE Sandbox などのサンドボックスは、このような攻撃の影響を抑えるのに役立ちます。

次のような状況では、ワークロードのサンドボックス化を検討する必要があります。

ワークロードが信頼できないコードを実行する
ワークロード内のコンテナが攻撃者によって不正使用された場合の影響を制限する必要がある。

GKE Sandbox の使用方法については、GKE Sandbox によるワークロード分離の強化をご覧ください。

セキュリティに関する公開情報の通知を有効にする

クラスタに関連するセキュリティ情報が利用可能になると、GKE はそれらのイベントに関する通知を構成済みの Pub/Sub トピックにメッセージとして公開します。これらの通知を Pub/Sub サブスクリプションで受信し、サードパーティサービスと統合して、受信したい通知タイプをフィルタできます。

GKE クラスタ通知を使用したセキュリティ情報の受信の詳細については、クラスタ通知をご覧ください。

安全でない kubelet 読み取り専用ポートを無効にする

kubelet 読み取り専用ポートを無効にし、ポート 10255 を使用するワークロードがより安全なポート 10250 を使用するように切り替えます。

ノードで実行されている kubelet プロセスは、安全でないポート 10255 を使用して読み取り専用 API を提供します。Kubernetes では、このポートに対して認証や承認のチェックが行われません。kubelet は、より安全な認証済みのポート 10250 で同じエンドポイントにサービスを提供します。

手順については、GKE クラスタで kubelet の読み取り専用ポートを無効にするをご覧ください。

権限

最小権限の IAM サービスアカウントを使用する

CIS GKE ベンチマークの推奨事項: 6.2.1. GKE クラスタの実行時に Compute Engine のデフォルトサービスアカウントを使用しないようにする

各 GKE ノードには Identity and Access Management（IAM）サービスアカウントが関連付けられています。デフォルトでは、ノードに Compute Engine のデフォルトのサービスアカウントが付与されています。このアカウントは、Google Cloud コンソールの IAM セクションに移動すると見つかります。このアカウントにはデフォルトで広範なアクセス権があり、さまざまな用途に役立ちますが、Kubernetes Engine クラスタの実行には権限が過剰です。Compute Engine のデフォルトサービスアカウントを使用するのでなく、使用するノード用の最小限の権限のみを持つサービスアカウントを作成および使用する必要があります。

GKE 用 Workload Identity 連携のリリースに伴い、ノードサービスアカウントのユースケースをより限定的にすることをおすすめします。Google では、ロギングやモニタリング、その他の似たようなタスクを担当するシステムデーモンがノードサービスアカウントを使用するようになると考えています。Pod のワークロードには、GKE 用 Workload Identity 連携を使用して ID をプロビジョニングする必要があります。

GKE では、サービスアカウントに最低でも container.defaultNodeServiceAccount ロールが必要です。詳細については、事前定義された GKE ロールをご覧ください。

以下のコマンドは、GKE を操作するために必要な最低限の権限を持つ IAM サービスアカウントを作成します。作成したサービスアカウントは、他のプロジェクトのリソースにも使用できます。手順については、プロジェクト間のサービスアカウントの権限借用を有効にするをご覧ください。

gcloud

gcloud iam service-accounts create SA_NAME \
    --display-name="DISPLAY_NAME"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/container.defaultNodeServiceAccount

次のように置き換えます。

SA_NAME: 新しいサービスアカウントの名前。
DISPLAY_NAME: 新しいサービスアカウントの表示名。これにより、アカウントを識別しやすくなります。
PROJECT_ID: 新しいサービスアカウントを作成するプロジェクトのプロジェクト ID。

Config Connector

注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順を実施してください。

サービスアカウントを作成するには、次のリソースを service-account.yaml としてダウンロードします。
```
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [SA_NAME]
spec:
  displayName: [DISPLAY_NAME]
```
次のように置き換えます。
- SA_NAME: 新しいサービスアカウントの名前。
- DISPLAY_NAME: 新しいサービスアカウントの表示名。これにより、アカウントを識別しやすくなります。
次のコマンドを実行します。
```
kubectl apply -f service-account.yaml
```

サービスアカウントに logging.logWriter ロールを割り当てます。次のリソースを policy-logging.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-logging
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/logging.logWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-logging.yaml

monitoring.metricWriter ロールを割り当てます。次のリソースを policy-metrics-writer.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.metricWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-metrics-writer.yaml

monitoring.viewer ロールを割り当てます。次のリソースを policy-monitoring.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-monitoring
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/monitoring.viewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-monitoring.yaml

autoscaling.metricsWriter ロールを割り当てます。次のリソースを policy-autoscaling-metrics-writer.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-autoscaling-metrics-writer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/autoscaling.metricsWriter
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-autoscaling-metrics-writer.yaml

限定公開イメージリポジトリへのアクセス権を付与する

Artifact Registry で非公開イメージを使用するには、サービスアカウントに Artifact Registry 読み取りロール（roles/artifactregistry.reader）を付与します。

gcloud

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

REPOSITORY_NAME を Artifact Registry リポジトリの名前に置き換えます。

Config Connector

注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順を実施してください。

次のマニフェストを policy-artifact-registry-reader.yaml として保存します。

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-artifact-registry-reader
spec:
  member: serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com
  role: roles/artifactregistry.reader
  resourceRef:
    apiVersion: artifactregistry.cnrm.cloud.google.com/v1beta1
    kind: ArtifactRegistryRepository
    name: REPOSITORY_NAME

次のように置き換えます。

SA_NAME: IAM サービスアカウントの名前。
PROJECT_ID: Google Cloud プロジェクト ID。
REPOSITORY_NAME: Artifact Registry リポジトリの名前。

Artifact Registry 読み取りロールをサービスアカウントに付与します。
```
kubectl apply -f policy-artifact-registry-reader.yaml
```

Container Registry の限定公開イメージを使用する場合は、それらのイメージに対するアクセス権も付与する必要があります。

gcloud

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

イメージを保存するバケットは、以下の形式の名前 BUCKET_NAME を持っています。

artifacts.PROJECT_ID.appspot.com。gcr.io ホスト内のレジストリに push されたイメージの場合。
STORAGE_REGION.artifacts.PROJECT_ID.appspot.com

次のように置き換えます。

PROJECT_ID: Google Cloud Console プロジェクト ID。
STORAGE_REGION: ストレージバケットの場所。
- us: us.gcr.io ホストのレジストリの場合
- eu: eu.gcr.io ホストのレジストリの場合
- asia。asia.gcr.io ホストのレジストリの場合

コマンドの詳細については、gcloud storage buckets add-iam-policy-binding のドキュメントをご覧ください。

Config Connector

注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順に従ってください。

storage.objectViewer ロールをサービスアカウントに適用します。次のリソースを policy-object-viewer.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-object-viewer.yaml

他のユーザーがこのサービスアカウントで新しいクラスタまたはノードプールを作成できるようにするには、そのサービスアカウントのユーザーにサービスアカウントユーザーロールを付与します。

gcloud

gcloud iam service-accounts add-iam-policy-binding \
    SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member=user:USER \
    --role=roles/iam.serviceAccountUser

Config Connector

注: この手順には Config Connector が必要です。Config Connector をクラスタにインストールするには、インストール手順に従ってください。

iam.serviceAccountUser ロールをサービスアカウントに適用します。次のリソースを policy-service-account-user.yaml としてダウンロードします。[SA_NAME] と [PROJECT_ID] はお客様自身の情報に置き換えてください。

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-service-account-user.yaml

既存の Standard クラスタの場合、この新しいサービスアカウントを使用して新しいノードプールを作成できるようになりました。Autopilot クラスタの場合は、このサービスアカウントを使用して新しいクラスタを作成する必要があります。手順については、Autopilot クラスタを作成するをご覧ください。

新しいサービスアカウントを使用するノードプールを作成します。

gcloud container node-pools create NODE_POOL_NAME \
--service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
--cluster=CLUSTER_NAME

GKE クラスタが他の Google Cloud サービスにアクセスする必要がある場合は、GKE 用 Workload Identity 連携を使用する必要があります。

クラスタ API 検出へのアクセスを制限する

Kubernetes はデフォルトで、CustomResourceDefinitions の API など、クラスタの API に関する情報に幅広くアクセスできる、制約の緩いディスカバリ ClusterRoleBindings のセットでクラスタをブートストラップします。

system:discovery と system:basic-user の ClusterRoleBindings のサブジェクトにある system:authenticated グループには、認証済みユーザーなら誰でも含めることができ（Google アカウントを持つユーザーもこれに含まれます）、そのため、このグループは GKE のクラスタのセキュリティにとってむしろ無意味なレベルに相当することに留意する必要があります。詳細については、デフォルトのロールとグループを使用しないをご覧ください。

クラスタのディスカバリ API を強化する場合は、次のうち 1 つ以上を実施することを検討してください。

設定済みの IP 範囲へのアクセスを制限するように承認済みネットワークを構成する
VPC へのアクセスを制限する限定公開クラスタを設定する

これらのオプションが GKE のユースケースに適していない場合、すべての API 検出情報（CustomResources のスキーマ、APIService の定義、拡張 API サーバーでホストされている検出情報）を一般公開として扱います。

どちらのオプションでも、Cloud Run と Cloud Run functions から API サーバーの IP アドレスにアクセスできます。このアクセス権は削除されるため、API サーバーとの通信にこれらのサービスを使用しないでください。詳細については、Google Cloud のブログ投稿をご覧ください。

Namespace と RBAC を使用してクラスタリソースへのアクセスを制限する

CIS GKE ベンチマークの推奨事項: 5.6.1。Namespace を使用してリソース間の管理境界を作成する

各チームと環境に個別の Namespace またはクラスタを作成して、チームに付与する Kubernetes へのアクセス権限を最低限に抑えます。アカウンタビリティとチャージバックに基づいて各名前空間にコストセンターと適切なラベルを割り当てます。開発者に付与する名前空間へのアクセス権は（特に本番環境において）、アプリケーションのデプロイと管理に必要なレベルのみに制限します。ユーザーがクラスタに対して行う必要があるタスクをマッピングし、各タスクの実行に必要な権限を定義します。

Namespace の作成について詳しくは、Kubernetes のドキュメントをご覧ください。RBAC 構成を計画する際のベストプラクティスについては、GKE RBAC のベストプラクティスをご覧ください。

IAM とロールベースのアクセス制御（RBAC）は相互に連携するため、クラスタ内のリソースを操作するには、エンティティに双方のレベルで十分な権限を与える必要があります。

GKE に適した IAM ロールをグループやユーザーに割り当て、プロジェクトレベルで権限を提供します。RBAC を使ってクラスタと Namespace レベルで権限を付与します。詳細については、アクセス制御をご覧ください。

IAM と RBAC の権限を Namespace と併用すると、Google Cloud コンソールのクラスタリソースに対するユーザー操作を制限できます。詳細については、アクセスを有効にしてクラスタリソースを Namespace ごとに表示するをご覧ください。

Pod 間のトラフィックをネットワークポリシーで制限する

CIS GKE ベンチマークの推奨事項: 6.6.7。ネットワークポリシーが有効であることを確認し、必要に応じて設定する

デフォルトでは、クラスタ内のすべてのポッドが相互通信できます。Pod 間通信は、ワークロードのニーズに応じて制御してください。

サービスへのネットワークアクセスを制限することで、攻撃者によるクラスタ内移動の難易度を大幅に上げることができ、偶発的または意図的な DoS 攻撃に対してサービスをある程度は保護できます。トラフィックを制御する 2 つの推奨方法は次のとおりです。

Istio を使用します。ロードバランシング、サービス許可、スロットリング、割り当て、指標などの詳細については、Google Kubernetes Engine に Istio をインストールするをご覧ください。
Kubernetes ネットワークポリシーを使用します。クラスタネットワークポリシーの作成をご覧ください。Kubernetes で公開されている基本的なアクセス制御機能をお探しの場合は、これを選択します。ネットワークポリシーを使用してトラフィックを制限する一般的なアプローチを実装するには、GKE Enterprise セキュリティブループリントの実装ガイドに従ってください。Kubernetes のドキュメントには簡単な nginx デプロイに関する優れたチュートリアルがあります。ネットワークポリシーロギングを使用して、ネットワークポリシーが期待どおりに動作していることを確認します。

Istio とネットワークポリシーは、必要に応じて併用できます。

Secret 管理

CIS GKE ベンチマークの推奨事項: 6.3.1. Cloud KMS で管理されている鍵を使用して Kubernetes Secrets を暗号化する

Secret を etcd に保存するなど、機密データを保護するために追加の層を設けることをおすすめします。これを行うには、GKE クラスタと統合されたシークレットマネージャーを構成する必要があります。一部のソリューションは GKE と Google Distributed Cloud の両方で動作するため、複数の環境にまたがってワークロードを実行する場合は、こうしたソリューションのほうが適している可能性があります。HashiCorp Vault などの外部シークレットマネージャーを使用する場合は、クラスタを作成する前に設定する必要があります。

Secret を管理する方法はいくつかあります。

Kukenetes Secret は、GKE でネイティブに使用できます。アプリケーションレイヤで Application-layer secrets encryption を使用して、自分が管理している鍵で Kukenetes Secret を暗号化することもできます。
HashiCorp Vault などのシークレットマネージャーを使用できます。強化 HA モードで実行すると、本番環境に適応した一貫性のあるシークレット管理が可能になります。HashiCorp Vault への認証には、Kubernetes サービスアカウントまたは Google Cloud サービスアカウントを使用できます。Vault と GKE を使用する詳しい方法については、Kubernetes での HashiCorp Vault の実行と接続を参照してください。

GKE の VM は、etcd を含むストレージレイヤではデフォルトで暗号化されます。

アドミッションコントローラを使用してポリシーを適用する

アドミッションコントローラは、クラスタの使用方法を管理および適用するプラグインです。Kubernetes の高度なセキュリティ機能の一部を使用するには、アドミッションコントローラを有効にする必要があります。また、クラスタを強化するための多層防御アプローチの重要な部分でもあります。

デフォルトでは、Kubernetes のポッドは、必要とする以上の機能で動作します。Pod の機能は、そのワークロードに必要な機能だけに制限するようにしてください。

Kubernetes には、明示的に付与された機能のみを使用して Pod を実行するように制限する制御手段が多数あります。たとえば、Policy Controller はフリート内のクラスタで使用できます。Kubernetes には PodSecurity アドミッションコントローラが組み込まれており、個々のクラスタに Pod セキュリティ標準を適用できます。

Policy Controller は、宣言型ポリシーを使用して GKE クラスタにセキュリティを大規模に適用し、検証できる GKE Enterprise の機能です。Policy Controller を使用して GKE クラスタに宣言型制御を適用する方法については、Policy Controller のインストールをご覧ください。

PodSecurity アドミッションコントローラを使用すると、特定の Namespace またはクラスタ全体で事前定義済みのポリシーを適用できます。これらのポリシーは、異なる Pod セキュリティ標準に対応しています。

ワークロードの自己変更機能を制限する

特定の Kubernetes ワークロード（特にシステムワークロード）には、自己変更の権限があります。たとえば、一部のワークロードは垂直方向に自動スケーリングされます。これは便利ですが、すでにノードを不正使用した攻撃者がクラスタ内でさらにエスカレーションする可能性があります。たとえば、攻撃者がノード上のワークロード自体を変更して、同じ Namespace 内に存在する、より権限の高いサービスアカウントとして実行するおそれがあります。

理想的には、ワークロードにはそもそも自己変更機能を付与するべきではありません。自己変更が必要な場合は、オープンソースの Gatekeeper ライブラリから NoUpdateServiceAccount などの Gatekeeper または Policy Controller の制約を適用して権限を制限できます。これにより、いくつかの有用なセキュリティポリシーが提供されます。

ポリシーをデプロイする場合、通常はクラスタのライフサイクルを管理するコントローラがポリシーをバイパスできるようにする必要があります。これは、コントローラがクラスタに変更を加える（クラスタのアップグレードを適用するなど）ことができるようにするために必要です。たとえば、NoUpdateServiceAccount ポリシーを GKE にデプロイする場合は、Constraint で次のパラメータを設定する必要があります。

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

非推奨の `gcePersistentDisk` ボリュームタイプの使用を制限する

非推奨の gcePersistentDisk ボリュームタイプを使用すると、Compute Engine 永続ディスクを Pod にマウントできます。ワークロードでの gcePersistentDisk ボリュームタイプの使用を制限することをおすすめします。GKE は、このボリュームタイプをマウントするときに Pod の IAM 認証チェックを行いません。ただし、Google Cloud は、基盤となる VM にディスクをアタッチするときに認証チェックを実行します。Namespace に Pod を作成する能力がすでにある攻撃者は、Google Cloud プロジェクトの Compute Engine 永続ディスクのコンテンツにアクセスできます。

Compute Engine 永続ディスクにアクセスして使用する場合は、代わりに PersistentVolumes と PersistentVolumeClaims を使用します。gcePersistentDisk ボリュームタイプの使用を防止するセキュリティポリシーをクラスタに適用します。

gcePersistentDisk ボリュームタイプの使用を防止するには、ベースラインまたは PodSecurity アドミッションコントローラによる制限ありポリシーを適用するか、Policy Controller か Gatekeeper アドミッションコントローラの中でカスタム制約を定義します。

このボリュームタイプを制限するカスタム制約を定義する手順は次のとおりです。

Policy Controller や Gatekeeper OPA などのポリシーベースのアドミッションコントローラをインストールします。
Policy Controller
クラスタに Policy Controller をインストールします。

GKE ユーザーの場合、Policy Controller は有償の機能です。Policy Controller はオープンソースの Gatekeeper をベースにしていますが、完全な制約テンプレートライブラリ、ポリシーバンドル、Google Cloud コンソールダッシュボードとの統合にもアクセスして、クラスタのモニタリングとメンテナンスを行うことができます。ポリシーバンドルはクラスタに適用できる独自のベストプラクティスで、CIS Kubernetes Benchmark のように推奨事項に基づくバンドルが含まれています。
Gatekeeper
クラスタに Gatekeeper をインストールします。

Autopilot クラスタの場合は、テキストエディタで Gatekeeper gatekeeper.yaml マニフェストを開きます。次の例のように、MutatingWebhookConfiguration 仕様の rules フィールドを変更して、ワイルドカード（*）文字を特定の API グループとリソース名に置き換えます。
```
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
...
webhooks:
- admissionReviewVersions:
  - v1
  - v1beta1
  ...
  rules:
  - apiGroups:
    - core
    - batch
    - apps
    apiVersions:
    - '*'
    operations:
    - CREATE
    - UPDATE
    resources:
    - Pod
    - Deployment
    - Job
    - Volume
    - Container
    - StatefulSet
    - StorageClass
    - Secret
    - ConfigMap
  sideEffects: None
  timeoutSeconds: 1
```
更新された gatekeeper.yaml マニフェストを Autopilot クラスタに適用して、Gatekeeper をインストールします。組み込みのセキュリティ対策として、Autopilot は変更用アドミッション Webhook にワイルドカード文字の使用を禁止しているため、これは必須です。

組み込みの Pod Security Policy Volume Types ConstraintTemplate をデプロイします。

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml

許可されたボリュームタイプのリストとして、次の制約を constraint.yaml として保存します。

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: k8sPSPVolumeTypes
metadata:
  name: nogcepersistentdisk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pods"]
  parameters:
    volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]

この制約は、ボリュームを spec.parameters.volumes フィールドのリストに制限します。

制約をデプロイします。
```
kubectl apply -f constraint.yaml
```

クラスタ構成を監視する

クラスタ構成と定義した設定に矛盾がないか監査してください。

セキュリティの健全性分析を使用すると、この強化ガイドで説明した推奨事項の多くを自動的に確認できるだけでなく、構成の誤りも検出できます。

安全なデフォルト

以降のセクションでは、新しいクラスタにおいて、デフォルトで安全に構成されるオプションについて説明します。既存のクラスタが安全に構成されていることを確認する必要があります。

ノードのメタデータを保護する

CIS GKE ベンチマークの推奨事項: 6.4.1。従来の Compute Engine インスタンスのメタデータ API が無効であることを確認する、6.4.2. GKE メタデータサーバーが有効になっていることを確認する

Compute Engine メタデータサーバーエンドポイント v0.1 と v1beta1 は、2020 年 9 月 30 日にサポート終了となり、停止されました。これらのエンドポイントは、メタデータクエリヘッダーを適用されませんでした。停止スケジュールについては、v0.1 と v1beta1 メタデータサーバーエンドポイントのサポート終了をご覧ください。

Kubernetes に対する攻撃の中には、VM のメタデータサーバーへのアクセスを使用して認証情報を抽出するものがあります。GKE 用 Workload Identity 連携またはメタデータ隠蔽を使用している場合、これらの攻撃はブロックされます。

以前のクライアント認証方式を無効のままにする

CIS GKE ベンチマークの推奨事項: 6.8.1。静的パスワードを使用する基本認証が無効になっていることを確認する、6.8.2. クライアント証明書を使用する認証が無効になっていることを確認する

Kubernetes API サーバーに対する認証方法は、複数存在します。GKE でサポートされる方法は、サービスアカウントの署名なしトークン、OAuth トークン、x509 クライアント証明書です。GKE では OAuth トークンベースで gcloud での認証を管理し、Kubernetes 構成の設定、アクセストークンの取得、トークンの更新を行います。

GKE を OAuth と統合する前は、1 回限りの x509 証明書または静的パスワードが唯一の認証方法でしたが、現在は推奨されておらず、無効にする必要があります。これらの方法は、クラスタの侵害に対する攻撃の範囲が広く、GKE バージョン 1.12 以降、デフォルトで無効になっています。以前の認証方法を使用している場合は、無効にすることをおすすめします。GKE バージョン 1.19 以降では、静的パスワードによる認証は非推奨となり、削除されています。

既存のクラスタは OAuth に移動する必要があります。クラスタの外部システムが長期間の認証情報を必要とする場合は、必要な権限を持つ Google サービスアカウントまたは Kubernetes サービスアカウントを作成し、そのキーをエクスポートすることをおすすめします。

既存のクラスタを更新して静的パスワードを削除するには、静的パスワードによる認証の無効化をご覧ください。

現在、既存のクラスタから発行済みの有効なクライアント証明書を削除する方法はありませんが、RBAC が有効で ABAC が無効ならば証明書に権限はありません。

Cloud Logging を有効のままにする

CIS GKE ベンチマークの推奨事項: 6.7.1。Stackdriver Kubernetes のロギングとモニタリングが有効になっていることを確認する

運用上のオーバーヘッドを削減し、ログの統合ビューを維持するには、クラスタがデプロイされているすべての場所に一貫性のあるロギング方法を実装します。GKE Enterprise クラスタはデフォルトで Cloud Logging と統合されており、その構成を維持する必要があります。

すべての GKE クラスタではデフォルトで Kubernetes 監査ロギングが有効になっています。これにより、Kubernetes API サーバーに対する呼び出しの記録が時系列で保持されます。Kubernetes 監査ログのエントリは、不審な API リクエストの調査、統計情報の収集、不要な API 呼び出しに対するモニタリングアラートの作成に役立ちます。

GKE クラスタは Kubernetes Audit Logging を Cloud Audit Logs と Cloud Logging に統合します。ログは、Cloud Logging から独自のロギングシステムにルーティングできます。

Kubernetes ウェブ UI（ダッシュボード）を無効のままにする

CIS GKE ベンチマークの推奨事項: 6.10.1。Kubernetes ウェブ UI が無効になっていることを確認する

GKE での実行時に Kubernetes ウェブ UI（ダッシュボード）を有効にしないでください。

Kubernetes ウェブ UI（ダッシュボード）は、高い特権を持つ Kubernetes サービスアカウントと関連付けられています。Google Cloud コンソールにほぼ同じ機能があるため、こうした権限は必要ありません。

Kubernetes ウェブ UI を無効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --update-addons=KubernetesDashboard=DISABLED

ABAC を無効のままにする

CIS GKE ベンチマークの推奨事項: 6.8.4。以前の承認（ABAC）が無効になっていることを確認する

GKE で、属性ベースのアクセス制御（ABAC）を無効にし、代わりにロールベースのアクセス制御（RBAC）を使用してください。

ABAC は、GKE バージョン 1.8 以降を使用して作成されたクラスタではデフォルトで無効になります。Kubernetes では、RBAC を使用してリソースに対する権限をクラスタレベルと Namespace レベルで付与します。RBAC では、一連の権限を含むルールを使用してロールを定義できます。RBAC には、ABAC と比較して重要なセキュリティ上の利点があります。

現状で ABAC に依存している場合は、まず RBAC を使用する場合の前提条件を確認してください。クラスタを古いバージョンからアップグレードして ABAC を使用している場合は、次のようにアクセス制御の構成を更新する必要があります。

gcloud container clusters update CLUSTER_NAME \
    --no-enable-legacy-authorization

上記の推奨に従って新しいクラスタを作成するには、次のコマンドを実行します。

gcloud container clusters create CLUSTER_NAME \
    --no-enable-legacy-authorization

`DenyServiceExternalIPs` アドミッションコントローラを有効のままにする

DenyServiceExternalIPs アドミッションコントローラを無効にしないでください。

DenyServiceExternalIPs アドミッションコントローラは、Service が ExternalIPs を使用できないようにするとともに、既知のセキュリティ脆弱性を緩和します。

GKE バージョン 1.21 以降で作成された新しいクラスタでは、DenyServiceExternalIPs アドミッションコントローラがデフォルトで有効になります。GKE バージョン 1.21 以降にアップグレードしたクラスタでは、次のコマンドを使用してアドミッションコントローラを有効にできます。

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-service-externalips

次のステップ

セキュリティの概要で GKE セキュリティの詳細を確認する。
GKE の共有責任モデルについての理解を深める。
CIS GKE ベンチマークをクラスタに適用する方法を理解する。
GKE でのアクセス制御の詳細を確認する。
GKE ネットワークの概要を読む。
GKE マルチテナンシーの概要を読む。

クラスタのセキュリティを強化する

GKE インフラストラクチャを適切なタイミングでアップグレードする

コントロール プレーンとノードへのネットワーク アクセスを制限する

最小権限のファイアウォール ルールを使用する

グループ認証

コンテナノードを選択する

シールドされた GKE ノードを有効にする

containerd ランタイムで強化されたノードイメージを選択する

GKE 用 Workload Identity 連携を有効にする

GKE Sandbox によるワークロード分離の強化

セキュリティに関する公開情報の通知を有効にする

安全でない kubelet 読み取り専用ポートを無効にする

権限

最小権限の IAM サービス アカウントを使用する

gcloud

Config Connector

限定公開イメージ リポジトリへのアクセス権を付与する

gcloud

Config Connector

gcloud

Config Connector

gcloud

Config Connector

クラスタ API 検出へのアクセスを制限する

Namespace と RBAC を使用してクラスタ リソースへのアクセスを制限する

Pod 間のトラフィックをネットワーク ポリシーで制限する

Secret 管理

アドミッション コントローラを使用してポリシーを適用する

ワークロードの自己変更機能を制限する

非推奨の gcePersistentDisk ボリューム タイプの使用を制限する

Policy Controller

Gatekeeper

クラスタ構成を監視する

安全なデフォルト

ノードのメタデータを保護する

以前のクライアント認証方式を無効のままにする

Cloud Logging を有効のままにする

Kubernetes ウェブ UI（ダッシュボード）を無効のままにする

ABAC を無効のままにする

DenyServiceExternalIPs アドミッション コントローラを有効のままにする

次のステップ

コントロールプレーンとノードへのネットワークアクセスを制限する

最小権限のファイアウォールルールを使用する

最小権限の IAM サービスアカウントを使用する

限定公開イメージリポジトリへのアクセス権を付与する

Namespace と RBAC を使用してクラスタリソースへのアクセスを制限する

Pod 間のトラフィックをネットワークポリシーで制限する

アドミッションコントローラを使用してポリシーを適用する

非推奨の `gcePersistentDisk` ボリュームタイプの使用を制限する

`DenyServiceExternalIPs` アドミッションコントローラを有効のままにする