AWS 자격 증명을 Docker 컨테이너에 전달하는 가장 좋은 방법은 무엇입니까?

Question

AmazonEC2에서 docker-container를 실행하고 있습니다. 현재 Dockerfile에 AWS 자격 증명을 추가했습니다. 이를 수행하는 가장 좋은 방법을 알려주시겠습니까?

P粉399585024 · Answer

Docker는 이 질문을 받은 이후로 많이 변경되었으므로 답변을 업데이트해 보겠습니다.

우선, 특히 이미 클라우드에서 실행 중인 컨테이너의 AWS 자격 증명의 경우 Vor에서 권장하는 과 같은 IAM 역할을 사용하는 것이 정말 좋은 선택입니다. 그렇게 할 수 있다면 그의 답변에 1 더하기 1을 추가하고 나머지는 건너뛰세요.

클라우드 외부에서 작업을 시작하거나 다양한 유형의 비밀이 있는 경우 권장하는 바는 두 가지 주요 위치에 비밀을 저장하는 것입니다.

환경 변수: 이러한 변수가 컨테이너에 정의되면 컨테이너 내의 모든 프로세스가 해당 변수에 액세스할 수 있고 /proc를 통해 볼 수 있으며, 애플리케이션은 환경을 stdout에 덤프하고 로그에 저장할 수 있습니다. 컨테이너를 검사하면 일반 텍스트로 나타납니다.
이미지 자체: 이미지는 많은 사용자가 가져오기 액세스 권한을 갖는 레지스트리로 푸시되는 경우가 많으며, 때로는 이미지를 가져오는 데 필요한 자격 증명 없이도 한 레이어에서 비밀을 삭제하더라도 다음과 같은 일반적인 Linux 유틸리티를 사용하여 이미지를 분해할 수 있습니다. tar 그리고 그 비밀은 이미지에 처음 추가된 단계부터 확인할 수 있습니다.

Docker 컨테이너의 비밀에는 어떤 다른 옵션이 있나요?

옵션 A: 이미지 빌드 중에만 이 키가 필요하고 빌드가 시작될 때까지 사용할 수 없으며 아직 BuildKit에 액세스할 수 없는 경우 다단계 빌드가 가장 나쁜 옵션입니다. 빌드의 초기 단계에 비밀을 추가하고 거기에서 사용한 다음 비밀 없이 해당 단계의 출력을 릴리스 단계에 복사하고 해당 릴리스 단계만 레지스트리 서버에 푸시할 수 있습니다. 비밀은 아직 빌드 서버의 이미지 캐시에 있기 때문에 최후의 수단으로만 사용하는 편입니다.

옵션 B: 빌드 중에 BuildKit 18.09 릴리스를 사용할 수 있는 경우 현재 단일 실행 라인에 대한 볼륨 마운트로 비밀 주입을 허용하는 실험적 기능이 있습니다. 마운트는 이미지 레이어에 기록되지 않으므로 공개 레지스트리 서버에 푸시되는 것에 대해 걱정하지 않고 빌드 중에 보안 비밀에 액세스할 수 있습니다. 생성된 Dockerfile은 다음과 같습니다.

으아악

18.09 이상의 명령을 사용하여 빌드할 수 있습니다. 예:

으아악

옵션 C: Swarm 모드나 기타 오케스트레이션 없이 단일 노드에서 실행하는 경우 자격 증명을 읽기 전용 볼륨으로 마운트할 수 있습니다. 이 자격 증명에 액세스하려면 docker 외부에서 동일한 자격 증명 파일에 액세스하는 것과 동일한 액세스가 필요하므로 docker가 없는 상황보다 더 좋거나 나쁘지 않습니다. 요점은 컨테이너를 검사하거나, 로그를 보거나, 이미지를 레지스트리 서버에 푸시할 때 이 파일의 내용이 표시되어서는 안 된다는 것입니다. 왜냐하면 각 경우에 파일이 볼륨 외부에 있기 때문입니다. 이를 위해서는 컨테이너 배포와 별도로 Docker 호스트에 자격 증명을 복사해야 합니다. (docker API에 대한 액세스는 호스트의 루트를 통해 이루어지고 루트는 모든 사용자의 파일을 볼 수 있으므로 해당 호스트에서 컨테이너를 실행할 수 있는 능력이 있는 사람은 누구나 귀하의 자격 증명을 볼 수 있습니다. 호스트에서 누구도 신뢰하지 않는 경우 루트 사용자라면 docker API 액세스 권한을 부여하지 마세요)

docker run의 경우 다음과 같습니다.

으아악

또는 문서 작성에 필요한 사항:

으아악

옵션 D: Swarm 모드 및 Kubernetes와 같은 오케스트레이션 도구를 사용하면 이제 볼륨보다 비밀에 대한 더 나은 지원이 제공됩니다. Swarm 모드를 사용하면 파일이 관리자 파일 시스템에서 암호화됩니다(비록 일반적으로 암호 해독 키도 있으므로 관리자가 암호 해독 키를 입력하지 않고도 관리자를 다시 시작할 수 있음). 게다가 비밀은 비밀이 필요한 작업자에게만 전송되며(해당 비밀로 컨테이너를 실행하기 위해) 디스크가 아닌 작업자의 메모리에만 저장되며 tmpfs를 사용하여 컨테이너에 파일로 주입됩니다. Swarm 외부 호스트의 사용자는 비밀을 자신의 컨테이너에 직접 탑재할 수 없습니다. 그러나 docker API에 대한 공개 액세스를 사용하면 노드에서 실행 중인 컨테이너에서 비밀을 추출할 수 있으므로 비밀에 액세스할 수 있는 사람이 다시 제한됩니다. API. Compose에서 이 비밀 주입은 다음과 같습니다:

으아악

docker swarm init for a single node, then follow the directions for adding additional nodes. You can create the secret externally with docker secret create aws_creds $HOME/.aws/credentials. And you deploy the compose file with docker stack deploy -c docker-compose.yml stack_name.

로 스웜 모드를 켤 수 있습니다.

저는 종종 다음 스크립트를 사용하여 비밀 버전을 관리합니다. https://github.com/sudo-bmitch/docker-config-update

옵션 E: 비밀 관리를 위한 다른 도구가 있습니다. 제가 가장 좋아하는 도구는 자동으로 만료되는 시간 제한이 있는 비밀을 생성할 수 있는 기능이 있는 Vault입니다. 그런 다음 각 애플리케이션은 비밀을 요청하기 위한 자체 토큰 세트를 가져오며, 이를 통해 Vault 서버에 도달할 수 있는 경우 시간이 제한된 비밀을 요청할 수 있습니다. 이렇게 하면 비밀이 네트워크에서 제거될 경우 비밀이 작동하지 않거나 빨리 만료되므로 위험이 줄어듭니다. Vault용 AWS 관련 기능은 https://www.vaultproject.io /docs/secrets/aws/index.html

에 문서화되어 있습니다.

P粉523625080 · Answer

가장 좋은 방법은 IAM 역할을 사용하고 자격 증명을 전혀 처리하지 않는 것입니다. (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html 참조)

자격 증명은 http://169.254.169.254.....에서 검색할 수 있습니다. 이는 개인 IP 주소이므로 EC2 인스턴스에서만 액세스할 수 있습니다.

모든 최신 AWS 클라이언트 라이브러리는 여기에서 자격 증명을 가져오고, 새로 고치고, 사용하는 방법을 "알고 있습니다". 따라서 대부분의 경우 이에 대해 알 필요조차 없습니다. 올바른 IAM 역할로 ec2를 실행하면 됩니다.

옵션으로 런타임에 환경 변수(예:

)로 전달할 수 있습니다docker run -e AWS_ACCESS_KEY_ID=xyz -e AWS_SECRET_ACCESS_KEY=aaa myimage

터미널에서 printenv를 실행하여 이러한 환경 변수에 액세스할 수 있습니다.