プロキシ経由での認証局との接続を構成する
このガイドでは、ファイアウォールやその他の制限機能などにより、サイドカー挿入のワークロードから認証局に直接接続できない場合に、プロキシ経由での認証局(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 カスタム リソースを構成する
サイドカー プロキシに挿入する Istio ProxyConfig カスタム リソース(CR)を構成し、HTTPS プロキシを指すようにします。次に例を示します。
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
環境変数と同様です。
Cloud Service Mesh コントロール プレーンをインストールしたら、Cloud Service Mesh のラベルが付いた名前空間内でワークロードを再起動する前に、クラスタに適切な
ProxyConfig
CR(手順 1 で構成したもの)を適用して、構成がサイドカーに正しく挿入されるようにします。この構成は、サイドカーが CA から署名されたワークロード証明書を取得するために必要です。これにより、サイドカーが挿入された Pod が起動できるようになります。