はじめに
相互TLS(mTLS/mutual-TLS)とは、サーバ証明書による通常のTLS サーバ認証に加えてクライアント側の証明を行う機能です。
サービスメッシュを担うIstioでは同設定をDestinationRuleとPeerAuthenticationで行えますが、PeerAuthenticationの設定内容が優先されることを実機で確認しました。
環境情報
- Openshift v4.6
- Red Hat OpenShift Service Mesh(2.1.0-0 provided by Red Hat, Inc)Operator
DestinationRulで設定するmTLS
各DestinationRuleに対して以下のように”ISTIO_MUTUAL”を指定することでmTLSを有効化できます。
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: tls: mode: ISTIO_MUTUAL ...
KialiのGraphを選択し、Displayの項目にて"Security"という欄をチェックすることでmTLSの設定状況が確認できますが、例えば一部のサービス(rateing)のみmTLSの設定せず他のサービスではmTLSを利用する定義を入れた場合、以下のようにKiali上で確認できます。
PeerAuthenticationで設定するmTLS
上記のように各DestinationRule毎にmTLSのオンオフは切り替えれますが、Namespace全体にmTLSを課す場合はPeerAuthenticationというリソースにて"STRICT"を指定することで制御できます。例えばOpenshiftのOperatorで入れたServiceMeshでは以下のような値がデフォルトで入っています。
$ oc get PeerAuthentication -A NAMESPACE NAME MODE AGE istio-system default PERMISSIVE ... istio-system disable-mtls-jaeger-collector DISABLE ... istio-system grafana-ports-mtls-disabled PERMISSIVE ...
今回はmTLSを全体に適用すべく以下のYAMLを適用すると
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: myrule namespace: istio-test spec: mtls: mode: STRICT
DestinationRuleでmTLSの設定を外した箇所も鍵ありになりました。
ちなみに同設定をmode: DISABLE
とすると全て平文になります。
終わりに
PeerAuthenticationとDestinationRuleで相反する設定がされていた場合、PeerAuthentication側の設定がmTLSに関しては有効であることが確認できました。実際に通信が暗号化されていることはtcpdumpで確認しないと分からないので、このあたりは別途別記事にて調査したいと思います。