Å tilføye en bedrifts-CA i en container retter ikke opp en mislykket image-henting hos en kollega. En vellykket henting viser heller ikke at applikasjonen i imaget stoler på den inspiserte HTTPS-tjenesten.

OperasjonTillit som må granskes
Hente et image gjennom organisasjonens inspeksjonsproxyMaskinen eller Docker-miljøet som utfører hentingen
Laste ned under bygging av et imageByggemiljøet og nedlastingsverktøyet
Kalle en HTTPS-tjeneste fra den kjørende applikasjonenImagets OS-lager eller applikasjonens eget tillitsoppsett

Følg feilen til prosessen som verifiserer motparten, og bekreft deretter utsteder, vertsnavn og trinnet i handshake. En autorisert inspeksjonstjeneste kan signere målsertifikatet med organisasjonens CA. TLS-svikt hos en HTTPS-proxylytter er ikke uten videre en svikt i målsertifikatet som nås gjennom den. Inntasting av proxyens IP gir ingen tillitsdata.

Installer det godkjente offentlige utstedersertifikatet via den støttede mekanismen til den aktuelle maskinen, imagedistribusjonen eller applikasjonen. Dockers CA-veiledning omfatter lager for maskin og container, men en CentOS-sti er ikke en overførbar instruks for Debian eller Windows. En tilføyelse til en generert pakke kan bli reversert av en oppdatering; en Java-applikasjon eller en annen klient med eget CA-oppsett kan se helt bort fra OS-pakken.

For varig tillit i applikasjonen må endringen inn i den godkjente prosessen for konfigurering av imaget eller applikasjonen. En interaktiv endring av én kjørende container vil ikke finnes i den neste containeren som lages fra imaget.

Distribuer bare det nødvendige offentlige tillitssertifikatet gjennom den autoriserte kanalen. Legg aldri en privat CA-nøkkel i et image, og behandle ikke en forespørsel om rotinstallasjon fra en ukjent offentlig proxy som vanlig oppsett. La vertsnavn- og kjedekontrollen være på etter at det tiltenkte lageret er konfigurert.

Relaterte artikler