プロキシの失敗はどの Docker の CA ストアを指しているのか
承認済みの検査用 CA を信頼する際に、イメージの取得、ビルド中のダウンロード、コンテナ内アプリケーションの要求を切り分けます。
コンテナ内に会社の CA を追加しても、同僚のイメージ取得の失敗は直りません。取得に成功しても、イメージ内のアプリケーションが検査対象の HTTPS サービスを信頼していることの証明にはなりません。
| 操作 | 調べるべき信頼 |
|---|---|
| 組織の検査プロキシ経由でイメージを取得する | 取得を実行するホストまたは Docker 環境 |
| イメージのビルド中にダウンロードする | ビルド環境とそのダウンローダー |
| 実行中のアプリケーションから HTTPS サービスを呼び出す | イメージの OS ストア、またはアプリケーション自身の信頼設定 |
エラーを、相手を検証しているプロセスまで追跡し、発行者、ホスト名、ハンドシェイクの段階を確認します。承認済みの検査サービスは、組織の CA で宛先証明書に署名することがあります。HTTPS プロキシのリスナーでの TLS 失敗は、自動的にそれを経由して到達した宛先証明書の失敗ではありません。プロキシの IP を入力しても、信頼の材料にはなりません。
承認済みの公開発行者の証明書を、該当するホスト、イメージ配布、またはアプリケーションが対応する仕組みでインストールします。Docker の CA ガイダンスはホストとコンテナのストアを扱っていますが、CentOS の手順は Debian や Windows にそのまま使えるものではありません。生成されたバンドルへの追記は更新で取り消されることがあり、Java アプリケーションや独自の CA 設定を持つ他のクライアントは OS のバンドルをまったく無視することがあります。
アプリケーションの信頼を永続させるには、変更を承認済みのイメージまたはアプリケーションの構成プロセスに組み込みます。実行中の 1 つのコンテナへの対話的な編集は、イメージから作成される次のコンテナには引き継がれません。
必要な公開の信頼証明書だけを承認された経路で配布します。CA の秘密鍵をイメージに入れず、未知の公開プロキシによるルート証明書のインストール要求を通常の設定として扱わないでください。目的のストアを設定した後も、ホスト名とチェーンの検証は有効なままにします。