Security+ Academy · レッスン

Kubernetesセキュリティ：RBAC、ネットワークポリシー、Podセキュリティ

KubernetesのRBACロールを設定し、Pod間通信を制限するネットワークポリシーを適用して、特権昇格を制限するPodセキュリティ標準を適用します。

「Kubernetesセキュリティ：RBAC、ネットワークポリシー、Podセキュリティ」はCoddyKit上の無料Security+ Academyレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはSecurity+ Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Security+ Academyコースには全4レッスンが含まれています。

Kubernetesの攻撃対象領域の概要

Kubernetesはコンテナ化されたワークロードを大規模にオーケストレーションしますが、その複雑さによって広範な攻撃対象領域が生じます。保護が必要な主なコンポーネントには、API Server（中央のコントロールプレーン。ここが侵害されるとクラスタ全体を制御されます）、etcd（クラスタ状態データベース。シークレットをbase64で保存するため、保存時の暗号化が必要です）、kubelet（ノードエージェント。認証されていないkubelet APIにより、任意のPodを実行される可能性があります）、container runtime（Docker/containerd）、すべてのPodを接続するネットワーク基盤があります。Security+の受験者は、Kubernetesの設定ミスがクラウドセキュリティで最も頻繁に見つかる問題の一つであることを理解しておく必要があります。

RBAC：Kubernetesにおけるロールベースアクセス制御

KubernetesのRBAC (Role-Based Access Control)は、ユーザー、サービスアカウント、プロセスが、どのAPIリソースに対してどの操作を実行できるかを制御します。このモデルには4つのオブジェクトがあります。Role（Namespace内の権限）、ClusterRole（クラスタ全体の権限）、RoleBinding（Namespace内でRoleを主体に付与）、ClusterRoleBinding（クラスタ全体でClusterRoleを主体に付与）です。すべてのkubectlコマンドはAPI呼び出しに変換され、RBACルールに基づいてチェックされます。RBACが設定されていない場合、認証済みのユーザー（またはサービスアカウント）が管理者アクセス権を持つ可能性があります。

# Create a role allowing only pod reads in 'default' namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [''] 
  resources: ['pods']
  verbs: ['get', 'list', 'watch']

サービスアカウントと最小権限

KubernetesのすべてのPodは、API認証に使用されるIDであるサービスアカウントのもとで実行されます。デフォルトでは、PodはそのNamespaceのdefaultサービスアカウントを使用しますが、このアカウントには広範な権限が付与されている可能性があります。最小権限の原則に従い、アプリケーションごとに、必要な権限だけを持つ専用サービスアカウントを作成する必要があります。さらに、APIアクセスを必要としないPodでautomountServiceAccountToken: falseを設定すると、サービスアカウントトークンがPodのファイルシステムにマウントされるのを防げます。これにより、侵害されたアプリケーションがそのトークンを使ってAPIを呼び出すことを防止できます。

# Pod spec: disable service account token auto-mount
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  serviceAccountName: myapp-sa
  automountServiceAccountToken: false
  containers:
  - name: myapp
    image: myapp:v1.0

ネットワークポリシー：デフォルト拒否

Kubernetesではデフォルトで、すべてのPodが任意のNamespaceにある他のすべてのPodと通信できますKubernetes NetworkPolicyリソースは、ラベル、Namespace、ポートに基づいてPod間のトラフィックを制限するルールを定義します。推奨される方法は、各Namespaceに「すべてをデフォルト拒否」するネットワークポリシーを設定し、その後、必要な通信経路に対する明示的な許可ルールを追加することです。ただし、NetworkPolicyを使用するには対応するCNIプラグイン（Calico、Cilium、Weave）が必要です。互換性のあるCNIがなければ、標準のKubernetesはNetworkPolicyを無視します。

# Default deny all ingress and egress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Pod Security Standards：PSPの置き換え

Pod Security Standards (PSS)は、Kubernetes 1.23で導入され、1.25で安定版となりました。非推奨となったPod Security Policy (PSP)に代わり、Namespaceレベルで適用される3つの組み込みプロファイルを提供します。Privileged（制限なし。システムコンポーネント向け）、Baseline（特権コンテナやホストネットワークアクセスなど、既知の権限昇格を防止）、Restricted（強化されたプロファイル。非rootユーザー、すべてのケーパビリティの削除、読み取り専用rootファイルシステムを必須化）です。Namespaceにポリシーレベルのラベルを付けて適用し、違反するPodはアドミッション時に拒否されます。

# Label namespace to enforce 'restricted' pod security
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

Kubernetesにおけるシークレット管理

KubernetesのSecretsは、パスワード、トークン、TLS証明書などの機密データを保存します。デフォルトでは、Secretsはbase64でエンコードされた値としてetcdに保存され、暗号化されていません。etcdを読み取れる人や、十分なRBAC権限を持つ人は、簡単にデコードできます。ベストプラクティスには、KMS（AWS KMS、GCP KMS）に保存した鍵を使ってetcdの保存時暗号化を有効にすること、Secrets Store CSI Driverを介してHashiCorp VaultやAWS Secrets Managerなどの外部シークレットマネージャーと統合すること、必要とするサービスアカウントだけがSecretを読み取れるようRBACでアクセスを制限することが含まれます。

# Enable etcd encryption at rest (encryption configuration)
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>

アドミッションコントローラー：セキュリティゲート

アドミッションコントローラーはKubernetes APIサーバーのプラグインです。認証と認可の後、オブジェクトが永続化される前にAPIリクエストを傍受し、リクエストの検証、変更、拒否を行います。セキュリティに関連するアドミッションコントローラーには、PodSecurity（Pod Security Standardsを適用）、ImagePolicyWebhook（外部のイメージ署名検証を可能にする）、AlwaysPullImages（常に新しいイメージをプルさせ、ローカルにキャッシュされた悪意のあるイメージの使用を防止）、OPA/Gatekeeper（Open Policy Agent。最も柔軟性が高く、Rego言語で記述したカスタムポリシーにより、組織の任意のセキュリティルールを適用可能）があります。

クラスタコンポーネントのハードニング

Kubernetesのコントロールプレーンコンポーネントをハードニングすることは重要です。APIサーバーでは、認証されていないアクセスを無効にするために--anonymous-auth=falseを設定し、すべてのAPIアクティビティを記録するよう--audit-log-pathを設定し、すべての接続にTLSを使用する必要があります。kubeletでは、--authorization-mode=Webhook（AlwaysAllowではない）を設定し、匿名認証を無効にする必要があります。etcdでは、ピアおよびクライアント間の通信をTLSで暗号化し、ネットワークアクセスを制限してAPIサーバーからのみ到達可能にし、保存データを暗号化する必要があります。CIS Kubernetes Benchmarkは、すべてのコンポーネント設定を対象とする包括的なチェックリストを提供します。

# Check kubelet configuration for security issues
kubectl get --raw /api/v1/nodes/nodename/proxy/configz | jq '.kubeletconfig | {anonymousAuth: .authentication.anonymous.enabled, authorization: .authorization.mode}'

Namespace分離とマルチテナンシー

KubernetesのNamespaceはリソースを論理的に分離しますが、それだけでは強固なセキュリティ境界にはなりません。主に組織上の分離を提供するものです。真のマルチテナント分離（例：異なる顧客のワークロード）には、追加の制御が必要です。たとえば、Namespace間のトラフィックをブロックするネットワークポリシー、ノイジーネイバーによるDoSを防ぐリソースクォータ、テナントを強力に分離する個別のノードプール、またはテナントごとの専用クラスタなどがあります。単一クラスタ内でより強力なマルチテナンシーを実現するために、多くの組織がHierarchical Namespacesや、vClusterなどの商用ソリューションを利用しています。

監査ログとランタイム監視

Kubernetes の監査ログには、すべての API リクエストについて、誰が、どこから、どの操作を要求し、どのリソースを対象にしたかが記録されます。監査ログは、セキュリティインシデント後のフォレンジック調査や、通常とは異なるロールバインディング、Secret へのアクセス、本番 Pod への exec コマンドなどの異常な挙動の検知に不可欠です。監査ログは一元化された SIEM にストリーミングする必要があります。Falco はコンテナの挙動をランタイムで監視します。また、クラウドマネージド Kubernetes サービス（EKS、GKE、AKS）は、それぞれのロギングプラットフォームとのネイティブな監査ログ統合機能を提供します。

# Check recent kubectl exec events in audit log
grep '"verb":"create".*"resource":"pods".*"subresource":"exec"' /var/log/kubernetes/audit.log | tail -20

サプライチェーンセキュリティ：イメージの出所

Kubernetes におけるサプライチェーンセキュリティは、信頼性があり検証済みのイメージだけを本番環境に到達させるためのものです。CNCF のサプライチェーンセキュリティに関する推奨事項には、デプロイ前に Cosign でイメージ署名を検証すること（admission controller によって強制）、すべてのコンテナイメージについてSBOM（Software Bills of Materials）を生成・検証し、コンポーネントの出所を追跡できるようにすること、変更可能なタグではなくダイジェスト（myimage@sha256:abc123）にイメージを固定すること、デプロイ前にすべてのサードパーティ製 Helm チャートを設定ミスや脆弱性についてスキャンすることが含まれます。

# Pin image to digest for immutability
# Instead of:
image: nginx:latest
# Use:
image: nginx@sha256:a3e2a7a3d7f94e...  # immutable digest

クイックチェック

このレッスンで扱った CompTIA Security+（SY0-701）の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、Kubernetes RBAC が Role、ClusterRole、Binding を通じて API アクセスを制御すること、サービスアカウントには常に最小権限を適用すること、NetworkPolicy のデフォルト拒否設定が Pod や Namespace 間のラテラルムーブメントを防ぐこと、そしてPod Security Standards がコンテナのハードニングを強制することで、特権コンテナ、ホストネットワークへのアクセス、root での実行を Namespace レベルでブロックすることを学びました。次は、サーバーレスセキュリティと、関数レベルの攻撃対象領域について学びます。

よくある質問

「Kubernetesセキュリティ：RBAC、ネットワークポリシー、Podセキュリティ」レッスンは無料ですか？

はい。「Kubernetesセキュリティ：RBAC、ネットワークポリシー、Podセキュリティ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Security+ Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Security+ Academyコースには全4レッスンが含まれています。

「Kubernetesセキュリティ：RBAC、ネットワークポリシー、Podセキュリティ」で何を学びますか？

KubernetesのRBACロールを設定し、Pod間通信を制限するネットワークポリシーを適用して、特権昇格を制限するPodセキュリティ標準を適用します。ブラウザで直接実行するハンズオンコードでSecurity+ Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Security+ Academyを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのSecurity+ Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン2/4です。

「Kubernetesセキュリティ：RBAC、ネットワークポリシー、Podセキュリティ」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSecurity+ Academyレッスンでコードを書いて実行できますか？

はい。すべてのSecurity+ Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

コンテナセキュリティ：イメージの堅牢化とランタイム保護
Kubernetesセキュリティ：RBAC、ネットワークポリシー、Podセキュリティ
サーバーレスと関数のセキュリティ
Infrastructure as Codeのセキュリティスキャン

← Security+ Academyに戻る