프록시 실패는 어느 Docker CA 저장소를 가리키는가
승인된 검사 CA를 신뢰할 때 이미지 풀, 빌드 다운로드, 컨테이너 애플리케이션 요청을 구분합니다.
컨테이너 안에 회사 CA를 추가해도 동료의 이미지 풀 실패는 해결되지 않습니다. 풀이 성공해도 이미지 안의 애플리케이션이 검사된 HTTPS 서비스를 신뢰한다는 증거는 아닙니다.
| 작업 | 조사할 신뢰 |
|---|---|
| 조직의 검사 프록시를 통해 이미지 풀 | 풀을 수행하는 호스트 또는 Docker 환경 |
| 이미지 빌드 중 다운로드 | 빌드 환경과 그 다운로더 |
| 실행 중인 애플리케이션에서 HTTPS 서비스 호출 | 이미지의 OS 저장소 또는 애플리케이션 자체의 신뢰 구성 |
오류를 상대방을 검증하는 프로세스까지 추적한 뒤 발급자, 호스트 이름, 핸드셰이크 단계를 확인합니다. 승인된 검사 서비스는 조직의 CA로 목적지 인증서에 서명할 수 있습니다. HTTPS 프록시 리스너의 TLS 실패가 자동으로 그를 통해 도달한 목적지 인증서의 실패인 것은 아닙니다. 프록시 IP를 입력하는 것은 신뢰 자료를 제공하지 않습니다.
승인된 공개 발급자 인증서를 해당 호스트, 이미지 배포 또는 애플리케이션이 지원하는 방식으로 설치합니다. Docker의 CA 지침은 호스트와 컨테이너 저장소를 다루지만 CentOS 경로는 Debian이나 Windows로 옮길 수 있는 지침이 아닙니다. 생성된 번들에 추가한 내용은 업데이트로 취소될 수 있으며, Java 애플리케이션이나 자체 CA 구성을 가진 다른 클라이언트는 OS 번들을 완전히 무시할 수 있습니다.
애플리케이션 신뢰를 지속하려면 변경을 승인된 이미지 또는 애플리케이션 구성 프로세스에 넣으십시오. 실행 중인 컨테이너 하나를 대화식으로 편집한 내용은 이미지에서 만들어지는 다음 컨테이너에 없습니다.
필요한 공개 신뢰 인증서만 승인된 경로로 배포하십시오. CA 개인 키를 이미지에 넣지 말고, 알 수 없는 공개 프록시의 루트 설치 요청을 일반 설정으로 다루지 마십시오. 의도한 저장소를 구성한 후에도 호스트 이름과 체인 검증을 켜 두십시오.