Istioセキュリティ実践 — mTLS、AuthorizationPolicy、そしてゼロトラストメッシュ

spiffe://cluster.local/ns/payments/sa/payments-api
         -------------    --------    ------------
         トラストドメイン    ネームスペース  サービスアカウント

+----------------------------------------------------------------------+
|  コントロールプレーン                                                   |
|  +----------------------------------------------------------------+  |
|  | istiod (内蔵CA)                                                 |  |
|  |  - ルート/中間CAキーを保管 (istio-ca-secretまたはcacerts)          |  |
|  |  - CSRに署名し、SPIFFE IDをSANに記録                             |  |
|  +----------------------------------------------------------------+  |
|        ^                                        |                    |
|        | 3. CSR提出                              | 4. 署名済み証明書    |
|        |    (サービスアカウントトークンで認証)        |    (デフォルト24時間)|
+--------|----------------------------------------|--------------------+
         |                                        v
+--------|----------------------------------------------------------+
|  ワークロードPod                                                    |
|  +--------------------------+    +------------------------------+ |
|  | istio-agent (pilot-agent) |<-->| Envoyサイドカー               | |
|  |  1. キーペア生成           | SDS |  - 発行された証明書で          | |
|  |  2. CSR作成               |    |    mTLSハンドシェイク         | |
|  |  5. SDSでEnvoyへ配布       |    |  - 相手証明書のSPIFFE IDを検証 | |
|  |  6. 期限前に自動再発行       |    +------------------------------+ |
|  +--------------------------+                                      |
+--------------------------------------------------------------------+

# 1) メッシュ全域のデフォルト — istio-system(ルートネームスペース)に置く
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
---
# 2) ネームスペース単位 — 該当ネームスペースのすべてのワークロードに適用
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: STRICT
---
# 3) ワークロード単位 — selectorで特定ワークロードのみ、ポート別の例外も可能
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: legacy-metrics-exception
  namespace: payments
spec:
  selector:
    matchLabels:
      app: legacy-batch
  mtls:
    mode: STRICT
  portLevelMtls:
    9090:                    # メッシュ外のPrometheusがスクレイプするポートだけ平文許可
      mode: PERMISSIVE

ステップ0: 現状観察 (PERMISSIVE維持)
  - Grafana/Kialiで平文トラフィックの割合を確認
  - メトリクス: istio_requests_totalの
    connection_security_policyラベル (mutual_tls / none)
  - noneが出る送信元を全数調査
    → サイドカー未注入のPodか、メッシュ外クライアントか

ステップ1: 平文の送信元を除去
  - サイドカー未注入のネームスペースに注入ラベルを追加
  - メッシュ外クライアントはメッシュへ編入するか、
    ingress gateway経由に変更

ステップ2: 非中核ネームスペースからSTRICT適用
  - dev → staging → 本番非中核 → 本番中核の順
  - ネームスペースごとにPeerAuthentication一つで明示的に適用
  - 適用後、5xx/接続エラーのダッシュボードを一定期間観察

ステップ3: メッシュ全域のデフォルトをSTRICTへ
  - istio-systemのdefault PeerAuthenticationをSTRICTに
  - 残る例外はportLevelMtlsまたはワークロード単位で狭く明示

ステップ4: 例外リストを定期的に再審査
  - DISABLE/PERMISSIVEの例外は有効期限を定めて管理

# 特定ワークロードのmTLS適用状態とポリシーの出どころを確認
istioctl x describe pod payments-api-6c9f7d-abcde -n payments

# ネームスペースの認証ポリシーの衝突/漏れを点検
istioctl analyze -n payments

# Prometheusで平文リクエストを追跡 (noneが0にならないとSTRICT不可)
# istio_requests_total{connection_security_policy="none"}

AuthorizationPolicyの評価順序 (リクエスト1件ごと):

1. CUSTOMポリシー評価 → 外部認可器が拒否したら即拒否
2. DENYポリシー評価   → 一つでもマッチしたら即拒否
3. ALLOWポリシー評価
   - 対象ワークロードにALLOWポリシーが一つもなければ → 許可 (デフォルト開放)
   - ALLOWポリシーが一つでもあれば → マッチするものがあって初めて許可、
     なければ拒否 (デフォルト拒否へ転換)

# 空のspecのALLOWポリシー = 何も許可しない = ネームスペースのデフォルト拒否
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: payments
spec: {}

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payments-api-allow
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments-api
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/commerce/sa/orders-api   # SPIFFE IDベース
      to:
        - operation:
            methods: ["POST"]
            paths: ["/v1/charges", "/v1/refunds"]
    - from:
        - source:
            principals:
              - cluster.local/ns/observability/sa/prometheus
      to:
        - operation:
            methods: ["GET"]
            paths: ["/metrics"]

# 管理用パスはどの送信元からでもメッシュ内部呼び出しを禁止
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-admin-paths
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments-api
  action: DENY
  rules:
    - to:
        - operation:
            paths: ["/admin/*", "/internal/*"]
---
# 特定ネームスペース全体から来るトラフィックを遮断 (例: サンドボックス隔離)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-from-sandbox
  namespace: payments
spec:
  action: DENY
  rules:
    - from:
        - source:
            namespaces: ["sandbox"]

# ingress gatewayを経由して入った外部トラフィックのみ許可し、
# 特定ヘッダーのあるリクエストだけ通す例
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: frontend-via-gateway-only
  namespace: commerce
spec:
  selector:
    matchLabels:
      app: storefront
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/istio-ingress/sa/ingress-gateway
      when:
        - key: request.headers[x-api-version]
          values: ["v1", "v2"]

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-auth
  namespace: commerce
spec:
  selector:
    matchLabels:
      app: storefront-api
  jwtRules:
    - issuer: "https://idp.example.com/"          # issクレームと一致する必要あり
      audiences:
        - "storefront-api"                         # audクレームを検証
      jwksUri: "https://idp.example.com/.well-known/jwks.json"
      forwardOriginalToken: true                   # バックエンドへトークンを転送

# 有効なJWT principalのあるリクエストのみ許可 → トークンがなければ拒否
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: commerce
spec:
  selector:
    matchLabels:
      app: storefront-api
  action: ALLOW
  rules:
    - from:
        - source:
            requestPrincipals: ["https://idp.example.com//*"]  # iss/sub形式
---
# クレームベースの細分化: 管理者スコープがあって初めて書き込み許可
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: write-requires-admin-scope
  namespace: commerce
spec:
  selector:
    matchLabels:
      app: storefront-api
  action: ALLOW
  rules:
    - to:
        - operation:
            methods: ["GET"]
    - to:
        - operation:
            methods: ["POST", "PUT", "DELETE"]
      when:
        - key: request.auth.claims[scope]
          values: ["storefront:admin"]

# MeshConfig (IstioOperatorまたはistio ConfigMap)
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    extensionProviders:
      - name: opa-ext-authz
        envoyExtAuthzGrpc:
          service: opa.authz-system.svc.cluster.local
          port: 9191
          timeout: 0.5s          # 認可器の遅延が全体遅延に直結 — 短く

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: opa-authz
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments-api
  action: CUSTOM
  provider:
    name: opa-ext-authz
  rules:
    - to:
        - operation:
            paths: ["/v1/charges"]    # コストの高い外部認可は必要なパスのみ

# Regoポリシー例 (envoy.authzパッケージ)
package envoy.authz

default allow := false

# 注文サービスが呼び出し、かつJWTのtierクレームがpremiumなら許可
allow if {
    input.attributes.source.principal ==
        "spiffe://cluster.local/ns/commerce/sa/orders-api"
    claims := input.attributes.metadata_context.filter_metadata["envoy.filters.http.jwt_authn"].fields
    claims["tier"] == "premium"
}

# 社内PKIから受け取った中間CAでcacertsシークレットを構成
kubectl create secret generic cacerts -n istio-system \
  --from-file=ca-cert.pem \
  --from-file=ca-key.pem \
  --from-file=root-cert.pem \
  --from-file=cert-chain.pem
# istiod再起動後、新規ワークロード証明書はこのチェーンで発行される

# cert-manager Issuerの例: Vault PKIバックエンドへ署名を委譲
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: vault-istio-ca
spec:
  vault:
    server: https://vault.corp.example:8200
    path: pki_int_mesh/sign/istio-workload
    auth:
      kubernetes:
        role: istio-csr
        mountPath: /v1/auth/kubernetes
        secretRef:
          name: istio-csr-vault-token
          key: token

istio-csr構成時の発行フロー:

ワークロード istio-agent
   → CSR → istiod
            → istio-csr (gRPC CAサーバーとして登録)
               → cert-manager CertificateRequest
                  → ClusterIssuer (Vault / Private CA / 社内PKI)
                     → 署名済み証明書が逆順で伝達される

効果:
- メッシュCAキーがクラスタの外(HSM/Vault)に保管される
- 発行履歴がcert-managerリソースとして残り監査可能
- 発行者の交換がIssuerの交換に単純化される

# ワークロード証明書のチェーンと期限を確認
istioctl proxy-config secret deploy/payments-api -n payments -o json

# istiod CA証明書の期限を監視 (Prometheus)
# メトリクス: citadel_server_root_cert_expiry_timestamp
# 期限30日前のアラートルールを必ず仕掛けておくこと

# 1) RBACデバッグログを有効化 (対象Pod)
istioctl proxy-config log deploy/payments-api -n payments \
  --level rbac:debug

# 2) サイドカーログで拒否理由を確認
kubectl logs deploy/payments-api -n payments -c istio-proxy --tail=100
# "RBAC: access denied" とともにマッチに失敗したprincipal/パスが出力される

# 3) ワークロードに適用中の認可ポリシーを一覧
istioctl x describe pod payments-api-6c9f7d-abcde -n payments

# 4) ポリシーの整合性を一括点検
istioctl analyze -n payments

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all-dryrun
  namespace: payments
  annotations:
    istio.io/dry-run: "true"     # 評価のみ行い、実際にはブロックしない
spec: {}

推奨ポリシーデプロイ手順:

1. dry-runでポリシーをデプロイ
2. 一定期間shadow deniedのログ/メトリクスを収集
   (istio_requests_totalおよびアクセスログのdry-run結果を確認)
3. 拒否リストが意図と一致するかレビュー
   → 意図しない拒否があればrulesを補完
4. dry-runアノテーションを除去 (ポリシー有効化)
5. 有効化直後は403率のダッシュボードを集中観察

+------------------------------------------------------------------+
| フェーズ1. 観察 (1~2週間)                                           |
|  - サイドカー注入完了、PERMISSIVEデフォルトを維持                     |
|  - Kiali/Grafanaでサービス呼び出しグラフと平文比率を把握               |
|  - 成果物: サービス間呼び出しマトリクス (認可ポリシーの設計入力)         |
+------------------------------------------------------------------+
| フェーズ2. mTLS STRICT移行 (ネームスペース単位、2~4週間)              |
|  - 平文送信元の除去 → devから段階適用 → 全域STRICT                   |
|  - 例外はportLevelMtlsで狭く、有効期限を管理                         |
+------------------------------------------------------------------+
| フェーズ3. 認可ポリシー (中核サービスから)                             |
|  - 呼び出しマトリクスに基づくALLOWポリシー作成 → dry-run検証          |
|    → 有効化                                                       |
|  - ネームスペースのデフォルト拒否は十分なdry-runの後に                 |
|  - 管理パスのDENY、gateway経由の強制などセーフティネットを追加         |
+------------------------------------------------------------------+
| フェーズ4. 高度化                                                   |
|  - RequestAuthenticationでJWT検証を入口に                          |
|  - データ依存の判断はOPA ext-authzで狭く                            |
|  - カスタムCA/社内PKI統合、CA期限監視の体系化                        |
+------------------------------------------------------------------+