Istioセキュリティ設定の基礎と実装方法

Istioセキュリティ設定の基礎と目的

サービスメッシュ環境におけるセキュリティ対策は、クラウドネイティブなワークロードを守る上で不可欠です。IstioはKubernetes上での通信をmTLS強制することで不正アクセスや情報漏洩リスクを軽減する仕組みを提供していますが、導入時に誤った設定を行うとセキュリティホールになる可能性があります。本記事では、現行版のIstio 1.20に対応した手順を解説し、特にPERMISSIVEモードの推奨を避けることを前提に具体的な構築方法をご案内します。

STRICTモードによるmTLS強制設定

サービス間通信の暗号化は、Istioセキュリティポリシーにおける最優先事項です。PeerAuthenticationリソースを通じてSTRICTモードを有効にすることで、すべての通信がmTLSで行われるようにします。

PeerAuthenticationリソースの作成手順

1. NamespaceごとにPolicyを作成するため、以下のようなYAMLファイルを作成します。
   yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default-peer-authn
namespace: <ターゲット名前空間>
spec:
mtls:
mode: STRICT

2. kubectl apply -fコマンドで適用し、対象のNamespace内での通信がmTLS強制化されます。

3. カスタムCA導入時は、spec.mtls.clientCertificateやspec.mtls.trustDomainを指定して証明書検証アルゴリズムを選定する必要があります。

Namespace単位でのポリシー適用

注意: PERMISSIVEモードはセキュリティ面でリスクが高いため、開発環境でのみ短期間の利用を検討してください。

認可ポリシー構築のベストプラクティス

サービスメッシュにおいて「最小権限設計」を実現するためには、AuthorizationPolicyとSPIFFEアイデンティティの連携が不可欠です。

AuthorizationPolicyでの最小権限設計例

1. 特定のServiceAccountにのみアクセス許可を与える場合、以下のように定義します。
   yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-specific-sa
namespace: default
spec:
rules:

   • from:
   • source:
     principals: ["cluster.local/ns/default/sa/app-sa"]
     to:
   • operation:
paths: ["/api/v1/data"]
action: ALLOW


2. デフォルトでDENYに設定し、必要最小限のアクセスを許可することで、攻撃面を制限します。

SPIFFEアイデンティティとの連携仕組み

SPIFFE（Secure Production Identity Framework For Everyone）は、各ワークロードが持つ信頼されるアイデンティティを管理するための仕組みです。Istioはistiod CAを使用してSPIFFE証明書を自動発行・更新し、以下のような連携を行います。

• 証明書の自動更新: 30日ごとにリフレッシュされるSPIFFE IDが、Envoyプロキシに注入されます
• 信頼性検証: istiodが発行した証明書のみを許容する仕組みで、不正なワークフローを阻止

SPIFFE証明書の自動更新期間（30日）は、セキュリティポリシーに基づく推奨値です。技術的妥当性については、Istio公式ドキュメントと最新のベストプラクティスで再確認してください。

JWT認証フローの構築方法

外部IDプロバイダ（OAuth2やOIDC）との連携によって、JWTトークンでのユーザー認証を実現します。

RequestAuthenticationリソース設定

1. 以下のようにRequestAuthenticationリソースを作成し、JWT検証ルールを定義します。
   yaml
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: jwt-example
namespace: default
spec:
jwtRules:

   • issuer: "https://example.com/auth/realms/myrealm"
jwksUri: "https://example.com/auth/realms/myrealm/.well-known/openid-configuration/jwks"
audiences: ["my-service"]


2. jwksUriに指定された公開鍵を用いて、クライアントが持つJWTトークンの署名検証を行います。

外部IDプロバイダ連携手順

• シークレット管理: JWT公開鍵はKubernetes Secretに保管し、istioctlやkubectlで参照可能な状態とします
• トークン有効期限: 30分以下の短いスコープを設定し、不正利用リスクを抑える

JWTトークンの有効期限（30分）はIstioの仕様に合致していますが、外部IDプロバイダとの連携でさらに制限をかける場合もあります。設定内容を確認してください。

OPAによる高度な認可制御

Istioのデフォルトポリシーではカバーできない複雑なルール（例: タイムベースのアクセス制限）はOPA（Open Policy Agent）と統合することで実現可能です。

外部認可エンジン統合手順

1. IstioとOPAを通信させるためのConfigMapを作成し、opa/decision_logsなどの設定を定義します。
2. OPAのPolicyファイル（.rego形式）を作成し、以下のように記述します。
   rego
package http

allow {
input.attributes.request.auth.claims["sub"] == "admin"
}


1. AuthorizationPolicyでOPAを呼び出すように設定し、動的ルール評価を実現します。

動的ポリシー評価の検証方法

• istioctl checkコマンドで、OPAとIstio間の通信が正常か確認
• KialiやGrafanaなどを利用して、許可・拒否されたリクエストを可視化

導入後のセキュリティ確認と最適化

ポリシーの導入直後は、実際に通信を監査し、リスクポイントを検証する必要があります。

ポリシー適用状況の可視化方法

• istioctl validateコマンドで設定ミスや不整合を即座に特定
• EnvoyのトレースログからmTLS通信が正しく行われているか確認

シミュレーションによるリスク検証

1. 無効なJWTトークン送信テスト: 拒否されることでポリシーの有効性を検証
2. CRI-Oとの互換性チェック:
3. --feature-gates=PodSecurityなどのオプションが設定されていないか確認
4. セキュリティポリシーファイルに不要な権限が含まれていないかレビュー

導入後のセキュリティ確認は、継続的な最適化の基盤となります。定期的な監査とポリシー見直しが推奨されます。

• IstioによるmTLS強制と認可ポリシー構築は、サービスメッシュ環境のセキュリティを確立するための基本です。
• 設定手順に従って導入することで、不正アクセスリスクの削減・最小権限設計の実現が可能になります。

• mTLS強制設定（STRICTモード）
• Namespace単位のポリシー管理
• AuthorizationPolicyとSPIFFEの連携
• JWTトークン検証フロー構築
• OPAによる動的認可ルールの導入
• トレースツールを用いたリスク検証

実際にIstioセキュリティポリシーを適用して、サービスメッシュ環境のリスク面を確認してください。