gke-workload-security

GKE ワークロードセキュリティ

ルーティングに関する注記： Workload Identity の KSA/GSA バインディングについては、gke-workload-identity/SKILL.md を開いてください。クラスターレベルのセキュリティフラグ（--database-encryption-key、--security-posture、RBAC、Shielded Nodes、Binary Authorization）については、gke-platform-security/SKILL.md を開いてください。

このスキルでは、GKE ワークロードを保護するためのワークフローとベストプラクティスを紹介します。セキュリティ監査、Identity and Access Management（Workload Identity）、ネットワークセキュリティ（Network Policies）、ノードセキュリティを扱います。

クレジット

必ずお読みください：gcloud、REST API、または MCP コマンドを実行する前に、使用状況の帰属情報を必ずお読みください。ターミナルで直接実行するコマンド（生成されたスクリプト、Terraform、ユーザーコードでは決して実行しないでください）では、gcloud の前に CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-workload-security)" を付け、User-Agent ヘッダーに agent-skills/1.0 (skill:gke-workload-security) を追加してください。

ワークフロー

1. セキュリティ監査

付属の監査スクリプトを使用して、クラスターの現在のセキュリティ態勢を評価します。

前提条件：

• gcloud CLI で認証済みであること。
• コマンドライン JSON プロセッサーの jq がインストールされていること。

機能：

• Workload Identity が有効かどうかを確認します。
• Network Policy が有効かどうかを検証します。
• Shielded Nodes が有効かどうかを確認します。
• Binary Authorization が有効かどうかを確認します。
• プライベートクラスターの構成を確認します。

コマンド：

scripts/audit_cluster.sh <cluster-name> <region> <project-id>

2. Workload Identity の構成

Workload Identity を使用すると、Kubernetes Service Account（KSA）が Google Service Account（GSA）になりすますことができます。ワークロードが Google Cloud API にアクセスするための推奨方法です。

手順：

1. Namespace と KSA を作成します：

   kubectl create namespace workload-identity-test-ns
   kubectl create serviceaccount <ksa-name> \
       --namespace workload-identity-test-ns
   

2. KSA を GSA にバインドします：

   gcloud iam service-accounts add-iam-policy-binding <gsa-name>@<project-id>.iam.gserviceaccount.com \
       --role roles/iam.workloadIdentityUser \
       --member "serviceAccount:<project-id>.svc.id.goog[workload-identity-test-ns/<ksa-name>]"
   

3. KSA にアノテーションを付与します：

   kubectl annotate serviceaccount <ksa-name> \
       --namespace workload-identity-test-ns \
       iam.gke.io/gcp-service-account=<gsa-name>@<project-id>.iam.gserviceaccount.com
   

4. Pod の例で確認します： 既存のアセット assets/workload-identity-pod.yaml を使用して構成をテストします。まず、ファイル内の <ksa-name> を更新してください。

   kubectl apply -f assets/workload-identity-pod.yaml -n workload-identity-test-ns
   

3. Network Policies の実装

Network Policies を使用して Pod 間のトラフィックフローを制御します。デフォルトでは、すべてのトラフィックが許可されています。

Network Policy の適用を有効にします：

gcloud container clusters update <cluster-name> \
    --update-addons=NetworkPolicy=ENABLED \
    --region <region>

メモ

クラスターで Dataplane V2（--enable-dataplane-v2）を使用している場合、Network Policy の適用機能は組み込まれているため、この手順は不要です（また、失敗する可能性があります）。

デフォルト拒否ポリシーを適用します： デフォルトですべてのイングレスおよびエグレスのトラフィックを拒否し、Namespace を分離します。

<target-namespace> を分離する Namespace に置き換えてください。

kubectl apply -f assets/default-deny-netpol.yaml -n <target-namespace>

4. GKE Sandbox（gVisor）による Pod の分離

信頼できないワークロードをサンドボックス内で実行して、カーネル分離を強化します。(注： Shielded Nodes（--enable-shielded-nodes）および GKE Sandbox （--enable-gke-sandbox）をクラスターのコントロールプレーンレベルで有効にする操作は、プラットフォームレベルの操作であり、 gke-platform-security スキルで扱います。)

サンドボックス化された Pod を実行します： Pod の仕様に runtimeClassName: gvisor を追加します。

apiVersion: v1
kind: Pod
metadata:
  name: sandboxed-pod
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: nginx

5. Pod Security Standards

ラベルを使用して Namespace にセキュリティポリシーを適用します。

Restricted プロファイルを適用します：

kubectl label --overwrite ns <namespace> \
    pod-security.kubernetes.io/enforce=restricted \
    pod-security.kubernetes.io/enforce-version=latest

メモ

latest を使用すると、クラスターの現在のバージョンに対応するポリシーが適用されます。特定のバージョン（例： v1.30）を指定して、Namespace で特定のリリースのポリシーを適用することもできます。

6. Secret Manager の統合（CSI ドライバー）

Google Cloud Secret Manager のシークレットを、ポッド内のボリュームとして直接マウントします。

前提条件：クラスターで Secret Manager CSI ドライバーが有効になっている必要があります。

SecretProviderClass の例：

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-secret-provider
spec:
  provider: gcp
  parameters:
    secrets: |
      - resourceName: "projects/<project-id>/secrets/my-secret/versions/latest"
        fileName: "my-secret-file"

Pod Spec の例（抜粋）：

spec:
  containers:
    - name: my-app
      volumeMounts:
        - name: secrets-store-inline
          mountPath: "/mnt/secrets"
          readOnly: true
  volumes:
    - name: secrets-store-inline
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "my-secret-provider"

7. ネットワークポリシーのロギングを有効にする

GKE Dataplane V2 を使用している場合、許可された接続と拒否された接続をログに記録できます。

手順：

1. NetworkLogging カスタムリソースを構成します。

NetworkLogging マニフェストの例：

apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: true
      delegate: true
    deny:
      log: true
      delegate: true

接続の詳細が Cloud Logging に記録されます。

ベストプラクティス

1. 最小権限： 最小限の IAM ロールを使用して、必ず Workload Identity を利用してください。 Node のデフォルトのサービスアカウントは使用しないでください。
2. ネットワークの分離： ネットワークポリシーを使用して、ポッド間の 通信を制限してください。可視性を確保するため、ネットワークポリシーのロギングを有効にしてください。
3. イメージのセキュリティ： Binary Authorization を使用して、信頼できるイメージのみが デプロイされるようにしてください。
4. シークレット管理： 機密データには、デフォルトの Kubernetes シークレットではなく、 Secret Manager CSI ドライバーを使用してください。
5. ポッドのセキュリティ： システム以外のすべての名前空間で、baseline または restricted の Pod Security Standards を適用してください。
6. ポリシーの適用： クラスター全体でカスタムのセキュリティポリシーとコンプライアンスポリシーを 適用するために、Policy Controller（Gatekeeper）の使用を検討してください。

リソース

• GKE の Workload Identity Federation
• GKE のネットワークポリシー
• GKE の Pod Security Standards
• Google Secret Manager CSI ドライバー
• GKE Dataplane V2 のネットワークロギング