--- title: "Istio AuthorizationPolicyの書き方：ALLOW・DENYの評価順とmTLS前提のYAML例【1.31系】" url: "https://www.issoh.co.jp/tech/details/18575/" published: 2026-10-19 updated: 2026-10-19 categories: ["Kubernetes・コンテナ"] publisher: "株式会社一創" --- # Istio AuthorizationPolicyの書き方：ALLOW・DENYの評価順とmTLS前提のYAML例【1.31系】 Istio AuthorizationPolicyは、サービスメッシュ内のどの呼び出し元が、どのサービスのどのメソッドやパスへアクセスしてよいかを決める認可のリソースです。この記事では、CUSTOM・DENY・ALLOWの評価順と既定の動作、PeerAuthenticationでmTLSをSTRICTにしてからサービス間の許可リストを組む手順、DENYやJWTを使った条件の書き方を、Istio 1.31系の公式ドキュメントに沿ったYAMLで示します。本番へ適用する前の確かめ方と、アンビエント方式での違いも扱います。 ## まとめ：DENYが優先しALLOWが1つでもあれば一致しない通信は拒否 AuthorizationPolicyは、CUSTOM、DENY、ALLOWの順に評価されます。DENYに一致した通信は、ALLOWに一致していても拒否の対象です。注意したいのはALLOWの扱いで、ワークロードにALLOWのポリシーが1つも無ければすべて通り、1つでも付いた瞬間に「どのALLOWにも一致しない通信」は拒否へ切り替わります。 サービス間の認可で呼び出し元を`principals`（サービスアカウント）や`namespaces`で指定する場合、その値はmTLSの証明書から取り出されます。先にPeerAuthenticationでmTLSを`STRICT`にし、そのうえで何も許可しないポリシーを置き、必要な呼び出しだけを1本ずつ許可する順で組むと、穴の無い構成になります。 適用前には`istio.io/dry-run`アノテーションで影響を数え、拒否の原因は`istioctl x authz check`とEnvoyのrbacログで追うのが基本の流れです。 ## 認可ポリシーの役割とmTLS認証との分担・YAMLの基本形を確認する Istio全体の仕組みは[Istioとは？サービスメッシュの仕組みとサイドカー/アンビエント方式・導入判断を解説](https://www.issoh.co.jp/tech/details/15568/)で扱っています。ここでは、セキュリティ系の3つのリソースの分担と、AuthorizationPolicyの書き方の骨格を押さえます。 ### PeerAuthenticationとAuthorizationPolicyの役割分担 PeerAuthenticationで相手を確かめ、AuthorizationPolicyで許可を決める関係です。Istioのセキュリティ設定は、役割の異なる3つのリソースで構成されます。 | リソース | 決めること | 主な設定 | | --------------------- | ------------------ | ----------------- | | PeerAuthentication | サービス間の通信にmTLSを求めるか | STRICTかPERMISSIVE | | RequestAuthentication | 利用者のJWTをどう検証するか | 発行者と公開鍵の取得先 | | AuthorizationPolicy | 確かめた相手に何を許すか | 呼び出し元と操作の条件 | 前の2つは「相手が誰か」を確かめる認証で、AuthorizationPolicyはその結果を使って許可か拒否かを決めます。mTLSそのものの仕組みと証明書の運用は[mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断を実装目線で解説](https://www.issoh.co.jp/tech/details/14378/)にまとめています。 ### security.istio.io/v1で認可を定義するYAMLの基本形 [AuthorizationPolicyのリファレンス](https://istio.io/latest/docs/reference/config/security/authorization-policy/)の例は、すべて`security.istio.io/v1`で書かれています。基本形での役割は、selectorが適用対象、actionが許可や拒否の動作、rulesが一致条件です。日本語の解説には`v1beta1`のYAMLが今も残っていますが、新しく書くならv1にそろえます。 ``` apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: orders-viewer namespace: shop spec: selector: matchLabels: app: orders action: ALLOW rules: - from: - source: principals: ["cluster.local/ns/shop/sa/frontend"] to: - operation: methods: ["GET"] paths: ["/api/orders/*"] ``` この例は、`shop`名前空間の`frontend`サービスアカウントから、`orders`のPodへのGETだけを許可します。`selector`を省くと同じ名前空間の全ワークロードが対象になり、ポリシーをルート名前空間（通常は`istio-system`）に置くとメッシュ全体に効きます。`action`を省いた場合に適用される既定のアクションはALLOWです。 1つの`rules`の中では`from`と`to`と`when`がANDで結ばれ、`rules`の要素どうしはORになります。 ## CUSTOM・DENY・ALLOWの評価順とポリシーが無いときの既定動作 ポリシーを何本も重ねると、どれが効いて拒否されたのかが分かりにくくなります。評価の規則を先に頭に入れておくと、設計と調査の両方が楽になります。 ### ALLOWが1つでも付くと一致しない通信は拒否される既定拒否の仕様 リファレンスが定める判定の流れは次のとおりです。 1. 一致するCUSTOMポリシーの外部認可が拒否を返したら拒否 2. 一致するDENYポリシーがあれば拒否 3. そのワークロードにALLOWポリシーが1つも無ければ許可 4. 一致するALLOWポリシーがあれば許可 5. どれにも当たらなければ拒否 3と5で許可の扱いが変わる点は、設定事故の原因です。たとえば管理画面用のパスだけを許可するつもりでALLOWを1本足すと、それまで通っていた他のパスへの通信もすべて拒否されます。[公式のExplicit Denyタスク](https://istio.io/latest/docs/tasks/security/authorization/authz-deny/)でも、`/ip`だけを許すALLOWを足した後、同じPodの`/get`が403になる様子が確かめられます。 ### allow-nothingとallow-allとdeny-allの空ルールの書き分け 中身の無い書き方は、見た目が似ていても意味が正反対です。 ``` # 何も許可しない（ALLOWでrulesなし）＝その名前空間の通信をすべて拒否 apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: allow-nothing namespace: shop spec: {} --- # すべて許可（空のルールは常に一致） apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: allow-all namespace: shop spec: rules: - {} ``` `spec: {}`はルールの無いALLOWとなり、何にも一致しないため全拒否と同じ効果になります。`rules: [{}]`は常に一致するので全許可です。`action: DENY`に空のルールを付けたdeny-allは、ALLOWより先に評価されるため、どのALLOWを足しても通らなくなります。緊急の遮断以外では使わないほうが無難です。 ## mTLSをSTRICTにしてからサービス間認可を許可リストで組む手順 ここからは、名前空間の中で「必要な呼び出しだけを通す」構成を作る順番を示します。順番を誤ると、許可リストが平文の通信を素通しにします。 ### PeerAuthenticationで名前空間からSTRICTへ切り替える適用順 [Istioのセキュリティの解説](https://istio.io/latest/docs/concepts/security/)によると、PeerAuthenticationの既定は平文とmTLSの両方を受け付けるPERMISSIVEです。同じページは、`principals`や`namespaces`を使うポリシーは、STRICTと組み合わせることを強く勧めています。PERMISSIVEのまま平文で届いた通信では、予期しない拒否やポリシーの回避が起こり得るためです。 ``` apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata: name: default namespace: shop spec: mtls: mode: STRICT ``` [公式のMutual TLS Migrationタスク](https://istio.io/latest/docs/tasks/security/authentication/mtls-migration/)は、全クライアントにサイドカーを入れてから、まず名前空間単位でSTRICTにし、問題が無ければ`istio-system`に同じリソースを置いてメッシュ全体へ広げる順を示しています。サイドカーの無いPodからSTRICTの名前空間を呼ぶと、curlは`exit code 56`で失敗します。設定範囲の優先順位は、ワークロード単位、名前空間単位、メッシュ全体の順です。 ### allow-nothingから始めてprincipalsで呼び出し元を1本ずつ許可する [公式のHTTP Trafficタスク](https://istio.io/latest/docs/tasks/security/authorization/authz-http/)は、名前空間にallow-nothingを置いて全体を止め、呼び出しの経路ごとにALLOWを足していく手順です。止めた直後の画面には`RBAC: access denied`と表示されます。 ``` apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: payments-from-orders namespace: shop spec: selector: matchLabels: app: payments action: ALLOW rules: - from: - source: principals: ["cluster.local/ns/shop/sa/orders"] to: - operation: methods: ["POST"] paths: ["/v1/charges"] ``` `principals`の値は`トラストドメイン/ns/名前空間/sa/サービスアカウント`の形です。Deploymentごとに専用のサービスアカウントを割り当てていないと、`default`を共有するPodがすべて同じ呼び出し元に見えてしまい、許可を絞れません。許可リストを書き始める前に、サービスアカウントを分けておいてください。ポリシーは反映まで数秒かかることがあるため、確認は少し待ってから行います。 ### namespaces指定による名前空間の分離とIngress Gatewayの例外 サービス単位まで細かく書く前に、名前空間の外からの通信だけを止める方法もあります。[公式のポリシー例集](https://istio.io/latest/docs/ops/configuration/security/security-policy-examples/)には、同じ名前空間からの通信に加えて、Ingress Gatewayからの通信だけを例外として許す形が載っています。 ``` apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: ns-isolation-except-ingress namespace: shop spec: action: ALLOW rules: - from: - source: namespaces: ["shop"] - source: principals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"] ``` Ingress Gatewayのサービスアカウント名は、インストール方法によって変わります。`kubectl get pods -n istio-system -o yaml`で実際の`serviceAccountName`を確かめてから書いてください。入口側の構成は[Istio Gatewayの設定方法：Ingress GatewayのYAML・TLS終端・Gateway API対応](https://www.issoh.co.jp/tech/details/18571/)で扱っています。 ## DENYで外せない禁止事項を先に書くパスとヘッダーとJWTの条件 ALLOWの許可リストは、誰かが緩いALLOWを足すと広がってしまいます。どんな場合も通してはいけない通信は、DENYで書いておくと後から崩れません。 ### DENYとwhen条件で管理用パスへのリクエストを拒否する例 Explicit Denyタスクは、`x-token`ヘッダーが`admin`でないGETを拒否する例を示しています。同じ考え方で、管理用のパスを特定の呼び出し元以外から閉じられます。 ``` apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: deny-admin-path namespace: shop spec: selector: matchLabels: app: orders action: DENY rules: - from: - source: notPrincipals: ["cluster.local/ns/ops/sa/admin-tool"] to: - operation: paths: ["/admin/*"] ``` `when`には`request.headers[x-token]`のような属性を`key`に取り、`values`か`notValues`で値を並べます。パスは前方一致や後方一致の`*`が使えますが、`when`の`key`と`ports`は完全一致のみです。 ### RequestAuthenticationと認可ポリシーでJWTを必須にする設定 [公式のJWT Tokenタスク](https://istio.io/latest/docs/tasks/security/authorization/authz-jwt/)によると、RequestAuthenticationだけを置いた状態では、不正なトークンは401になりますが、トークンの無いリクエストは200で通ります。トークンを必須にするには、AuthorizationPolicyを組み合わせます。以下は、notRequestPrincipalsでトークンの無いリクエストを拒否する設定例です。 ``` apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata: name: jwt-orders namespace: shop spec: selector: matchLabels: app: orders jwtRules: - issuer: "https://auth.example.com/" jwksUri: "https://auth.example.com/.well-known/jwks.json" --- apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: require-jwt namespace: shop spec: selector: matchLabels: app: orders action: DENY rules: - from: - source: notRequestPrincipals: ["*"] ``` `*`は「空でない値」に一致するため、`notRequestPrincipals: ["*"]`は検証済みのトークンを持たないリクエストに当たります。ポリシー例集で紹介されているのも、このDENYを使う構成です。`requestPrincipals`の値はトークンの`iss`と`sub`を`/`でつないだ文字列なので、利用者単位で絞る場合はその形で書きます。発行者のURLと鍵の取得先は、利用している認証基盤の値に置き換えてください。 ### TCPポートにHTTP専用の条件を書くと意図より厳しくなる落とし穴 `methods`、`paths`、`hosts`、`requestPrincipals`はHTTPでしか判定できません。[公式のSecurity Problemsのページ](https://istio.io/latest/docs/ops/common-problems/security-issues/)は、TCPとして扱われるポートにこれらを書くとポリシーが意図より厳しくなると注意しています。リファレンスにも、DENYではTCPで欠けている属性を「一致した」とみなすため、ポートで絞らないとTCPの通信がまとめて拒否されるとの注記があります。 対策は2つです。HTTPのServiceはポート名を`http-`で始め、IstioにHTTPとして認識させます。DENYには`ports`を付け、対象のポートを限定してください。 ## dry-runとistioctlで本番適用前に効き方を確かめる確認の手順 認可の設定ミスは、障害として表に出るまで気付きにくいのが難点です。適用前の確認と、拒否されたときの原因の追い方を手順にしておきます。 ### istio.io/dry-runアノテーションで拒否されるはずの通信を数える [公式のDry Runタスク](https://istio.io/latest/docs/tasks/security/authorization/authz-dry-run/)は、ポリシーを強制せずに「適用していたら拒否された件数」を記録する方法です。機能の段階はAlphaで、ALLOWとDENYだけが対象です。 ``` # 既存のポリシーをdry-runに切り替える kubectl annotate --overwrite authorizationpolicies deny-admin-path -n shop istio.io/dry-run='true' # rbacのログをdebugにして、拒否されるはずだった通信を探す istioctl proxy-config log deploy/orders -n shop --level "rbac:debug" kubectl logs deploy/orders -n shop -c istio-proxy | grep "shadow denied" ``` Prometheusを入れている環境では、rbacのメトリクスを`authz_dry_run_action`と`authz_dry_run_result`のラベルで絞ると件数を見られます。ALLOWとDENYは別々に記録されるので、両方の結果を合わせて判断してください。数日分の通信で想定外の拒否が0件だと確かめてから、アノテーションを外して強制に移ります。 ### istioctl x authz checkとrbacログで拒否の原因ポリシーを特定する Security Problemsのページは、次の順で確認する手順を挙げています。 ``` # Podに実際に適用されているポリシーの一覧 istioctl x authz check orders-7d9f8c6b5-abcde.shop # rbacログを有効にして、拒否したポリシー名を確かめる istioctl proxy-config log deploy/orders -n shop --level "rbac:debug" kubectl logs deploy/orders -n shop -c istio-proxy | grep "enforced" ``` ログの`enforced denied`の後ろに、拒否したポリシーの名前が出ます。よくある原因は、`from`の前に余計な`-`を付けてルールが2つに分かれ、AND条件のつもりがOR条件になっているケースです。セレクタのラベルと名前空間が対象のPodと合っているかも、同じタイミングで確かめます。 ## サイドカー方式とアンビエント方式での書き方の違いと採用判断の目安 同じAuthorizationPolicyでも、データプレーンの方式によって評価される場所が変わります。方式ごとの差と、どこまでIstioで認可を担うかの判断を示します。 ### ztunnelはL4属性だけを扱いL7条件付きのALLOWは拒否に倒れる [アンビエント方式のL4ポリシーのページ](https://istio.io/latest/docs/ambient/usage/l4-policy/)によると、ztunnelが判定できるのは呼び出し元のID、名前空間、IP、ポートといったL4の属性だけです。L7の属性を含むポリシーがztunnelで強制されると、安全側に倒れてDENYとして扱われます。`methods: ["GET"]`を足したALLOWで、正しい呼び出し元からの接続まで失敗するのはこのためです。 アンビエント方式でメソッドやパスの条件を使うなら、waypointを置き、ポリシーを`selector`ではなく`targetRefs`でwaypointに結び付けます。waypointを経由すると宛先のztunnelから見た呼び出し元はwaypointのIDに変わるため、呼び出し元で絞るL4のポリシーもwaypoint側へ移す必要があります。 ### NetworkPolicyで足りる通信制御とサービス間認可を追加する判断条件 Podどうしの通信を名前空間やラベルで止めるだけなら、KubernetesのNetworkPolicyで足ります。サービスが数本で、呼び出しの経路が固定されている構成では、Istioを入れずにNetworkPolicyで始めるのが手軽です。 AuthorizationPolicyを選ぶのは、IPではなくサービスアカウント単位で呼び出し元を特定したい場合、メソッドやパスの単位で許可を分けたい場合、利用者のJWTとサービス間の認可を同じ仕組みで扱いたい場合です。両方を重ねる多層防御も、公式のL4ポリシーのページで紹介されています。考え方の土台は[ゼロトラストとは？境界型防御との違い・NIST7原則と導入判断を解説](https://www.issoh.co.jp/column/details/13096/)で整理しています。 利用者の認証基盤とサービス間の認可をまとめて設計し直すなら、[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)のように、JWTの発行側から権限の設計までを一体で任せる方法もあります。 ## Istio AuthorizationPolicyの設定と運用で挙がるよくある質問 AuthorizationPolicyを書き始めたときに出やすい疑問に、公式ドキュメントの記述をもとに答えます。 ### PeerAuthenticationがPERMISSIVEのままでも認可は効きますか？ メソッドやパスの条件だけなら、PERMISSIVEのままでも認可は有効です。ただし`principals`や`namespaces`はmTLSの証明書から取り出す値なので、平文で届いた通信では空になります。ALLOWなら一致せずに拒否され、`notPrincipals`を使ったDENYでは想定と違う結果になり得ます。呼び出し元で絞るポリシーを使うなら、対象の名前空間はSTRICTにしてください。 ### AUDITとCUSTOMのアクションはどんな場面で使いますか？ AUDITは許可や拒否に影響せず、一致したリクエストを監査ログに残すためのアクションで、別途プラグインの設定が要ります。CUSTOMは判定を外部の認可サービスへ委ねるもので、MeshConfigに登録した拡張プロバイダーを`provider.name`で指定します。CUSTOMの評価順は、ALLOWやDENYよりも先です。 ### ポリシーを変更してから反映されるまでどのくらいかかりますか？ HTTP Trafficタスクは、キャッシュや伝播の遅れで数秒かかる場合があると記しています。適用直後に結果が変わらなくても、数秒待ってから再度試してください。それでも変わらない場合は、`istioctl x authz check`でPodにポリシーが届いているかを見ます。 ### VirtualServiceのルーティングと認可はどちらが先に効きますか？ 役割が別で、VirtualServiceは呼び出し元側のEnvoyで行き先を決め、AuthorizationPolicyは受け手側（サイドカー方式では宛先Podのサイドカー）で許可を判定します。カナリアで新バージョンへ振り分けた通信にも、受け手のポリシーがそのまま効きます。ルーティングの書き方は[Istio VirtualServiceの書き方：DestinationRuleとカナリア・リトライのYAML例](https://www.issoh.co.jp/tech/details/18573/)を参照してください。 ### Istioのバージョンを上げるとポリシーの書き換えが要りますか？ `security.istio.io/v1`で書いていれば、1.31系への更新で書き換えは要りません。[Istioのサポート表](https://istio.io/latest/docs/releases/supported-releases/)では、2026年10月時点で1.31系が現行（最新パッチは1.31.2）です。`v1beta1`のまま残っているマニフェストは、更新の機会にv1へ直しておくと後の移行が楽になります。版ごとの差分は[Istioの最新バージョンは1.31｜1.28〜1.31の新機能・サポート期限とアップグレード手順](https://www.issoh.co.jp/tech/details/9698/)にまとめています。 ## 関連記事 - [Istioとは？サービスメッシュの仕組みとサイドカー/アンビエント方式・導入判断を解説](https://www.issoh.co.jp/tech/details/15568/)：Istio全体の仕組みと導入判断 - [mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断を実装目線で解説](https://www.issoh.co.jp/tech/details/14378/)：認可の前提となる相互TLS認証 - [Istio Gatewayの設定方法：Ingress GatewayのYAML・TLS終端・Gateway API対応](https://www.issoh.co.jp/tech/details/18571/)：外部からの入口の設定 - [Istio VirtualServiceの書き方：DestinationRuleとカナリア・リトライのYAML例](https://www.issoh.co.jp/tech/details/18573/)：メッシュ内のルーティング設定 - [サービスメッシュとは？サイドカー方式の仕組みとAPIゲートウェイとの違い・導入判断を解説](https://www.issoh.co.jp/tech/details/13224/)：サービスメッシュの位置づけ - [Linkerdとは？軽量なRust製サービスメッシュの仕組みとIstioとの選び分けを解説](https://www.issoh.co.jp/tech/details/15570/)：より軽量なメッシュとの比較 --- 出典: [Istio AuthorizationPolicyの書き方：ALLOW・DENYの評価順とmTLS前提のYAML例【1.31系】]()（株式会社一創）