Istioセキュリティモデル分析：mTLS、認証、認可

istiod CA
├── Root Certificate（自己署名または外部CAから発行）
├── Intermediate CA Certificate（オプション）
└── Workload Certificates（各ワークロードに発行）
    ├── frontend → spiffe://cluster.local/ns/prod/sa/frontend
    ├── reviews → spiffe://cluster.local/ns/prod/sa/reviews
    └── ratings → spiffe://cluster.local/ns/prod/sa/ratings

[1] Pod起動 → istio-agent初期化
        │
[2] istio-agentがRSA 2048またはECDSA P-256鍵ペアを生成
        │
[3] SPIFFE IDを含むCSRを作成
    (spiffe://cluster.local/ns/NAMESPACE/sa/SA_NAME)
        │
[4] Kubernetes ServiceAccountトークンと共にCSRをistiodに送信
        │
[5] istiod検証：
    ├── ServiceAccountトークンの妥当性（TokenReview API）
    ├── トークンのネームスペース/SAがCSRのSPIFFE IDと一致するか
    └── CSR形式の妥当性
        │
[6] istiod CAがX.509証明書に署名
    ├── Subject: SPIFFE ID
    ├── SAN（Subject Alternative Name）：SPIFFE URI
    ├── 有効期間：24時間（デフォルト）
    └── Key Usage: Digital Signature, Key Encipherment
        │
[7] 署名済み証明書 + CAチェーンをistio-agentに返却
        │
[8] istio-agentがSDSを通じてEnvoyに証明書を配信
        │
[9] 期限前に自動更新（有効期間の約50%時点）

外部CA連携方式：
├── 1. Plug-in CA：istiodに外部CAの中間証明書をマウント
│   └── istiodが中間CAとしてワークロード証明書に署名
│
├── 2. CSR API：Kubernetes CertificateSigningRequest APIを使用
│   └── 外部署名者がKubernetes CSRを承認/署名
│
└── 3. Custom CA（istio-csr）：cert-manager + Istio CSR Agent
    └── cert-managerが外部CA（Vault、AWS ACMなど）から証明書を発行

Client Pod (frontend)              Server Pod (reviews)
[App] → [Envoy Proxy]     ←→     [Envoy Proxy] → [App]

1. Appがreviews:9080にリクエスト
   （平文HTTP、localhost内部）
        │
2. iptablesがトラフィックをEnvoy（15001）にリダイレクト
        │
3. Envoyが宛先クラスターのTLS設定を確認
   （DestinationRuleまたはauto mTLS）
        │
4. TLSハンドシェイク開始：
   ├── ClientHello（対応TLSバージョン、暗号スイート）
   ├── ServerHello + Server Certificate
   │   └── reviewsのSPIFFE証明書を提示
   ├── Client Certificate
   │   └── frontendのSPIFFE証明書を提示
   ├── Certificate Verification（双方向）
   │   ├── CAチェーン検証
   │   ├── SPIFFE ID検証
   │   └── 証明書期限確認
   └── Finished（セッションキー交換完了）
        │
5. 暗号化されたチャネルでHTTPリクエスト送信
        │
6. Server EnvoyがTLS終端
        │
7. 平文でAppに転送（localhost）

宛先にサイドカーがあるか？
    │
    ├── Yes → 自動的にmTLSを使用
    │   （DestinationRuleにTLS設定がなくても）
    │
    └── No → 平文を使用
        （サイドカーのないサービスにmTLSを強制すると失敗）

優先順位（高い順）：
1. Workloadレベル（selector指定）
2. Namespaceレベル（selector未指定、特定ネームスペース）
3. Meshレベル（istio-systemネームスペース、selector未指定）

{
  "filter_chains": [
    {
      "filter_chain_match": {},
      "transport_socket": {
        "name": "envoy.transport_sockets.tls",
        "typed_config": {
          "require_client_certificate": true,
          "common_tls_context": {
            "validation_context": {
              "trusted_ca": "CA証明書"
            }
          }
        }
      }
    }
  ]
}

{
  "filter_chains": [
    {
      "filter_chain_match": {
        "transport_protocol": "tls"
      },
      "transport_socket": {
        "name": "envoy.transport_sockets.tls",
        "typed_config": {
          "require_client_certificate": true
        }
      }
    },
    {
      "filter_chain_match": {},
      "transport_socket": {
        "name": "envoy.transport_sockets.raw_buffer"
      }
    }
  ]
}

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: reviews-mtls
  namespace: production
spec:
  selector:
    matchLabels:
      app: reviews
  mtls:
    mode: STRICT
  portLevelMtls:
    8080:
      mode: STRICT
    15021:
      mode: DISABLE # ヘルスチェックポートはmTLS無効化

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-auth
spec:
  selector:
    matchLabels:
      app: reviews
  jwtRules:
    - issuer: 'https://auth.example.com'
      jwksUri: 'https://auth.example.com/.well-known/jwks.json'
      forwardOriginalToken: true
      outputPayloadToHeader: 'x-jwt-payload'

リクエスト到着 (Authorization: Bearer TOKEN)
    │
    ▼
JWT Authn Filter (envoy.filters.http.jwt_authn)
    │
    ├── JWTトークン抽出（Authorizationヘッダー）
    │
    ├── JWKSキャッシュ確認
    │   ├── キャッシュヒット → 公開鍵で署名検証
    │   └── キャッシュミス → jwksUriからキーをダウンロード
    │
    ├── トークン検証：
    │   ├── 署名の妥当性
    │   ├── issuer（iss）一致確認
    │   ├── 期限（exp）確認
    │   └── audience（aud）確認（設定されている場合）
    │
    ├── 検証成功：
    │   ├── ペイロードをフィルターメタデータに保存
    │   ├── forwardOriginalToken: true → 元のトークンを維持
    │   └── outputPayloadToHeader → ペイロードを指定ヘッダーに追加
    │
    └── 検証失敗：
        ├── 無効なJWT → 401 Unauthorized
        └── JWTなし → リクエスト通過（認証されていない状態で）

# JWTなしのリクエストも拒否するパターン
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
spec:
  selector:
    matchLabels:
      app: reviews
  action: DENY
  rules:
    - from:
        - source:
            notRequestPrincipals: ['*']

リクエスト到着
    │
    ▼
[1] CUSTOMポリシー評価
    ├── マッチして拒否 → 403 Forbidden
    ├── マッチして許可 → [2]へ進行
    └── マッチしない → [2]へ進行
    │
    ▼
[2] DENYポリシー評価
    ├── マッチ → 403 Forbidden
    └── マッチしない → [3]へ進行
    │
    ▼
[3] ALLOWポリシーの存在確認
    ├── ALLOWポリシーなし → 許可（デフォルト許可）
    └── ALLOWポリシーあり：
        ├── マッチ → 許可
        └── マッチしない → 403 Forbidden

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ['cluster.local/ns/production/sa/frontend']
      to:
        - operation:
            methods: ['GET']
            paths: ['/api/*']

{
  "name": "envoy.filters.http.rbac",
  "typed_config": {
    "rules": {
      "action": "ALLOW",
      "policies": {
        "allow-frontend": {
          "permissions": [
            {
              "and_rules": {
                "rules": [
                  {
                    "header": {
                      "name": ":method",
                      "string_match": {
                        "exact": "GET"
                      }
                    }
                  },
                  {
                    "url_path": {
                      "path": {
                        "prefix": "/api/"
                      }
                    }
                  }
                ]
              }
            }
          ],
          "principals": [
            {
              "authenticated": {
                "principal_name": {
                  "exact": "spiffe://cluster.local/ns/production/sa/frontend"
                }
              }
            }
          ]
        }
      }
    }
  }
}

Trust Domain：証明書を発行するCAの信頼範囲

cluster-1: trust domain = "cluster-1.example.com"
  └── spiffe://cluster-1.example.com/ns/prod/sa/frontend

cluster-2: trust domain = "cluster-2.example.com"
  └── spiffe://cluster-2.example.com/ns/prod/sa/frontend

# MeshConfigでtrust domainエイリアスを設定
meshConfig:
  trustDomain: 'new-domain.example.com'
  trustDomainAliases:
    - 'old-domain.example.com'

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: ext-authz
  namespace: production
spec:
  selector:
    matchLabels:
      app: reviews
  action: CUSTOM
  provider:
    name: 'opa-ext-authz'
  rules:
    - to:
        - operation:
            paths: ['/api/*']

meshConfig:
  extensionProviders:
    - name: 'opa-ext-authz'
      envoyExtAuthzGrpc:
        service: 'opa.opa-system.svc.cluster.local'
        port: 9191
        timeout: 5s
        failOpen: false

リクエスト到着
    │
    ▼
Envoy ext_authzフィルター
    │
    ├── gRPCでOPAサービスに認可リクエストを送信
    │   ├── リクエストヘッダー
    │   ├── パス、メソッド
    │   ├── ソースprincipal（SPIFFE ID）
    │   └── カスタム属性
    │
    ├── OPAレスポンス：
    │   ├── ALLOW → リクエスト処理を継続
    │   ├── DENY → 403を返却
    │   └── タイムアウト：
    │       ├── failOpen: true → リクエストを許可
    │       └── failOpen: false → リクエストを拒否
    │
    └── OPAがレスポンスに追加ヘッダーを含めることが可能
        （例：認可コンテキスト情報）

# フェーズ1：メッシュ全体PERMISSIVE
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: PERMISSIVE

# フェーズ2：ネームスペース別STRICT移行
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

# フェーズ3：メッシュ全体STRICT
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

# すべてのリクエストをデフォルト拒否し、明示的に許可
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec: {} # 空のspec = ALLOWアクション、空のrules = すべてのリクエスト拒否

# 同じネームスペース内部のトラフィックのみ許可
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-same-namespace
  namespace: production
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            namespaces: ['production']

# mTLS状態確認
istioctl authn tls-check PODNAME.NAMESPACE

# AuthorizationPolicy適用状態
istioctl x authz check PODNAME.NAMESPACE

# 証明書情報確認
istioctl proxy-config secret PODNAME.NAMESPACE -o json

# Envoy RBACデバッグログ有効化
kubectl exec PODNAME -c istio-proxy -- \
  curl -X POST "localhost:15000/logging?rbac=debug"

# RBAC拒否統計確認
kubectl exec PODNAME -c istio-proxy -- \
  curl -s localhost:15000/stats | grep rbac