mcpField
M
mtls-configuration

mtls-configuration

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

mtls-configuration について

サービス間通信やサービスメッシュを保護するチーム向けのmTLS設定ガイドです。証明書のライフサイクル、設定上の境界、トラブルシューティングを扱い、バージョンや信頼チェーン、IDの検証を重視します。

主な機能

  1. 01mTLSのフローと証明書階層
  2. 02IstioとLinkerdの設定テンプレート
  3. 03証明書ローテーションのガイダンス
  4. 04ハンドシェイクとポリシーの問題解決
  5. 05信頼と認可の安全対策

活用シーン

  1. 01サービス間トラフィックの保護
  2. 02証明書ローテーションの計画
  3. 03TLSハンドシェイク障害の調査
  4. 04マルチクラスターの信頼性検証

インストール

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

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill mtls-configuration

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

詳細

mTLS の設定

ゼロトラストのサービスメッシュ通信に相互 TLS を導入するための包括的なガイドです。

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

  • タスクが mTLS の設定に関係しない場合
  • この範囲外の別のドメインやツールが必要な場合

手順

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

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

  • ゼロトラストネットワークを導入するとき
  • サービス間通信を保護するとき
  • 証明書をローテーションおよび管理するとき
  • TLS ハンドシェイクの問題をデバッグするとき
  • コンプライアンス要件(PCI-DSS、HIPAA)に対応するとき
  • 複数クラスター間の安全な通信を実現するとき

基本概念

1. mTLS のフロー
┌─────────┐                              ┌─────────┐
│ Service │                              │ Service │
│    A    │                              │    B    │
└────┬────┘                              └────┬────┘
     │                                        │
┌────┴────┐      TLS Handshake          ┌────┴────┐
│  Proxy  │◄───────────────────────────►│  Proxy  │
│(Sidecar)│  1. ClientHello             │(Sidecar)│
│         │  2. ServerHello + Cert      │         │
│         │  3. Client Cert             │         │
│         │  4. Verify Both Certs       │         │
│         │  5. Encrypted Channel       │         │
└─────────┘                              └─────────┘
2. 証明書の階層
Root CA (Self-signed, long-lived)
    │
    ├── Intermediate CA (Cluster-level)
    │       │
    │       ├── Workload Cert (Service A)
    │       └── Workload Cert (Service B)
    │
    └── Intermediate CA (Multi-cluster)
            │
            └── Cross-cluster certs

設定の境界

以下の断片はバージョン固有であり、メッシュ/PKI のデプロイ全体を網羅するものではありません。まず、インストール済みの CRD とプロキシ/アンビエントモードを確認してください。cert-manager の Certificate/Issuer リソースだけでは Istio の署名機能と連携しません。サポートされている、レビュー済みの統合を使用してください。Linkerd の Server はインバウンドポリシーを制御するものであり、アウトバウンドの外部 TLS は制御しません。サポートされているアウトバウンドのスキップ用アノテーションは、Service ではなくワークロードの Pod テンプレートに設定してください。メトリクス/ポートの除外は保護を弱めるため、レビュー済みのネットワーク/認証ポリシーが必要です。mTLS はピアを認証しますが、認可には引き続き許可された ID が必要です。CA キーはバージョン管理システムの外部で保護し、信頼のローテーションとロールバックに備えて信頼期間の重複を計画してください。また、strict モードを強制する前に、許可される ID と拒否される ID の両方を検証してください。

テンプレート

テンプレート 1:Istio mTLS(Strict モード)
# Enable strict mTLS mesh-wide
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
---
# Namespace-level override (permissive for migration)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: legacy-namespace
spec:
  mtls:
    mode: PERMISSIVE
---
# Workload-specific policy
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: payment-service
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  mtls:
    mode: STRICT
  portLevelMtls:
    8080:
      mode: STRICT
    9090:
      mode: DISABLE  # Metrics port, no mTLS
テンプレート 2:Istio の mTLS 用 Destination Rule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: default
  namespace: istio-system
spec:
  host: "*.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
---
# TLS to external service
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: external-api
spec:
  host: api.external.com
  trafficPolicy:
    tls:
      mode: SIMPLE
      caCertificates: /etc/certs/external-ca.pem
---
# Mutual TLS to external service
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: partner-api
spec:
  host: api.partner.com
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/client.pem
      privateKey: /etc/certs/client-key.pem
      caCertificates: /etc/certs/partner-ca.pem
テンプレート 3:cert-manager と Istio
# Install cert-manager issuer for Istio
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: istio-ca
spec:
  ca:
    secretName: istio-ca-secret
---
# Create Istio CA secret
apiVersion: v1
kind: Secret
metadata:
  name: istio-ca-secret
  namespace: cert-manager
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-ca-cert>
  tls.key: <base64-encoded-ca-key>
---
# Certificate for workload
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-service-cert
  namespace: my-namespace
spec:
  secretName: my-service-tls
  duration: 24h
  renewBefore: 8h
  issuerRef:
    name: istio-ca
    kind: ClusterIssuer
  commonName: my-service.my-namespace.svc.cluster.local
  dnsNames:
    - my-service
    - my-service.my-namespace
    - my-service.my-namespace.svc
    - my-service.my-namespace.svc.cluster.local
  usages:
    - server auth
    - client auth
テンプレート 4:SPIFFE/SPIRE の統合
# SPIRE Server configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: spire-server
  namespace: spire
data:
  server.conf: |
    server {
      bind_address = "0.0.0.0"
      bind_port = "8081"
      trust_domain = "example.org"
      data_dir = "/run/spire/data"
      log_level = "INFO"
      ca_ttl = "168h"
      default_x509_svid_ttl = "1h"
    }

    plugins {
      DataStore "sql" {
        plugin_data {
          database_type = "sqlite3"
          connection_string = "/run/spire/data/datastore.sqlite3"
        }
      }

      NodeAttestor "k8s_psat" {
        plugin_data {
          clusters = {
            "demo-cluster" = {
              service_account_allow_list = ["spire:spire-agent"]
            }
          }
        }
      }

      KeyManager "memory" {
        plugin_data {}
      }

      UpstreamAuthority "disk" {
        plugin_data {
          key_file_path = "/run/spire/secrets/bootstrap.key"
          cert_file_path = "/run/spire/secrets/bootstrap.crt"
        }
      }
    }
---
# SPIRE Agent DaemonSet (abbreviated)
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: spire-agent
  namespace: spire
spec:
  selector:
    matchLabels:
      app: spire-agent
  template:
    metadata:
      labels:
        app: spire-agent
    spec:
      containers:
        - name: spire-agent
          image: ghcr.io/spiffe/spire-agent:1.8.0
          volumeMounts:
            - name: spire-agent-socket
              mountPath: /run/spire/sockets
      volumes:
        - name: spire-agent-socket
          hostPath:
            path: /run/spire/sockets
            type: DirectoryOrCreate
テンプレート 5:Linkerd mTLS(自動)
# Linkerd enables mTLS automatically
# Verify with:
# linkerd viz edges deployment -n my-namespace

# For external services without mTLS
apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
  name: external-api
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      app: my-app
  port: external-api
  proxyProtocol: HTTP/1  # or TLS for passthrough
---
# Skip TLS for specific port
apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    config.linkerd.io/skip-outbound-ports: "3306"  # MySQL

証明書のローテーション

# Istio - Check certificate expiry
istioctl proxy-config secret deploy/my-app -o json | \
  jq '.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes' | \
  tr -d '"' | base64 -d | openssl x509 -text -noout # security-allowlist: local certificate inspection

# An authorized restart may obtain a new workload certificate, but is not
# a general CA/certificate rotation procedure and disrupts workloads.
kubectl rollout restart deployment/my-app

# Check Linkerd identity
linkerd identity -n my-namespace

mTLS の問題のデバッグ

# Istio - Check if mTLS is enabled
istioctl authn tls-check my-service.my-namespace.svc.cluster.local

# Verify peer authentication
kubectl get peerauthentication --all-namespaces

# Check destination rules
kubectl get destinationrule --all-namespaces

# Debug TLS handshake
istioctl proxy-config log deploy/my-app --level debug
kubectl logs deploy/my-app -c istio-proxy | grep -i tls

# Linkerd - Check mTLS status
linkerd viz edges deployment -n my-namespace
linkerd viz tap deploy/my-app --to deploy/my-backend

ベストプラクティス

推奨事項
  • PERMISSIVE から始める — 段階的に STRICT へ移行します
  • 証明書の有効期限を監視する — アラートを設定します
  • 有効期間の短い証明書を使う — ワークロード用には 24 時間以内にします
  • CA を定期的にローテーションする — CA のローテーションを計画します
  • TLS エラーを記録する — デバッグと監査に役立てます
禁止事項
  • mTLS を無効にしない — 本番環境で利便性を優先して無効にしないでください
  • 証明書の有効期限を無視しない — ローテーションを自動化します
  • 任意の自己署名リーフ証明書を信頼しない — 管理されたルート CA 自体は自己署名でもかまいません。意図した信頼チェーンとワークロード ID を検証してください
  • 検証を省略しない — チェーン全体を検証してください

リソース

制限事項

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

コメント