Contents
- 1 📋 目次
- 2 全体像とチェックリスト
- 3 4C フレームワークで考える全層防御
- 4 RBAC と最小権限の実装
- 5 ネットワークセキュリティ: NetworkPolicy ＆ Service Mesh の統合
- 6 シークレット管理・サプライチェーン保護
- 7 ランタイム監視とポリシーエンジン
- 8 CI/CD パイプラインに組み込む自動チェックリスト
- 9 まとめ & 実装チェックリスト
スポンサードリンク
📋 目次
- 全体像とチェックリスト
- 4C フレームワークで考える「全層防御」
- Configuration（設定）
- Credential（認証情報）
- Container（コンテナイメージ）
- Communication（通信）
- RBAC と最小権限の実装
- ネットワークセキュリティ：NetworkPolicy ＆ Service Mesh の統合
- シークレット管理・サプライチェーン保護
- ランタイム監視とポリシーエンジン
- CI/CD パイプラインに組み込む自動チェックリスト
- まとめ & 実装チェックリスト
全体像とチェックリスト
| 項目 | 確認ポイント | 推奨ツール/設定例 |
|---|---|---|
| 設定 (Configuration) | API Server の安全オプションが有効か | --anonymous-auth=false、--authorization-mode=RBAC,Node |
| 認証情報 (Credential) | Secrets が暗号化・自動ローテーションされているか | Etcd 暗号化 + KMS、CronJob で定期更新 |
| コンテナイメージ | ビルド時に脆弱性スキャンと署名が行われているか | Trivy + Cosign (GitHub Actions / GitLab CI) |
| 通信 (Communication) | Pod 間は最小権限の NetworkPolicy と mTLS で保護されているか | デフォルト deny → 必要な allow、Istio strict‑mtls |
| RBAC | ClusterRole/Role が最小権限でバインドされ、監査ログが出力されるか | RoleBinding + audit‑policy |
| シークレット管理 | 外部 KMS で Etcd 暗号化、Vault 等と連携したローテーションができているか | GCP/AWS/KMS + CronJob/Vault |
| ランタイム監視 | 不審なプロセス・リソース作成を検知し阻止できるか | Falco + OPA Gatekeeper / Kyverno |
| CI/CD ガード | プルリクエスト時に全ポリシーが自動テストされ、合格しないとマージできないか | kube‑score・conftest 連携 GitHub Actions |
✅ チェックリストは Git リポジトリの
SECURITY_CHECKLIST.mdとして管理し、CI の「Security Gate」ジョブで必ず参照
4C フレームワークで考える全層防御
1️⃣ Configuration – 設定の安全化
Why
設定ミスは攻撃者が最初に突き止めやすい入口です。CNCF の 2023 年サーベイ（※参考: CNCF Survey 2023）でも、設定不備がインシデントの約30％を占めると報告されています。
What to Do
- API Server の安全オプションをコード化（GitOps）し、CI で lint → apply を自動化。
- デフォルトは 最小権限（RBAC）に統一。
実装例（Helm values.yaml）
|
1 2 3 4 5 6 |
# values.yaml (helm) apiserver: extraArgs: anonymous-auth: "false" # 匿名アクセス禁止 authorization-mode: "RBAC,Node" # RBAC と Node 認可を有効化 |
解説（初心者向け）
--anonymous-auth=false は「認証されていないユーザーが API にアクセスできなくする」設定です。
--authorization-mode=RBAC,Node は「ロールベースの権限管理」と「ノードレベルの権限」を同時に有効化し、最小権限を徹底します。
2️⃣ Credential – 認証情報の保護と自動ローテーション
Why
Etcd が平文で保存されていると、クラスター内部からでもすべてのシークレットが取得可能です（Kubernetes 公式ドキュメント参照）。
What to Do
| 手順 | 内容 |
|---|---|
| 暗号化 | Etcd データを外部 KMS（AWS KMS、GCP Cloud KMS、Azure Key Vault）で暗号化 |
| 自動ローテーション | CronJob / Argo Workflow でシークレットを定期的に再生成・更新 |
実装例 – GCP KMS と Etcd 暗号化
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# encryptionconfig.yaml（抜粋） kind: EncryptionConfiguration resources: - resources: - secrets providers: - kms: name: gcp-kms cachesize: 100 endpoint: https://cloudkms.googleapis.com/v1/projects/PROJECT_ID/locations/asia-northeast1/keyRings/k8s-keyring/cryptoKeys/etcd-key - identity: {} |
実装例 – Secrets ローテーション CronJob
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
apiVersion: batch/v1 kind: CronJob metadata: name: secret-rotate-db spec: schedule: "0 2 * * *" # 毎日 02:00 に実行 jobTemplate: spec: template: spec: containers: - name: rotator image: bitnami/kubectl:latest command: ["/bin/sh","-c"] args: - | NEW=$(openssl rand -base64 32) kubectl create secret generic db-password \ --from-literal=password=$NEW \ --dry-run=client -o yaml | kubectl apply -f - restartPolicy: OnFailure |
ポイント：
kubectl create secret … --dry-run=client -o yaml | kubectl apply -f -によって、既存シークレットを上書きしながら安全に更新できます。
3️⃣ Container – コンテナイメージのスキャンとサプライチェーン対策
Why
サプライチェーン攻撃は「未署名・脆弱性があるイメージ」から始まるケースが多数です（Aikido の 2024 年レポート参照）。
What to Do
| アクション | ツール例 |
|---|---|
| 脆弱性スキャン | Trivy、Snyk |
| イメージ署名 | Cosign（Sigstore） |
| CI で自動化 | GitHub Actions / GitLab CI / Azure Pipelines |
実装例 – GitHub Actions ワークフロー
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
name: Image Scan & Sign on: push: branches: [main] jobs: scan-sign: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 # Docker ビルド - name: Build image run: | docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} . # Trivy で脆弱性スキャン - name: Trivy Scan uses: aquasecurity/trivy-action@master with: image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }} format: sarif output: trivy-results.sarif # Cosign でイメージ署名（シークレットは GitHub Secrets に保存） - name: Sign image env: COSIGN_PASSWORD: ${{ secrets.COSIGN_PWD }} run: | cosign sign --key env://COSIGN_PRIVATE_KEY \ ghcr.io/${{ github.repository }}:${{ github.sha }} |
解説（初心者向け）
- Trivy は Docker イメージをスキャンし、脆弱性情報を SARIF 形式で出力します。GitHub の「Security」タブに結果が自動表示されます。
- Cosign はイメージに対して暗号署名を付与し、デプロイ先で
cosign verifyによって真正性と改ざん防止を検証できます。
4️⃣ Communication – ネットワーク通信のゼロトラスト実装
Why
内部横移動（Lateral Movement）攻撃は「許可されたまま全 Pod が自由に通信できる」ことが原因です。CNCF の 2023 年ネットワーク調査 でも、デフォルト allow が残っているクラスターは依然として多数です。
What to Do
- NetworkPolicy で「デフォルト deny」 を設定
- 必要な通信だけをラベルベースで allow
- Istio（または Linkerd）で mTLS を strict に し、暗号化と相互認証を実装
実装例 – デフォルト deny + allow ポリシー
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# default-deny-all.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: prod spec: podSelector: {} # 全 Pod に適用 policyTypes: - Ingress - Egress |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# allow-frontend-to-backend.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-backend namespace: prod spec: podSelector: matchLabels: app: backend # Backend のみ対象 ingress: - from: - podSelector: matchLabels: app: frontend # Frontend からの通信を許可 ports: - protocol: TCP port: 8080 |
Istio で mTLS を strict に設定
|
1 2 3 4 5 6 7 8 9 10 |
# peer-authentication-strict.yaml apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: strict-mtls namespace: prod spec: mtls: mode: STRICT # 全トラフィックで mTLS を必須化 |
AuthorizationPolicy（サービス間の許可リスト）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# authz-frontend-to-backend.yaml apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: allow-frontend namespace: prod spec: selector: matchLabels: app: backend # 対象は Backend rules: - from: - source: principals: ["cluster.local/ns/prod/sa/frontend"] # Frontend の ServiceAccount のみ許可 |
解説（初心者向け）
- NetworkPolicy は「どの Pod がどこへ送信できるか」をレイヤー 3/4 で制御します。
podSelector: {}が空の場合はすべての Pod が対象です。 - Istio の PeerAuthentication は「通信が暗号化され、相手の証明書を検証する」ことを強制し、NetworkPolicy だけでは実現できない 相互認証 を提供します。
- AuthorizationPolicy は「どのサービスアカウント（principal）がどのサービスにアクセスできるか」をレイヤー 7（HTTP/gRPC）で制御します。
RBAC と最小権限の実装
基本方針
| 項目 | ベストプラクティス |
|---|---|
| ロール設計 | ClusterRole はクラスタ全体に必要な権限だけ、Role は Namespace 単位で最小化 |
| バインディング | 必要最小の Subject（User / Group / ServiceAccount）にだけ結び付ける |
| 監査ログ | audit-policy.yaml で RBAC 関連 API を必ず記録する |
| CI テスト | conftest や kube-score で Role/RoleBinding の過剰権限を検出 |
実装例 – Namespace 別の最小権限ロール
|
1 2 3 4 5 6 7 8 9 10 11 |
# pod-reader-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: production rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# pod-reader-binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-reader-binding namespace: production subjects: - kind: Group name: dev-team # AD / G Suite のグループ名 apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io |
ポイント解説
- Role は
productionNamespace にだけ作用し、Pod の読み取り権限だけを付与。 - Subject に Group を指定することで、個々のユーザー管理が不要になり、チーム単位での権限付与が楽になります。
監査ポリシー例
|
1 2 3 4 5 6 7 8 9 10 |
# audit-policy.yaml（抜粋） apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse verbs: ["create", "update", "patch", "delete"] resources: - group: rbac.authorization.k8s.io resources: ["roles","rolebindings","clusterroles","clusterrolebindings"] |
Tip：このポリシーを
kube-apiserverの起動オプション--audit-policy-file=/etc/kubernetes/audit-policy.yamlに設定すると、RBAC 変更がすべてログに残ります。
ネットワークセキュリティ: NetworkPolicy ＆ Service Mesh の統合
1. デフォルト deny ポリシーの適用（全クラスター共通）
|
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: prod spec: podSelector: {} # 全 Pod に適用 policyTypes: - Ingress - Egress |
2. ラベルベースで許可対象を絞るパターン例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-monitoring namespace: prod spec: podSelector: {} # 全 Pod が対象（必要に応じて変更） ingress: - from: - namespaceSelector: matchLabels: purpose: monitoring # `monitoring` ラベルが付いた Namespace のみ許可 |
3. Service Mesh (Istio) でのゼロトラスト実装（上記参照）
- PeerAuthentication：全通信を mTLS に強制
- AuthorizationPolicy：サービスアカウント単位でアクセス許可
ベストプラクティスまとめ
1.NetworkPolicy→ ネットワークレイヤー の「誰がどこへ行けるか」
2.Istio PeerAuthentication→ トランスポート層 の暗号化と相互認証
3.Istio AuthorizationPolicy→ アプリケーション層 の細粒度アクセス制御
この 3 層を 同時に適用 すると、ネットワークレイヤーで不正な通信はすべて遮断され、残ったトラフィックも暗号化・認証された安全なものだけになります。
シークレット管理・サプライチェーン保護
KMS 統合と Etcd 暗号化（GCP 例）
|
1 2 3 4 5 6 7 8 9 10 |
# 1. キーリングとキーを作成 gcloud kms keyrings create k8s-keyring --location=asia-northeast1 gcloud kms keys create etcd-key --keyring=k8s-keyring \ --purpose=encryption --location=asia-northeast1 # 2. kube-apiserver に暗号化設定を注入（Helm values.yaml） apiServer: extraArgs: encryption-provider-config: /etc/kubernetes/encryptionconfig.yaml |
encryptionconfig.yaml の抜粋は前述の Configuration セクションをご参照ください。
外部シークレットストアと CronJob/Vault の連携例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
apiVersion: batch/v1 kind: CronJob metadata: name: vault-secret-sync spec: schedule: "0 */6 * * *" # 6 時間ごとに実行 jobTemplate: spec: template: spec: containers: - name: sync image: hashicorp/vault:latest env: - name: VAULT_ADDR value: https://vault.example.com command: ["/bin/sh","-c"] args: - | NEW=$(vault kv get -field=password secret/db) kubectl create secret generic db-password \ --from-literal=password=$NEW \ --dry-run=client -o yaml | kubectl apply -f - restartPolicy: OnFailure |
ポイント：Vault の
kvエンジンから取得した最新パスワードを直接 Kubernetes Secret に上書きするだけで、シークレットのローテーションが自動化できます。
サプライチェーン全体の防御フロー
- コードリポジトリ → PR 時点で
kube-scoreとconftestが manifest を検証 - CI ビルド → Trivy で脆弱性スキャン、合格したイメージだけをレジストリへプッシュ
- 署名 → Cosign によりイメージに署名し、デプロイ時に
cosign verifyで検証 - デプロイ → Argo CD / Flux がマニフェストの GitOps デプロイを実行、同時に RBAC/NetworkPolicy の適用も確認
ランタイム監視とポリシーエンジン
| エンジン | 主な役割 | 設定例 |
|---|---|---|
| Falco | カーネルレベルの syscalls で不審行動を検知 | falco_rules.yaml（Privileged Container の検出） |
| OPA Gatekeeper | Admission 時にポリシー違反を阻止 | ConstraintTemplate + Constraint（必須ラベル） |
| Kyverno | YAML ベースで簡単にポリシー記述・自動修正 | ClusterPolicy（リソース上限の強制） |
Falco カスタムルール例
|
1 2 3 4 5 6 7 |
# falco_rules.yaml - rule: Privileged Container Execution desc: Detect execution of privileged containers condition: container.privileged == true output: "Privileged container started (container=%container.id image=%container.image)" priority: WARNING |
OPA Gatekeeper ConstraintTemplate（必須ラベル）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8srequiredlabels spec: crd: spec: names: kind: K8sRequiredLabels targets: - target: admission.k8s.gatekeeper.sh rego: | package k8srequiredlabels violation[{"msg": msg}] { provided := {label | input.review.object.metadata.labels[label]} required := {"team", "env"} missing := required - provided count(missing) > 0 msg := sprintf("Missing required labels: %v", [missing]) } |
Kyverno リソース上限ポリシー
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: enforce-resource-limits spec: rules: - name: require-limits match: resources: kinds: ["Pod"] validate: message: "CPU と Memory のリソース上限が設定されていません" pattern: spec: containers: - resources: limits: cpu: "?*" memory: "?*" |
実装ヒント：Falco は DaemonSet で全ノードに展開し、Kubernetes の
Eventと連携させると Grafana ダッシュボードで可視化できます。Gatekeeper／Kyverno は GitOps リポジトリ内のpolicies/ディレクトリに配置し、CI がプルリクエスト時にconftest testで検証すると一貫性が保たれます。
CI/CD パイプラインに組み込む自動チェックリスト
チェックリストの形態例（SECURITY_CHECKLIST.md）
|
1 2 3 4 5 6 7 8 9 10 11 |
# Kubernetes Security Checklist (2026) - [ ] API Server の安全オプションが有効 (`anonymous-auth=false`, `authorization-mode=RBAC,Node`) - [ ] Etcd が外部 KMS で暗号化されているか - [ ] 全 Namespace にデフォルト deny NetworkPolicy があるか - [ ] Istio mTLS が STRICT モードになっているか - [ ] RBAC が最小権限で定義され、過剰権限の Role/ClusterRole がないか (`kube-score` でチェック) - [ ] コンテナイメージが Trivy スキャンを通過し、Cosign 署名が付与されているか - [ ] Falco のカスタムルールがデプロイ済みか - [ ] Gatekeeper / Kyverno ポリシーが全マニフェストに適用されるか (`conftest` テスト) |
GitHub Actions での「Security Gate」ジョブ例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
name: Security Gate on: pull_request: branches: [main] jobs: kube-score: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Install kube-score run: | curl -sL https://github.com/zegl/kube-score/releases/download/v1.14.0/kube-score_1.14.0_linux_amd64.tar.gz | tar xz sudo mv kube-score /usr/local/bin/ - name: Run kube-score run: kube-score score ./manifests/**/*.yaml conftest: runs-on: ubuntu-latest needs: kube-score steps: - uses: actions/checkout@v3 - name: Install Conftest run: | curl -L https://github.com/open-policy-agent/conftest/releases/download/v0.45.0/conftest_0.45.0_Linux_x86_64.tar.gz | tar xz sudo mv conftest /usr/local/bin/ - name: Run OPA & Kyverno policies run: | conftest test ./manifests/**/*.yaml -p policies/ |
効果：プルリクエストがマージされる前にすべてのセキュリティ基準を自動的に検証し、違反があれば即座にブロックします。
まとめ & 実装チェックリスト
キーポイント（箇条書き）
- 設定は GitOps 化 →
--anonymous-auth=false・RBACを必須化 - 認証情報は外部 KMS による Etcd 暗号化＋CronJob/Vault で自動ローテーション
- イメージは Trivy スキャン + Cosign 署名を CI に組み込み、未署名・脆弱なイメージのデプロイを防止
- 通信は
NetworkPolicyのデフォルト deny → 必要最小許可 + Istio strict‑mtls + AuthorizationPolicy でゼロトラスト実現 - RBACは Role/ClusterRole を最小権限に絞り、監査ログと CI テストを併用
- シークレット管理は KMS 暗号化＋Vault 等外部ストアでの自動ローテーション
- ランタイム監視は Falco（行動検知）＋ OPA Gatekeeper / Kyverno（ポリシー適用）で二層防御
- CI/CD ガードは
kube-score、conftest、チェックリストを組み合わせてプルリクエスト時に自動阻止
実装チェックリスト（最終確認）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
- [ ] API Server の安全オプションが全クラスタで有効化されているか - [ ] Etcd が外部 KMS で暗号化された設定ファイルを適用しているか - [ ] 全 Namespace にデフォルト deny NetworkPolicy が存在するか - [ ] 必要な通信だけを許可する NetworkPolicy がラベルベースで定義されているか - [ ] Istio（または代替 Service Mesh）が strict‑mtls を有効にしているか - [ ] RBAC ロールが最小権限で設計され、過剰権限ロールが残っていないか - [ ] 監査ポリシー (`audit-policy.yaml`) が RBAC 変更を記録するよう設定されているか - [ ] コンテナイメージが Trivy スキャンに合格し、Cosign 署名が付与されているか - [ ] Secrets のローテーションジョブ（CronJob / Vault） が稼働しているか - [ ] Falco カスタムルールがデプロイ済みでアラートが正しく通知されるか - [ ] Gatekeeper／Kyverno ポリシーが CI でテストされ、違反時にプルリクエストがブロックされているか - [ ] `SECURITY_CHECKLIST.md` が最新で、GitHub Actions の Security Gate が参照しているか |
次のステップ：上記チェックリストをプロジェクトのリポジトリに追加し、CI パイプラインへ組み込むだけで「2026 年版 Kubernetes ベストプラクティス」の実装が完了します。継続的なレビューとツールバージョン更新（例：Trivy の CVE データベース）を忘れずに行い、常に最新の脅威情報に対応してください。
本稿は 2026 年時点で公表されている CNCF・CIS・NIST 等の公式ガイドラインや、広く実績が確認できるオープンソースツールをベースに作成しています。特定ベンダーの調査結果（例: CrowdStrike 2026 年調査）については出典不明な情報は除外し、一般的に信頼できる情報源へ置き換えました。
スポンサードリンク