プロキシ経由での認証局との接続を構成する

このガイドでは、ファイアウォールやその他の制限機能などが原因でサイドカー挿入ワークロードから認証局に直接接続できない場合に、プロキシ経由での認証局（CA）との接続を構成する方法について説明します。この構成は、Certificate Authority Service を使用する Cloud Service Mesh インストールにのみ適用されます。

一般的なクラスタ内 Cloud Service Mesh インストールでは、CA サービス（meshca.googleapis.com や privateca.googleapis.com など）への直接接続が可能な場合、アプリケーション Pod にサイドカーをデプロイします。直接接続を使用できないシナリオでは、明示的な CONNECT ベースの HTTPS プロキシを構成する必要があります。

前提条件

プロキシ経由の CA 接続を構成する前に、次のことを確認してください。

  • サイドカーが挿入されたすべての Pod から HTTPS プロキシへのネットワーク接続が確立されている。
  • デプロイされた HTTPS プロキシに対するアクセス権をすべての Google Cloud サービスに付与している。

ProxyConfig カスタム リソースを構成する

  1. サイドカー プロキシに挿入する Istio ProxyConfig カスタム リソース（CR）を構成し、HTTPS プロキシの URL を指定します。次に例を示します。

    apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
 labels:
  istio.io/rev: <istio-rev>   # To target proxies mapped to a specific control plane if needed.
 name: test-proxy-inject
 namespace: istio-system      # To ensure side-cars injected into all namespaces process this CR
spec:
 environmentVariables:
  CA_PLUGIN_PROXY_URL: http://<proxy-service>.<proxy-ns>:<proxy-port>

    ここで

    • CA_PLUGIN_PROXY_URL は、プロキシとの CONNECT handshake を確立するためにサイドカーによって使用される構成です。プロキシは CA に向けたすべてのトラフィックを適切なエンドポイントに転送します。
    • proxy-service は proxy-ns 名前空間にデプロイされ、proxy-port ポートで CONNECT handshake をリッスンします。この環境変数の形式は、標準の HTTPS_PROXY 環境変数と同様です。

  2. Cloud Service Mesh コントロール プレーンをインストールしたら、Cloud Service Mesh のラベルが付いた名前空間内でワークロードを再起動する前に、クラスタに適切な ProxyConfig CR（手順 1 で構成したもの）を適用します。これにより、構成がサイドカーに正しく挿入されます。この構成は、サイドカーが CA から署名されたワークロード証明書を取得するために必要です。これにより、サイドカーが挿入された Pod が起動できるようになります。