At tilføje en virksomheds-CA inde i en container kan ikke rette en kollegas mislykkede image-hentning. En vellykket hentning beviser heller ikke, at applikationen inde i imaget stoler på den inspicerede HTTPS-tjeneste.

HandlingTillid, der skal undersøges
Hent et image gennem organisationens inspektionsproxyVærten eller Docker-miljøet, der udfører hentningen
Download under et image-buildBuild-miljøet og dets downloader
Kald en HTTPS-tjeneste fra den kørende applikationImagets OS-lager eller applikationens egen tillidskonfiguration

Spor fejlen til den proces, der verificerer modparten, og bekræft derefter udsteder, værtsnavn og handshake-trin. En autoriseret inspektionstjeneste kan signere destinationscertifikatet med organisationens CA. TLS-fejl ved en HTTPS-proxylytter er ikke automatisk en fejl i destinationscertifikatet, der nås gennem den. Indtastning af proxyens IP giver intet tillidsmateriale.

Installer det godkendte offentlige udsteder-certifikat via den relevante vært, imagedistribution eller applikations understøttede mekanisme. Dockers CA-vejledning dækker værtens og containerens lager, men en CentOS-sti er ikke en bærbar instruktion til Debian eller Windows. Tilføjelser til en genereret bundle kan annulleres af en opdatering; en Java-applikation eller en anden klient med sin egen CA-konfiguration kan helt ignorere OS-bundlen.

For vedvarende applikationstillid skal ændringen lægges i den godkendte image- eller applikationskonfigurationsproces. En interaktiv redigering af én kørende container vil mangle i den næste container, der oprettes ud fra imaget.

Distribuer kun det nødvendige offentlige tillidscertifikat gennem den autoriserede kanal. Læg aldrig en CA-privatnøgle i et image, og behandl en ukendt offentlig proxys anmodning om rodinstallation som almindelig opsætning. Hold værtsnavn- og kædeverifikation slået til, efter det tilsigtede lager er konfigureret.

Relaterede artikler