1.12. サービスメッシュのセキュリティーのカスタマイズ
サービスメッシュアプリケーションが複雑な配列のマイクロサービスで構築されている場合、Red Hat OpenShift Service Mesh を使用してそれらのサービス間の通信のセキュリティーをカスタマイズできます。サービスメッシュのトラフィック管理機能と共に OpenShift Container Platform のインフラストラクチャーを使用すると、アプリケーションの複雑性を管理し、マイクロサービスのサービスおよびアイデンティティーのセキュリティーを提供することができます。
1.12.1. 相互トランスポート層セキュリティー (mTLS) の有効化
相互トランスポート層セキュリティー (mTLS) は、二者が同時に相互の認証を行うプロトコルです。これは、一部のプロトコル(IKE、SSH)での認証のデフォルトモードであり、他のプロトコル (TLS) ではオプションになります。
mTLS は、アプリケーションやサービスコードを変更せずに使用できます。TLS は、サービスメッシュインフラストラクチャーおよび 2 つのサイドカープロキシー間で完全に処理されます。
デフォルトで、Red Hat OpenShift Service Mesh は Permissive モードに設定されます。この場合、サービスメッシュのサイドカーは、プレーンテキストのトラフィックと mTLS を使用して暗号化される接続の両方を受け入れます。メッシュのサービスがメッシュ外のサービスと通信している場合、厳密な mTLS によりサービス間の通信に障害が発生する可能性があります。ワークロードをサービスメッシュに移行する間に Permissive モードを使用します。
1.12.1.1. メッシュ全体での厳密な mTLS の有効化
ワークロードがメッシュ外のサービスと通信せず、暗号化された接続のみを受け入れることで通信が中断されない場合は、メッシュ全体で mTLS をすぐに有効にできます。ServiceMeshControlPlane
リソースで spec.istio.global.mtls.enabled
を true
に設定します。Operator は必要なリソースを作成します。
apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane spec: istio: global: mtls: enabled: true
1.12.1.1.1. 特定のサービスの受信接続用のサイドカーの設定
ポリシーを作成して、個別のサービスまたは namespace に mTLS を設定することもできます。
apiVersion: "authentication.istio.io/v1alpha1" kind: "Policy" metadata: name: "default" namespace: <NAMESPACE> spec: peers: - mtls: {}
1.12.1.2. 送信接続用のサイドカーの設定
宛先ルールを作成し、サービスメッシュがメッシュ内の他のサービスに要求を送信する際に mTLS を使用するように設定します。
apiVersion: "networking.istio.io/v1alpha3" kind: "DestinationRule" metadata: name: "default" namespace: <CONTROL_PLANE_NAMESPACE> spec: host: "*.local" trafficPolicy: tls: mode: ISTIO_MUTUAL
1.12.1.3. 最小および最大のプロトコルバージョンの設定
ご使用の環境のサービスメッシュに暗号化されたトラフィックの特定の要件がある場合、許可される暗号化機能を制御できます。これは、ServiceMeshControlPlane
リソースに spec.istio.global.tls.minProtocolVersion
または spec.istio.global.tls.maxProtocolVersion
を設定して許可できます。コントロールプレーンリソースで設定されるこれらの値は、TLS 経由でセキュアに通信する場合にメッシュコンポーネントによって使用される最小および最大の TLS バージョンを定義します。
apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane spec: istio: global: tls: minProtocolVersion: TLSv1_0
デフォルトは TLS_AUTO
であり、TLS のバージョンは指定しません。
値 | 説明 |
---|---|
| default |
| TLS バージョン 1.0 |
| TLS バージョン 1.1 |
| TLS バージョン 1.2 |
| TLS バージョン 1.3 |
1.12.2. 暗号化スイートおよび ECDH 曲線の設定
暗号化スイートおよび ECDH 曲線 (Elliptic-curve Diffie–Hellman) は、サービスメッシュのセキュリティーを保護するのに役立ちます。暗号化スイートのコンマ区切りの一覧を spec.istio.global.tls.cipherSuites
を使用して定義し、 ECDH 曲線を ServiceMeshControlPlane
リソースの spec.istio.global.tls.ecdhCurves
を使用して定義できます。これらの属性のいずれかが空の場合、デフォルト値が使用されます。
サービスメッシュが TLS 1.2 以前のバージョンを使用する場合、cipherSuites
設定が有効になります。この設定は、TLS 1.3 でネゴシエートする場合は影響を与えません。
コンマ区切りの一覧に暗号化スイートを優先度順に設定します。たとえば、ecdhCurves: CurveP256, CurveP384
は、CurveP256
を CurveP384
よりも高い優先順位として設定します。
暗号化スイートを設定する場合は、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
または TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
のいずれかを追加する必要があります。HTTP/2 のサポートには、1 つ以上の以下の暗号スイートが必要です。
サポートされている暗号化スイートは以下になります。
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
サポートされる ECDH 曲線は以下のとおりです。
- CurveP256
- CurveP384
- CurveP521
- X25519
1.12.3. 外部認証局キーおよび証明書の追加
デフォルトで、Red Hat OpenShift Service Mesh は自己署名ルート証明書およびキーを生成し、それらを使用してワークロード証明書に署名します。Operator 指定のルート証明書およびキーを使用して、Operator 指定のルート証明書を使用してワークロード証明書に署名することもできます。このタスクは、証明書およびキーをサービスメッシュにプラグインするサンプルを示しています。
前提条件
- 証明書を設定するには、相互 TLS を有効にして Red Hat OpenShift Service Mesh をインストールしておく必要があります。
- この例では、Maistra リポジトリー からの証明書を使用します。実稼働環境の場合は、認証局から独自の証明書を使用します。
- これらの手順で結果を確認するには、Bookinfo サンプルアプリケーションをデプロイする必要があります。
1.12.3.1. 既存の証明書およびキーの追加
既存の署名 (CA) 証明書およびキーを使用するには、CA 証明書、キー、ルート証明書が含まれる信頼ファイルのチェーンを作成する必要があります。それぞれの対応する証明書について以下のファイル名をそのまま使用する必要があります。CA 証明書は ca-cert.pem
と呼ばれ、キーは ca-key.pem
であり、ca-cert.pem
を署名するルート証明書は root-cert.pem
と呼ばれます。ワークロードで中間証明書を使用する場合は、cert-chain.pem
ファイルでそれらを指定する必要があります。
以下の手順に従い、証明書をサービスメッシュに追加します。Maistra リポジトリー から証明書をローカルに保存し、<path>
を証明書へのパスに置き換えます。
シークレット
cacert
を作成します。これには、入力ファイルのca-cert.pem
、ca-key.pem
、root-cert.pem
およびcert-chain.pem
が含まれます。$ oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \ --from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \ --from-file=<path>/cert-chain.pem
ServiceMeshControlPlane
リソースでglobal.mtls.enabled
をtrue
に設定し、security.selfSigned
をfalse
に設定します。サービスメッシュは、secret-mount ファイルから証明書およびキーを読み取ります。apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane spec: istio: global: mtls: enabled: true security: selfSigned: false
ワークロードが新規証明書を追加することをすぐに確認するには、
istio.*
という名前のサービスメッシュによって生成されたシークレットを削除します。この例ではistio.default
です。サービスメッシュはワークロードの新規の証明書を発行します。$ oc delete secret istio.default
1.12.3.2. 証明書の確認
Bookinfo サンプルアプリケーションを使用して、証明書が正しくマウントされていることを確認します。最初に、マウントされた証明書を取得します。次に、Pod にマウントされた証明書を確認します。
Pod 名を変数
RATINGSPOD
に保存します。$ RATINGSPOD=`oc get pods -l app=ratings -o jsonpath='{.items[0].metadata.name}'`
以下のコマンドを実行して、プロキシーにマウントされている証明書を取得します。
$ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/root-cert.pem > /tmp/pod-root-cert.pem
/tmp/pod-root-cert.pem
ファイルには、Pod に伝播されるルート証明書が含まれます。$ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/cert-chain.pem > /tmp/pod-cert-chain.pem
/tmp/pod-cert-chain.pem
ファイルには、ワークロード証明書と Pod に伝播される CA 証明書が含まれます。ルート証明書が Operator によって指定される証明書と同じであることを確認します。
<path>
を証明書へのパスに置き換えます。$ openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txt
$ openssl x509 -in /tmp/pod-root-cert.pem -text -noout > /tmp/pod-root-cert.crt.txt
$ diff /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt
出力が空になることが予想されます。
CA 証明書が Operator で指定された証明書と同じであることを確認します。
<path>
を証明書へのパスに置き換えます。$ sed '0,/^-----END CERTIFICATE-----/d' /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-ca.pem
$ openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt
$ openssl x509 -in /tmp/pod-cert-chain-ca.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt
$ diff /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt
出力が空になることが予想されます。
ルート証明書からワークロード証明書への証明書チェーンを確認します。
<path>
を証明書へのパスに置き換えます。$ head -n 21 /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-workload.pem
$ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) /tmp/pod-cert-chain-workload.pem
出力例
/tmp/pod-cert-chain-workload.pem: OK
1.12.3.3. 証明書の削除
追加した証明書を削除するには、以下の手順に従います。
シークレット
cacerts
を削除します。$ oc delete secret cacerts -n istio-system
ServiceMeshControlPlane
リソースで自己署名ルート証明書を使用してサービスメッシュを再デプロイします。apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane spec: istio: global: mtls: enabled: true security: selfSigned: true