Å legge til en bedrifts-CA inne i en container kan ikke rette en kollegas mislykkede image-henting. En vellykket henting beviser heller ikke at applikasjonen inne i imaget stoler på den inspiserte HTTPS-tjenesten.

HandlingTillit som skal undersøkes
Hent et image gjennom organisasjonens inspeksjonsproxyVerten eller Docker-miljøet som utfører hentingen
Last ned under en image-buildBuild-miljøet og nedlasteren
Kall en HTTPS-tjeneste fra den kjørende applikasjonenImagets OS-lager eller applikasjonens egen tillitskonfigurasjon

Spor feilen til prosessen som verifiserer motparten, og bekreft deretter utsteder, vertsnavn og handshake-trinn. En autorisert inspeksjonstjeneste kan signere destinasjonssertifikatet med organisasjonens CA. TLS-feil ved en HTTPS-proxylytter er ikke automatisk en feil i destinasjonssertifikatet som nås gjennom den. Å taste inn proxyens IP gir ingen tillitsmateriale.

Installer det godkjente offentlige utstedersertifikatet gjennom den støttede mekanismen til den aktuelle verten, imagedistribusjonen eller applikasjonen. Dockers CA-veiledning dekker vertens og containerens lager, men en CentOS-sti er ikke en bærbar instruksjon for Debian eller Windows. Et tillegg til en generert pakke kan bli omgjort av en oppdatering; en Java-applikasjon eller en annen klient med egen CA-konfigurasjon kan ignorere OS-pakken helt.

For varig applikasjonstillit bør endringen legges i den godkjente konfigurasjonsprosessen for imaget eller applikasjonen. En interaktiv endring av én kjørende container vil mangle i den neste containeren som opprettes 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 ukjent offentlig proxys forespørsel om rotinstallasjon som vanlig oppsett. Hold vertsnavn- og kjedeverifisering påslått etter at det tiltenkte lageret er konfigurert.

Relaterte artikler