Å leggje til ein bedrifts-CA inne i ein container kan ikkje rette ei mislukka image-henting hos ein kollega. Ei vellukka henting bevisar heller ikkje at applikasjonen inne i imaget stolar på den inspiserte HTTPS-tenesta.

HandlingTillit som skal undersøkjast
Hent eit image gjennom inspeksjonsproxyen til organisasjonenVerten eller Docker-miljøet som utfører hentinga
Last ned under ein image-buildBuild-miljøet og nedlastaren
Kall ei HTTPS-teneste frå den køyrande applikasjonenOS-lageret til imaget eller applikasjonen si eiga tillitskonfigurasjon

Spor feilen til prosessen som verifiserer motparten, og stadfest deretter utgivar, vertsnamn og handshake-steg. Ein autorisert inspeksjonsteneste kan signere målsertifikatet med CA-en til organisasjonen. TLS-feil ved ein HTTPS-proxylyttar er ikkje automatisk ein feil i målsertifikatet som ein når gjennom han. Å skrive inn proxy-IP-en gir ingen tillitsmateriale.

Installer det godkjende offentlege utgivarsertifikatet gjennom den støtta mekanismen til den aktuelle verten, imagedistribusjonen eller applikasjonen. CA-rettleiinga til Docker dekkjer lageret til verten og containeren, men ein CentOS-sti er ikkje ei overførbar instruks for Debian eller Windows. Eit tillegg til ein generert pakke kan bli omgjort av ei oppdatering; ein Java-applikasjon eller ein annan klient med eigen CA-konfigurasjon kan ignorere OS-pakken heilt.

For varig applikasjonstillit bør endringa leggjast i den godkjende konfigurasjonsprosessen for imaget eller applikasjonen. Ei interaktiv endring av ein køyrande container vil mangla i den neste containeren som blir laga frå imaget.

Distribuer berre det nødvendige offentlege tillitssertifikatet gjennom den autoriserte kanalen. Legg aldri ein privat CA-nøkkel i eit image, og handsam ikkje ein førespurnad om rotinstallasjon frå ein ukjend offentleg proxy som vanleg oppsett. Hald vertsnamn- og kjedeverifisering påslått etter at det tiltenkte lageret er konfigurert.

Relaterte artiklar