На якое сховішча Docker CA паказвае збой проксі?
Аддзяліце загрузкі вобразаў, спампаванні падчас зборкі і запыты праграмы кантэйнера пры даверы да паўнаважнага аглядальнага CA.
Даданне карпаратыўнага CA унутры кантэйнера не выправіць няўдалую загрузку вобраза ў калегі. Паспяховая загрузка таксама не даказвае, што праграма ўнутры вобраза давярае праверанай службе HTTPS.
| Аперацыя | Давер, які трэба даследаваць |
|---|---|
| Загрузка вобраза праз аглядальны проксі арганізацыі | Хост або асяроддзе Docker, якое выконвае загрузку |
| Спампаванне падчас зборкі вобраза | Асяроддзе зборкі і яго сродак спампоўвання |
| Зварот да службы HTTPS з працуючай праграмы | Сховішча АС вобраза або ўласная канфігурацыя даверу праграмы |
Прасочыце памылку да працэсу, які правярае суразмоўцу, затым пацвердзіце выдаўца, імя хоста і этап рукапаціску. Паўнаважная аглядальная служба можа падпісаць сертыфікат прызначэння CA арганізацыі. Збой TLS на слухачы проксі HTTPS не абавязкова з'яўляецца збоем сертыфіката прызначэння, дасягнутага праз яго. Увод IP проксі не дае ніякага матэрыялу даверу.
Усталюйце зацверджаны публічны сертыфікат выдаўца праз падтрыманы механізм адпаведнага хоста, распаўсюджвання вобраза або праграмы. Кіраўніцтва Docker па CA ахоплівае сховішчы хоста і кантэйнераў, але шлях CentOS не з'яўляецца пераноснай інструкцыяй для Debian або Windows. Даданне ў згенераваны набор можа быць адменена абнаўленнем; праграма Java або іншы кліент з уласнай канфігурацыяй CA можа цалкам ігнараваць набор АС.
Для пастаяннага даверу праграмы ўнясіце змену ў зацверджаны працэс канфігурацыі вобраза або праграмы. Інтэрактыўнае рэдагаванне аднаго працуючага кантэйнера будзе адсутнічаць у наступным кантэйнеры, створаным з вобраза.
Размяркоўвайце толькі патрэбны публічны сертыфікат даверу праз паўнаважны канал. Ніколі не змяшчайце прыватны ключ CA у вобраз і не ўспрымайце запыт невядомага публічнага проксі на ўсталёўку кораня як звычайную наладку. Пакіньце праверку імя хоста і ланцуга ўключанай пасля налады патрэбнага сховішча.