이미지 분석 소프트웨어를 실행하는 데 사용되는 기본 도커 이미지가 있습니다. 이미지에서 생성 된 각 컨테이너에는 처리 된 이미지를 분석하고 배포하기 위해 소프트웨어에서 사용하는 비밀 (암호화 키, 고객 정보 등) 인 구성 설정 세트가 있습니다. 이러한 비밀을 컨테이너에 안전하게 전달하려면 어떻게해야합니까?

도커 컨테이너 내부의 앱에 비밀을 얻는 세 가지 방법이 있습니다. 처음 2 개는 도커 구성과 관련이 있습니다. 마지막으로 앱이 비밀 저장소에서 비밀을 직접 가져 오도록하는 것입니다.

1-환경 변수

"The 12 Factor App"안내서 에 따르면 , 비밀은 단지 구성이며 항상 환경에서 설정해야합니다. 도커 실행 중에 비밀을 환경 변수로 설정할 수 있으며 앱이 거기에서 액세스합니다.

2-탑재 된 볼륨

비밀을 모두 특정 구성 / 비밀 파일 내에 보관 한 다음 마운트 된 볼륨으로 인스턴스에 마운트 할 수 있습니다 .

3-비밀 저장소에서 가져 오기

@ 030에서 언급했듯이 Hashicorp Vault (또는 "Amazon Secrets Manager"또는 이와 유사한 서비스)를 사용할 수 있습니다.
앱 또는 사이드카 앱은 Docker 컨테이너의 구성을 처리하지 않고도 필요한 비밀을 직접 가져올 수 있습니다. 이 방법을 사용하면 파일 시스템에서 볼 수 있거나 도커 컨테이너의 env 변수를 검사 할 때 비밀을 걱정할 필요없이 동적으로 생성 된 비밀 (이러한 시스템의 매우 매력적인 기능)을 사용할 수 있습니다.

개인적인 의견

나는 env 변수가 갈 길이라고 믿는다. 관리하기가 더 쉬우 며 Hashicorp Vault와 같은 시크릿 저장소에서 CI 빌드 시스템을 사용하는 경우 빌드 중에 시크릿을 가져와 배포시 설정할 수 있습니다. 두 가지 이점을 모두 누리고 비밀을 가져 오기 위해 응용 프로그램 코드를 작성할 필요가없는 개발자의 이점도 있습니다. 개발자는 암호 가져 오기와 같은 관리 작업을 처리하지 말고 코드 기능에 중점을 두어야합니다.

애플리케이션 코드는 자체 앱 기능 자체에 중점을 두어야하며 비밀번호 가져 오기와 같은 백엔드 작업을 처리하지 않아야합니다. 12 팩터 앱 상태와 같습니다.

편집 : Developer와 SysAdmin 사일로의 영향을 제거하기 위해 마지막 문장을 변경했습니다. 작업 자체는 코드 관점에서 분리되어야하지만 DevOps는 동일한 사람을 염두에두고 제한하지 않아야합니다.

개인 의견 (업데이트)

@ Dirk의 우수한 의견 ( 비밀을 Docker 컨테이너로 전달 )에 따르면 ENV vars보다 비밀 저장소를 유출하지 않기로 우선 순위를 매기는 매우 강력한 주장이 있습니다.

파이프를 사용하는 다른 옵션이 있습니다.

docker run -d -i --name $n alpine sh -c 'read A; echo "[$A]"; exec some-server'
docker exec -i $n sh -c 'cat > /proc/1/fd/0' <<< _a_secret_

먼저을 사용하여 docker 데몬을 만듭니다. -i명령 read A은 입력을 기다리는 동안 중단됩니다 /proc/1/fd/0. 그런 다음 두 번째 docker 명령을 실행하여 stdin에서 비밀을 읽고 마지막 중단 프로세스로 리디렉션하십시오.