mcpField
K
k8s-security-policies

k8s-security-policies

github.com/sickn33セキュリティ48.7k205 回インストール1 日前に更新
リポジトリ

k8s-security-policies について

Kubernetes のセキュリティ対策を案内するスキルです。NetworkPolicy、RBAC、Pod Security Standards、アドミッション制御を扱い、ネットワーク分割や最小権限、多テナント環境の設定を支援します。

主な機能

  1. 01ネットワークポリシーと分割の設定
  2. 02最小権限 RBAC の設計
  3. 03Pod Security Standards の適用
  4. 04Gatekeeper と Istio のポリシー例
  5. 05ポリシー検証とトラブル対応の案内

活用シーン

  1. 01ワークロード間通信の制限
  2. 02サービスアカウントの権限最小化
  3. 03マルチテナント Kubernetes クラスターの強化

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill k8s-security-policies

インストール後、Claude Code で/k8s-security-policiesを入力して読み込まれたか確認します。

同梱ファイルreferences/rbac-patterns.mdassets/network-policy-template.yaml

詳細

サポート資料の入手可能性

このカタログのコピーには、以下のインラインガイダンスが含まれていますが、次のサポート用パスは含まれていません。これらは外部の前提条件であり、同梱ファイルではありません。

  • <support-root>/assets/pod-security-template.yaml

これらのパスに依存する手順を実行する前に、元のサポート資料または既存のインストール環境を入手してください。このカタログには、検証済みのダウンロード元は記載されていません。各パスはそのインストール環境を基準に解決し、内容を確認して、該当するライセンスと実行上の前提条件を検証してください。必要なファイルが存在することを確認するまでは、コマンドを実行したり、参照先の手順に従ったと主張したりしないでください。不足しているスクリプトを捏造したり、同名の無関係なファイルを同等のものとして扱ったりしないでください。ここにすべて記載された独立した手順は、ユーザーが承認した範囲内で実行できます。依存する手順は利用できないものとして報告してください。

Kubernetes セキュリティポリシー

Kubernetes における NetworkPolicy、RBAC、Pod Security Admission/Standards(PodSecurityPolicy は Kubernetes1.25 で削除されました)に関するガイドです。

このスキルを使用しない場合

  • Kubernetes のセキュリティポリシーに関係のないタスク
  • この範囲外の別のドメインやツールが必要な場合

手順

  • 目標、制約、必要な入力を明確にします。
  • 関連するベストプラクティスを適用し、結果を検証します。
  • 実行可能な手順と検証方法を提示します。

目的

ネットワークポリシー、Pod セキュリティ標準、RBAC を使用して、Kubernetes クラスターの多層防御セキュリティを実装します。

このスキルを使用する場合

  • ネットワークのセグメンテーションを実装する
  • Pod セキュリティ標準を設定する
  • 最小権限アクセスのために RBAC を設定する
  • コンプライアンス対応のセキュリティポリシーを作成する
  • アドミッション制御を実装する
  • マルチテナントクラスターを保護する

Pod セキュリティ標準

1. Privileged(制限なし)
apiVersion: v1
kind: Namespace
metadata:
  name: privileged-ns
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/warn: privileged
2. Baseline(制限を最小限に抑える)
apiVersion: v1
kind: Namespace
metadata:
  name: baseline-ns
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/warn: baseline
3. Restricted(最も制限が厳しい)
apiVersion: v1
kind: Namespace
metadata:
  name: restricted-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

ネットワークポリシー

NetworkPolicy には強制力のある CNI が必要です。ノードやポリシーの一覧表示だけでは、強制されていることの証明にはなりません。ポリシーは加算的に適用され、接続を許可するには、送信元のエグレスと宛先のイングレスの両方で許可されている必要があります。デフォルトですべて拒否する場合、バックエンドのイングレス例に加えて、対応するフロントエンドのエグレス許可も必要です。DNS には kube-system の Pod 宛てではなく NodeLocal DNS が使われる場合があります。実際のリゾルバーとセレクターを確認してください。標準のポリシーは L3/L4 を対象としており、FQDN/HTTP やすべての環境でのメタデータ分離を強制するものではありません。NAT/ホストネットワーク/IPv6 の動作は CNI によって異なります。障害を避けるため、強制する前に段階的に適用するかドライランを行い、承認済みの通信フローについて許可・拒否の両方をテストしてください。Pod Security の特権モードでは制限が解除されます。まず監査/警告を使用し、強制する前に意図したポリシーバージョンを固定してください。

デフォルトですべて拒否
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
フロントエンドからバックエンドへの通信を許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
DNS を許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

参照: assets/network-policy-template.yaml を参照してください。

RBAC の設定

Role(Namespace スコープ)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
ClusterRole(クラスター全体)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

参照: references/rbac-patterns.md を参照してください。

Pod セキュリティコンテキスト

制限付き Pod
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

OPA Gatekeeper によるポリシー適用

ConstraintTemplate
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("missing required labels: %v", [missing])
        }
Constraint
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-app-label
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels: ["app", "environment"]

サービスメッシュのセキュリティ(Istio)

PeerAuthentication(mTLS)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
AuthorizationPolicy
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/frontend"]

ベストプラクティス

  1. Namespace レベルでPod セキュリティ標準を実装する
  2. ネットワークのセグメンテーションにNetwork Policies を使用する
  3. すべてのサービスアカウントに最小権限の RBAC を適用する
  4. アドミッション制御を有効化する(OPA Gatekeeper/Kyverno)
  5. コンテナーを非 root で実行する
  6. root ファイルシステムを読み取り専用にする
  7. 必要な場合を除き、すべてのケイパビリティを削除する
  8. リソースクォータとリミットレンジを実装する
  9. セキュリティイベントの監査ログを有効化する
  10. イメージの定期的なセキュリティスキャンを実施する

コンプライアンスフレームワーク

CIS Kubernetes Benchmark
  • RBAC 認可を使用します
  • 監査ログを有効にします
  • Pod Security Standards を使用します
  • ネットワークポリシーを設定します
  • 保存時のシークレット暗号化を実装します
  • ノード認証を有効にします
NIST Cybersecurity Framework
  • 多層防御を実装します
  • ネットワークをセグメント化します
  • セキュリティ監視を設定します
  • アクセス制御を実装します
  • ログ記録と監視を有効にします

トラブルシューティング

NetworkPolicy が機能しない場合:

# Check if CNI supports NetworkPolicy
kubectl get nodes -o wide
kubectl describe networkpolicy <name>

RBAC の権限が拒否された場合:

# Check effective permissions
kubectl auth can-i list pods --as system:serviceaccount:default:my-sa
kubectl auth can-i '*' '*' --as system:serviceaccount:default:my-sa

参照ファイル

  • assets/network-policy-template.yaml - ネットワークポリシーの例
  • assets/pod-security-template.yaml - Pod セキュリティポリシー
  • references/rbac-patterns.md - RBAC 設定パターン

関連スキル

  • k8s-manifest-generator - セキュアなマニフェストの作成に使用します
  • gitops-workflow - ポリシーのデプロイを自動化する場合に使用します

制限事項

  • タスクが上記の説明された範囲に明確に該当する場合にのみ、このスキルを使用してください。
  • 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
  • 必要な入力、権限、安全上の境界、または成功基準が不足している場合は、停止して確認を求めてください。

コメント