Na katero shrambo CA v Dockerju kaže napaka proxyja?
Ločite pridobivanje podob, prenose med gradnjo in zahteve aplikacije v vsebniku, ko zaupate pooblaščeni pregledni CA.
Dodajanje podjetniške CA znotraj vsebnika ne more popraviti neuspešnega pridobivanja podobe pri sodelavcu. Uspešno pridobivanje tudi ne dokazuje, da aplikacija znotraj podobe zaupa pregledani storitvi HTTPS.
| Operacija | Zaupanje, ki ga je treba preveriti |
|---|---|
| Pridobivanje podobe prek preglednega proxyja organizacije | Gostitelj ali okolje Docker, ki izvaja pridobivanje |
| Prenos med gradnjo podobe | Okolje gradnje in njegov prenašalnik |
| Klic storitve HTTPS iz delujoče aplikacije | Shramba OS podobe ali lastna konfiguracija zaupanja aplikacije |
Sledite napaki do procesa, ki preverja drugo stran, nato potrdite izdajatelja, ime gostitelja in fazo rokovanja. Pooblaščena pregledna storitev lahko podpiše ciljno potrdilo s CA organizacije. Napaka TLS na poslušalcu proxyja HTTPS ni samodejno napaka ciljnega potrdila, doseženega prek njega. Vnos IP-ja proxyja ne daje nobenega gradiva zaupanja.
Namestite odobreno javno potrdilo izdajatelja prek podprtega mehanizma ustreznega gostitelja, distribucije podobe ali aplikacije. Dockerjeva navodila za CA pokrivajo shrambi gostitelja in vsebnika, vendar pot CentOS ni prenosljivo navodilo za Debian ali Windows. Dodatek ustvarjenemu paketu lahko posodobitev razveljavi; aplikacija Java ali drug odjemalec z lastno konfiguracijo CA lahko paket OS popolnoma prezre.
Za trajno zaupanje aplikacije vnesite spremembo v odobreni postopek konfiguracije podobe ali aplikacije. Interaktivno urejanje enega delujočega vsebnika ne bo prisotno v naslednjem vsebniku, ustvarjenem iz podobe.
Razširjajte samo zahtevano javno potrdilo zaupanja po pooblaščenem kanalu. Nikoli ne vstavite zasebnega ključa CA v podobo in ne obravnavajte zahteve neznanega javnega proxyja za namestitev korena kot običajne nastavitve. Po konfiguraciji želene shrambe pustite preverjanje imena gostitelja in verige vklopljeno.