In bedriuws-CA tafoegje yn in container kin in mislearre image-pull fan in kollega net reparearje. In slagge pull bewiist ek net dat de applikaasje yn it image de ynspektearre HTTPS-tsjinst fertrout.

BewurkingFertrouwen om te ûndersykjen
In image lûke fia de ynspeksje-proxy fan 'e organisaasjeDe host of Docker-omjouwing dy't de pull útfiert
Downloade by in image-buildDe build-omjouwing en har downloader
In HTTPS-tsjinst oanroppe fan 'e draaiende applikaasjeDe OS-opslach fan it image of de eigen fertrouwenskonfiguraasje fan 'e applikaasje

Folch de flater nei it proses dat de tsjinpartij ferifiearret, en befêstigje dan de útjower, hostnamme en handshake-faze. In autorisearre ynspeksjetsjinst kin it sertifikaat fan 'e bestimming mei de CA fan 'e organisaasje ûndertekenje. In TLS-flater by in HTTPS-proxy-listener is net automatysk in flater fan it bestimmingssertifikaat dat der troch berikt wurdt. It ynfieren fan it proxy-IP jout gjin fertrouwensmateriaal.

Ynstallearje it goedkarde iepenbiere útjowersertifikaat fia it stipe meganisme fan 'e oanbelangjende host, image-distribúsje of applikaasje. De CA-rigels fan Docker beslacht host- en containeropslaggen, mar in CentOS-paad is gjin oerdraachbere ynstruksje foar Debian of Windows. It tafoegjen oan in generearre bondel kin troch in update ûngedien makke wurde; in Java-applikaasje of in oare klant mei eigen CA-konfiguraasje kin de OS-bondel hielendal negearje.

Foar bliuwend applikaasjefertrouwen sette jo de feroaring yn it goedkarde image- of applikaasjekonfiguraasjeproses. In ynteraktive bewurking oan ien draaiende container sil ôfwêzich wêze yn 'e folgjende container dy't út it image makke wurdt.

Ferspriede allinnich it nedige iepenbiere fertrouwenssertifikaat fia it autorisearre kanaal. Pleats nea in CA-privekaai yn in image en behannelje it root-ynstallaasjeferzoek fan in ûnbekende iepenbiere proxy net as gewoane opset. Hâld hostnamme- en ketenferifikaasje ynskeakele neidat de bedoelde opslach konfigurearre is.

Relatearre artikelen