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