Na které úložiště CA v Dockeru ukazuje selhání proxy?
Oddělte stahování imageů, stahování při buildu a požadavky aplikace v kontejneru při důvěře v autorizovanou inspekční CA.
Přidání firemní CA uvnitř kontejneru neopraví neúspěšné stažení imageu u kolegy. Úspěšné stažení také nedokazuje, že aplikace uvnitř imageu důvěřuje inspektované službě HTTPS.
| Operace | Důvěra k prošetření |
|---|---|
| Stažení imageu přes inspekční proxy organizace | Hostitel nebo prostředí Dockeru, které stahování provádí |
| Stahování během buildu imageu | Prostředí buildu a jeho stahovací nástroj |
| Volání služby HTTPS z běžící aplikace | Úložiště OS imageu nebo vlastní konfigurace důvěry aplikace |
Vysledujte chybu k procesu, který ověřuje protistranu, a poté potvrďte vydavatele, název hostitele a fázi handshake. Autorizovaná inspekční služba může podepsat certifikát cíle firemní CA. Selhání TLS na listeneru HTTPS proxy není automaticky selháním cílového certifikátu dosaženého přes něj. Zadání IP adresy proxy neposkytuje žádný materiál důvěry.
Nainstalujte schválený veřejný certifikát vydavatele podporovaným mechanismem příslušného hostitele, distribuce imageu nebo aplikace. Pokyny Dockeru k CA pokrývají úložiště hostitele i kontejneru, ale cesta pro CentOS není přenosný pokyn pro Debian nebo Windows. Přidání do generovaného svazku může aktualizace zrušit; aplikace v Javě nebo jiný klient s vlastní konfigurací CA může svazek OS zcela ignorovat.
Pro trvalou důvěru aplikace vložte změnu do schváleného procesu konfigurace imageu nebo aplikace. Interaktivní úprava jednoho běžícího kontejneru nebude v dalším kontejneru vytvořeném z imageu.
Šiřte pouze požadovaný veřejný certifikát důvěry autorizovaným kanálem. Nikdy nevkládejte soukromý klíč CA do imageu a s požadavkem neznámé veřejné proxy na instalaci kořene nezacházejte jako s běžným nastavením. Po konfiguraci zamýšleného úložiště ponechte ověřování názvu hostitele a řetězce zapnuté.