Istioで実現するZero TrustとmTLS設定ガイド

2026年6月18日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 Istio のサービスメッシュ概念とセキュリティ層の位置付け
- 1.1 データプレーンの概要
- 1.2 コントロールプレーンの概要
2 PeerAuthentication による mTLS の設定方法と通信暗号化の流れ
- 2.1 グローバル・ネームスペース単位での PeerAuthentication 設定手順
- 2.2 mTLS ハンドシェイクとデータ暗号化の実装フロー
3 RequestAuthentication と JWT 検証による外部 IdP 連携（Keycloak 例）
- 3.1 Keycloak 側のクライアント・レルム設定概要
- 3.2 Istio の RequestAuthentication リソースで JWT 公開鍵を指定する方法
4 AuthorizationPolicy の基本構文とマイクロサービス単位でのアクセス制御例
- 4.1 ポリシーのスコープ（ネームスペース・サービス単位）
- 4.2 allow/deny ルールの実装サンプル
5 NIST SP 800‑204 に基づくゼロトラストモデルと Istio の役割
- 5.1 ZTA と Istio 機能の対応表
6 実装手順・デバッグ方法と次のアクション

スポンサードリンク

Istio のサービスメッシュ概念とセキュリティ層の位置付け

Istio は、マイクロサービス同士の通信を データプレーン と コントロールプレーン に分離して管理することで、アプリケーションコードに手を加えることなく高度な認証・認可機能を提供します。このセクションでは、各プレーンが担う役割と、サービスメッシュ全体で実現できる統一的なセキュリティ基盤について解説します。

データプレーンの概要

データプレーンは各 Pod にサイドカーとして注入される Envoy が中心です。Envoy はトラフィックをプロキシし、暗号化・レートリミット・ヘッダー操作などの処理をリアルタイムで実行します。

暗号化：相互 TLS（mTLS）により通信路を保護
レートリミット：サービス単位でリクエスト数を制御
アクセスログ：標準出力へ詳細なトラフィック情報を出力

コントロールプレーンの概要

コントロールプレーンは istiod が中心となり、サービスディスカバリやポリシー配布、証明書管理などを一元的に行います。

サービスディスカバリ：Kubernetes の Service と Endpoint を自動取得
ポリシー配信：PeerAuthentication・RequestAuthentication・AuthorizationPolicy などの CRD を Envoy にプッシュ
証明書管理：SPIFFE ID に基づく短期証明書を自動発行

結論：Istio の認証機能はコントロールプレーンで定義され、データプレーンの Envoy が実際にトラフィックを保護するため、開発者はコード変更なしでゼロトラストを適用できます。

PeerAuthentication による mTLS の設定方法と通信暗号化の流れ

この章では、クラスター全体に対して mTLS を有効化する手順と、実際にハンドシェイクがどのように行われてデータが暗号化されるかを具体的に示します。まずは設定対象のスコープについて理解し、その後ハンドシェイクの内部フローを確認しましょう。

グローバル・ネームスペース単位での PeerAuthentication 設定手順

以下の手順では、クラスター全体（istio-system 名前空間）に対して STRICT モードの mTLS を適用します。設定を反映させるだけで、同一クラスタ内のすべてのサイドカーが相互認証を必須とし、暗号化されていない接続は自動的に切断されます。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system   # グローバル設定はこの名前空間に置く
spec:
  mtls:
    mode: STRICT

apiVersion: security.istio.io/v1beta1

kind: PeerAuthentication

metadata:

namespace: istio-system # グローバル設定はこの名前空間に置く

spec:

mtls:

mode: STRICT

ポイント：STRICT に変更した瞬間、全サイドカーが mTLS ハンドシェイクを要求し、失敗した接続は 403 Forbidden 相当でリジェクトされます。
留意点：既存の非 TLS 通信がある場合は、先に対象サービスを段階的に移行するか、一時的に PERMISSIVE に設定して安全確認を行うことが推奨されます。

mTLS ハンドシェイクとデータ暗号化の実装フロー

mTLS の内部動作は「相互認証」＋「通信路暗号化」の二段階で構成されています。ここでは、Envoy が istiod から取得した証明書を用いてどのようにハンドシェイクと鍵交換が行われるかを時系列で示します。

証明書取得
istiod は各 Envoy に対して SPIFFE ID を含む短期証明書（有効期限は数時間）を自動配布します。
ハンドシェイク開始
クライアント側 Envoy がサーバー側 Envoy の証明書を受信し、tls_context に基づいて検証を行います。
相互認証完了
証明書が有効かつ信頼できる場合に限り、TLS 1.3 の ECDHE アルゴリズムで共通鍵（セッションキー）を生成します。
データ暗号化
以降の HTTP/2 フレームは AES‑GCM などの対称鍵暗号で保護され、ネットワーク上に平文が流れることはありません。
ポイント：STRICT モードでは証明書検証に失敗した接続を即座にリジェクトするため、設定ミスや証明書の期限切れが早期に検知できます。

RequestAuthentication と JWT 検証による外部 IdP 連携（Keycloak 例）

このセクションでは、外部認可サーバーとして Keycloak を利用し、Istio が JWT の署名を検証するまでの手順を示します。まずは Keycloak 側で必要なレルムとクライアントを作成し、次に Istio 側で RequestAuthentication リソースを設定します。

Keycloak 側のクライアント・レルム設定概要

Keycloak において「レルム」と「クライアント」を正しく構築すれば、Istio が JWT の署名と有効期限を検証できるようになります。以下は最小構成の要点です。

レルム作成
例: microservice-realm（テナント単位で分離）
クライアント登録
タイプ: confidential
アクセストークン署名アルゴリズム: RS256（デフォルト推奨）
公開鍵取得
レルム設定 → Keys タブ → Public Key (PEM) をコピー、または JWKS エンドポイントを利用
ポイント：JWKS エンドポイント（例: https://keycloak.example.com/realms/microservice-realm/protocol/openid-connect/certs）を指定すれば、鍵ローテーションが自動的に反映されます。

Istio の RequestAuthentication リソースで JWT 公開鍵を指定する方法

Istio 側では RequestAuthentication に JWKS URI を設定し、Envoy が受信したリクエストヘッダーのトークンを自動的に検証します。以下は frontend 名前空間のフロントエンドアプリケーション向け設定例です。

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: keycloak-jwt
  namespace: frontend
spec:
  selector:
    matchLabels:
      app: my-frontend
  jwtRules:
  - issuer: &quot;https://keycloak.example.com/realms/microservice-realm&quot;
    jwksUri: &quot;https://keycloak.example.com/realms/microservice-realm/protocol/openid-connect/certs&quot;
    forwardOriginalToken: true   # 必要に応じてバックエンドへトークン転送

apiVersion: security.istio.io/v1beta1

kind: RequestAuthentication

metadata:

namespace: frontend

spec:

selector:

matchLabels:

app: my-frontend

jwtRules:

- issuer: "https://keycloak.example.com/realms/microservice-realm"

jwksUri: "https://keycloak.example.com/realms/microservice-realm/protocol/openid-connect/certs"

forwardOriginalToken: true # 必要に応じてバックエンドへトークン転送

ポイント：RequestAuthentication が有効になると、同一名前空間内の AuthorizationPolicy と組み合わせて RBAC を実装でき、認証済みユーザーだけが特定 API にアクセス可能となります。

AuthorizationPolicy の基本構文とマイクロサービス単位でのアクセス制御例

ここでは、Istio が提供する AuthorizationPolicy の書き方と、実際にマイクロサービスごとに細かいアクセス権限を設定する方法を紹介します。まずはポリシー適用範囲（スコープ）の決め方を説明し、その後 allow/deny ルールの具体例を示します。

ポリシーのスコープ（ネームスペース・サービス単位）

AuthorizationPolicy は ネームスペースレベル と Pod ラベルベース（サービス単位） のいずれかで適用できます。スコープを意図的に絞ることで、最小特権の原則を実装しやすくなります。

ネームスペース全体：namespace: orders に対してポリシーを設定すると、その名前空間内のすべてのサービスが対象になります。
ラベル指定：selector.matchLabels.app: orders-service のように特定の Pod にだけ適用可能です。

以下は orders 名前空間で読み取りは全ユーザー、書き込みは管理者のみ許可する例です。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: orders-read-only
  namespace: orders
spec:
  selector:
    matchLabels:
      app: orders-service
  rules:
  - from:
    - source:
        requestPrincipals: [&quot;*&quot;]   # 任意の認証済みユーザー
    to:
    - operation:
        methods: [&quot;GET&quot;]

apiVersion: security.istio.io/v1beta1

kind: AuthorizationPolicy

metadata:

namespace: orders

spec:

selector:

matchLabels:

app: orders-service

rules:

- from:

- source:

requestPrincipals: ["*"] # 任意の認証済みユーザー

to:

- operation:

methods: ["GET"]

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: orders-admin-write
  namespace: orders
spec:
  selector:
    matchLabels:
      app: orders-service
  rules:
  - from:
    - source:
        requestPrincipals: [&quot;admin@microservice-realm&quot;]   # Keycloak の admin ユーザー
    to:
    - operation:
        methods: [&quot;POST&quot;,&quot;PUT&quot;,&quot;DELETE&quot;]

apiVersion: security.istio.io/v1beta1

kind: AuthorizationPolicy

metadata:

namespace: orders

spec:

selector:

matchLabels:

app: orders-service

rules:

- from:

- source:

requestPrincipals: ["admin@microservice-realm"] # Keycloak の admin ユーザー

to:

- operation:

methods: ["POST","PUT","DELETE"]

ポイント：requestPrincipals は RequestAuthentication が検証した JWT の sub や aud とマッチさせられるため、外部 IdP とシームレスに連携できます。

allow/deny ルールの実装サンプル

Istio のデフォルトは「ポリシーが無ければ許可」になるため、安全なベースラインを作るには 明示的な deny を先に設定し、その上で allow ポリシーを追加します。以下は外部 IP からの全アクセスを遮断する例です。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-external-ip
  namespace: istio-system   # クラスタ全体に適用
spec:
  action: DENY
  rules:
  - from:
    - source:
        ipBlocks: [&quot;0.0.0.0/0&quot;]   # 全IP アドレス
    when:
    - key: request.headers[&quot;:authority&quot;]
      notValues: [&quot;internal.example.com&quot;]

apiVersion: security.istio.io/v1beta1

kind: AuthorizationPolicy

metadata:

namespace: istio-system # クラスタ全体に適用

spec:

action: DENY

rules:

- from:

- source:

ipBlocks: ["0.0.0.0/0"] # 全IP アドレス

when:

- key: request.headers[":authority"]

notValues: ["internal.example.com"]

ポイント：action: DENY が最優先で評価され、後続の allow ルールがあっても上書きできません。これにより意図しない外部アクセスを確実に防げます。

NIST SP 800‑204 に基づくゼロトラストモデルと Istio の役割

NIST が示す Zero Trust Architecture（ZTA）は、常に認証・認可を行い、最小特権でアクセスする ことを基本原則としています。この章では、Istio が ZTA の主要要素にどのようにマッピングできるかを具体的に示します。

ZTA と Istio 機能の対応表

以下の表は NIST SP 800‑204 の要素と、それに該当する Istio の機能・実装例をまとめたものです。各項目は実際のマニフェスト例と併せて示しています。

ZTA 要素	対応する Istio 機能	実装例
アイデンティティ検証	`RequestAuthentication` + JWT	Keycloak と連携し、JWT 署名を検証
データ保護（暗号化）	`PeerAuthentication` (STRICT mTLS)	全サービス間の通信を TLS で暗号化
ポリシー駆動アクセス制御	`AuthorizationPolicy`	allow/deny ルールで RBAC を実装
ログ・監査	Envoy アクセスログ + Telemetry (Prometheus)	トラフィックメトリクスを可視化

ポイント：Istio を導入するだけで、ZTA が要求する「認証」「暗号化」「ポリシー制御」の三本柱が自動的に満たされます。追加のセキュリティツールは最小限に抑えられ、運用コストを削減できます。

実装手順・デバッグ方法と次のアクション

この章では、Istio のインストールからポリシー適用、トラブルシューティングまでの一連のフローを具体的に示します。実際に手を動かす際の注意点や、問題が発生した場合の確認ポイントも併せて解説します。

istiod のインストールと基本設定

まずは istioctl を用いてコントロールプレーン（istiod）をデプロイし、サイドカー自動注入を有効化します。以下の手順でデフォルトプロファイルをインストールすると、認証関連の CRD がすべて作成されます。

# Istio バイナリ取得（例: 1.20.0）
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.0 sh -
cd istio-1.20.0
export PATH=$PWD/bin:$PATH

# デフォルトプロファイルでインストール
istioctl install --set profile=default -y

# default 名前空間へ自動サイドカー注入ラベル付与
kubectl label namespace default istio-injection=enabled

# Istio バイナリ取得（例: 1.20.0）

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.0 sh -

cd istio-1.20.0

export PATH=$PWD/bin:$PATH

# デフォルトプロファイルでインストール

istioctl install --set profile=default -y

# default 名前空間へ自動サイドカー注入ラベル付与

kubectl label namespace default istio-injection=enabled

ポイント：インストール後は kubectl get pods -n istio-system で istiod と istio-proxy が正常に起動していることを必ず確認してください。

ポリシー適用フロー（kubectl apply → istioctl proxy‑status）

ポリシーは Kubernetes の標準コマンドで作成し、istioctl proxy-status で各サイドカーへの反映状況を即座にチェックできます。以下は先ほどの PeerAuthentication・RequestAuthentication・AuthorizationPolicy を適用する例です。

# CRD 適用
kubectl apply -f peer-authentication.yaml
kubectl apply -f request-authentication.yaml
kubectl apply -f authorization-policy.yaml

# 反映確認
istioctl proxy-status

# CRD 適用

kubectl apply -f peer-authentication.yaml

kubectl apply -f request-authentication.yaml

kubectl apply -f authorization-policy.yaml

# 反映確認

istioctl proxy-status

ポイント：proxy-status の出力に SYNCED と表示されていれば、Envoy に設定が正しくプッシュされています。NOT_SYNCED が出た場合は、対象 Pod のラベルや名前空間がポリシーと合致しているかを再確認してください。

トラブルシューティングとログ確認ポイント

認証エラーは主に 証明書期限切れ、JWKS 取得失敗、Namespace/Label 不一致 が原因です。下記チェックリストに沿って順番に検証すると、問題箇所を迅速に特定できます。

確認項目	実行コマンド例	主な判定ポイント
Envoy ログで JWT エラー検索	`kubectl logs <pod>-istio-proxy -c istio-proxy \| grep jwt_authn`	`jwt verification failed` が出ていないか
Istiod のイベント確認	`kubectl describe pod istiod-xxxxx -n istio-system`	CRD 更新時の Warning が無いか
mTLS ステータスチェック	`istioctl authn tls-check <pod>.<ns>`	`MTLS: ENABLED` と表示されるか
JWKS エンドポイントの可達性	`curl -v https://keycloak.example.com/realms/microservice-realm/protocol/openid-connect/certs`	HTTP 200 と正しい JSON が返ってくるか

ポイント：問題が判明したら該当リソース（例: PeerAuthentication の mode）を修正し、再度 kubectl apply で上書きすれば即座に反映されます。

以上が、Istio を用いたサービスメッシュの認証・認可基盤構築手順とデバッグ方法です。各セクションで示したマニフェスト例やコマンドを参考に、自組織の要件に合わせて Zero Trust アーキテクチャを実装してください。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-Istio

comment コメントをキャンセル

: Istio

Istio vs. Linkerd: 2024 性能・機能比較と導入チェックリスト

本記事では、IstioとLinkerdの性能・機能・コストを2024年ベンチマークデータやCNCF動向に基づき比較。サービスメッシュ選定に役立つチェックリストを紹介します。

: Istio

Zero Trust アーキテクチャと Istio 実装手順 – mTLS・認可・外部認証の全体像

Zero Trust の基本概念と Istio による mTLS、認可ポリシー、外部 IdP 統合の実装手順をわかりやすく紹介します。

: Istio

Istio Ingress Gatewayの導入とクラスタへのデプロイガイド

KubernetesクラスタにIstio Ingress Gatewayを導入する方法と、Gateway/VirtualServiceリソースの構成・セキュリティ設定・トラフィック制御のベストプラクティスを解説します。

: Istio

Istio Ingress Gateway のインストール・設定とTLS/mTLS構成ガイド

本記事では、Kubernetes クラスタ上に Istio Ingress Gateway をデプロイし、Sidecar 自動注入やGateway/VirtualService の設定、TLS・mTLS の有効化方法をステップバイステップで紹介します。

: Istio

Istioトラフィックシフト実装ガイド | 無停止リリースとCanaryテスト

Kubernetes環境におけるサービスバージョン切り替えは、Istioのトラフィックシフト機能により無停止で可能に。VirtualServiceとWeighted RoutingによるCanaryリリースやグレースフルなロールアウトの実装手順を解説。

Istioトラフィックミラリングの設定とリスク低減方法

Docker ComposeでTraefikとLet’s Encrypt自動取得の手順