#6075가 당신에게 필요한 것을 줄 것인지 궁금합니다.

비밀 용기는 그것을 조금 더 안전하게 만들 수 있지만 언급된 모든 요점은 여전히 ​​유효합니다.

+1 이 기능도 유용하다고 생각합니다. 특히 예를 들어 개인 git repos에서 소프트웨어가 필요한 컨테이너를 빌드할 때. 나는 repo 키를 컨테이너에 공유할 필요가 없고 대신 "docker build ..."가 잠금 해제된 SSH 키에 액세스하기 위해 다른 방법을 사용하도록 하고 싶습니다. 아마도 실행 중인 ssh를 통해 -대리인.

+1. 저는 이제 막 도커에 젖기 시작했고 이것이 제가 부딪힌 첫 번째 장벽이었습니다. 도커가 빌드 중에 호스트 볼륨을 마운트할 수 없거나 마운트하지 않는다는 것을 깨닫기 전에 VOLUME을 사용하여 인증 양말을 마운트하는 데 시간을 보냈습니다.

암호가 없는 SSH 키의 복사본이 주변에 있는 것을 원하지 않고 하나를 컨테이너에 복사한 다음 빌드 중에 삭제하는 메커니즘이 잘못된 것처럼 느껴집니다. 나는 EC2 내에서 일하고 거기에 내 개인 키를 복사하는 것에 대해 기분이 좋지 않습니다(비밀번호가 있든 없든).

내 사용 사례는 철근으로 erlang 프로젝트를 구축하는 것입니다. 물론 첫 번째 리포지토리를 복제하고 Dockerfile을 사용하여 이미지에 추가할 수는 있지만 프로젝트에 있는 개인 종속성에서는 작동하지 않습니다. 호스트 시스템에서 프로젝트를 빌드하고 결과를 새 Docker 이미지에 추가할 수 있을 것 같지만 Docker라는 샌드박스에서 빌드하고 싶습니다.

다음은 동일한 사용 사례를 가진 다른 사람들입니다. https://twitter.com/damncabbage/status/453347012184784896

SSH_AUTH_SOCK을 수용하십시오. 매우 유용합니다.

감사 해요

편집: 이제 Docker 작동 방식(FS 계층)에 대해 더 많이 알게 되었으므로 빌드 중에 SSH 키를 추가하고 나중에 삭제하는 것과 관련하여 설명한 작업을 수행하는 것이 불가능합니다. 키는 일부 FS 계층에 여전히 존재합니다.

+1, SSH_AUTH_SOCK을 사용할 수 있다는 것은 매우 유용할 것입니다!

저는 SSH 키를 사용하여 프라이빗 리포지토리이든 퍼블릭 리포지토리이든 Github에 인증합니다.

이것은 내 git clone 명령이 git clone [email protected]:razic/my-repo.git 처럼 보인다는 것을 의미합니다.

docker run 동안 호스트 ~/.ssh 디렉토리를 컨테이너에 볼륨 마운트할 수 있으며 ssh 는 모두 정상입니다. 나는 그러나 탑재 할 수 없습니다 내 ~/.ssh 동안 docker build .

:+1: 빌드 중 ssh 전달용.

내가 이해하는 바와 같이 이것은 잘못된 방법입니다. 올바른 방법은 dev 시스템에서 도커 이미지를 만들고 도커 서버에 복사하는 것입니다.

@SevaUA - 정확하지 않습니다. 이 요청은 docker build... 수행할 때 제한 사항으로 인해 발생합니다. docker run ... 수행할 때와 같이 이 단계로 변수를 내보낼 수 없습니다. run 명령을 사용하면 실행하는 동안 변수를 도커 컨테이너로 내보낼 수 있지만 빌드에서는 허용하지 않습니다. 이 제한은 컨테이너를 빌드할 때 dockerd가 작동하는 방식에 따라 부분적으로 의도된 것입니다. 그러나 이 문제를 해결할 수 있는 방법이 있으며 설명된 사용 사례는 유효한 것입니다. 따라서 이 요청은 어떤 방식으로든 빌드에서 이 기능을 구현하려고 합니다.

나는 #6697(비밀 저장소/저장소)의 아이디어가 마음에 드는데, 일단 병합되면 이것이 작동할 수 있습니다. 그러나 그것이 작동하지 않으면 대안은 중간자 투명 프록시 ssh 작업을 수행하는 것입니다. 도커 데몬 외부에서 도커 데몬 트래픽을 가로챕니다(내부가 아님). 또는 모든 git+ssh 요청은 github 또는 궁극적으로 최종적으로 필요한 모든 것에 투명하게 프록시하는 로컬 정의 호스트에 대한 것일 수 있습니다.

그 아이디어는 이미 제기되었습니다(코멘트 2 참조). 문제가 해결되지 않습니다.

빌드 중 ssh 전달에 +1.

docker build 에서 SSH 에이전트 전달에 +1

npm install 또는 이와 유사한 것과 같은 빌드 중 ssh 전달의 경우 +1입니다.

OSX에서 실행하는 동안 ssh 포워딩이 작동하는 사람이 있습니까? 여기에 질문을 올렸습니다. http://stackoverflow.com/questions/27036936/using-ssh-agent-with-docker/27044586?noredirect=1#comment42633776_27044586 OSX에서는 불가능한 것 같습니다...

+1 =(

이 장애물도 누르십시오. 개인 저장소를 가리키는 npm install 를 실행하려고 합니다. 설정은 다음과 같습니다.
host -> vagrant -> docker ssh-agent forward host -> vagrant -! docker

+1
'도커 빌드' 중에 ssh 에이전트를 작동시키는 방법을 알아내려고 시도하는 동안 이것을 누르십시오.

+1 이전 사람들과 동일합니다. Docker 이미지를 빌드할 때 하나 이상의 개인 git 리포지토리(예 bundle install 및 npm install 생각)에 액세스해야 할 때 이 문제에 대한 최상의 솔루션인 것 같습니다.

도커를 실행하는 동안 호스트 ~/.ssh 디렉토리를 컨테이너에 볼륨 마운트할 수 있으며 ssh는 모두 정상입니다.

@razic 어떻게 작동하는지 공유할 수 있습니까? "나쁜 소유자 또는 권한"에 대해 불평하기 전에 시도했을 때

모든 컨테이너가 특정 사용자 또는 권한으로 실행되는지 확인하지 않는 한 그렇게 할 수 있습니까?

SSH_AUTH_SOCK에 +1

@tonivdv 는 이 문제에 대한 초기 의견 에서 docker run 명령을 살펴보십시오. 바인드는 SSH_AUTH_SOCK 가 참조하는 경로를 컨테이너 내부의 /tmp/ssh_auth_sock 마운트한 다음 컨테이너의 SSH_AUTH_SOCK 를 해당 경로로 설정합니다.

@md5 @razic 과 @tonivdv 가 -v ~/.ssh:/root/.ssh:ro 와 같은 마운트에 대해 이야기하고 있다고 가정하지만 이렇게 하면 .ssh 파일은 루트가 소유하지 않으므로 보안 검사에 실패합니다.

@KyleJamesWalker 네, 그게 제가 @razic 에서 이해한 @razic 을 읽었을 때 어떻게 작동하는지 궁금했습니다. :)

@tonivdv 가능한지 알고 싶습니다. 마지막으로 시도했을 때 아무 것도 찾을 수 없었습니다.

+1 Docker를 사용하여 일회용 개발 환경을 구축하는 데 관심이 있지만 제대로 작동하지 않습니다. 그런 면에서 많은 도움이 될 것입니다.

임시 솔루션을 찾는 사람을 위해 무차별 대입을 사용하는 수정 사항이 있습니다.

https://github.com/atrauzzi/docker-laravel/blob/master/images/php-cli/entrypoint.sh

전체 진입점 스크립트가 필요하기 때문에 바람직한 솔루션은 아니지만 작동합니다.

@atrauzzi 흥미로운 접근 방식입니다. dev env의 경우 기본 이미지를 빌드하고 ssh 키를 직접 복사합니다. 매번 실행할 때마다 제공할 필요가 없다는 장점이 있습니다. 그리고 기본적으로 해당 마법사에서 상속되는 모든 이미지에는 키도 있습니다. 그러나 우리의 방식으로는 분명히 공개적으로 공유할 수 없습니다 ;p

+1 이것은 좋을 것입니다

@tonivdv 스크립트의 대상 컨테이너는 CLI 도구의 호스트일 뿐이므로 자주 만들고 파괴합니다. 물론 한 번만 작업을 수행할 수 있습니다. 그러나 누군가가 설정을 변경하고 컨테이너를 통해 명령을 다시 실행하면 매번 새로운 복사본이 필요합니다.

@atrauzzi 알겠습니다 . 개인 SSH 키가 필요할 수 있는 도커 이미지에 접근 방식을 채택해야 합니다. 예를 들어, 작곡가 이미지는 개인 저장소의 경우 진입점 스크립트를 포함해야 합니다. 적어도 도커에 기본 솔루션이 제공될 때까지는.

:+1: 빌드를 통한 ssh 전달용

여기도 필수!

@atrauzzi 저는 현재 제가 정말 좋아하는 다른 접근 방식을 사용하고 있습니다. ssh 항목이 포함된 데이터 볼륨 컨테이너를 만들고 있습니다. 다른 컨테이너에 ssh 키를 사용하려는 경우 다음 명령으로 간단히 사용할 수 있습니다.

docker run -ti --volumes-from ssh-data ...

이렇게 하면 각 이미지에 진입점을 넣을 필요가 없으며 모든 이미지에서 작동할 수 있습니다.

해당 컨테이너를 만들려면 다음을 수행합니다.

docker run \
  --name ssh-data \
  -v /root/.ssh \
  -v ${USER_PRIVATE_KEY}:/root/.ssh/id_rsa \
  busybox \
  sh -c 'chown -R root:root ~/.ssh && chmod -R 400 ~/.ssh'

이것이 다른 사람들을 도울 수 있기를 바랍니다. :)

건배

@tonivdv - 누군가 SSH 설정을 추가하거나 업데이트해야 하는 경우 다시 가져와야 하기 때문에 접근 방식을 취했습니다. 내가 사용하는 특정 컨테이너는 단일 명령을 실행하도록 빌드된 컨테이너이므로 실행할 때마다 복사본을 사용하여 최신 상태인지 확인합니다.

@atrauzzi 네 알겠습니다 . 즉, ssh 볼륨 컨테이너를 올바르게 유지 관리하는 것은 사용자에게 달려 있습니다. 그는 필요한 경우 다른 것을 사용할 수도 있습니다. 그리고 선택적으로 스크립트를 사용하여 즉석에서 생성할 수 있습니다. 하지만 좋은 해결책은 하나뿐이라고 생각하지 않습니다. 그것은 모두 필요에 달려 있습니다. 다른 사람들이 필요에 따라 어떤 솔루션을 선택할 수 있도록 공유하고 싶었습니다. 이에 대해 곧 블로그에 올릴 수 있기를 바랍니다. 귀하의 솔루션도 전달해 드리겠습니다! 건배

나는 당신의 컨테이너를 실행하는 사람들이 ssh 키로 가득 찬 데이터 전용 컨테이너를 유지하는 것을 요구 사항으로 만들지 않을 것입니다. 관련된 것 같습니다.

@atrauzzi 볼륨 컨테이너가 반드시 있어야 하는 것은 사실이지만, 사용자가 실행 시 ssh 키를 공유해야 하는 방식이 너무 맞나요? 따라서 ssh 볼륨 컨테이너가 필요하다는 점 외에 실행 관점에서 두 솔루션의 유일한 차이점은 다음과 같습니다.

docker run ... --volumes-from ssh-data ... php-cli ...

그리고

docker run ... -v ~/.ssh:/path/.host-ssh ... php-cli ..

오른쪽? 아니면 다른 것을 놓치고 있습니까? :)

그러나 나는 당신이 당신의 방식으로 그것을하는 이유를 완전히 이해합니다. 그러나 예를 들어 다른 사람의 작곡가 이미지를 사용하려는 경우 볼륨 출처 방식이 기본적으로 작동합니다. 적어도 "진입점 해킹"으로 자신의 이미지를 만드는 것은 피합니다.

내가 말했듯이 둘 다 해결 방법이며 둘 다 장단점이 있습니다.

건배

Docker 팀에서 이 기능의 상태에 대한 업데이트를 받으면 정말 좋을 것입니다. 특히 docker build SSH 인증.

어느덧 1년이 다가오고 있습니다. 이에 대한 실제 사용 사례의 실용성을 고려할 때 다소 놀라운 일입니다. 현재 실행 중인 컨테이너를 커밋하여 이미지를 동적으로 생성하고 있습니다. 애플리케이션 저장소에 Dockerfile 가 있을 수 없습니다. 이것은 거의 모든 것에 대한 흐름을 깨뜨립니다. 이 문제가 해결될 때까지 Compose 또는 Swarm과 같은 Docker 서비스와 함께 내 애플리케이션을 사용할 수 없습니다.

업데이트는 정말 감사하겠습니다. 감사합니다.

/cc @페머

우리가 이 기능이나 그 밖의 것을 원하지 않는 것이 아닙니다. 빌드에서 이와 같은 것에 대한 사용 사례나 비밀을 실제로 보고 있습니다. 구현하려는 사람의 제안이 필요하고 제안의 구현이 승인되면 제안이 필요합니다.
또한 나는 모든 유지 보수가 아닌 나 자신을 대신하여 말합니다.

@jfrazelle

나는 너희들이 우리를 무시하지 않는다는 것을 알고 있습니다 :)

따라서 상태는 다음과 같습니다.

승인된 제안이 있는 경우 구현을 고려할 것입니다.
및 엔지니어링 대역폭.

이것이 당신에게 정확합니까?

또한 현재 이 문제를 해결하는 공개 제안이 있습니까?

2015년 4월 7일 화요일, Jessie Frazelle [email protected] 은 다음과 같이 썼습니다.

우리가 이 기능을 원하지 않는다는 것이 아니라
이와 같은 경우 또는 빌드의 비밀이 필요한 경우
구현하려는 사람의 제안 및 승인된 경우
제안의 구현.
또한 나는 모든 유지 보수가 아닌 나 자신을 대신하여 말합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment -90737847.

승인된 제안이 있는 경우 구현을 고려할 것입니다.
및 엔지니어링 대역폭.

네

그리고 이에 대한 공개 제안이 없다고 생각합니다.

2015년 4월 7일 화요일 오후 2:36 Zachary Adam Kaplan <
[email protected]>은 다음과 같이 썼습니다.

@jfrazelle

나는 너희들이 우리를 무시하지 않는다는 것을 알고 있습니다 :)

따라서 상태는 다음과 같습니다.

승인된 제안이 있는 경우 구현을 고려할 것입니다.
및 엔지니어링 대역폭.

이것이 당신에게 정확합니까?

또한 현재 이 문제를 해결하는 공개 제안이 있습니까?

2015년 4월 7일 화요일, Jessie Frazelle [email protected]
썼다:

우리가 이 기능을 원하지 않는다는 것이 아니라
이와 같은 경우 또는 빌드의 비밀이 필요한 경우
구현하려는 사람의 제안 및 승인된 경우
제안의 구현.
또한 나는 모든 유지 보수가 아닌 나 자신을 대신하여 말합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment -90737847.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment -90738913.

내가 일을 지나치게 단순화하고 있는지 모르겠지만 여기에 내 제안이 있습니다.

SSHAGENT: forward # 기본값은 무시

설정하면 빌드 중에 소켓 및 관련 환경 변수가 컨테이너에 연결되어 사용할 수 있습니다. 이것의 기계적 부분은 이미 존재하고 작동하고 있습니다. docker build 에 연결하기만 하면 됩니다.

도커 코드베이스 내에서 작업한 경험이 없지만 이 작업을 수행하는 것을 고려할 만큼 충분히 중요합니다.

엄청난. 제안서를 제출하는 방법은 어디에서 확인할 수 있습니까? 있습니까?
특정 지침 또는 문제를 열어야 합니까?

2015년 4월 7일 화요일, Jessie Frazelle [email protected] 은 다음과 같이 썼습니다.

허용되는 경우 구현을 고려할 것입니다.
제안
및 엔지니어링 대역폭.

네

그리고 이에 대한 공개 제안이 없다고 생각합니다.

2015년 4월 7일 화요일 오후 2:36 Zachary Adam Kaplan <
알림@github.com
<_e i="18">

@jfrazelle

나는 너희들이 우리를 무시하지 않는다는 것을 알고 있습니다 :)

따라서 상태는 다음과 같습니다.

허용되는 경우 구현을 고려할 것입니다.
제안
및 엔지니어링 대역폭.

이것이 당신에게 정확합니까?

또한 현재 이 문제를 해결하는 공개 제안이 있습니까?

2015년 4월 7일 화요일, Jessie Frazelle < [email protected]
<_ i="31"/>은(는) 다음과 같이 썼습니다.

우리가 이 기능을 원하지 않는다는 것이 아니라
사용
이와 같은 경우 또는 빌드의 비밀이 필요한 경우
구현하려는 사람의 제안 및 승인된 경우
제안의 구현.
또한 나는 모든 유지 보수가 아닌 나 자신을 대신하여 말합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment -90737847.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment -90738913.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment -90739596.

디자인 제안서처럼
https://docs.docker.com/project/advanced-contributing/#design - 제안

2015년 4월 7일 화요일 오후 2시 39분, Daniel Staudigel [email protected]
썼다:

내가 일을 지나치게 단순화하고 있는지 모르겠지만 여기에 내 제안이 있습니다.

SSHAGENT: forward # 기본값은 무시

설정하면 빌드 중에 소켓 및 관련 환경 변수가
컨테이너에 연결하여 사용할 수 있습니다. 기계 조각
이 중 이미 존재하고 작동 중입니다. 연결만 하면 됩니다.
도커 빌드에서.

도커 코드베이스 내에서 작업한 경험이 없지만 이것은
나는 그것을 취하는 것을 고려할 만큼 나에게 충분히 중요하다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment -90739803.

이것은 정말 높은 수준의 아이디어이지만 docker remote api를 통해 연결하는 대신 docker가 컨테이너 내부에서 번들된 ssh 데몬과 함께 init 데몬을 실행하면 어떻게 될까요?

이것은 여러 문제를 해결하는 데 사용할 수 있습니다.

• 이 데몬은 PID 1이고 기본 컨테이너 프로세스는 PID 2가 됩니다. 이렇게 하면 PID 1이 신호를 무시하고 컨테이너가 제대로 종료되지 않는 모든 문제가 해결됩니다. (#3793)
• 이렇게 하면 SSH 키 에이전트를 깔끔하게 전달할 수 있습니다. (#6396)
• 이 데몬은 네임스페이스를 열어둘 수 있습니다(#12035).
• TTY는 데몬에 의해 생성됩니다(#11462).
• ...그리고 아마도 내가 잊고 있는 수많은 다른 문제들.

https://github.com/docker/docker/issues/11529 에 대해 보고 싶을 수도 있습니다.
첫 번째 글머리 기호

2015년 4월 7일 화요일 오후 2:46 Patrick Hemmer [email protected]
썼다:

이것은 정말 높은 수준의 아이디어이지만
docker remote api, docker는 번들 ssh와 함께 init 데몬을 실행했습니다.
데몬, 컨테이너 내부?

이것은 여러 문제를 해결하는 데 사용할 수 있습니다.

• 이 데몬은 PID 1이고 기본 컨테이너 프로세스는
  PID 2. 이것은 PID 1이 신호를 무시하고
  컨테이너가 제대로 종료되지 않습니다. (#3793
  https://github.com/docker/docker/issues/3793)
• 이렇게 하면 SSH 키 에이전트를 깔끔하게 전달할 수 있습니다. (#6396
  https://github.com/docker/docker/issues/6396)
• 이 데몬은 네임스페이스를 열어둘 수 있습니다(#12035
  https://github.com/docker/docker/issues/12035)
• TTY는 데몬에 의해 생성됩니다(#11462
  https://github.com/docker/docker/issues/11462)
• ...그리고 아마도 내가 잊고 있는 수많은 다른 문제들.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment -90741192.

11529는 PID 1 문제와 완전히 관련이 없습니다.

복사 붙여 넣기를 쏴 이제 다른 것을 다시 찾아야합니다.

아니요, 그것은 PID 1 좀비 문제를 수정합니다. 이것은 내가 당신이 언급한 것이라고 생각했지만 그럼에도 불구하고 흥미로운 것이 전부이므로 게시하고 있었습니다.

@phemmer 구현을 위한 지능적인 제안을 하는 데 도움을 줄 수 있는 전문 지식이 있는 것 같습니다.

또한 @dts 처럼

@phemmer 및 @dts 더 쉬운 의사 소통을 위해 이 토론을 좀 더 실시간 채팅 클라이언트로 가져올 수 있는 가능한 방법이 있습니까? Slack, Google Chat/Hangout, IRC를 통해 연락할 수 있으며 필요한 경우 다른 모든 것을 다운로드하겠습니다.

@phemmer 구현을 위한 지능적인 제안을 하는 데 도움을 줄 수 있는 전문 지식이 있는 것 같습니다.

불행히도 실제로는 아닙니다 :-)
디자인 아이디어는 버릴 수 있지만 도커 코드 기반의 작은 부분만 알고 있습니다. 이러한 유형의 변화는 대규모일 가능성이 높습니다.

여기에 이미 몇 가지 제안이 있습니다.

@phemmer 제안

docker remote api를 통해 연결하는 대신 docker가 컨테이너 내부에서 번들된 ssh 데몬과 함께 init 데몬을 실행하면 어떻게 될까요?

@dts 제안

SSHAGENT: forward # 기본값은 무시
설정하면 빌드 중에 소켓 및 관련 환경 변수가 컨테이너에 연결되어 사용할 수 있습니다. 이것의 기계적 부분은 이미 존재하고 작동하고 있습니다. 도커 빌드에서 연결하기만 하면 됩니다.

@razic 제안

docker build 대한 볼륨 바인딩을 활성화합니다.

이 시점에서 우리에게 정말 필요한 것은 그 중 하나를 수락하여 작업을 시작할 수 있는 사람입니다.

@jfrazelle 다음 단계로 넘어가는 방법에 대한 아이디어가 있습니까? 정말로 나는 이것을 끝내려고 노력하고 있다. 이에 대한 관심이 많은 것은 분명합니다. 이 기능이 완성될 때까지 이 기능을 옹호할 용의가 있습니다.

나는 slack/irc/Gchat/etc 회의에 참석할 수 있습니다. 이것은 최소한 요구 사항을 수집하고 합리적인 행동 과정을 결정하는 데 조금 더 쉽게 만들 것이라고 생각합니다.

@dts 제안

SSHAGENT: forward # 기본값은 무시

이것은 구현이 아니라 소비 방법에 대한 아이디어일 뿐입니다. "init/ssh 데몬"은 구현 방법에 대한 아이디어입니다. 둘 다 존재할 수 있습니다.

@razic 제안

도커 실행을 위한 볼륨 바인딩을 활성화합니다.

불행히도 이것은 작동하지 않습니다. 이것이 이미 볼륨 마운트를 지원하는 docker run 아니라 docker build 의미한다고 가정하면 클라이언트가 원격일 수 있습니다(boot2docker가 대표적인 예임). 볼륨 바인드는 클라이언트가 도커 데몬과 동일한 호스트에 있을 때만 작동합니다.

@razic 디자인 제안에 대한 이 링크를 참조하세요... 제안이 아닙니다 https://docs.docker.com/project/advanced-contributing/#design -proposal

@페머

이것이 작동하지 않는 이유를 정확히 이해하지 못하고 있습니다. docker-compose 는 swarm 클러스터에 대한 볼륨 마운트와 함께 작동합니다. 파일/폴더가 호스트 시스템에 없으면 존재하지 않는 경로로 -v 를 실행한 것과 동일한 동작을 수행합니다.

@jfrazelle 알겠습니다.

파일/폴더가 호스트 시스템에 없으면 로컬 도커에 없는 경로로 -v를 실행한 것과 동일한 동작을 수행합니다.

나는 당신의 요점을 따랐는지 확신하지 못합니다. 그 행동이 이 문제에 어떻게 도움이 됩니까?
로컬 시스템에서 /tmp/ssh-UPg6h0 수신 대기하는 ssh 키 에이전트가 있고 원격 시스템에서 도커가 실행 중이고 docker build 호출하면 해당 로컬 ssh 키 에이전트에 액세스할 수 없습니다. 도커 데몬. 볼륨 마운트는 그것을 얻지 못하고 docker build 컨테이너는 ssh 키에 접근할 수 없습니다.

높은 수준에서 이 문제를 해결하는 방법은 두 가지뿐입니다.

1. ssh 키 에이전트 소켓을 프록시합니다.

도커 데몬은 컨테이너 내부에 유닉스 도메인 소켓을 만들고 무언가가 연결될 때마다 실제로 docker build 명령을 실행하는 클라이언트에 해당 연결을 다시 프록시합니다.

컨테이너 내부의 해당 유닉스 도메인 소켓에 대한 임의의 수의 연결이 있을 수 있으므로 구현하기 어려울 수 있습니다. 이는 도커 데몬 및 클라이언트가 임의의 수의 연결을 프록시해야 하거나 데몬이 ssh 에이전트 프로토콜을 말하고 요청을 다중화할 수 있어야 함을 의미합니다.

그러나 이제 도커 원격 API가 웹 소켓을 지원하므로(이 문제가 생성될 당시에는 지원하지 않았음), 그다지 어렵지 않을 수 있습니다.

2. 실제 SSH 데몬 시작

SSH 에이전트를 해킹하는 대신 클라이언트에서 컨테이너로 실제 ssh 연결을 사용합니다. 도커 클라이언트에는 ssh 클라이언트가 번들로 포함되거나 원격 컨테이너로 ssh 를 호출합니다.
이것은 컨테이너에 부착하는 방식을 대체할 것이기 때문에 훨씬 더 큰 규모의 변경이 될 것입니다. 그러나 도커가 이를 처리하고 표준 프로토콜로 마이그레이션해야 하는 부담도 덜어줍니다.
이것은 또한 다른 문제를 해결할 가능성이 있습니다( 여기에 언급됨).

따라서 궁극적으로 훨씬 더 큰 규모로 변경되지만 더 적절한 솔루션이 될 수 있습니다.
현실적으로는 규모 때문에 이런 일이 일어날지 의문이다.

@페머

나는 당신의 요점을 따랐는지 확신하지 못합니다. 그 행동이 이 문제에 어떻게 도움이 됩니까?

가장 일반적인 사용 사례는 SSH 인증이 필요한 프라이빗 리포지토리에서 호스팅되는 종속성이 있는 이미지를 구축하는 사람들이기 때문입니다.

SSH 키가 있는 시스템에서 이미지를 빌드합니다. 간단합니다.

내 로컬 시스템의 /tmp/ssh-UPg6h0에서 수신 대기하는 ssh 키 에이전트가 있고 원격 시스템에서 docker가 실행 중이고 docker build를 호출하는 경우 해당 로컬 ssh 키 에이전트는 docker 데몬에 액세스할 수 없습니다.

알아요. 무슨 상관이야? 인증 소켓에 액세스할 수 있는 시스템에서 docker build 를 실행하겠습니다.

내가 말하려는 것은.... docker-compose 를 사용 하면 파일이 실제로 호스트에 있는지 여부에 관계없이 swarm 클러스터에 대해 볼륨 명령을 사용할 수 있습니다 ! .

도커 빌드의 볼륨 마운트에 대해서도 동일한 작업을 수행해야 합니다.

| 파일이 시스템에 있음 | 액션 |
| :-- | :-- |
| 예 | 마운트 |
| 아니오 | 없음(실제로 마운트를 시도하지만 파일/폴더가 존재하지 않으면 빈 폴더를 생성합니다. docker run -v /DOES_NOT_EXIST:/DOES_NOT_EXIST ubuntu ls -la /DOES_NOT_EXIST 를 실행하여 확인할 수 있습니다) |

swarm 의 개념 중 하나는 다중 호스트 모델을 투명하게 만드는 것입니다.

원격 도커에 대해 생각하는 것은 좋지만 실제로는 중요하지 않습니다.

우리는 마운팅 볼륨의 동작을 복사해야합니다 docker build 우리가 할 똑같은 방법으로 docker run .

https://github.com/docker/compose/blob/master/SWARM.md에서 :

다중 컨테이너 앱이 Swarm에서 원활하게 작동하는 것을 막는 가장 중요한 것은 앱이 서로 통신하도록 하는 것입니다.

장기적으로 네트워킹은 다중 호스트 모델에 훨씬 더 잘 맞는 방식으로 정밀 검사를 받고 있습니다. 현재 연결된 컨테이너는 동일한 호스트에서 자동으로 예약됩니다.

@phemmer 나는 사람들이 당신이 설명한 문제에 대한 해결책에 대해 생각하고 있다고 생각합니다. 설명하는 문제는 별도의 https://github.com/docker/docker/issues/7249 와 같은 소리입니다.

내 접근 방식을 취하면: 도커 빌드에서 볼륨 마운트를 허용하면(마운트하려는 파일이 실제로 시스템에 있는지 여부에 관계없이 이 문제를 닫고 https://github.com/에서 작업을 시작할 수 있습니다.

@cpuguy83 제안서를 작성하기 전에 #7133을 보고 직접적으로 관련이 있는 것으로 나타났습니다.

여기에 몇 마디만 덧붙이실 수 있습니까? #7133은 실제로 docker build 에서 볼륨을 지원하도록 허용하는 이 문제를 수정하기 위한 제 제안과 관련이 있습니다.

@razic VOLUME /foo 실제로 볼륨을 생성하고 빌드 중에 컨테이너에 마운트한다는 사실과 관련이 있습니다. 이는 일반적으로 바람직하지 않습니다.

또한 파일을 빌드 컨테이너에 가져오기 위해 bind-mounts를 사용하는 것을 기반으로 하는 제안은 아마도 실행되지 않을 것이라고 말하고 싶습니다.
#6697 참조

docker build와 함께 -v를 실행하면 다른 코드 실행 경로가 있을 수 있습니다.
볼륨을 생성하고 빌드하는 동안 마운트하는 대신
dockerfiles의 볼륨이 참조되지 않는 현재 동작. 그리고
대신 CLI에 대한 인수를 사용하여 실행할 때 -v에서만 작동합니다.

2015년 4월 8일 수요일에 Brian Goff [email protected] 은 다음과 같이 썼습니다.

@razic https://github.com/razic VOLUME이라는 사실과 관련하여
/foo는 실제로 볼륨을 만들어 컨테이너에 마운트합니다.
일반적으로 바람직하지 않은 빌드입니다.

또한 bind-mounts를 사용하여 파일을
빌드 컨테이너는 아마도 날아가지 않을 것입니다.
참조 #6697 https://github.com/docker/docker/pull/6697

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment -90905722.

@ cpuguy83 설명

6697 또한 이미 닫혀 있고 #10310은 #6697의 속임수이기 때문에 비행하지 않을 것입니다.

+1, 저는 오늘 Bower를 사용하여 클라이언트 측 종속성을 설치하는 Rails 앱용 이미지를 빌드하는 동안 이것을 쳤습니다. 종속성 중 하나가 [email protected]:angular/bower-angular-i18n.git 가리키고 git이 거기에서 실패하기 때문에 bower가 실패하고 이미지 빌드도 실패합니다.

나는 방랑자가 하는 일을 정말 좋아합니다. Vagrantfile에 단일 forward_agent 구성을 사용하면 방랑자 게스트에 대해 이 문제가 해결됩니다. Docker가 이와 같은 것을 구현할 수 있습니까?

또한 추가 참고 사항으로 이것은 이미지를 빌드 하는 동안 발생합니다. 기존 해결 방법을 아는 사람이 있습니까?

내 해결 방법은 새 RSA 키 쌍을 생성하고 github에서 공개 키를 설정하고(지문 추가) 개인 키를 Docker 이미지에 추가하는 것이었습니다.

ADD keys/docker_rsa /srv/.ssh/id_rsa

나는 이것을 피하고 싶지만 현재로서는 이것이 용인될 수 있다고 생각합니다. 다른 제안을 주시면 감사하겠습니다!

누가 더 많은 강아지를 죽였는지는 확실하지 않습니다. 그렇게 하는 당신, 또는 아직 더 나은 방법을 제공하지 않는 Docker.

어쨌든 이번 주말에 제안서를 제출할 예정입니다. @cpuguy83 사람들이 적어도 이것에 대해 생각하고 가능한 솔루션에 대해 논의하고 있다는 것이 맞습니다. 따라서 이 시점에서 우리가 무언가에 동의하고 누군가가 작업하도록 하는 문제입니다. 실제로 현재 Docker에 대한 가장 큰 불만 중 하나이기 때문에 작업을 완전히 중단했습니다.

@razic 상당히 일반적인 사용 사례이므로 이에

@fullofcaffeine Docker가 내부적으로 어떻게 작동하는지 100% 확신할 수 없지만 단일 RUN 명령(해결 방법으로는 불가능)으로 완료되지 않는 한 이미지의 기록이 SSH 키를 유지 관리한다고 생각합니다.

@ 아주 좋은 지적입니다.

이 제한 사항을 해결하기 위해 로컬 HTTP 서버에서 개인 키를 다운로드하고 키가 필요한 명령을 실행하고 나중에 키를 삭제하는 아이디어를 가지고 놀았습니다.

이 모든 작업을 단일 RUN 에서 수행하기 때문에 이미지에 아무 것도 캐시되지 않습니다. Dockerfile에서 보이는 방법은 다음과 같습니다.

RUN ONVAULT npm install --unsafe-perm

이 개념에 대한 첫 번째 구현은 https://github.com/dockito/vault 에서 사용할 수 있습니다.

유일한 단점은 실행 중인 HTTP 서버가 필요하므로 Docker 허브가 빌드되지 않는다는 것입니다.

당신이 무슨 생각을하는지 제게 알려주세요 :)

+1
이것이 구현되는 것을 보고 싶습니다. 개발 환경을 위한 컨테이너를 설정하는 데 도움이 될 것입니다.

+1, boot2dock과 함께 전달된 ssh-agent가 필요합니다.

이 제한을 해결하기 위해 3단계 프로세스를 완료했습니다.

1. SSH 필수 종속성 없이 도커 컨테이너 빌드, 최종 단계에서 소스 추가
2. 공유 볼륨을 통해 소스를 마운트하고 공유 볼륨을 통해 SSH_AUTH_SOCK를 마운트하고 빌드 단계를 실행하여 ssh가 필요한 출력(예: github에서 호스팅하는 ruby ​​gems)을 공유 볼륨에 다시 씁니다.
3. gem이 이제 소스 디렉토리에 있기 때문에 소스 추가를 다시 트리거하는 docker 빌드를 다시 실행합니다.

결과는 SSH 키가 없는 SSH 인증을 통해 가져온 종속성이 있는 도커 이미지입니다.

최소한의 번거로움으로 OSX의 boot2docker 환경에서 docker run 에 대한 ssh 에이전트 전달을 활성화하는 스크립트를 만들었습니다. 빌드 문제를 해결하지 못한다는 것을 알고 있지만 일부 사용자에게는 유용할 수 있습니다.

https://gist.github.com/rcoup/53e8dee9f5ea27a51855

Forward ssh 키 에이전트는 Amazon EC 2 Container 서비스와 같은 서비스와 함께 작동합니까? 이를 위해서는 컨테이너를 배포하는 데 사용하는 모든 플랫폼 또는 PaaS에서 사용할 수 없는 특정 소프트웨어가 필요할 것 같습니다.

보다 포괄적이고 모두를 위한 솔루션이 필요합니다.

현재 환경 변수를 사용하고 있습니다. bash 스크립트는 개인 키(및 알려진 호스트) 변수를 가져와 id_rsa 및 known_hosts 파일에 인쇄합니다. 작동하지만 아직 그러한 솔루션의 보안 영향을 평가하지 않았습니다.

FWIW, 컨테이너화된 ssh-agent 및 볼륨 공유가 최소한의 구피로 잘 작동한다는 것을 발견했습니다.

https://github.com/whilp/ssh-agent

그러나 이에 대한 일급 지원이 있으면 좋을 것입니다.

_run_ 대 _build_에서 작동하는 것을 구별하는 것이 중요합니다. @whilp 의 솔루션은 _run_에서 훌륭하게 작동하지만 _build_ 동안 다른 도커의 볼륨에 액세스할 수 없기 때문에 _build_에서는 작동하지 않습니다. 따라서 이 티켓이 여전히 아프고 상처가 있는 이유입니다.

@rvowles 네, 동의합니다. 나는 일련의 실행/커밋 호출을 통해 컨테이너를 생성하기 위해 무언가를 모았습니다(예: Dockerfile 없이). 내 특정 사용 사례에 적합하지만 에이전트 전달과 같은 일반화된 지원(빌드 시간 포함)은 매우 도움이 될 것입니다.

빌드하는 동안 컨테이너를 실행하기 위한 IP가 /etc/hosts에 포함되어 있습니까? 그렇다면 한 가지 솔루션은 키를 제공하는 컨테이너를 시작한 다음 빌드 중에 컬링하는 것입니다.

내가 docker build 동안 SSH 에이전트를 사용하는 방법에 대해 블로그를 작성했다는 사실에 관심이 있을 것입니다. - http://aidanhs.com/blog/post/2015-10-07-dockerfiles-reproducibility- 속임수/#_streamlining_your_experience_using_an_ssh_agent

단일 컨테이너를 시작하기만 하면 됩니다. SSH 에이전트 액세스가 시작되면 Dockerfile에 3줄만 추가하면 완벽하게 작동합니다. 더 이상 키를 컨테이너에 노출할 필요가 없습니다.

몇 가지 주의 사항: Docker >= 1.8이 필요하며 Docker Hub 자동화 빌드에서는 작동하지 않습니다(분명히). 보안에 관한 주의사항도 읽어주세요! 문제가 있는 경우 게시물에 링크된 sshagent github 저장소에서 자유롭게 문제를 제기하세요.

또한 @aidanhs 와 유사한 방식으로 이 문제를 해결했습니다. 로컬 도커 서브넷을 통해 필요한 비밀을 가져온 다음 파일 시스템 스냅샷이 발생하기 전에 이를 제거합니다. 실행 중인 컨테이너는 브로드캐스트 UDP를 사용하여 클라이언트가 발견한 비밀을 제공합니다.
https://github.com/mdsol/docker-ssh-exec

이를 가능하게 하는 진전이 있었습니까? 권한과 소유권이 엉망이기 때문에 호스트의 ~/.ssh 디렉토리를 바인딩 마운트할 수 없습니다.

바인드 마운트가 특정 uid/gid 및 권한을 강제로 적용하도록 허용하면 이 문제를 해결할 수 없습니까?

@atrauzzi bind-mounts는 uid/gid/permissions를 강제할 수 없습니다.
FUSE(예: bindfs)를 통해 이 작업을 수행할 수 있지만 일반 바인드 마운트로는 불가능합니다.

@cpuguy83 정말 내가 처리하고 싶지 않은 길로 나를 데려가기 시작합니다. 특히 Windows 기반 호스트를 사용할 때.

여기에 사용자 친화적 인 옵션이 없습니까? 여기에서 문제가 발생하고 있는 것처럼 느껴집니다.

@atrauzzi 사실, 단기간에 풀기 쉬운 문제가 아닙니다(어쨌든

+1 이것은 간단한 Node.js 앱 Dockerfile에 대한 큰 차단기입니다. 저는 많은 Node 앱에서 작업했으며 NPM 종속성으로 개인 Github 리포지토리가 없는 앱은 거의 본 적이 없습니다.

@apeace 해결 방법으로 git repo에 git 하위 모듈로 추가할 수 있습니다. 그렇게 하면 컨텍스트에 있고 빌드 중에 추가할 수 있습니다. 정말 깔끔하게 삭제하려면 각 파일에서 .git 파일을 삭제하거나 무시하십시오. 도커 빌드에서는 로컬 디렉토리를 사용하여 설치할 수 있습니다. 어떤 이유로 완전한 git repos가 필요한 경우 .git 파일이 도커 빌드에 없는지 확인하고 .git/modules/<repo> 를 <path>/<repo>/.git . 그렇게 하면 복제된 것처럼 정상적인 리포지토리인지 확인합니다.

@jakirkham의 제안에 감사드립니다. 하지만 우리는 너무 오랫동안 개인 npm install 워크플로를 깨고 싶지 않습니다.

현재로서는 작동하지만 엉뚱한 솔루션이 있습니다. 우리는 다음을 가지고 있습니다:

• NPM 종속성으로 사용하는 저장소에 대한 읽기 전용 액세스 권한이 있는 Github 사용자 및 팀을 만들었습니다.
• Dockerfile이 있는 저장소에 해당 사용자의 개인 키를 커밋했습니다.
• Dockerfile에서 RUN npm install 대신 RUN GIT_SSH='/code/.docker/git_ssh.sh' npm install

여기서 git_ssh.sh 는 다음과 같은 스크립트입니다.

#!/bin/sh
ssh -o StrictHostKeyChecking=no -i /code/.docker/deploy_rsa "$@"

그것은 작동하지만 ssh 키 에이전트를 전달하는 것이 훨씬 더 좋고 설정 작업이 훨씬 적습니다!

:+1:
사람들이 빌드 시간 동안 개인 저장소에서 액세스해야 하는 많은 사용 사례가 있기 때문에 이 기능 요청이 여전히 구현되지 않았다는 사실을 믿을 수 없습니다.

개인 리포지토리에 액세스해야 하는 다양한 임베디드 시스템 개발 환경을 위한 컨테이너를 구축하려고 합니다. 호스트 ssh 키에 대한 지원을 추가하면 훌륭한 기능이 될 것입니다. SO 및 기타 페이지에서 가장 많이 사용되는 방법은 안전하지 않으며 개인 키가 있는 이 기능 레이어에 대한 지원이 없는 한 널리 퍼질 것입니다.

:+1:

:+1: 이것이 영원히 필요했습니다.

안녕하세요 @apeace님 ,

스크립트와 웹 서버의 조합입니다. https://github.com/dockito/vault 어떻게 생각

@pirelenito 는 키를 빌드 레이어 내에서 계속 사용할 수 있게 하지 않습니까? 만약 그렇다면, Dockito Valut를 빌드 프로세스에 추가하는 것은 우리에게 가치가 없습니다. 우리가 지금 하고 있는 것처럼 '젠키'한 것처럼 보입니다. 제안 감사합니다!

@apeace ONVAULT 스크립트는 키를 다운로드하고 명령을 실행한 다음 즉시 키를 삭제합니다. 이 모든 것이 동일한 명령에서 발생하므로 최종 레이어에는 키가 포함되지 않습니다.

@apeace Medidata에서는 docker-ssh-exec 라는 작은 도구를 사용하고 있습니다. 결과 빌드 이미지에 docker-ssh-exec 바이너리만 남게 됩니다. 비밀은 없습니다. 그리고 Dockerfile 대해 한 단어만 변경하면 되므로 매우 "적은 공간"입니다.

그러나 _정말__ docker-native-only 솔루션을 사용해야 하는 경우 회사 블로그 게시물에 설명 된 대로 이제 이를 수행할 수 있는 기본 제공 방법이 있습니다. Docker 1.9에서는 --build-arg 매개변수를 사용하여 임시 값을 빌드 프로세스에 전달할 수 있습니다. 개인 SSH 키를 ARG 로 전달하고 파일 시스템에 쓰고 git checkout 수행한 다음 _delete_ 키를 모두 RUN 범위 내에서 할 수 있어야 합니다. docker-ssh-exec 클라이언트가 하는 일입니다). 이것은 보기 흉한 Dockerfile 을 만들지만 외부 도구가 필요하지 않습니다.

도움이 되었기를 바랍니다.

@benton 우리는 비슷한 해결책을 생각해 냈습니다. :)

@pirelenito 와 @benton 에게 감사드립니다. 모든 제안을 확인하겠습니다!

편집 : 다음은 실제로 _NOT_ 안전합니다.

기록을 위해 다음은 결과 이미지에 SSH 키를 남기지 않고 Github에서 비공개 리포지토리를 확인하는 방법입니다.

먼저 다음 Dockerfile user/repo-name 에서 [email protected] 접두사를 유지해야 함).

FROM ubuntu:latest

ARG SSH_KEY
ENV MY_REPO [email protected]:user/repo-name.git

RUN apt-get update && apt-get -y install openssh-client git-core &&\
    mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
    ssh-keyscan github.com >/root/.ssh/known_hosts

RUN echo "$SSH_KEY" >/root/.ssh/id_rsa &&\
    chmod 0600 /root/.ssh/id_rsa &&\
    git clone "${MY_REPO}" &&\
    rm -f /root/.ssh/id_rsa

그런 다음 명령으로 빌드하십시오.

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

개인 SSH 키에 대한 올바른 경로를 전달합니다.

^ 도커 1.9 사용

@benton docker inspect sshtest 및 docker history sshtest 의 출력을 자세히 살펴보고 싶을 수 있습니다. 컨테이너 컨텍스트 자체 내에서 사용할 수 없는 경우에도 최종 이미지의 메타데이터에 비밀이 있다는 것을 알게 될 것이라고 생각합니다...

@ljrittle 좋은 발견. VAR 를 사용하면 키가 실제로 있습니다. 여기에는 여전히 외부 해결 방법이 필요한 것 같습니다.

기본 솔루션이 아직 개발되지 않은 한 가지 이유는 아마도 여러 가지 해결 방법이 _적용되기 때문일 것입니다. 그러나 내장 솔루션이 사용자에게 더 나은 서비스를 제공하고 Docker의 "배터리 포함" 철학에 부합한다는 대부분의 다른 의견에 동의합니다.

문서에서...

참고: github 키, 사용자 자격 증명 등과 같은 비밀을 전달하기 위해 빌드 시간 변수를 사용하는 것은 권장하지 않습니다.

( https://docs.docker.com/engine/reference/builder/#arg )

파일 경로가 여기에 적용되지 않는다고 생각합니다. 참고 사항은 콘솔 로그에 일반 암호/토큰을 볼 수 있도록 하는 것입니다.

@jcrombez를 팔로우하지 않습니다. 예제는 ARG 를 통해 ssh 키를 변수로 전달하는 것입니다. 따라서 적용됩니다.

보안 위험 측면에서 이것은 매우 다릅니다.

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

이것보다 :

docker build --tag=sshtest --build-arg SSH_KEY="mykeyisthis" .

누군가가 터미널 로그를 찾은 경우 결과는 동일하지 않습니다.
하지만 저는 보안 전문가가 아닙니다. 이것은 제가 알지 못하는 다른 이유로 여전히 위험할 수 있습니다.

커맨드 라인에서, 나는 가정한다.

그러나 @ljrittle이 지적하고 @benton이 인정한 --build-arg / ARG 를 사용하는 모든 방법은 빌드에서 커밋됩니다. 따라서 이를 검사하면 키에 대한 정보가 드러납니다. 둘 다 최종 도커 컨테이너에 상태를 남기고 둘 다 그 끝에서 동일한 취약성을 겪습니다. 따라서 docker가 이 작업을 권장하지 않는 이유는 무엇입니까?

_USER POLL_

_업데이트 알림을 받는 가장 좋은 방법은 이 페이지의 _구독_ 버튼을 사용하는 것입니다._

문제에 대해 "+1" 또는 "나도 있습니다" 댓글을 사용하지 마십시오. 우리는 자동으로
스레드를 짧게 유지하려면 해당 주석을 수집하십시오.

아래 나열된 사람들이 +1 댓글을 남겨 이 문제에 찬성했습니다.

@fletcher91
@benlemasurier
@dmuso
@probepark
@saada
@ianAndrewClark
@jakirkham
@galindro
@luisguilherme
@akurkin
@allardhoeve
@SevaUA
@sankethkatta
@kouk
@cliffxuan
@kotlas92
@taion

_USER POLL_

_업데이트 알림을 받는 가장 좋은 방법은 이 페이지의 _구독_ 버튼을 사용하는 것입니다._

문제에 대해 "+1" 또는 "나도 있습니다" 댓글을 사용하지 마십시오. 우리는 자동으로
스레드를 짧게 유지하려면 해당 주석을 수집하십시오.

아래 나열된 사람들이 +1 댓글을 남겨 이 문제에 찬성했습니다.

@parknicker
@dursk
@adambiggs

보안 위험 측면에서 이것은 매우 다릅니다.

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

bash 기록을 제외하고는 완전히 동일합니다. 그 정보가 끝날 수 있는 곳이 많이 있습니다.

예를 들어, API 요청이 서버에 기록될 수 있다고 생각해 보십시오.

다음은 docker build --tag=sshtest --build-arg SSH_KEY="fooobar" . 대한 데몬 로그입니다.

DEBU[0090] Calling POST /v1.22/build
DEBU[0090] POST /v1.22/build?buildargs=%7B%22SSH_KEY%22%3A%22fooobar%22%7D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&memory=0&memswap=0&rm=1&shmsize=0&t=sshtest&ulimits=null
DEBU[0090] [BUILDER] Cache miss: &{[/bin/sh -c #(nop) ARG SSH_KEY]}
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] Skipping excluded path: .wh..wh.aufs
DEBU[0090] Skipping excluded path: .wh..wh.orph
DEBU[0090] Applied tar sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef to 91f79150f57d6945351b21c9d5519809e2d1584fd6e29a75349b5f1fe257777e, size: 0
INFO[0090] Layer sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef cleaned up

_USER POLL_

_업데이트 알림을 받는 가장 좋은 방법은 이 페이지의 _구독_ 버튼을 사용하는 것입니다._

문제에 대해 "+1" 또는 "나도 있습니다" 댓글을 사용하지 마십시오. 우리는 자동으로
스레드를 짧게 유지하려면 해당 주석을 수집하십시오.

아래 나열된 사람들이 +1 댓글을 남겨 이 문제에 찬성했습니다.

@cj2

간단한 루비/랙 응용 프로그램을 컨테이너화하려고 합니다. Gemfile은 여러 개인 gem을 참조합니다. bundle install 시작되고 개인 저장소에 액세스하려고 하는 순간 이 오류가 발생하기 시작합니다.

Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

나는 그것을 해결할 수 있었지만 내 개인 키를 노출시키지 않고는 불가능했습니다. 그렇게 하지 않을 것입니다. SSH 인증 전달을 활성화하십시오.

빌드 중 ssh 전달에 +1. go get 때문에 private repos와 함께 사용할 수 없습니다 ;(

안전한 방식으로 이 사용 사례를 활성화하기 위해 +1

_USER POLL_

_업데이트 알림을 받는 가장 좋은 방법은 이 페이지의 _구독_ 버튼을 사용하는 것입니다._

문제에 대해 "+1" 또는 "나도 있습니다" 댓글을 사용하지 마십시오. 우리는 자동으로
스레드를 짧게 유지하려면 해당 주석을 수집하십시오.

아래 나열된 사람들이 +1 댓글을 남겨 이 문제에 찬성했습니다.

@lukad

이 매우 흥미로운 토론을 읽으면서 간단한 솔루션으로 이러한 문제를 해결할 수 있는지 궁금합니다. 내 머리 꼭대기에서 나는 스냅 샷을 찍을 때 특정 내부 디렉토리 / 파일을 제외 / 무시할 수있는 Dockerfile의 옵션을 생각하고 있습니다. 얼마나 어려울 수 있습니까?

즉

.ssh 제외

나는 그것이 뒤따르는 모든 단계에 적용될 것이라고 생각하므로 FROM 다음에 배치하면 원하는 만큼 키를 추가하고 정상적으로 빌드할 수 있으며 키가 실수로 이미지에서 끝나는 것에 대해 걱정할 필요가 없습니다(허용됨 필요한 모든 단계에서 추가해야 할 수도 있지만 이미지로 끝나는 것에 대해 걱정할 필요는 없습니다)

@benton 의 제안은 잘 작동하며 도커 데몬은 디버그 모드에 있는 경우에만 id_rsa 키를 기록합니다.

빌드 중에 키를 노출하는 더 귀여운 방법은 다음과 같습니다.

# Dockerfile
ARG SSH_KEY
RUN eval `ssh-agent -s` > /dev/null \
    && echo "$SSH_KEY" | ssh-add - \
    && git clone [email protected]:private/repository.git

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" .

하, docker inspect my_tag 를 보면 정말 그냥 거기에 앉아 있는 것 같지만 .. ENV보다 약간 깔끔하다는 점 외에는 boot-arg의 실제 가치가 무엇인지 잘 모르겠습니다.

그리고 id_rsa 키에 암호가 있는 경우 나쁜 사람이 될 수 있으며 다음을 수행합니다.

# Dockerfile
ARG SSH_KEY
ARG SSH_PASS
RUN eval `ssh-agent -s` > /dev/null \
    && echo "echo $SSH_PASS" > /tmp/echo_ps && chmod 700 /tmp/echo_ps \
    && echo "$SSH_KEY" | SSH_ASKPASS=/tmp/echo_ps DISPLAY= ssh-add - \
    && git clone [email protected]:private/repository.git
    && rm /tmp/echo_ps

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" --build-arg SSH_PASS=<bad_idea> .

물론 멀리 떨어져 있어도 좋은 생각이라고 합리화하기는 어렵습니다. 그러나 우리는 모두 인간입니다.

물론 이렇게 하는 가장 큰 이유는 빌드 중에 개인 리포지토리에 대해 "번들 설치" 또는 "가져오기"를 수행하는 사람들 때문인 것 같습니다.

나는 당신의 의존성을 공급하고 전체 프로젝트를 추가한다고 말하고 싶지만 때로는 일을 지금 끝내야합니다.

@SvenDowideit @thaJeztah 이 문제에 대한 해결책이 있습니까? 스레드를 따라가려고 했지만 다른 스레드를 닫았다가 여는 사이에 Docker 팀이 언제, 무엇을 할 것인지에 대한 많은 의견이 있습니다.

최고지만 구현이 필요합니까?

Docker 빌드는 빌드 내에서 ssh-agent를 사용하여 호스트의 ssh에 프록시한 다음 키를 알 필요 없이 키를 사용합니다!

ssh-agent 프록시에 대해 막 배우는 사람을 위해: github를 구출하기

@phemmer 의 독창적인 아이디어.

@yordis 아직 무료로 사용할 수 있는 스레드에 "훌륭한" 솔루션이 없다고 생각합니다.

docker/docker-py#980의 이 주석은 ssh 키를 호스트 시스템의 루트 사용자 키 디렉토리에 복사하면 데몬이 해당 키를 사용한다는 것을 나타내는 것 같습니다. 그러나 나는 이와 관련하여 미친 초보자이므로 다른 사람이 명확히 할 수 있습니다.

좋아, 하지만 최고는 아니야

docker 1.8의 빌드 인수로 키를 전달합니다.
주의 사항 .

확실히 나쁜 아이디어

많은 사람들이 여기에서 임시로 빌드 컨텍스트에 키를 추가한 다음 빠르게 제거할 것을 권장했습니다. 키가 커밋 중 하나에 들어가면 컨테이너를 사용하는 모든 사람이 특정 커밋을 확인하여 해당 키에 액세스할 수 있기 때문에 정말 위험해 보입니다.

이게 왜 아직까지 안나왔지?

그것은 디자인 제안이 필요합니다. 이 문제는 _cah_- _luttered_이고 아이디어는 현재로서는 막연합니다. 실제 구현 세부 정보는 "만약 우리가 x를 했다면 어땠을까"와 +1의 흐릿함 속에서 사라지고 있습니다. 이 매우 필요한 기능을 정리하고 계속 진행하려면 가능한 솔루션이 있는 사용자가 . . .

디자인 제안

그런 다음 이 문제를 참조하세요.

이 문제에 대한 소식이 있습니다.

지난 주 DockerCon에서 우리는 가장 어려운 질문을 Docker의 "Ask Experts" 파빌리온에 가져오도록 권장받았습니다. 그래서 저는 그곳에 가서 영감을 주는 제목인 Solutions Architect를 가진 똑똑하고 친근한 엔지니어와 짧은 대화를 나누었습니다. 나는 그에게 이 문제에 대한 간략한 요약을 주었습니다. 정확하게 전달했으면 하는 바램입니다. 그가 _only_ docker-compose 할 수 있다고 확신했기 때문입니다! 그가 제안한 세부 사항에는 최종 앱 빌드와 다른 컨텍스트에서 종속성을 누적하기 위한 다단계 빌드가 포함되었으며 빌드 시 데이터 볼륨을 사용하는 것으로 보였습니다.

불행히도 나는 docker-compose에 대한 경험이 없기 때문에 모든 세부 사항을 따를 수는 없었지만 그는 정확한 문제에 대해 그에게 편지를 보내면 해결책으로 응답할 것이라고 확신했습니다. 그래서 나는 이 공개된 GitHub 문제에 대한 참조를 포함하는 충분히 명확한 이메일 을 작성했습니다. 그리고 나는 오늘 아침에 그에게서 답장을 받았고, 그가 뭔가를 생각해 냈을 때 답장을 보낼 것이라고 안심시켰습니다.

나는 그가 매우 바쁘다고 확신하므로 즉각적인 조치를 기대하지는 않겠지만 그가 문제를 이해하고 도커 네이티브 도구 세트만으로 문제를 공격할 준비가 되어 있다는 점에서 이것은 고무적입니다.

@benton docker-compose.yaml의 다음 구성을 사용하여 이 주제에서 설명하는 작업을 수행합니다.

version: '2'
services:
  serviceName:
     volumes:
      - "${SSH_AUTH_SOCK}:/tmp/ssh-agent"
    environment:
      SSH_AUTH_SOCK: /tmp/ssh-agent

ssh-agent가 호스트 시스템에서 시작되었고 키에 대해 알고 있는지 확인합니다(ssh-add -L 명령으로 확인할 수 있음).

추가해야 할 수도 있습니다.

Host *
  StrictHostKeyChecking no

컨테이너의 .ssh/config.

안녕하세요 @WoZ입니다! 답변 감사합니다. 간단해 보여서 시도해 보겠습니다. :)

질문이 있습니다. 도커 허브에서 자동화된 빌드와 함께 이것을 어떻게 사용할 수 있습니까? 지금까지 작성 파일을 사용할 방법이 없습니다 :(

@garcianavalon 은 잘 작동하지만 build 가 아니라 run 에만 해당됩니다. 분명히 할 일 목록에 있지만 아직 Mac용 Docker와 함께 작동하지 않습니다.

편집: https://github.com/docker/for-mac/issues/410

특정 요구 사항에 대해 2가지 해결 방법을 더 제시했습니다.

1) VPN 뒤에 npm, pypi 등에 대한 자체 패키지 미러를 설정합니다. 이렇게 하면 SSH가 필요하지 않습니다.

2) 모든 호스트 시스템은 이미 개인 저장소에 액세스할 수 있으므로 개인 패키지를 호스트 시스템에 로컬로 복제/다운로드하고 패키지 설치를 실행하여 다운로드한 다음 -v를 사용하여 볼륨을 도커에 매핑한 다음 도커를 빌드합니다.

우리는 현재 옵션 2)를 사용하고 있습니다.

docker run 까지 docker-ssh-agent-forward 는 우아한 솔루션을 제공하고 Mac/Linux용 Docker에서 작동합니다.

ssh-agent가 알려진 호스트를 전달하지 않는 것처럼 보이므로 컨테이너에 파일을 만드는 대신 호스트에서 known_hosts 파일을 복사하는 것이 좋습니다(보안 수준이 낮음).

그러나 도커 실행 단계에서 개인 종속성을 가져올 때의 근본적인 문제는 도커 빌드 캐시를 우회하는 것인데, 이는 빌드 시간 측면에서 매우 중요할 수 있습니다.

이 제한을 해결하는 한 가지 방법은 빌드 종속성 선언(예: package.json )을 md5/date하고, 결과를 이미지로 푸시하고, 파일이 변경되지 않은 경우 동일한 이미지를 재사용하는 것입니다. 이미지 이름에 해시를 사용하면 여러 상태를 캐싱할 수 있습니다. 사전 설치 이미지 다이제스트와도 결합해야 합니다.

이것은 빌드 서버를 위한 @aidanhs 의 솔루션보다 더 강력해야 하지만 여전히 대규모로 테스트해야 합니다.

이것은 빌드 서버를 위한 @aidanhs 의 솔루션보다 더 강력해야 하지만 여전히 대규모로 테스트해야 합니다.

내 특정 솔루션은 1.9.0 이후로 작동하지 않았습니다. 내가 의존하고 있던 1.8.0에 도입된 기능이 의도적인 것이 아니었기 때문에 제거되었습니다.

내 솔루션의 원칙은 여전히 ​​잘 유지되지만 (컴퓨터에 DNS 서버가 있어야 함) 컴퓨터가 사용하고 b) 적절한 위치에 항목을 추가 할 수 있어야 함) 열성적으로 말할 수는 없습니다. 더 이상 추천합니다.

@aidanhs 추가 정보 감사합니다!

내가 제안한 솔루션에 대한 몇 가지 업데이트: 종속성 선언 파일을 추가한 직후 기본 이미지의 해시로 해시를 결합할 필요는 없습니다. 간단히 사용할 수 있습니다. 게다가 ssh-agent는 런타임에만 사용할 수 있기 때문에 단순히 known_host 파일을 볼륨으로 마운트하는 것이 더 낫습니다. 그리고 연결하는 모든 호스트의 목록이 포함되어 있기 때문에 더 안전합니다.

나는 node/npm에 대한 완전한 솔루션을 구현했으며 자세한 문서와 예제와 함께 여기에서 찾을 수 있습니다: https://github.com/iheartradio/docker-node

물론 원칙은 다른 프레임워크로 확장될 수 있습니다.

여기에서 같은 문제가 있는데, 빌드 시 이미지나 기본 이미지에 자격 증명을 쓰지 않고 도커 컨테이너 내부에서 여러 프로젝트를 확인하고 빌드하기 위해 SSH 자격 증명이 필요한 경우 어떻게 빌드합니까?

https://github.com/bibendi/dip#dip -ssh

우리는 2단계 빌드 프로세스를 통해 이 문제를 해결합니다. 소스/키/빌드 종속성을 포함하는 "빌드" 이미지가 생성됩니다. 일단 빌드되면 빌드 결과를 나중에 "배포" 이미지에 추가되는 tarfile로 추출하기 위해 실행됩니다. 그런 다음 빌드 이미지가 제거되고 "배포" 이미지만 게시됩니다. 이것은 컨테이너/레이어 크기를 줄이는 좋은 부작용이 있습니다.

@binarytemple-bet365 정확히 수행하는 종단 간 예제는 https://github.com/iheartradio/docker-node 를 참조

Rocker를 확인하십시오. 깨끗한 솔루션입니다.

@Sodki 당신의 조언을 받아 로커 는 깨끗하고 잘 생각한 솔루션입니다. 도커 팀이 해당 프로젝트를 자신의 날개 아래에 두고 docker build 사용하지 않는 것이 더 수치스럽습니다. 감사합니다.

아직 더 나은 방법이 없습니까? :(

이 새로운 스쿼시를 시도한 사람이 있습니까? https://github.com/docker/docker/pull/22641 우리가 찾고 있는 도커 기본 솔루션일 수 있습니다. 지금 그것을 시도하고 어떻게 진행되는지 다시 보고할 것입니다.

2년이 넘었지만 이것은 아직 수정되지 않았습니다 😞 Docker 팀에서 이에 대해 조치를 취하십시오.

1.13의 새로운 --squash 옵션이 저에게 맞는 것 같습니다.
http://g.recordit.co/oSuMulfelK.gif

docker build -t report-server --squash --build-arg SSH_KEY="$(cat ~/.ssh/github_private_key)" . 빌드합니다.

따라서 docker history 또는 docker inspect 하면 키가 표시되지 않습니다.

내 Dockerfile은 다음과 같습니다.

FROM node:6.9.2-alpine

ARG SSH_KEY

RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* &&\
  mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
  ssh-keyscan github.com > /root/.ssh/known_hosts

RUN echo "$SSH_KEY" > /root/.ssh/id_rsa &&\
  chmod 0600 /root/.ssh/id_rsa

COPY package.json .

RUN npm install
RUN rm -f /root/.ssh/id_rsa

# Bundle app source
COPY . .

EXPOSE 3000

CMD ["npm","start"]

@kienpham2000 , 스크린샷에 여전히 키가 포함되어 있는 것 같습니다 - --no-trunc 플래그로 docker history 의 출력을 확인하고 개인 키가 docker에 표시되는지 여부를 여기에 다시 보고해 주시겠습니까? 역사?

@ryanschwartz 당신이 옳습니다. --no-trunc 는 모든 것을 보여줍니다. 이것은 날지 않습니다.

@kienpham2000
1.13 릴리스에서 도입한 또 다른 사항은 다음과 같습니다.

비밀 구축
• —build-secret 플래그를 사용하여 빌드 시간 비밀을 활성화합니다.
• 빌드하는 동안 tmpfs를 만들고 비밀을
빌드 중에 사용할 컨테이너를 빌드합니다.
• https://github.com/docker/docker/pull/28079

어쩌면 이것이 효과가 있을까요?

빌드 시크릿은 1.13에 포함되지 않았지만 1.14에 포함되기를 바랍니다.

2016년 12월 15일 오전 9시 45분에 "Alex" [email protected]이 다음과 같이 썼습니다.

@kienpham2000 https://github.com/kienpham2000
1.13 릴리스에서 도입한 또 다른 사항은 다음과 같습니다.

비밀 구축
• —build-secret 플래그를 사용하여 빌드 시간 비밀을 활성화합니다.
• 빌드하는 동안 tmpfs를 만들고 비밀을
빌드 중에 사용할 컨테이너를 빌드합니다.
• #28079 https://github.com/docker/docker/pull/28079

어쩌면 이것이 효과가 있을까요?

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/6396#issuecomment-267393020 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAdcPDxrctBP2TlCtXen-Y_uY8Y8B09Sks5rIXy2gaJpZM4CD4SM
.

1년 후: 아니요, 이것은 나쁜 생각입니다. 그렇게 해서는 안 됩니다. 다른 다양한 솔루션이 있습니다. 예를 들어 Github은 액세스 토큰을 제공할 수 있습니다. 각 토큰에 허용되는 작업을 지정할 수 있으므로 위험이 적은 구성 파일/환경 변수에서 사용할 수 있습니다.

해결책은 SSH 전달을 구현하는 것입니다. 예를 들어 Vagrant가 그렇습니다.

누군가 그것을 구현하기 위해 왜 그렇게 복잡한지 설명할 수 있습니까?

@omarabid -

액세스 토큰 사용에 대한 귀하의 제안에 따르면 액세스 토큰은 결국 계층에 저장되며 SSH 키처럼 방치하는 것만큼 위험할 수 있습니다. 읽기 전용 액세스 권한만 있는 경우에도 대부분의 사람들은 다른 사람들이 자신의 리포지토리에 대한 읽기 전용 액세스 권한을 갖는 것을 원하지 않을 것입니다. 또한 빈번한 철회/순환/배포가 발생해야 합니다. 이것은 "마스터" 액세스 토큰을 사용하는 것보다 각 개발자 등에 대해 처리하기가 조금 더 쉽습니다.

몇 가지 코멘트를 다시 언급한 빌드 비밀 솔루션은 올바른 방향으로 가는 단계인 것처럼 보이지만 SSH 에이전트를 사용하는 기능이 가장 좋습니다. 빌드 비밀과 함께 SSH 에이전트를 사용할 수 있을지도 모르겠습니다. 잘 모르겠습니다.

개발자/CI 시스템이 git/build 작업 중에 SSH 에이전트를 사용하는 것은 자연스러운 일입니다. 이는 다양한 시스템에서 일괄 취소/교체해야 하는 일반 텍스트의 암호 없는 개인 키를 사용하는 것보다 훨씬 더 안전합니다. 또한 SSH 에이전트를 사용하면 개인 키 데이터가 이미지에 커밋될 가능성이 없습니다. 최악의 경우 환경 변수/SSH_AUTH_SOCK 잔여물이 이미지에 남습니다.

비밀 키 콘텐츠를 표시하거나 추가 타사 도커 도구를 사용하지 않고 이 최신 해결 방법을 얻었습니다(빌드된 PR 중 비밀 금고가 곧 병합되기를 바랍니다).

aw cli를 사용하여 S3에서 호스트 현재 리포지토리로 공유 프라이빗 키를 다운로드하고 있습니다. 이 키는 KMS를 사용하여 저장 시 암호화됩니다. 키가 다운로드되면 Dockerfile은 빌드 프로세스 중에 해당 키를 복사하고 나중에 제거합니다. 콘텐츠는 docker inspect 또는 docker history --no-trunc 표시되지 않습니다.

먼저 S3에서 호스트 머신으로 github 개인 키를 다운로드합니다.

# build.sh
s3_key="s3://my-company/shared-github-private-key"
aws configure set s3.signature_version s3v4
aws s3 cp $s3_key id_rsa --region us-west-2 && chmod 0600 id_rsa

docker build -t app_name .

Dockerfile은 다음과 같습니다.

FROM node:6.9.2-alpine

ENV id_rsa /root/.ssh/id_rsa
ENV app_dir /usr/src/app

RUN mkdir -p $app_dir
RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* && mkdir -p /root/.ssh && ssh-keyscan github.com > /root/.ssh/known_hosts

WORKDIR $app_dir

COPY package.json .
COPY id_rsa $id_rsa
RUN npm install && npm install -g gulp && rm -rf $id_rsa

COPY . $app_dir
RUN rm -rf $app_dir/id_rsa

CMD ["start"]

ENTRYPOINT ["npm"]

@kienpham2000 , 이 솔루션이 이미지 레이어에 키를 유지하지 않는 이유는 무엇입니까? 키 복사 및 제거 작업은 별도의 명령으로 수행되므로 키가 있어야 하는 레이어가 있습니다.
우리 팀은 어제까지 귀하의 솔루션을 사용했지만 개선된 솔루션을 찾았습니다.

• aws s3 cli를 사용하여 키에 액세스하기 위한 사전 서명 URL을 생성하고 약 5분 동안 액세스를 제한하고 이 사전 서명 URL을 repo 디렉터리의 파일에 저장한 다음 dockerfile에서 이미지에 추가합니다.
• dockerfile에는 이 모든 단계를 수행하는 RUN 명령이 있습니다. pre-sing URL을 사용하여 ssh 키를 가져오고, npm install을 실행하고, ssh 키를 제거합니다.
  이 작업을 하나의 명령으로 하면 ssh 키가 어떤 계층에도 저장되지 않지만 사전 서명 URL은 저장되며 5분 후에 URL이 유효하지 않기 때문에 문제가 되지 않습니다.

빌드 스크립트는 다음과 같습니다.

# build.sh
aws s3 presign s3://my_bucket/my_key --expires-in 300 > ./pre_sign_url
docker build -t my-service .

Dockerfile은 다음과 같습니다.

FROM node

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    ssh -o StrictHostKeyChecking=no [email protected] || true && \
    npm install --production && \
    rm ./my_key && \
    rm -rf ~/.ssh/*

ENTRYPOINT ["npm", "run"]

CMD ["start"]

@diegocsandrim 지적해 주셔서 감사합니다. 귀하의 솔루션이 정말 마음에 듭니다. 여기에서 우리의 내용을 업데이트할 예정입니다. 공유해 주셔서 감사합니다!

나는 스레드에 약간 익숙하지 않지만 근본적으로 사람들이 PKI로 더 잘 해결되는 문제를 해결하려고하는 것처럼 보입니다. 모든 사람이 PKI가 더 나은 솔루션이 되는 동일한 문제를 저장하려고 하는 것은 아니지만 충분한 참조 자료에 따르면 이것이 고려해야 할 사항일 수 있음을 나타내는 것 같습니다.

귀찮아 보이지만 기본적으로는

• 로컬 인증 기관 생성
• 인증서를 생성하는 프로세스가 있습니다.
• 증명서를 발급하는 절차가 있습니다
• 해당 인증서를 취소하는 프로세스가 있습니다.
• ssh 데몬이 PKI를 사용하도록 하십시오.

그리고 사람들이 이것이 실현 가능하다고 생각한다면, 모든 작업이 한 번 잘 수행되어야 하는 후, 반드시 그것을 만들고 오픈 소스로 만드십시오. roumen petrov 빌드가 안전한지, 소스 코드를 기록하지 않았는지(tar를 확인하지 않은 경우) 나는 그것이 얼마나 안전한지 전혀 모릅니다.

https://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

@mehmetcodes : PKI가

지역 인증 기관에서 수명이 매우 짧은 인증서(예: 1시간 미만)를 발급하고 성공적인 빌드 직후 인증서를 취소하지 않는 한 이는 안전하지 않습니다.

단기 인증서 프로세스를 생성할 수 있다면 빌드가 완료된 후 즉시 취소하는 새 SSH 키를 사용하는 것과 크게 다르지 않습니다.

오, 그것보다 더 짜증나는 일이지만, 내가 무언가를 하고 있는 것이 틀림없거나 그것이 야생에 존재하는 이유는 무엇입니까?

https://blog.cloudflare.com/red-october-cloudflares-open-source-implementation-of-the-two-man-rule/
https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/

저는 잘 모르겠습니다. SSH 임시 키가 대부분의 사용 사례에 훨씬 더 나을지 모르지만, 특히 이 맥락에서 제가 제안한 것을 포함하여 모든 수단에 대해 불안한 점이 있습니다.

http://blog.cloud66.com/using-ssh-private-keys-securely-in-docker-build/에 대해 어떻게 생각

일반적으로 대신 키를 사용하여 볼륨을 마운트하지만 Mac/moby 솔루션용 도커의 필요성에는 도움이 되지 않습니다.

누구 f..는 moby입니까?

@whitecolor

MacOS에서는 다음과 같은 정보가 있습니다.

bash-3.2$ docker run -t -i -v "$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
docker: Error response from daemon: Mounts denied:
The path /var/folders/yb/880w03m501z89p0bx7nsxt580000gn/T//ssh-DcwJrLqQ0Vu1/agent.10466
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.
.

/var/는 Docker가 어려움을 겪고 있는 별칭입니다. 그러나 $SSH_AUTH_SOCK 경로 앞에 /private (즉, 확인된 별칭 경로)를 붙이면 Docker는 파일을 읽을 수 있지만 다음과 같은 결과를 얻습니다.

bash-3.2$ docker run -t -i -v "/private$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
Could not open a connection to your authentication agent.

이 시점에서 나는 단지 그것이 얼마나 나쁜지 궁금합니다 ...

docker run -v ~/.ssh:/root/.ssh python:3.6 bash

?

docker build  --build-arg ssh_prv_key="$(cat ~/.ssh/id_rsa_no_pass)" --build-arg ssh_pub_key="$(cat ~/.ssh/id_rsa.pub)" --squash .

그런 다음 Docker 파일 내부에서 다음을 수행합니다.

ARG ssh_prv_key
ARG ssh_pub_key

# Authorize SSH Host
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts

# Add the keys and set permissions
RUN echo "$ssh_prv_key" > /root/.ssh/id_rsa && \
    echo "$ssh_pub_key" > /root/.ssh/id_rsa.pub && \
    chmod 600 /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa.pub

포함하는 것을 잊지 마십시오.

RUN rm -f /root/.ssh/id_rsa /root/.ssh/id_rsa.pub

마지막 단계로.

여기서 주의할 점은 개인 키가 비밀번호로 보호되어서는 안 된다는 것입니다.

이전 주석의 문제는 키가 레이어에 있다는 것입니다... rm은 도커 파일의 각 줄이 하나의 레이어이기 때문에 이전 레이어에서 삭제되지 않습니다.

docker secret 이 이 문제를 해결하지 않습니까?
WDYT @thaJeztah

도커 비밀은 (아직) 빌드 중에 사용할 수 없으며 서비스에서만 사용할 수 있습니다(그래서 아직 docker run 아님).

다단계 빌드를 사용할 때 이와 같은 것이 작동할 수 있습니다. https://gist.github.com/thaJeztah/836c4220ec024cf6dd48ffa850f07770

나는 더 이상 Docker와 관련이 없지만 어떻게 이 문제가 그렇게 오랫동안 존재할 수 있는지. 전화를 걸지 않고 이 문제를 해결하는 데 필요한 노력이 무엇인지 이해하기보다는 이 문제를 처리할 때 ruby gems 와 같은 개인 패키지를 가져오는 회사에서 정말 일반적인 문제인 것 같았습니다. 개인 리포지토리.

Moby 은(는) 이 문제에 관심이 있습니까? 별 것 아닌 것 같아 보이는 일이 왜 그렇게 힘든 일인가.

거의 3년 만이에요 😢

@yordis 도커 빌더는 ​​1~2년 동안 동결되었습니다. 도커 팀은 빌더가 충분히 훌륭하며 다른 곳에 노력을 집중하고 있다고 말했습니다. 그러나 이것은 사라지고 그 이후로 빌더에 두 가지 변경 사항이 있습니다. 스쿼시와 머슬리 스테이지 빌드. 따라서 빌드 시 비밀이 진행 중일 수 있습니다.

ssh-agent의 런타임 전달을 위해 https://github.com/uber-common/docker-ssh-agent-forward를 권장합니다.

별 것 아닌 것 같아 보이는 일이 왜 그렇게 힘든 일인가.

@yordis 는 이 문제의 맨 위 설명을 읽고 이를 구현하는 것은 결코 buildkit 프로젝트가 시작되었습니다. https://github.com/moby/buildkit

@thaJeztah 필요한 기술이 있으면 좋겠지만 그렇지 않습니다.

@villlem Docker 팀의 로드맵을 알고 있습니까?

빌더에 대한 주간 보고서는 여기에서 찾을 수 있습니다. https://github.com/moby/moby/tree/master/reports/builder 빌드 시간 비밀은 여전히 ​​최신 보고서에 나열되어 있지만 도움말을 사용할 수 있습니다.

우리는 @diegocsandrim 의 솔루션을 사용하고 있지만 S3에 암호화되지 않은 SSH 키가 남지 않도록 중간 암호화 단계가 있습니다.

이 추가 단계는 도커 이미지에서 키를 복구할 수 없고(다운로드하는 URL은 5분 후에 만료됨) AWS에서 복구할 수 없음을 의미합니다(도커 이미지에만 알려진 회전 암호로 암호화됨). .

build.sh에서:

BUCKET_NAME=my_bucket
KEY_FILE=my_unencrypted_key
openssl rand -base64 -out passfile 64
openssl enc -aes-256-cbc -salt -in $KEY_FILE -kfile passfile | aws s3 cp - s3://$BUCKET_NAME/$(hostname).enc_key
aws s3 presign s3://$BUCKET_NAME/$(hostname).enc_key --expires-in 300 > ./pre_sign_url
docker build -t my_service

그리고 Dockerfile에서:

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - | openssl enc -aes-256-cbc -d -kfile passfile > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    mkdir /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts && \
    [commands that require SSH access to Github] && \
    rm ./my_key && \
    rm ./passfile && \
    rm -rf /root/.ssh/

docker run 를 사용하는 경우 --mount type=bind,source="${HOME}/.ssh/",target="/root/.ssh/",readonly .ssh를 마운트해야 합니다. 읽기 전용은 마술이며 일반 권한을 마스크하고 ssh는 기본적으로 만족하는 0600 권한을 봅니다. -u root:$(id -u $USER) 를 사용하여 컨테이너의 루트 사용자가 사용자와 동일한 그룹으로 생성하는 모든 파일을 쓰도록 할 수도 있으므로 chmod/chown 없이 완전히 쓰지 않더라도 최소한 읽을 수 있기를 바랍니다. .

드디어.

이 문제는 이제 다단계 빌드를 사용하여 docker build 만 사용하여 해결할 수 있다고 생각 합니다 .
필요할 때마다 COPY 또는 ADD SSH 키 또는 기타 비밀을 원하는 대로 RUN 문에서 사용하십시오.

그런 다음 두 번째 FROM 문을 사용하여 새 파일 시스템을 시작하고 COPY --from=builder 를 사용 하여 secret 을 포함하지 않는 디렉터리의 일부 하위 집합을 가져옵니다.

(아직 실제로 시도하지는 않았지만 기능이 설명된 대로 작동한다면...)

@benton 다단계 빌드는 설명된 대로 작동하므로 사용합니다. 이것은 이 문제를 포함하여 다양한 문제에 대한 최고의 옵션입니다.

다음 기술을 확인했습니다.

1. 같은 빌드 인수로 개인 KEY_의 _location 전달 GITHUB_SSH_KEY a의 첫 번째 단계로, 다단계 빌드
2. ADD 또는 COPY 를 사용하여 인증에 필요한 모든 위치에 키를 씁니다. 키 위치가 URL이 아닌 로컬 파일 시스템 경로인 경우 .dockerignore 파일에 _없게_ 있어야 합니다. 그렇지 않으면 COPY 지시문이 작동하지 않습니다. 이것은 4단계에서 볼 수 있듯이 최종 이미지에 영향을 미칩니다.
3. 필요에 따라 키를 사용합니다. 아래 예에서 키는 GitHub에 인증하는 데 사용됩니다. 이것은 Ruby의 bundler 및 개인 Gem 저장소에서도 작동합니다. 이 시점에서 포함해야 하는 코드베이스의 양에 따라 COPY . 또는 ADD . 사용의 부작용으로 키를 다시 추가하게 될 수 있습니다.
4. 필요한 경우 키를 제거하십시오 . 키 위치가 URL이 아닌 로컬 파일 시스템 경로인 경우 ADD . 또는 COPY . 를 수행할 때 코드베이스와 함께 추가되었을 가능성이 큽니다. 이것은 아마도 _정확히 디렉토리_일 것입니다. 최종 런타임 이미지에 복사될 것이므로 키 사용이 끝나면 RUN rm -vf ${GITHUB_SSH_KEY} 문도 포함할 수 있습니다.
5. 앱이 WORKDIR 완전히 빌드되면 원하는 런타임 이미지를 나타내는 새로운 FROM 문으로 두 번째 빌드 단계를 시작합니다. 다음 필요한 런타임 종속성을 설치하고 COPY --from=builder 에 대한 WORKDIR 첫 번째 단계에서.

다음은 위의 기술을 보여주는 Dockerfile 의 예입니다. GITHUB_SSH_KEY 빌드 인수를 제공하면 빌드할 때 GitHub 인증을 테스트하지만 키 데이터는 최종 런타임 이미지에 포함되지 _않습니다_. GITHUB_SSH_KEY 는 파일 시스템 경로(Docker 빌드 디렉토리 내) 또는 키 데이터를 제공하는 URL일 수 있지만 이 예에서 키 자체는 암호화되어서는 안 됩니다.

########################################################################
# BUILD STAGE 1 - Start with the same image that will be used at runtime
FROM ubuntu:latest as builder

# ssh is used to test GitHub access
RUN apt-get update && apt-get -y install ssh

# The GITHUB_SSH_KEY Build Argument must be a path or URL
# If it's a path, it MUST be in the docker build dir, and NOT in .dockerignore!
ARG GITHUB_SSH_KEY=/path/to/.ssh/key

  # Set up root user SSH access for GitHub
ADD ${GITHUB_SSH_KEY} /root/.ssh/id_rsa

# Add the full application codebase dir, minus the .dockerignore contents...
# WARNING! - if the GITHUB_SSH_KEY is a file and not a URL, it will be added!
COPY . /app
WORKDIR /app

# Build app dependencies that require SSH access here (bundle install, etc.)
# Test SSH access (this returns false even when successful, but prints results)
RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1 | grep -i auth

# Finally, remove the $GITHUB_SSH_KEY if it was a file, so it's not in /app!
# It can also be removed from /root/.ssh/id_rsa, but you're probably not going
# to COPY that directory into the runtime image.
RUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id*

########################################################################
# BUILD STAGE 2 - copy the compiled app dir into a fresh runtime image
FROM ubuntu:latest as runtime
COPY --from=builder /app /app

키 데이터의 _위치_보다는 GITHUB_SSH_KEY 빌드 인수에서 키 데이터 자체를 전달하는 것이 _아마도_ 더 안전합니다. 이렇게 하면 키 데이터가 로컬 파일에 저장된 다음 COPY . 로 추가되는 경우 실수로 키 데이터가 포함되는 것을 방지할 수 있습니다. 그러나 이를 위해서는 echo 및 셸 리디렉션을 사용하여 데이터를 파일 시스템에 써야 하며, 이는 모든 기본 이미지에서 작동하지 않을 수 있습니다. 기본 이미지 세트에 가장 안전하고 실현 가능한 기술을 사용하십시오.

@jbiel 또 다른 해에 내가 찾은 해결책은 Vault와 같은 것을 사용하는 것입니다.

다음은 2가지 방법에 대한 링크 입니다(앞서 @benton이 설명한 스쿼시 및 중간 컨테이너).

액세스가 필요한 작업을 수행할 때마다 에이전트가 암호를 묻는 메시지를 표시하므로 사용 중인 ssh 키에 암호가 있는 경우 현재 접근 방식 중 어느 것도 작동하지 않는다는 메모를 추가하는 중입니다. 핵심 문구를 전달하지 않고 이 문제를 해결할 방법이 없다고 생각합니다(여러 가지 이유로 바람직하지 않음).

해결.
bash 스크립트 생성(~/bin/docker-compose 등):

#!/bin/bash

trap 'kill $(jobs -p)' EXIT
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &

/usr/bin/docker-compose $@

그리고 socat을 사용하는 Dockerfile에서:

...
ENV SSH_AUTH_SOCK /tmp/auth.sock
...
  && apk add --no-cache socat openssh \
  && /bin/sh -c "socat -v UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:172.22.1.11:56789 &> /dev/null &" \
  && bundle install \
...
or any other ssh commands will works

그런 다음 docker-compose build

@benton 왜 RUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id* 합니까? 그냥 RUN rm -vf /root/.ssh/id* 이어야 하지 않습니까? 아니면 여기서 의도를 잘못 이해했을 수도 있습니다.

@benton 또한 다음을 수행하는 것이 안전하지 않습니다.

RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1

지문을 확인해야 합니다

나는이 방법으로이 문제를 해결했다.

ARGS USERNAME
ARGS PASSWORD
RUN git config --global url."https://${USERNAME}:${PASSWORD}@github.com".insteadOf "ssh://[email protected]"

다음으로 빌드

docker build --build-arg USERNAME=use --build-arg PASSWORD=pwd. -t service

하지만 처음에는 개인 git 서버가 username:password 복제 저장소를 지원해야 합니다.

@zeayes RUN 명령은 컨테이너 히스토리에 저장됩니다. 따라서 귀하의 비밀번호는 다른 사람이 볼 수 있습니다.

옳은; --build-arg / ARG 하면 해당 값이 빌드 기록에 표시됩니다. 다단계 빌드를 사용하고 이미지가 빌드된 호스트를 신뢰하면(즉, 신뢰할 수 없는 사용자가 로컬 빌드 기록에 액세스할 수 없음) 이 기술을 _사용할 수 있습니다. _및_ 중간 빌드 단계는 레지스트리에 푸시되지 않습니다.

예를 들어 다음 예에서 USERNAME 및 PASSWORD 는 첫 번째 단계("빌더")의 기록에만 발생하지만 최종 단계의 기록에는 없습니다.

FROM something AS builder
ARG USERNAME
ARG PASSWORD
RUN something that uses $USERNAME and $PASSWORD

FROM something AS finalstage
COPY --from= builder /the/build-artefacts /usr/bin/something

최종 이미지("finalstage"에서 생성)만 레지스트리에 푸시되면 USERNAME 및 PASSWORD 는 해당 이미지에 없습니다.

_하지만_, 로컬 빌드 캐시 기록에서 해당 변수는 여전히 존재합니다(디스크에 일반 텍스트로 저장됨).

차세대 빌더( BuildKit 사용)에는 빌드 시간 비밀 전달과 관련된 더 많은 기능이 있습니다. Docker 18.06에서 실험적 기능으로 사용할 수 있지만 향후 릴리스에서는 실험적이지 않고 더 많은 기능이 추가될 예정입니다(비밀/자격 증명이 현재 버전에서 이미 가능한지 확인해야 함)

@kinnalru @thaJeztah thx, 다단계 빌드를 사용하지만 암호는 캐시 컨테이너의 히스토리, thx에서 볼 수 있습니다!

@zeayes 오! 복사/붙여넣기 오류가 발생했습니다. 마지막 단계는 FROM builder .. 사용해서는 안 됩니다. 다음은 전체 예입니다. https://gist.github.com/thaJeztah/af1c1e3da76d7ad6ce2abab891506e50

@kinnalru의 이 댓글은 https://github.com/moby/moby/issues/6396#issuecomment -348103398

이 방법을 사용하면 docker가 개인 키를 처리하지 않습니다. 또한 새로운 기능을 추가하지 않고도 오늘날에도 작동합니다.

이해하는 데 시간이 걸렸으므로 여기에 더 명확하고 향상된 설명이 있습니다. --network=host 및 localhost 를 사용하도록 @kinnalru 코드를 변경 요점 )

이것은 docker_with_host_ssh.sh 이며 docker를 래핑하고 SSH_AUTH_SOCK 를 localhost의 포트로 전달합니다.

#!/usr/bin/env bash

# ensure the processes get killed when we're done
trap 'kill $(jobs -p)' EXIT

# create a connection from port 56789 to the unix socket SSH_AUTH_SOCK (which is used by ssh-agent)
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &
# Run docker
# Pass it all the command line args ($@)
# set the network to "host" so docker can talk to localhost
docker $@ --network='host'

Dockerfile에서 localhost를 통해 호스트 ssh-agent에 연결합니다.

FROM python:3-stretch

COPY . /app
WORKDIR /app

RUN mkdir -p /tmp

# install socat and ssh to talk to the host ssh-agent
RUN  apt-get update && apt-get install git socat openssh-client \
  # create variable called SSH_AUTH_SOCK, ssh will use this automatically
  && export SSH_AUTH_SOCK=/tmp/auth.sock \
  # make SSH_AUTH_SOCK useful by connecting it to hosts ssh-agent over localhost:56789
  && /bin/sh -c "socat UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:localhost:56789 &" \
  # stuff I needed my ssh keys for
  && mkdir -p ~/.ssh \
  && ssh-keyscan gitlab.com > ~/.ssh/known_hosts \
  && pip install -r requirements.txt

그런 다음 스크립트를 호출하여 이미지를 빌드할 수 있습니다.

$ docker_with_host_ssh.sh build -f ../docker/Dockerfile .

@cowlicks 빌드 중에 SSH 에이전트를 전달하기 위해 docker build --ssh 에 대한 지원을 추가하는 이 pull 요청에 관심이 있을 수 있습니다. https://github.com/docker/cli/pull/1419. Dockerfile 구문은 아직 공식 사양에 없지만 Dockerfile에서 syntax=.. 지시문을 사용하여 이를 지원하는 프런트엔드를 사용할 수 있습니다(풀 요청의 예제/지침 참조).

해당 풀 리퀘스트는 다가오는 18.09 릴리스의 일부가 될 것입니다.

이제 18.09 릴리스에서 사용할 수 있는 것 같습니다. 이 스레드는 릴리스 정보와 중간 게시물보다 먼저 나오기 때문에 여기에 교차 게시합니다.

릴리즈 노트:
https://docs.docker.com/develop/develop-images/build_enhancements/#using -ssh-to-access-private-data-in-builds

중간 포스트:
https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

매우 흥미진진합니다.

@kalenp 는 https://github.com/moby/buildkit/issues/760 및 https://github.com/moby/buildkit/issues/825 도 참조 하십시오.

지금 docker build --ssh 이 있으므로 닫을 수 있다고 생각합니다.

관련 작성 문제: docker/compose#6865. Compose를 사용하고 SSH 에이전트 소켓을 다음 릴리스 후보인 1.25.0-rc3( 릴리스 )에 상륙할 것으로 알려진 컨테이너에 노출하는 기능.