문제 설명:
docker를 사용하여 nginx와 haproxy(및 기타 컨테이너)를 실행하는 웹 서비스가 있습니다. 개인용 Docker 허브 레지스트리를 통해 이러한 Docker 이미지를 제공하고 싶기 때문에 각 고객이 자신의 인증서를 컨테이너(nginx 및 haproxy)에 마운트할 수 있도록 이미지에 TLS 인증서를 구축하고 싶지 않습니다.
haproxy 컨테이너를 보호하기 위해 루트 권한 없이 실행합니다(1000 이상의 포트는 docker-compose에서 1000 미만의 포트에 매핑됨). nginx 컨테이너는 공식 nginx 이미지를 기반으로 하므로 서비스가 시작될 때만 루트를 사용하고 이후 nginx 사용자로 변경됩니다.
컨테이너를 추가로 보호하기 위해 docker-remapping을 설정했습니다(기본 설정에 기본 Dockerremap 사용자 사용).
질문:
TLS 인증서 공개 및 개인 키는 사용자 "nobody"로 컨테이너에 설치되므로 haproxy 및 nginx 컨테이너는 루트가 아닌 다른 사용자를 사용하여 파일을 읽기 때문에 이러한 파일을 읽을 수 없습니다.
해결책(지금까지):
tls 파일을 읽을 수 있도록 만들 수 있습니다(예: 644). 작동하지만 끔찍할 정도로 안전하지 않은 솔루션입니다.
haproxy 이미지에서 했던 것처럼 자체 nginx 이미지를 구축하고 컨테이너 사용자를 없음 그룹에 추가하여 인증서 권한을 640으로 변경할 수 있습니다. 이것은 추악한 해킹입니다.
nginx 및 haproxy 컨테이너의 사용자와 동일한 uid를 사용하여 인증서 파일을 마운트할 수 있도록 도커 재매핑을 제거했습니다. 이는 docker-remapping의 보안이 상실되고 인증서 파일에 haproxy 및 nginx 컨테이너의 사용자와 동일한 uid가 필요함을 의미합니다.
설치 프로세스 중에(및 기본 이미지나 인증서 파일을 업데이트할 때) 고객 서버에 새 이미지를 빌드하고 개인 Docker 저장소의 기존 이미지를 기본 이미지로 사용합니다. 내 클라이언트 서버의 도커 빌드 파일은 매우 간단하며 올바른 권한을 사용하여 SSL 인증서 파일을 contsiners에 복사합니다.
질문:
마운트된 파일이 올바른 uid를 갖도록 호스트 uid를 컨테이너 내부의 사용자 uid에 매핑하는 방법이 있습니까?