Contents
Istioで実現するサービス間通信のセキュリティ概要
マイクロサービスアーキテクチャにおいて、サービス間通信の安全性は不可欠です。Istioはサービスメッシュとしての機能を活用し、暗号化と認証・承認を通じて信頼性の高い通信環境を構築します。このセキュリティ仕組みでは、mTLS(相互TLS)による暗号化とAuthorizationPolicyによるアクセス制御が中心となります。
サービスメッシュでは、各マイクロサービスが独自に認証・承認ロジックを持たなくても、Istioのポリシーによって一括で管理可能です。これにより、開発者負担を減らしつつ、セキュリティリスクを低減できます。以下では具体的な設定手順とベストプラクティスを解説します。
mTLS通信の必須化設定(PeerAuthenticationリソース)
Istioでサービス間通信をmTLS必須にするには、PeerAuthenticationリソースを用います。これにより、通信相手が信頼できる証明書を持っていることを保証し、不正アクセスや盗聴のリスクを防ぎます。
PeerAuthenticationの基本構文と適用範囲
|
1 2 3 4 5 6 7 8 9 |
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: production spec: mtls: mode: STRICT |
この設定では、STRICTモードを指定すると、mTLSでの通信が必須となります。一方でPERMISSIVEは、mTLSと普通のHTTP通信を併用可能にしますが、セキュリティ上は推奨されません。
Namespace単位のポリシー適用例
Istioでは、Namespaceごとに異なるセキュリティポリシーを設定可能です。以下のようにnamespace: productionなど指定することで、特定のNamespaceでのみmTLSを強制できます。
|
1 2 3 4 5 6 7 |
| 項目 | 値 | 補足 | |------|----|------| | **Namespace** | `production` | mTLS必須設定(信頼性の高い環境向け) | | **Namespace** | `test` | `PERMISSIVEモード`(テスト環境用に指定) | > `PERMISSIVEモード`は、テスト環境での柔軟なデバッグを目的としています。このモードではmTLSとHTTP通信を併用可能ですが、本番環境には適用しないでください。 |
細粒度なアクセス制御の実装(AuthorizationPolicy)
mTLSで通信が暗号化されても、特定のサービスやメソッドへのアクセスを制限する必要があります。AuthorizationPolicyリソースを使うことで、細かいルール設定が可能です。
セキュリティポリシーの定義方法
AuthorizationPolicyは以下のような構造を持ちます:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: orders-api-policy namespace: production spec: selector: matchLabels: app: orders-api action: ALLOW rules: - from: - source: principals: ["cluster.local/ns/production/sa/frontend-service"] to: - operation: methods: ["GET", "POST"] paths: ["/api/orders/*"] |
この例では、orders-apiというラベルを持つサービスに対して、frontend-serviceから送信されるGETとPOSTリクエストのみを許可しています。
サービス間通信の許可・拒否ルール
以下のような手順でアクセス制御を設定できます。
-
対象のサービスを指定
selectorフィールドで、セキュリティポリシーを適用するマイクロサービスを選択します。 -
アクセス元の条件を定義
source.principalsやheadersなどを使って、送信元のサービスやヘッダ情報を指定します。 -
アクセス先の条件を設定
operation.methodsやpathsで、許可するHTTPメソッドやパスを限定します。
Namespaceごとのセキュリティポリシーの最適な適用方法
Istioでは、Namespace単位でのセキュリティポリシー管理が可能です。これにより、各開発環境や本番環境で異なる設定を柔軟に導入できます。
デフォルトポリシーの設定ベストプラクティス
Namespaceごとにデフォルトのセキュリティポリシーを定義することで、手動での再設定を防ぎます。例えば以下のようにdefaultという名前のポリシーを作成します:
|
1 2 3 4 5 6 7 8 9 |
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: development spec: mtls: mode: PERMISSIVE |
こうすることで、developmentNamespace内のサービスはデフォルトでPERMISSIVEモードになります。
複数Namespaceへのポリシー適用戦略
複数のNamespaceに同一のセキュリティ設定を適用する際には、以下のような対応策があります。
- 個別適用: 各Namespaceごとに設定ファイルを作成し管理
- 共通テンプレート利用: 一部の設定を再利用可能なYAMLとして定義し、他のNamespaceにコピー・カスタマイズ
ただし、ポリシーの上書き注意が必要です。デフォルトが存在するNamespaceに個別ポリシーを適用する場合、デフォルト値より優先されます。
Istioセキュリティ設定ファイルテンプレートと導入ガイド
ここでは、mTLSおよびAuthorizationPolicyを組み合わせた実装例を提示します。以下のYAMLコードをベースに、実際にクラスターに適用できます。
実装に必要なYAMLファイルの構成例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: mTLS-required namespace: production spec: mtls: mode: STRICT --- apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: secure-access namespace: production spec: selector: matchLabels: app: user-service action: ALLOW rules: - from: - source: principals: ["cluster.local/ns/production/sa/order-service"] to: - operation: methods: ["POST", "PUT"] paths: ["/api/users/*"] |
この設定では、user-serviceにアクセスできるのはorder-serviceのみで、POSTまたはPUTメソッドでの通信が許可されます。
ステップバイステップの導入手順
-
Istioをクラスターにインストール
Istioのコントローラーとsidecarコンテナが正常に動くことを確認してください。詳細はこちら(Istio公式ドキュメント)。 -
YAMLファイルを適用する
上記のコードをkubectl apply -f istio-security.yamlコマンドでクラスターに反映させます。 -
ポリシーが正しく動作することを確認
kubectl describe authorizationpolicy secure-accessなどのコマンドで、ポリシーが適用されたか確認します。また、サービス間通信ログやメトリクスでセキュリティの実装効果を検証してください。 -
環境ごとに最適な設定を行う
本番環境ではSTRICTモードを、テスト環境ではPERMISSIVEモードを使うなどの差分を導入します。
記事の要点まとめ
- IstioはmTLS通信とAuthorizationPolicyを通じて、マイクロサービス間のセキュリティを強化する
PeerAuthenticationでmTLS必須設定を行うことで、信頼できる通信環境が構築可能AuthorizationPolicyにより、細かいアクセス制御が可能となり、不正アクセスリスクが軽減- Namespace単位でのポリシー管理により、開発・テスト・本番環境のセキュリティ設定を個別に調整可能
- 実装テンプレートを利用することで、効率的に導入を進めることが可能
Istioによるセキュリティ設定は、信頼性のあるマイクロサービスアーキテクチャ構築の基盤です。この記事で紹介した手順に沿って、早速実装してみてください。