moby 🚀 - --insecure-registry는 "docker pull"에 있어야 합니다.

우리는 모든 CI 및 프로덕션 환경에서 내부 보안되지 않은 도커 레지스트리를 실행합니다. 안전하지 않은 레지스트리를 하나씩 나열할 필요 없이 모든 불안정한 레지스트리에 액세스할 수 있도록 하는 것이 매우 유용할 것이라고 말해야 합니다. 각 환경에는 HA에 대한 여러 레지스트리가 있습니다. 이 변경으로 인해 상황이 훨씬 더 복잡해졌습니다. 이 문제는 데몬이 아닌 풀로 옵션을 이동하는 데 더 가깝기 때문에 특별히 이 문제를 해결하기 위해 다른 문제 티켓을 열겠습니다.

octalthorpe 에 2014년 10월 31일

👍3

그리고 레지스트리를 실행하기 위해 고정 포트를 사용하지 않을 때 약간의 닭고기와 계란 문제가 있습니다.

어떤 포트가 도커에 의해 할당될지 미리 알지 못하기 때문에 그것을 참조하는 플래그로 데모를 시작할 수 없습니다.

proppy 에 2014년 10월 31일

:+1:

reinh 에 2014년 10월 31일

그래서 docker pull 명령줄에서 --insecure 를 지원하고 _this_ pull 명령에 대해 보안 검사를 강제로 비활성화하면 @proppy 및 @octalthorpe 문제도 해결할 수 있다고 생각합니다. 맞습니까? 이 플래그로 실행하면 목록을 검사하지 않습니다.

abourget 에 2014년 10월 31일

@abourget 원격 API에서도 지원해야 합니다.

현재 docker-py는 pull 함수에서 insecure_registry 플래그를 노출하지만 끝점을 해결하는 데만 사용됩니다. https://github.com/docker/docker-py/blob/master/ 도커/클라이언트.py#L794

proppy 에 2014년 10월 31일

범인은 https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6인 것 같습니다.

하지만 해당 PR이나 해당 변경 사항이 논의된 문제를 찾을 수 없었습니다.

@tiborvass 아이디어가 있습니까?

proppy 에 2014년 10월 31일

@proppy - 이것은 금지된 보안 취약점으로 처리되었으며 공개 PR에서 논의되지 않았습니다. 핵심 팀은 문제에 대한 가시성과 투표권을 가지고 있었습니다.

localhost/127.0.0.1에 대한 이러한 변경의 의미에 대해 숙고할 필요가 있지만 특별히 관심이 없습니다. 이는 비표준적이고 흔하지 않은 구성이며 솔루션이 잘 문서화되어 있습니다.

ewindisch 에 2014년 10월 31일

반면 에 localhost 에서 실행 중인 레지스트리 컨테이너와 함께 이미 실행 중인 많은 도커 데몬이 있습니다.

말 그대로 모든 사용자가 --insecure-registry localhost:5000 를 전달해야 하는 경우 기본값으로 설정할 수도 있습니다.

proppy 에 2014년 10월 31일

@ewindisch 엠바고급 취약점을 구성하는 문서나 지침이 있습니까? 이것은 원격의 인증되지 않은 RCE가 아닙니다. 여기서의 위험은 경고 없이 포인트 릴리스의 주요 변경 사항을 정당화할 만큼 충분히 심각해 보이지 않습니다.

mmdriley 에 2014년 10월 31일

@mmdriley - Mitre/NST에 따른 정의가 일반적으로 적용됩니다. 이 경우 영향을 받는 시스템에서 임의의 신뢰할 수 없는 코드를 실행할 수 있는 메시지 가로채기 공격이 실행 가능하므로 예, 이를 RCE로 분류합니다. 즉, 예를 들어 카페의 랩톱에서 이미지를 가져오기 위해 Docker를 사용하는 경우 해당 WiFi 액세스 지점의 다른 사용자가 잠재적으로 공격자가 제공한 임의의 응용 프로그램을 실행할 수 있습니다. 또한 잠재적으로 DockerHub 계정 또는 인증할 기타 레지스트리에 액세스할 수 있습니다.

편집: CVE 설명에 대한 링크 추가: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

ewindisch 에 2014년 10월 31일

예, 이것이 RCE가 아니라고 말한 것이 틀렸습니다. 이것은 나쁜 버그이며 강력한 이미지 서명이 왜 좋은 아이디어인지에 대한 훌륭한 증거입니다. 그러나 악용은 사소한 것이 아닙니다. 근처에 있는 누군가가 안전하지 않은 Wi-Fi를 통해 Docker를 사용하기를 바라면서 스타벅스에서 시간을 보내려면 적극적인 공격자가 필요합니다. 이것은 하룻밤 사이에 무기화되지 않을 것이므로 경고 없이 이전 버전과 호환되지 않는 변경을 할 가치가 없습니다.

위에서 제안한 것처럼 호환성을 손상시키지 않고 즉시 보안을 향상시킬 수 있는 분명한 방법이 있습니다. 예를 들어 index.docker.io 및 소수의 다른 인기 있는 공개 레지스트리에 대한 HTTPS 대체를 비활성화하면 대부분의 사용자가 효과적으로 문제를 해결할 수 있습니다. HTTP 대체가 발생했다는 경고를 콘솔 출력에 추가하면 대화형 사례가 완화되었을 것입니다. HTTP 대체는 사용되지 않는 것으로 표시되고 다음 달 릴리스에서 제거됩니다. 마지막으로 localhost 및 ::1은 분명히 취약하지 않습니다.

다시 말하지만 취약점의 정도를 무시하지 말았어야 했는데 대응 프로세스와 수정이 고객을 깨뜨리지 않는 데 충분한 가치를 두지 않은 것 같아 걱정입니다.

mmdriley 에 2014년 10월 31일

우리는 현재 이러한 많은 인스턴스에서 FQDN을 사용할 수 없는 환경에서 동적으로 도커 레지스트리를 생성/파기하고 있습니다. 레지스트리 관련 요청(원격 API를 통해)에 --insecure-repository 옵션을 지원하면 이 보안 수정 사항으로 인해 발생하는 심각한 문제를 해결할 수 있습니다.

jwthomp 에 2014년 11월 03일

Docker 1.3.1에도 비슷한 문제가 있습니다. http://docker :5000/ 주소에서 로컬(개인) Docker 레지스트리를 사용합니다. Docker 1.3.0까지는 잘 작동했습니다. Docker 버전 1.3.1에서는 Docker 클라이언트가 HTTPS에서 레지스트리에 연결할 수 있다고 자동으로 가정하기 때문에 더 이상 작동하지 않습니다. 그러나 우리는 HTTPS를 전혀 사용하지 않습니다.

HTTPS를 통해 Docker 레지스트리 서버에 액세스할 수 없는 경우 HTTP를 사용하는 대체 메커니즘을 구현하는 것이 좋습니다.

kruxik 에 2014년 11월 04일

@kruxik 데몬을 시작할 때 --insecure-registry docker:5000 하면 HTTP로 대체됩니다.

tiborvass 에 2014년 11월 04일

@tiborvass 제안 감사합니다. 당신이 올바른지. 그러나 워크스테이션과 노트북을 사용하는 개발자가 많은 경우 각 스테이션에 --insecure-registry 를 설정하는 것은 비현실적입니다. 최소한 pull/push 작업에 대한 선택적 매개변수로 사용하면 충분합니다. ;)

kruxik 에 2014년 11월 04일

+1

이것은 1.3.0에서 우리에게 효과가 있었지만 1.3.1에서는

도커 버전
....
서버 버전: 1.3.1
....
도커 푸시 10.121.4.236:5000/debian7/consul
-> ....이 개인 레지스트리가 알 수 없는 CA 인증서가 있는 HTTP 또는 HTTPS만 지원하는 경우 데몬 인수에 --insecure-registry 10.121.4.236:5000 를 추가하십시오. HTTPS의 경우 레지스트리의 CA 인증서에 액세스할 수 있으면 플래그가 필요하지 않습니다. CA 인증서를

다운그레이드
서버 버전: 1.3.0
도커 푸시 10.121.4.236:5000/debian7/consul
-> 문제 없이 컨테이너 업로드.

epankala 에 2014년 11월 05일

1.3.0에서 1.3.1에 문제가 있는 다른 사람들을 위해 boot2docker를 사용하여 OS X에 대해 다음과 같이 변경해야 했습니다.

$ boot2docker delete #removes old image
$ rm -f ~/.ssh/id_boot2docker* # remove old keys
$ boot2docker init #generates new keys, cert
$ boot2docker up
$ boot2docker ssh
$ # add EXTRA_ARGS="--insecure-registry <YOUR INSECURE HOST>" 
$ # to /var/lib/boot2docker/profile
$ sudo /etc/init.d/docker restart

그러면 도커 풀을 할 수 _해야_ 합니다.

fig를 사용하는 경우 Fig 1.0.1도 필요하고 다음을 수행하십시오.

$ fig up --allow-insecure-ssl

mhamrah 에 2014년 11월 05일

@mhamrah 감사합니다! 이 문제를 해결하기 위해 몇 시간을 보냈습니다...

jdongelmans 에 2014년 11월 06일

localhost가 안전하다고 가정하면 +1입니다. 실제로 이에 반대하는 사람이 있습니까?

thockin 에 2014년 11월 06일

예, localhost가 안전하다고 가정하면 많은 도움이 될 것입니다. 나는 도커 상자에 방랑자를 사용하므로 상자를 파괴하거나 불러올 때마다 초기화 스크립트를 업데이트하는 것은 비효율적입니다. 이제 방랑자에서 init를 수정할 수 있도록 도커 상자를 인형화해야 할 것 같습니다.

또한 pull 및 push에 --insecure 플래그를 사용하는 것도 좋을 것이므로 필요한 경우 방랑자 상자 IP를 사용할 수 있습니다.

jasonwatt 에 2014년 11월 06일

@thocking : localhost가 안전하다고 가정: https://github.com/docker/docker/issues/8898을 참조

proppy 에 2014년 11월 06일

솔직히 말해서 자동화된 Jenkins Containerbuilds가 푸시에 실패한 이유도 궁금했습니다.
(프로덕션에 넣기 전에 testenv.가 있는 것이 좋습니다.)
이 "기능"이 실제로 발표되었는지 확인해야 합니다. 그렇지 않은 경우 데몬 동작에 대한 극단적인 대규모 변경에 대해 더 편집증적일 것입니다.

이 토론에서 내가 놓친 것:
각 호스트에 대해 "기본" 보안/비보안 모드를 사용하도록 데몬에 지시해야 하는 이유는 무엇입니까?

이 기본 동작으로 레지스트리를 설정하는 것이 더 생산적이지 않습니까?
따라서 설정에 따라 --secure 또는 --insecure 매개변수가 제공되지 않으면 데몬이 요청해야 합니다.
안전한 방법이 가능하고 그렇지 않은 경우 안전하지 않은 것으로의 대체가 사용되었습니다.

docker의 주요 기능 중 하나는 사용하기 쉽고 완전한 환경을 설정한다는 것입니다. 이러한 "출시/결정"으로 이 WOW 효과를 죽이지 마십시오...

내 2센트만...

bjneuhaus 에 2014년 11월 07일

@jwthomp를 포함하여 위와 유사한 문제가 있습니다. 이 문제를 해결하기 위해 10시간 이상을 보냈고 그 동안 docker 1.3.0으로 다운그레이드했습니다.

저는 마라톤에서 도커 레지스트리를 실행하고 있으며 도커 레지스트리는 현재 "nginx를 프론트엔드로 실행하여 SSL을 지원합니다"( https://github.com/docker/docker-registry/issues/697 참조). 그러나 nginx를 프론트엔드로 사용하는 것은 다양한 슬레이브 호스트/포트에서 도커 레지스트리를 실행하는 마라톤으로 인해 복잡합니다.

GUNICORN_OPTS를 사용하여 레지스트리 내에서 직접 SSL을 활성화할 수 있지만 SSL만 사용하고 마라톤 상태 확인을 통과할 수 없습니다.

나는 nginx와 같은 방식으로 모든 서비스에 대한 https 프론트엔드로 HAProxy를 구성하도록 Bamboo HAProxy 구성 시스템을 수정했지만, 여전히 도커가 내 개인 레지스트리에서 인증서를 검증하는 데 문제가 있으므로 여전히 이 시간에 나.

RCE로부터 보호하는 것은 매우 좋지만 일부 하위 호환성도 필요합니다. 모든 레지스트리를 안전하지 않은 것으로 지정하기 위한 최소한 도커 데몬에 대한 플래그입니다. 각 docker pull 명령에서 레지스트리 이름의 일부로 http 또는 https를 지정하는 방법이 있어야 합니다. 현재 1.3.1은 개인 레지스트리를 사용하는 모든 사람에게 큰 Catch-22처럼 보입니다.

nickandrew 에 2014년 11월 09일

@mhamrah https://github.com/boot2docker/boot2docker/pull/630

knownasilya 에 2014년 11월 14일

멋진.
2014년 11월 14일 금요일 오전 10:42 Ilya Radchenko [email protected]
썼다:

@mhamrah https://github.com/mhamrah boot2docker / boot2docker # 630
https://github.com/boot2docker/boot2docker/pull/630
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/8887#issuecomment -63082089.

mhamrah 에 2014년 11월 14일

@mhamrah ssh 키 등을 제거할 필요가 없었습니다. 필요한 줄을 /var/lib/boot2docker/profile에 추가하고 도커를 다시 시작했습니다. 팁 고마워!

ksylvan 에 2014년 11월 20일

멋있는. 나는 ssh'ing하는 것조차 문제가 있었다, 나는 어떤 버전 때문에 추측한다
도커 iso 간의 불일치. 나는 실제로 vagrant +를 사용하도록 전환했습니다.
docker 지원을 위해 coreos를 사용하고 잘 작동합니다. 설정하기만 하면 됩니다
boot2docker가 자동으로 수행하는 DOCKER_HOST.

2014년 11월 20일 목요일 오전 1:52:21 Kayvan Sylvan [email protected]
썼다:

@mhamrah https://github.com/mhamrah 제거할 필요가 없었습니다
ssh 키 등. 방금 필요한 줄을 추가했습니다.
/var/lib/boot2docker/profile 및 도커를 다시 시작했습니다. 팁 고마워!
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/8887#issuecomment -63768043.

mhamrah 에 2014년 11월 20일

미안 얘들아, 나는 더 일찍 답장을 하려고 했다.

@ewindisch가 이미 말했듯이 우리는 이러한 클라이언트 측 행동을 권장하고 싶지 않습니다. 플래그를 데몬 플래그로 요구함으로써 야기되는 고통은 사람들이 실제로 레지스트리에 TLS를 설정하는 것입니다. 그렇지 않으면 인센티브가 없습니다. 이해 해주셔서 감사 해요.

tiborvass 에 2014년 11월 25일

공식 도커 레지스트리에 도커 레지스트리의 "공식" 도커 기반 이미지가 있습니다. TLS를 사용 하지 않는 것이 좋습니다.

Docker가 사용자가 레지스트리에 TLS를 설정하기를 원하는 경우 기본적으로 TLS를 제공하는 공식 도커 이미지를 제공 하여 "고통 유발"과 동등하고 반대되는 "고통 감소"의 균형을 맞추는 것이 합리적이지 않습니까?

sroebuck 에 2014년 11월 26일

@티보르바스 . 내부 방화벽 개발자 사례를 무시하고 있습니다. 이제 레지스트리 앞에서 SSL이 활성화된 역방향 프록시를 설정해야 하거나(이 작업을 수행할 이유가 없음) 모든 개발자에게 이동하여 실행 중인 데몬에 대한 인수를 수정해야 합니다. boot2docker 내부. 이건 말이 안 됩니다. 구성 가능한 보안을 제공하는 많은 개발 환경에서 보안이 개발 환경에 대해 비활성화되는 경우가 많습니다. 솔루션에 대한 투표가 너무 많았을 때 이 문제를 닫는 것을 보고 놀랐습니다.

blevine 에 2014년 11월 26일

👍8

모든 개인 IP를 허용 목록에 추가하는 것은 어떻습니까? 중앙 필드?

mhamrah 에 2014년 11월 26일

또는 풀을 위해 프로토콜 이름, 'http' 또는 'https'를 이미지 이름의 일부로 만듭니다.

nickandrew 에 2014년 11월 26일

모두 @sroebuck을 @tiborvass 및 @blevine 큰 점을합니다. 이것은 점점 더 사내에서 컨테이너를 만드는 상점의 시나리오가 될 것이며 이전 워크플로를 깨는 것에 대한 분노도 증가할 것입니다. 우리는 모두 이것의 보안 측면을 이해하고 있으며 pull이 이를 해결하기에 적합한 장소가 아닐 수도 있지만, 공식 레지스트리 이미지가 이 변경 사항을 처리할 수 있는 간단하고 즉시 사용 가능한 방법을 제공하지 않는 한 해결해야 할 꽤 중요한 UX 문제로 간주됩니다.

justinclayton 에 2014년 11월 26일

안녕하세요 @tiborvass입니다 ! 이 문제는 지금 우리도 물고 있습니다. 나는 @nickandrew 의 접근 방식을 선호합니다. git clone과 조금 더 비슷할 것이며 미래에 다른 플러그형 프로토콜의 가능성을 열어줄 것입니다. 커플링을 줄이고 커뮤니티를 위한 승리이기 때문에 docker의 승리입니다.

davidhoyt 에 2014년 11월 26일

@blevine 참고: 1.3.2 localhost 는 기본적으로 허용 목록에 있습니다. https://github.com/docker/docker/pull/9124를 참조

-p 127.0.0.0:5000:5000 to docker run 를 전달하여 레지스트리가 localhost에서 수신 대기하도록 할 수 있습니다.

proppy 에 2014년 11월 26일

@proppy , localhost에서 듣는 것이 어떻게 도움이되는지 잘 모르겠습니다.

blevine 에 2014년 12월 01일

docker pull {http}myregistry.domain.com/myapp:latest

아니면 실제 URL이 되어야 합니까? 레지스트리 프로토콜에 대해 아무것도 모르지만 적절한 URL을 지정하기 위해 현재 구문을 확장하는 것이 호환되지 않는 것 같습니다.

nickandrew 에 2014년 12월 01일

@blevine 로컬 미러링 레지스트리를 설정할 수 있음을 의미합니다.

SvenDowideit 에 2014년 12월 02일

Arg, 이제 내 머신을 시작하려면 coreos용 클라우드 구성을 base64로 디코딩해야 합니다.

mattwilliamson 에 2014년 12월 09일

@tiborvas 와, 정말 안타까운 일입니다. :(

우리는 즉시 가동 및 중단하는 개발 클러스터를 가지고 있으며 이러한 클러스터를 처리하는 방법의 일부는 해당 클러스터에 대한 레지스트리를 생성하는 것입니다. 클러스터는 많은 물리적 노드 또는 VM일 수 있으며 개발자 데스크톱 컴퓨터 또는 랩톱에 있을 수도 있습니다(일반적으로 전체 스택을 시작할 수는 없지만). 각 클러스터는 완전히 독립적인 스택 및 개발 환경입니다. 또한 개발자가 회사의 모든 개발 클러스터 설정과 상호 작용할 수 있도록 하는 도커 기반 명령줄 도구가 있습니다.

이러한 종류의 복잡하고 동적인 환경에서 레지스트리에서 TLS를 요구 사항으로 만드는 것은 엄청난 고통입니다. 레지스트리가 있을 수 있는 새 네트워크를 추가할 때마다 도커 데몬 시작을 수정해야 하는 것도 똑같이 고통스럽습니다.

오해하지 마세요. TLS를 독점적으로 지원하려는 생각에 감사드립니다. 그러나 환경이 지원에 필요한 고통과 인프라를 줄이기 위해 TLS의 복잡성 제거를 안전하게 지원하는 유효한 경우가 있음을 고려하시기 바랍니다. 그것.

jwthomp 에 2014년 12월 09일

@티보르바스 +1. +1000. 이것은 절대적으로 불필요한 복잡성을 생성했습니다.
매우 역동적인 개발 워크플로로 전환합니다. 진입장벽이 생겼다
에만 적용해야 하는 항목에 대해 여기에서 크게 제기되었습니다.
생산 컨텍스트. 우리의 고통을 끝내주세요.

2014년 12월 9일 화요일, Jeff Thompson [email protected]
썼다:

@tiborvass https://github.com/tiborvass 와우, 이것도 그 중 하나
슬프게도 순간을 뒤집는 가상 테이블. :(
우리는 즉석에서 시작 및 중단하는 개발 클러스터를 보유하고 있습니다.
이러한 클러스터를 처리하는 방법은 해당 클러스터에 대한 레지스트리를 만드는 것입니다. NS
클러스터는 많은 물리적 노드 또는 VM일 수 있으며
개발자 데스크톱 컴퓨터 또는 노트북(일반적으로
전체 스택). 각 클러스터는 완전히 자체 포함된 스택 및 개발입니다.
환경. 우리는 또한 도커 기반 명령줄 도구를 가지고 있습니다.
개발자는 회사의 모든 개발 클러스터 설정과 상호 작용할 수 있습니다.
이러한 복잡하고 동적인 환경에서 레지스트리에 TLS를
요구 사항은 거대한 고통입니다. 도커 데몬 시작을 수정해야 함
설정할 때마다 레지스트리가 있을 수 있는 새 네트워크를 추가합니다.
똑같이 고통.
오해하지 마세요. 응원하고 싶은 마음에 감사드립니다.
TLS, 그러나 환경이 안전하게 제거를 지원하는 경우가 있습니다.
필요한 인프라와 고통 감소를 위한 TLS의 복잡성
그것을 지원하기 위해.
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/8887#issuecomment -66367681.

justinclayton 에 2014년 12월 10일

@jusinclayton @jwthomp @mattwilliamson @nickandrew @blevine

--insecure-registry 0.0.0.0/8 문제가 해결되지 않습니까? 그렇게 하면 여전히 HTTP를 사용할 수 있습니다.

tiborvass 에 2014년 12월 10일

이 CIDR 표기법을 사용하여 "--insecure-registry 172.16.0.0/12"와 같은 범위를 지정하여 "방화벽 뒤" 구성을 활성화할 수 있습니다. 이 옵션을 사용하는 것은 전혀 권장하지 않지만 사용자가 0.0.0.0/8에서 가능한 모든 주소보다 더 선택적인 범위(예: IP 공간)를 사용하려면 이 옵션을 선택하는 것이 좋습니다.

ewindisch 에 2014년 12월 10일

도커 데몬은 coreos에 내장되어 있으므로 어떻게든 해당 플래그를 클러스터 전체의 시작에 추가해야 합니다. 도커 데몬 자체를 제어할 수 없는 환경의 경우 pull 명령에 사용하는 것이 훨씬 더 유연하다고 생각합니다.

이는 공유 PHP 호스트에 대한 php.ini 파일을 변경하도록 지시하는 것과 같습니다.

2014년 12월 9일 22:18에 Tibor Vass [email protected]에서 다음과 같이 썼습니다.
@jusinclayton @jwthomp @mattwilliamson @nickandrew @blevine
--insecure-registry 0.0.0.0/8이 문제를 해결하지 않습니까? 그렇게 하면 여전히 HTTP를 사용할 수 있습니다.
—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

mattwilliamson 에 2014년 12월 10일

👍1

@mattwilliamson 실행 플래그는

Docker 구성 변경의 예는 CoreOS 웹 사이트에 있습니다. 대신에 insecure-registry 플래그를 지정하기 위해 debug-flag를 추가하도록 명령을 쉽게 수정할 수 있습니다.

https://coreos.com/docs/launching-containers/building/customizing-docker/

ewindisch 에 2014년 12월 10일

@tiborvass 전체 구성 에코시스템은 @mattwilliamson이 언급했듯이 공유 빌드 환경과 같이 데몬을 사용하여 이미지를 가져오는 사람이 데몬을 구성하는 사람과 다른 경우가 무수히

결론은 이것을 클라이언트 측 주장으로 만드는 것이 분명히 덜 파괴적인 솔루션이며 더 중요하게는 덜 규범적인 솔루션이라는 것입니다. Docker는 수백 개는 아니더라도 수십 개의 다른 프로젝트 및 워크플로에서 이미 기본 요소가 되었기 때문에 실제로 이 범위에서 사용 패턴을 지시해서는 안 됩니다. Git이 http.sslverify를 비활성화하는 간단한 런타임 구성 옵션을 제공한다고 해서 Linus Torvalds가 중요한 상황에서 민감한 데이터를 보호하지 않도록 권장하는 것은 아닙니다.

justinclayton 에 2014년 12월 10일

git 비유는 이것이 어떻게 작동해야 하는지에 대한 좋은 예입니다. Git은 TLS를 사용하도록 강요하지 않으며 호스트를 설정할 때 지원하려는 수준을 사용자가 결정합니다. 또한 필요한 보안 수준(또는 우회하려는)을 가져올 때 사용자의 결정입니다. 구성은 전역적으로 또는 리포지토리별로 간단한 단계입니다. Docker가 TLS를 사용하도록 강요하지는 않지만 대안을 중요하지 않게 만들어 다른 합리적인 옵션을 제공하지 않습니다.

CIDR 표기법은 틀림없이 "무거운 망치" 접근 방식을 허용하고 AFAIK는 dns 이름에 매핑되지 않으므로 10.0.0.0/16을 마스킹하더라도 some.private-registry.com을 10.0/16 원으로 가져옵니다. 일. 더 중요한 것은 구성이 간단하지 않다는 것입니다.

Docker는 컨테이너화를 위한 단순성으로 번창하고 다양한 환경에서 애플리케이션을 배포하는 장벽을 크게 낮춥니다. 우리 모두는 이점을 알고 있습니다. 대부분의 개발자는 간단한 CIDR 표기법 질문에 대답할 수 없으며 도커 구성 파일이 비표준 위치에 있을 수 있으며(boot2docker 및 CoreOS 위치는 모두 다른 배포판과 다름) 이러한 구성 파일을 어려운 피드백 루프로 엉망으로 만드는 것은 상당히 쉽습니다. 성공. 나는 syslog를 꼬리해야합니까? 아 잠깐만 내가 RHEL을 사용 중이고 메시지인가요?

새 개발자는 docker pull 스니펫을 쉽게 복사하여 붙여넣을 수 있지만 ssh를 boot2docker 호스트에 넣고 vi를 실행하고 구성 파일을 편집한 다음 syslog에 오류가 있는지 확인합니다...별로 많지는 않습니다. 그리고 오 예, 도커 데몬을 다시 시작하는 것을 잊었습니다.

보고 싶은 내용은 다음과 같습니다.

docker 명령을 통해 적용된 Docker 데몬 설정
docker 명령을 통해 지정된 TLS 재정의에 대한 Docker 풀 설정
특정 레지스트리에 대한 명령 전반에 걸쳐 유지되는 Docker 풀 설정

mhamrah 에 2014년 12월 10일

예, 하지만 Amazon에서는 autoscscale 구성을 변경할 수 없습니다. 사본을 만들거나 완전히 새로 만들어야 합니다.

2014년 12월 9일 23시 55분에 Eric Windisch [email protected] 은 다음과 같이 썼습니다.
실행 플래그는 CoreOS로 구성할 수 있습니다. Docker의 systemd 구성 파일을 편집할 수 있습니다. 클러스터에 대해 구성하려면 cloud-config를 사용할 수 있습니다.
Docker 구성 변경의 예는 CoreOS 웹 사이트에 있습니다. 대신에 insecure-registry 플래그를 지정하기 위해 debug-flag를 추가하도록 명령을 쉽게 수정할 수 있습니다.
https://coreos.com/docs/launching-containers/building/customizing-docker/
—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

mattwilliamson 에 2014년 12월 10일

나는 현재 'boot2docker up'을 할 때마다 이 힘들게 연구한 명령을 실행하여 회사의 개발 환경에서 이 문제를 해결해야 합니다.

boot2docker ssh 'sudo sh -c "echo \"EXTRA_ARGS=\\\"--insecure-registry 10.0.0.0/8\\\"\" > /var/lib/boot2docker/profile && sudo /etc/init.d/docker restart"'

정말 고통스럽습니다. 이 문제로 인해 400명 이상의 직원이 근무하는 회사에서 docker 채택이 중단되었습니다. 모든 것이 통제되는 내부 개발 환경에서는 TLS를 전혀 사용하지 않습니다. 우리는 공개 허브 리포지토리에 대한 사용에 박수를 보내며 모든 경우에 다른 곳에서 강제하는 것은 큰 실수라고 생각합니다.

CleanCut 에 2014년 12월 12일

@CleanCut 아주 잘 넣었습니다. 1.4.0이 왔다가 사라지고 이 문제가 여전히 열려 있다는 사실에 정말 실망했습니다.

justinclayton 에 2014년 12월 13일

@CleanCut 굉장 - boot2docker init 초기 페이로드에 더 많은 정보를 추가하도록 하는 것입니다. 그러면 이 작업을 수행할 수 있습니다.

vm 기반 boot2docker가 아닌 특정 문제를 해결하지는 않지만 --insecure-registry 는 b2d 사용자가 원하는 유일한 사이트 특정 사용자 정의는 아닙니다.

boo2docker 리포지토리에서 이에 대한 풀 요청이나 문제를 제기할 수 있습니까?

SvenDowideit 에 2014년 12월 15일

누군가가 장벽을 낮추는 데 박수를 보낸 프로젝트를 사용하기 위해 장벽을 실제로 높입니다.

2014년 12월 13일 02:10에 Justin Clayton [email protected]이 다음과 같이 썼습니다.
@CleanCut 아주 잘 넣었습니다. 1.4.0이 왔다가 사라지고 이 문제가 여전히 열려 있다는 사실에 정말 실망했습니다.
—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

mattwilliamson 에 2014년 12월 15일

@SvenDowideit 물론입니다. 여기있어

CleanCut 에 2014년 12월 15일

이 스레드에서 이것이 해결된 문제가 아니라는 합의가 있는 것처럼 들립니다. 이 문제를 다시 열 수 있습니까?

justinclayton 에 2014년 12월 15일

예, 부탁합니다!
Le 2014-12-15 15:05, "Justin Clayton" [email protected] a écrit :

이 스레드에는 이것이 해결되지 않는다는 합의가 있는 것 같습니다.
문제; 이 문제를 다시 열 수 있습니까?
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/8887#issuecomment -67055878.

abourget 에 2014년 12월 16일

+1. 추가할 내용은 없지만 이 결정에 대한 불만을 토로하고 싶습니다. 다른 사람들과 마찬가지로 저는 보안이 다른 곳에서 어지럽게 처리되는 로컬 네트워크에서 레지스트리를 실행하고 있습니다. 나는 수십 개의 도커 컨테이너를 실행하고 있는데 '잘 문서화된' 플래그를 추가하기 위해 이제 바운스되어야 합니다.

seanmcl 에 2014년 12월 16일

@bfirsh - 이것은 Docker 데몬 구성 파일과 kill -HUP <dockerdaemonpid> 가 멋진 예 중 하나입니다. 다시 시작할 필요 없이 cfg를 다시 읽도록 트리거하여 컨테이너 다시 시작을 방지합니다.

SvenDowideit 에 2014년 12월 16일

@SvenDowideit 리로드 기능 +1, 간단한 구성으로 서버를 다시 시작하는 것은 정말 짜증납니다.

larrycai 에 2014년 12월 16일

+1

mingfang 에 2014년 12월 17일

내가 상황을 올바르게 이해하지 못한다면 용서해 주십시오. 하지만 이 문제가 내 시나리오의 근본 원인인 것 같습니다( @blevine 에서 설명한 것과 유사합니다. 내 회사에 인증서 재작성 프록시가 있어서 공개 Docker Hub Registry와도 대화). 결국에는 나만의 개인 레지스트리를 설정하고 싶지만 학습 단계에 있으므로 Docker를 채택할지 여부는 아직 확실하지 않습니다. 이것은 채택의 초기 단계에 있는 누군가에게 UX 악몽입니다.

http://stackoverflow.com/questions/27536180/docker-on-mac-behind-proxy-that-changes-ssl-certificate

pohl 에 2014년 12월 18일

커뮤니티가 현재 솔루션에 만족하지 않는 것 같으므로 이 토론을 다시 열려면 +1하세요.

dgolja 에 2014년 12월 31일

https://twitter.com/justinclayton42/status/550143834705780737

이 주제에 대한 확실한 답변을 들을 때까지 모든 각도에서 이 문제를 해결하려고 합니다.

justinclayton 에 2014년 12월 31일

+1, 현재 구성 및 작동이 어렵습니다.

@mhamrah 는 훌륭한 포인트를 만듭니다. 강제하지 말고 사용자가 자신의 필요에 따라 결정하고 구성하도록 하십시오.

jaytaylor 에 2015년 01월 25일

자체 서명된 인증서를 사용하는 레지스트리도 문제입니다. 특히
읽기 전용 파일로 전환한 boot2docker를 사용하는 개발자 컨텍스트에서
체계. 이를 위해서는 추가 및 다른 구성 단계가 필요합니다.
실행 중인 VM을 부트스트랩합니다.

이 스레드에 게시된 모든 사람이 가치와 이점을 보고 있다고 믿습니다.
docker의 도커는 매일 사용하고 있으며
그러나 고통스럽고 불필요한 문제를 겪고 있습니다.
입양을 방해합니다.

우리 모두가 docker를 알고 있는 한 여전히 기술 분야의 많은 사람들에게 알려지지 않았습니다.
특히 기업 내에서. 문서가 도움이 되지만 여전히
후프를 뛰어 넘고 전반적으로 부정적인 영향을 미치는 큰 차단기입니다.
효과.
2015년 1월 25일 일요일 오후 5시 54분 Jay Taylor [email protected] 은 다음과 같이 썼습니다.

+1, 현재 구성 및 작동이 어렵습니다.
@mhamrah https://github.com/mhamrah 는 좋은 지적을 합니다. 강요하지마
사용자가 자신의 필요에 맞게 결정하고 구성하도록 합니다.
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/8887#issuecomment -71398193.

mhamrah 에 2015년 01월 26일

+1 빠르게 시도하는 데 좋습니다.

NoumanSaleem 에 2015년 01월 27일

:+1:

ChiChou 에 2015년 01월 29일

:+1:

jsdir 에 2015년 02월 01일

도커 데몬에 플래그를 전달하지 않고 안전하지 않은 레지스트리에서 가져올 수 없다는 것은 매우 실망스럽습니다. 이것은 우리가 배포하는 모든 새 시스템의 또 다른 번거로움입니다.

toddbu 에 2015년 02월 11일

+1

몇 가지 생각:

호스트 이름 와일드카드를 사용할 수 있습니까? 예: --insecure-registry=*.internal
자체 서명 인증서가 http와 다르게 취급될 수 있습니까?
2와 관련하여 도커가 SSH와 유사한 작업을 수행하고 새 인증서를 볼 때마다 사용자에게 자체 서명된 인증서를 수락하도록 프롬프트를 표시할 수 있습니까? 일치하지 않는 인증서가 있는 경우 큰 소리로 불평할 수 있습니까?

aidanhs 에 2015년 02월 15일

제안을 하는 동안 localhost를 항상 안전한 것으로 취급하지 않는 이유는 무엇입니까? (크롬처럼)

편집: 아, 이미 알고 있습니다.

aidanhs 에 2015년 02월 15일

이것에 +1000.. 구성 다시 로드 기능에 +1, 이것이 이것이 두 배나 나쁜 이유입니다. 나는 확실히 유지 관리자가 데몬의 --insecure-registry 플래그가 배포 및 수정에 얼마나 성가신 것인지 깨달을 것이라고 생각했기 때문에 v1.2를 유지했지만 마이너 릴리스에서는 계속 무시했습니다.

예를 들어 어떤 이유로든 내 개인 레지스트리 IP를 변경해야 하는 경우 모든 VM에서 모든 단일 도커 데몬을 다시 시작해야 합니다. 단지 레지스트리가 변경되었기 때문입니다!? 이 2가지가 그렇게 밀접하게 결합되어서는 안 됩니다. 그리고 사람들에게 0.0.0.0/8을 추가하라고 말하는 것은 처음부터 보안 구현의 전체 목적을 무효화합니다.

push/pull 명령에 이 플래그를 추가하는 것은 데몬 플래그에 대한 폴백으로 너무 분명해 보입니다. 누군가 왜 여전히 싸우고 있지만 그 동안 "가져가기 좋은" 기능을 추가하는지 설명해주십시오.

agquick 에 2015년 02월 17일

@agquick 의 의견은 특히 "가져가서 좋은" 기능을 제공합니다.

seanmcl 에 2015년 02월 17일

이것이 많은 사용자에게 계속되는 고통임을 깨닫고 --insecure 를 pull 추가하는 것을 재고하고 있습니다. @ewindisch 와 저는 이 문제에 연결할 PR 작업을 할 것입니다.

오래 기다리게 해서 죄송하고, 의견을 제시하고 문제점을 지적해주셔서 감사합니다.

tiborvass 에 2015년 02월 23일

👍3

@tiborvass 안전하지 않은 레지스트리에서 가져오기를 허용하고 싶지 _않은_ 동일한 수의 사용자가 있다고 상상할 수 있습니다. Docker는 현재 권한/구성에 대한 세밀한 제어가 없다는 것을 알고 있지만 이것을 "잠글" 수 있는 기회가 있다면 좋은 터치가 될 것이라고 생각합니다.

thaJeztah 에 2015년 02월 23일

어머나 그렇게 해줘! 직접 구현하기로 했습니다.

Bell 네트워크의 내 BlackBerry 10 스마트폰에서 보냈습니다.
보낸 사람: Sebastiaan van Stijn
보낸 날짜: 2015년 2월 23일 월요일 오후 4:53
받는 사람: 도커/도커
답장: 도커/도커
참조: 크리스토퍼 시플락
제목: Re: [docker] --insecure-registry는 "docker pull"에 있어야 합니다(#8887).

@tibor vasshttps://github.com/tiborvass 안전하지 않은 레지스트리에서 가져오기를 허용하지 않으려는 동일한 수의 사용자가 있다고 상상할 수 있습니다. Docker는 현재 권한/구성에 대한 세밀한 제어가 없다는 것을 알고 있지만 이것을 "잠글" 수 있는 기회가 있다면 좋은 터치가 될 것이라고 생각합니다.

—
이 이메일에 직접 답장하거나 Gi tHubhttps://github.com/docker/docker/issues/8887#issuecomment -75644600에서 확인하세요.

octalthorpe 에 2015년 02월 24일

@thaJeztah 나는 --insecure-registry 플래그를 docker pull 가질 수 없다는 것을 의미하는 어떤 사용 사례를 생각하고 있는지 알아내려고 노력 중입니다.

사용자가 보안 레지스트리에서 실수로 MITMed되는 것을 원하지 않으면 --insecure-registry 전달을 피할 수 있습니다.
사용자가 모든 이미지가 보안 레지스트리(예: '기업' 시나리오)에서 가져온 것임을 사용자에게 적용하려는 경우 어쨌든 현재로서는 실제로 이를 전혀 적용할 수 없습니다!

그렇다면 docker pull --insecure-registry 무엇을 금지하는지 자세히 설명해 주시겠습니까?

두 번째 요점을 자세히 설명하기 위해 도커가 작동하는 방식에 대해 다시 생각하지 않고 어떻게 이것을 잠글 수 있는지 알 수 없습니다! 자체 레지스트리 풀러를 작성하여 얻을 수 있는 tarball docker load 을 제쳐두고 docker run -v 를 사용하여 privs를 에스컬레이션하고 데몬 인수에 무언가를 추가하는 것 외에는 모든 항목을 우회하는 매우 간단한 방법이 있습니다. '시행':

$ docker pull registry:5000/aidanhs/blah                                    
FATA[0004] Error: v1 ping attempt failed with error: Get https://registry:5000/v1/_ping: EOF. If this private registry supports only HTTP or HTTPS [...]
$ socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 &
[1] 22924
$ docker pull localhost:5000/aidanhs/blah
Pulling repository localhost:5000/aidanhs/blah
[...]
Status: Image is up to date for localhost:5000/aidanhs/blah:latest
$ docker tag localhost:5000/aidanhs/blah registry:5000/aidanhs/blah

aidanhs 에 2015년 03월 02일

사용자가 모든 이미지가 보안 레지스트리(예: '기업' 시나리오)에서 가져온 것임을 사용자에게 적용하려는 경우 어쨌든 현재로서는 실제로 이를 전혀 적용할 수 없습니다!

이것이 시나리오입니다.

두 번째 요점을 자세히 설명하기 위해 도커가 작동하는 방식에 대해 다시 생각하지 않고는 이것을 어떻게 잠글 수 있는지 알 수 없습니다.

나는 (현재로서는) 그것을 잠글 방법이 없다는 것을 충분히 이해합니다. docker.sock 대한 액세스 권한이 있는 사용자는 사실상 루트 액세스 권한이 있으므로 원하는 대로 변경할 수 있습니다. 또한 여전히 데몬 플래그를 변경하고 데몬을 다시 시작할 수 있습니다.

그러나 docker pull --insecure-registry .. 에서 오류("안전하지 않은 레지스트리가 비활성화됨")가 발생하면 사용자에게 명확한 신호를 _하지_ 않습니다. 이 오류는 예를 들어 찾은 몇 가지 예를 시도할 때 사용자에게 원하지 않음을 _알립니다. 어딘가에.

그렇다면 모든 경우를 커버할까요? 아뇨. _아파요_, 저도 그렇게 생각하지 않습니다.

thaJeztah 에 2015년 03월 02일

나는 개인적으로 그것이 실제로는 매우 피상적인 보호일 때 "오 봐, 도커가 이것을 시행한다"고 생각하도록 오도하기 때문에 득보다 실이 더 많을 것이라고 생각합니다. 계속할 수는 있지만 결국 취향의 문제라고 생각합니다.

aidanhs 에 2015년 03월 02일

그것이 얼마나 아플 수 있는지 찾고 있다면 위로 스크롤하십시오. 이 접근 방식에는 채택에 장벽을 만드는 무수히 많은 UX 문제가 있으며, 모두 위에 자세히 설명되어 있습니다.

justinclayton 에 2015년 03월 02일

나는 주로 docker가 sub를 죽이지 않고 다시 시작할 수 없다는 문제를 봅니다.
컨테이너. 구성/재구성을 훨씬 어렵게 만듭니다.

2015년 4월 15일 수요일 오후 8시 11분, Jan Krueger [email protected]
썼다:

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

thefallentree 에 2015년 04월 15일

아직 이 문제에 대한 조치가 취해지지 않았다는 점에 매우 실망스럽습니다. 분명히 많은 사람들에게 고통을 주고 있습니다.

많은 사람들에게 분명히 짜증나는 일이며, 지금 적극적으로 제 일을 차단하고 있습니다. 안전하지 않은 레지스트리에서 가져오기를 허용하기 위해 Docker 데몬을 다시 시작해야 하는 것은 상황에 따라 성가신 것에서 완전히 불가능한 것까지 다양합니다.

이것을 하지 않는 것에 대한 주된 주장은 시스템 관리자가 시스템을 잠글 수 있어야 하고 보안 저장소에서 이미지만 가져올 수 있도록 해야 한다는 것입니다. 그 사용 사례는 확실히 현실적이지만 잘못된 기본값이라고 생각합니다. pull 에서 --insecure-registry 사용을 비활성화하는 --no-insecure 와 같이 시작할 때 데몬에 전달할 수 있는 플래그를 갖는 것이 훨씬 더 합리적입니다. 그렇게 하면 관리자가 정말로 원할 경우 사물을 잠글 수 있습니다.

jdoliner 에 2015년 04월 16일

이 동작을 매우 원하는 사람들을 위해 다음 해결 방법을 제공합니다. 풀에 Docker API를 사용하지 않기 때문에 모든 사용자에게 실행 가능하지 않을 것임을 이해합니다. 그것도 좀 느립니다...

내 프로젝트 'docker-pull' 참조 :

다음과 같이 사용합니다.

docker run ewindisch/docker-pull --insecure-registry 10.0.0.0/16 10.0.1.2/someimage | docker load

모든 레지스트리를 안전하지 않은 것으로 허용하는 것도 가능합니다.

docker run ewindisch/docker-pull --insecure 10.0.1.2/someimage | docker load

실제로 이것을 하는 것은 _여전히_ 매우 바람직하지 않다는 것을 상기시키겠습니다.

ewindisch 에 2015년 04월 16일

@ewindisch 멋진 해킹.

또 다른 좋은 솔루션은 tcp 터널을 사용하는 것입니다.

$ docker pull host:5000/image #fails
$ ssh -N -L 5000:host:5000 user<strong i="8">@host</strong>
$ docker pull localhost:5000/image #works

jdoliner 에 2015년 04월 16일

둘 다 환상적인 해결 방법입니다!

justinclayton 에 2015년 04월 16일

저도 기본값이 바뀌었으면 합니다.

2015년 4월 15일 오후 6시 14분에 Joe Doliner [email protected]이 다음과 같이 썼습니다.
아직 이 문제에 대한 조치가 취해지지 않았다는 점에 매우 실망스럽습니다. 분명히 많은 사람들에게 고통을 주고 있습니다.
많은 사람들에게 분명히 짜증나는 일이며, 지금 적극적으로 제 일을 차단하고 있습니다. 안전하지 않은 레지스트리에서 가져오기를 허용하기 위해 Docker 데몬을 다시 시작해야 하는 것은 상황에 따라 성가신 것에서 완전히 불가능한 것까지 다양합니다.
이것을 하지 않는 것에 대한 주된 주장은 시스템 관리자가 시스템을 잠글 수 있어야 하고 보안 저장소에서 이미지만 가져올 수 있도록 해야 한다는 것입니다. 그 사용 사례는 확실히 현실적이지만 잘못된 기본값이라고 생각합니다. 풀에서 --insecure-registry 사용을 비활성화하는 --no-insecure와 같이 시작할 때 데몬에 전달할 수 있는 플래그를 갖는 것이 훨씬 더 합리적으로 보입니다. 그렇게 하면 관리자가 정말로 원할 경우 사물을 잠글 수 있습니다.
—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

jaytaylor 에 2015년 04월 16일

그래서 이것은 다시 열리고 4 개월 후 현재 상태는 아무 것도 아니며 해결 방법으로 여러 가지 해킹을 사용합니까? :-/ 다른 곳에서 진행 중인 이에 대한 논의가 있습니까? 아니면 그냥 죽은 것입니까?

예, +1

echox 에 2015년 06월 16일

+1

devsli 에 2015년 06월 18일

+1

AngryHacker 에 2015년 06월 18일

나는 이 페이지에서 "+1"의 인스턴스를 세었고 그 수는 지금까지 31에 이르렀음을 지적하고 싶습니다. 그것은 실제로 정확한 문자열을 포함하지 않는 다른 지원 주석을 계산하지 않습니다.

CleanCut 에 2015년 06월 18일

여기서 문제는 끌어오기 시 --insecure 를 활성화하면 제어권이 속한 sysadmin에서 제어권을 빼앗는다는 것입니다.
보안은 어렵고 보안을 완화하기 위해 변경하는 것은 작은 결정이 아닙니다.
또한 현재 설정에 완벽하게 만족하는 사람들은 여기에 오지 않을 것이며 -1 이것도 마찬가지입니다.
반면에...
레지스트리에서 안전하지 않은 풀을 사용하도록 데몬을 다시 구성하는 것은 간단합니다.
자체 서명 인증서를 설정하고 도커를 다시 구성할 필요도 없습니다.

cpuguy83 에 2015년 06월 18일

"Sysadmin"은 docker의 한 사용 사례이지만 "개발자"와 "non-sysadmin"은 똑같이 유효한 사용 사례입니다. 개발자의 경우 --insecure 옵션을 제공하면 워크플로의 마찰이 줄어듭니다.

아마도 우리는 시스템 관리자가 --insecure 옵션의 사용을 _거부_하도록 지정할 수 있는 옵션을 제공함으로써 두 세계의 장점을 모두 가질 수 있을 것입니다. 그렇게 하면 시스템 관리자가 여전히 모든 권한을 가지지만 시스템 관리자가 아닌 경우 워크플로 문제를 처리할 필요가 없습니다.

시스템 관리자에게는 사소한 것이 시스템 관리자가 아닌 사람들에게는 놀라울 정도로 번거로울 수 있습니다. 저는 거의 24명의 개발자가 우리 개발 그룹에서 사용되는 5개의 다른 OS에서 이 구성 변경을 수행(및 다시 작성)하도록 도와야 했습니다. 저는 실제로 환경에 대한 구성 변경을 자동화하는 스크립트를 유지 관리합니다.

우리의 시스템 관리자는 현재 우리 레지스트리에 자체 서명된 인증서를 설정하지 않을 것입니다.

어쨌든 이것이 변하지 않더라도 결국 사람들은 그것에 적응하게 될 것입니다. 다음 번에 시스템 관리자가 레지스트리를 유지 관리할 때 내가 겪고 있는 고통이 모두 사라질 것이라고 생각합니다. 그 시점에서 실제 SSL 인증서를 설치할 수 있어야 하기 때문입니다. 아마도 그것이 요점일 것입니다. 앞으로의 불안한 길보다 안전한 길을 더 쉽게 가도록 하라.

CleanCut 에 2015년 06월 18일

👍1

:+1: @CleanCut , 그리고 다른 모든 사람들이 다 말했습니다. 저는 개발자 케이스로만 작업하고 도커 데몬을 재구성하는 것은 시간 낭비일 뿐입니다.

andrask 에 2015년 08월 02일

오늘 도커 소켓에 액세스할 수 있다면 당신은 시스템 관리자입니다. 당신은
이미 루트, "도커 로드"가 있고 이미 수행할 해결 방법이 있습니다.
안전하지 않은 레지스트리 풀. 클라이언트에 이미지 옵션을 추가하는 것은
현상 유지보다 덜 안전합니다.

그러나 의도적으로 증가시키는 것에 대해 말할 것이 있습니다.
다른 사람을 유인하기 위해 잘못된 일을 하려는 개발자의 마찰
올바른 일을 하도록 합니다.
2015년 6월 18일 오후 12시 41분에 "Brian Goff" [email protected]이 작성했습니다.

여기서 문제는 --insecure on pull을 활성화하면 제어권이 사라집니다.
그것이 속한 sysadmin에서.
보안은 어렵고 보안을 느슨하게 하는 변경은 작은 일이 아닙니다
결정.
또한 현재 설정에 완벽하게 만족하는 사람들은 가지 않습니다.
여기에 와서 -1 이것도.
반면에...
보안되지 않은 풀을 사용하도록 데몬을 다시 구성하는 것은 간단합니다.
기재.
자체 서명된 인증서를 설정하는 것도 간단합니다.
도커를 다시 구성하십시오.
—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/docker/docker/issues/8887#issuecomment -113213172.

ewindisch 에 2015년 08월 02일

@ewindisch @tiborvass 읽기, https://github.com/docker/docker/issues/8887#issuecomment -75638745;

이것이 상당한 수의 사용자에게 계속되는 고통임을 깨닫고 우리는 --insecure to pull을 추가하는 것을 재고하고 있습니다. @ewindisch 와 저는 이 문제에 연결할 PR 작업을 할 것입니다.
오래 기다리게 해서 죄송하고, 의견을 제시하고 문제점을 지적해주셔서 감사합니다.

그게 아직도 현 위치인가요? (PR이 만들어 졌다고 생각하지 않습니다)

thaJeztah 에 2015년 08월 02일

👍1

+1

eddwardo 에 2015년 08월 17일

이것은 매일 나를 괴롭히고 짜증나게 합니다.

:( 슬픈 콘헤드.

sleaze 에 2015년 08월 19일

--insure는 개발자 POV에서 완전히 의미가 있습니다. 보안을 위해 환경에서 도커를 구현하는 사람에게 달려 있습니다.

ppiersonbt 에 2015년 08월 20일

+1

tony-kerz 에 2015년 08월 23일

:+1:

tim-kretschmer-c2fo 에 2015년 08월 28일

_USER POLL_

_이 토론에 변경 사항이 있을 때 알림을 받는 가장 좋은 방법은 오른쪽 상단의 구독 버튼을 클릭하는 것입니다._

아래 나열된 사람들은 무작위 +1로 귀하의 의미 있는 토론에 감사했습니다.

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@밍팡
@djannot
@프러스티
@tobegit3hub
@testaccountspivey
@mhamrah
@mwooker
@ryan-stateless
@jonathanvaughn
@gollawil
@ebartz
@maelp

GordonTheTurtle 에 2015년 09월 14일

+1

tjadams 에 2015년 09월 15일

+1

thrap 에 2015년 09월 21일

+1

폐쇄된 네트워크에서 내부 레지스트리를 사용하므로 이를 추가하면 배포가 더 쉬워집니다.

halvorgb 에 2015년 09월 21일

+1

devsli 에 2015년 09월 21일

이 문제가 할로윈까지 여전히 열려 있다면 모든 +1이 1년 동안 우리의 docker-sorrows에 익사 기념일 파티를 해야 한다고 생각합니다.

mhamrah 에 2015년 09월 21일

슬픔의 파티에 +1!

2015년 9월 14일 오후 1시 32분에 Gordon [email protected] 은 다음과 같이 썼습니다.
사용자 설문조사
이 토론에 변경 사항이 있을 때 알림을 받는 가장 좋은 방법은 오른쪽 상단에 있는 구독 버튼을 클릭하는 것입니다.
아래 나열된 사람들은 무작위 +1로 귀하의 의미 있는 토론에 감사했습니다.
@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@밍팡
@djannot
@프러스티
@tobegit3hub
@testaccountspivey
@mhamrah
@mwooker
@ryan-stateless
@jonathanvaughn
@gollawil
@ebartz
@maelp
—
이 이메일에 직접 회신하거나 GitHub에서 확인하세요.

jaytaylor 에 2015년 09월 21일

+1

sroebuck 에 2015년 09월 21일

슬픔의 파티 +1

사람들에게 "+1" 사용을 중단하라고 지시하는 봇 소유자에게:
우리는 그것을 처리하기 위해 +1을 사용하고 더 이상 할 말이 없습니다.

cornfeedhobo 에 2015년 09월 23일

+1

nicornk 에 2015년 09월 30일

+1

sebadiaz 에 2015년 10월 01일

SSH 터널 사용을 포함하여 몇 가지 해결 방법이 있지만 레지스트리 호스트에 ssh 계정이 필요합니다. 다음 해결 방법은 필요하지 않습니다.

다음과 같이 레지스트리 포트 포워더를 실행합니다.

docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder

그런 다음 로컬 레지스트리에서 이미지를 가져오거나 푸시합니다.

docker pull localhost:5000/your-image
docker push localhost:5000/my-image

rsmoorthy 에 2015년 10월 08일

👍1

@rsmoorthy 환상적입니다. 이 현재 제한의 무의미함을 간결하게 보여주셔서 감사합니다.

Docker, 이 특정 배터리를 다시 포함시키십시오.

justinclayton 에 2015년 10월 09일

+1

JasonHartmann 에 2015년 11월 06일

사용자에 대한 보안을 강력하게 권장하는 것이 도커 사용에 대한 내 생각을 심각하게 흔들었다고 말해야 합니다. 나는 시작할 때 --insecure-registry 플래그를 데몬에 추가할 수 있다는 것을 완전히 이해하고 항상 작동하지 않거나 불가능할 수 있는 모든 이유에 대해서는 설명하지 않겠습니다.

Docker 개발자에게 질문이 있습니다. 최종 사용자에게 가장 적합한 것이 무엇인지 알고 있다고 생각하십니까? 저는 레지스트리가 실행되는 네트워크가 이미 완전히 암호화되어 있기 때문에 레지스트리에 SSL이 전혀 필요하지 않습니다. 그렇다면 도대체 내가 암호화된 트래픽을 암호화하는 이유는 무엇입니까? 이미 복잡하고 방대한 시스템에 오버헤드를 추가하고 조각을 이동하는 것 외에 실제로 어떤 일을 하고 있습니까?

또한 사람들이 인터넷을 통해 개인 레지스트리를 사용하는 경우가 실제로 있습니까? 그런 의미에서 인증에 대해 무엇을 합니까? 이미지를 아래로 당겨서 찢을 수 없습니까? 다른 컴퓨터로 가는 도중에 가로채려고 하는 대신?

TL;DR +1

supernomad 에 2015년 12월 01일

👍4

+1

Koriit 에 2015년 12월 02일

@Supernomad님 말씀 잘 하셨습니다.

mingfang 에 2015년 12월 02일

docker 측면에서 확인하십시오. 공식적으로 구현하지 않는 것이 더 나은 문제 중 하나이지만 고통을 완화하기 위해 가능한 많은 해결 방법이 있습니다. 큰 소리로 비명을 지르는 일부 사용자는 도커를 "의도적으로 안전하지 않음"으로 표시하고 평판을 영원히 손상시키는 경쟁 제품보다 덜 고통스럽습니다.
그러고 보니 +1.

belooussov 에 2015년 12월 07일

@tiborvass @ewindisch 이 문제는 1년이 넘었습니다. 재평가를 받으라고 하신지 8개월이 넘었습니다. 당신은 그것을 평가 했습니까? 그렇다면 무엇이 결정되었습니까? 형제를 교수형에 처하게 두지 마십시오! :-)

이 문제가 처음에 열렸다 닫혔다가 다시 열렸기 때문에 커뮤니티는 주로 이 기본 설정의 무의미함을 보여주기 위해 이 문제를 스스로 해결할 수 있는 다양한 방법을 생각해 냈습니다.

ssh -N -L 5000:host:5000 user<strong i="10">@host</strong> && docker pull localhost:5000/lolsecurity
socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 && docker pull localhost:5000/lolsecurity
docker-machine create -d virtualbox --engine-insecure-registry 0.0.0.0/0 lolsecurity
docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder && docker pull localhost:5000/lolsecurity

말할 것도 없이 CoreOS는 이제 --insecure-registry 0.0.0.0/0 를 기본값으로 제공합니다. 이러한 예는 "sysadmin"과 "개발자" 사이에 분리된 관심이 있다는 생각이 2015년에 현재 대부분 임의적이고 가짜라는 것을 분명히 보여줍니다. 에반젤리스트)는 처음부터 누군가를 "sysadmin"이라고 부르기를 여전히 귀찮게 하는 전통적인 작업에서 벗어나 이 추세를 크게 가속화했습니다.

어쨌든, 나는 이것이 어떤 식 으로든 영원히 닫히는 것을보고 싶습니다.

justinclayton 에 2015년 12월 30일

👍6

+1

jhinds 에 2016년 01월 06일

+1

tdensmore 에 2016년 01월 12일

+1

JonathanRosado 에 2016년 02월 05일

내 SSL 개인 키로 Docker Registry를 신뢰해야 하는 이유는 무엇입니까?

이 간섭으로 인해 건조에 빠진 다른 CoreOS 사용자들을 위해,
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registry-without-ssl-configured

dzrw 에 2016년 02월 05일

👍2

@politician 은 나 자신이 더 낫다고

사실 저는 도커에서 완전히 마이그레이션하는 과정에 있으며 결정에 만족할 수 없었습니다. 저는 현재 git과 lxc를 사용하고 있으며 docker보다 빠를 뿐만 아니라 실제로 완전히 그리고 완전히 부정확하긴 하지만 다른 회사가 생각하는 것이 아니라 우리 회사에 가장 좋은 것을 할 수 있습니다.

나는 로켓, raw lxc, qemu(동일하지는 않지만 여전히 더 나은)와 같이 솔직히 docker보다 나은 대안을 살펴보는 것이 좋습니다.

나는 지금부터 컨테이너를 고려하고 있는 모든 사람에게 이 행동 방침을 강력히 제안할 것입니다. 최소한 docker의 사람들이 자신이 모른다는 것을 깨닫고 보안 측면에서 최종 사용자에게 가장 좋은 것이 _절대적으로_ 전혀 모른다는 점을 강조합니다.

supernomad 에 2016년 02월 06일

👍3

저는 포기하고 싸구려 전용 SSL인증서를 샀습니다. CA 시스템에 대한 Docker CLI 종속성은 너무 강합니다. 자체 서명된 인증서는 작동을 방해할 뿐만 아니라 단순히 작동하지 않습니다.

docker-machine은 down/up 사이의 ca.crt 재정의를 삭제합니다.
기본 이미지에는 CI 불가능을 위한 무인 항공기와 같은 도구를 만드는 인증서가 포함되어 있지 않습니다.
docker CLI는 인증서에 비표준 폴더를 사용하므로 기억해야 할 사항입니다.
18시간 후에 작동시키더라도 항상 다른 것이 고장난 것 같은 잔소리를 느낄 것입니다.

결론: Docker는 자체 서명된 인증서를 사용하려고 할 때 운영 팀에 지속적이고 지속적인 패널티를 가합니다.

curl -k 는 영원히 존재했기 때문에 더욱 답답합니다.

dzrw 에 2016년 02월 09일

😕2 👍1

+1

stephenenelson 에 2016년 03월 31일

그들이 이것에 대해 신경 쓰지 않는다는 것은 꽤 슬픈 일입니다. 일부 개발자가 도커를 만지작거리고 자신의 환경을 호스팅하려는 경우 일반적으로 SSL 인증서 및 기타 항목을 엉망으로 만들고 싶지 않습니다. 또한 집에 공개되지 않은 자체 서버가 있는 경우 SSL이 필요하지 않습니다.

buehler 에 2016년 04월 16일

@buehler 는 데몬 설정이나 daemon.json 구성 파일에 --insecure-registry 옵션을 추가할 수 있습니다. 그런 다음 한 번만 구성하고 플래그를 지정할 필요 없이 끌어오기만 하면 됩니다.

thaJeztah 에 2016년 04월 16일

👍1

업데이트: 우리는 이후로 인프라에서 레지스트리를 제거 하고 Azure Blob 스토리지 지원과 함께 dogestry의 사용자 지정 포크 를 사용하도록 되돌렸습니다. 우리는 Docker Registry가 레이어를 복제하고 있고 우리 머신의 디스크 공간이 부족하여 중단이 발생했다는 것을 발견했습니다. 레지스트리는 우리에게 시간을 낭비하는 막다른 골목으로 밝혀졌습니다.

dzrw 에 2016년 04월 18일

@buehler 단지 구성에이 줄을 추가 @thaJeztah의 제안을 구체화하기 :

--insecure-registry 0.0.0.0/0

원하는 레지스트리에 액세스할 수 있습니다. 테스트 항목에 잘 작동합니다.

@politician 이미지에 다른 저장소로 태그가 지정되면 복제가 발생합니다. Blob 삭제가 없다는 것이 훨씬 더 큰 문제입니다.

andrask 에 2016년 04월 18일

👍1

@thaJeztah 그렇게 하기 쉽지만 사용자의 80%(임의의 수)가 이 작업을 수행해야 하는 경우 기본값으로 설정하십시오.

justinclayton 에 2016년 04월 20일

@justinclayton 아니요; 해당 옵션을 설정하면 기본적으로 "레지스트리에 대한 보안 통신과 관련된 모든 문제 무시"라고 표시되므로 중간자 공격을 "즉시" 허용하거나 데몬이 비 TLS "http://"로 폴백할 수 있습니다. . Docker는 이미 127.x.x.x 범위의 레지스트리에 대해 기본값으로 설정했습니다.

로컬 레지스트리가 있고 이에 대한 인증서를 생성하지 않으려는 경우 데몬 옵션에 --insecure-registry 를 추가하는 데 1분 미만이 소요됩니다. 기본적으로 설정되어 있는 것이 아니라 의도적인 조치여야 합니다.

thaJeztah 에 2016년 04월 20일

👍1

@thaJeztah 나는 당신의 주장을 이해하지만 그것으로 끝날 수는 없습니다. 이것이 데몬 측에 있기 때문에 새로운 개발자를 위한 사용자 경험에는 상당한 격차가 있습니다. 이것이 고통스러운 _majority_ 시나리오는 docker.com의 지침에 따라 Mac에서 Docker Toolbox 설치 프로그램을 다운로드하고 실행하는 새로운 개발자입니다. 완료되면 즉시 docker pull <internally-signed-registry>/foo 를 실행하려고 하고 오류가 표시됩니다. 이것이 진정한 문제입니다. 아마도 이 문제의 이름을 바꿔야 한다는 의미일까요?

이 문제를 해결할 수 있는 다른 방법도 많이 있습니다. 커뮤니티와 회사가 다음 중 하나에 동의할 수 있다고 확신합니다.

이 문제의 현재 이름은 '--insecure-registry가 "docker pull"에 있어야 함'입니다. 이 문제는 아직 미해결 상태이므로 이 옵션이 아직 고려 중이라고 가정해야 합니다.
이에 대한 단일 명령 솔루션이 초보자에게 간단하게 제공(및 문서화)된다면 이 문제가 해결될 것입니다.
우리의 경우 레지스트리는 _is_ 보안되어 있습니다. 빌드 환경의 다른 모든 것과 마찬가지로 내부 CA에서 서명한 인증서를 사용합니다. 이것은 충분한 보안입니다. 데몬이 어떻게든 MacOS의 인증서 저장소를 존중할 수 있다면 이 골칫거리도 사라질 것입니다.
도구 상자 설치 프로세스 중에 인증서를 추가하거나 이 구성을 docker-machine에 만들라는 메시지가 표시되면 그것도 괜찮을 것입니다.

이 문제의 70명 이상의 참가자에게 이 문제에 대해 어떤 방향으로 갈 계획인지 알려주거나, 문제를 종료하여 중단되지 않도록 하십시오. 감사 해요.

justinclayton 에 2016년 04월 21일

👍6

@tajeztah
실행 중인 모든 컨테이너를 다시 시작하지 않고 단일 --insecure-registry를 데몬 옵션에 추가할 수 있는 방법은 없습니다. 이것이 주요 문제 중 하나입니다. 다시 시작하지 않고 구성을 다시 로드할 수 없습니다(문제는 2013년부터 지속됨). 데몬에 옵션을 추가하고 다시 시작하지 않고는 다른 안전하지 않은 레지스트리에서 이미지를 가져올 수 없습니다. 그리고 오늘날 우리는 여전히 그 문제를 해결하기 위한 명확한 로드맵을 가지고 있지 않습니다.

apakhomov 에 2016년 04월 26일

@apakhomov가 다시 시작하지 않고 업데이트 할 수 있습니다 구성 변경의 목록에 추가 할 수있을 것 같아요 https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading. 그것에 대해 별도의 문제를 열 수 있습니까?

thaJeztah 에 2016년 04월 26일

👍2

+1.

일부 PaaS 제공업체는 데몬에 대한 액세스 권한을 부여하지 않고 사용자를 위해 사설 네트워크를 실행합니다(예: Jelastic).

Tails 에 2016년 05월 07일

docker에 여러 개의 안전하지 않은 레지스트리를 추가할 수 있습니까?
--insecure-registry xxxx:xxxx --insecure-registry zzzz:zzzz와 같은 것

kkorada 에 2016년 05월 16일

@kkorada --insecure-registry=0.0.0.0/0 는 Docker가 이전처럼 작동하도록 합니다.

mingfang 에 2016년 05월 16일

@kkorada 예, 여러 레지스트리를 지정할 수 있습니다(플래그는 --insecure-registry=[] - 대괄호는 여러 번 지정할 수 있음을 나타냄).

또한 docker 1.12의 경우 데몬을 다시 시작하지 않고 daemon.json 구성 파일에서 이 옵션을 구성할 수 있습니다. 여기에서 공개 풀 요청을 참조하십시오: https://github.com/docker/docker/pull/22337

thaJeztah 에 2016년 05월 16일

@mingfang 과 @thaJeztah 감사합니다

kkorada 에 2016년 05월 16일

@mhamrah 및 @justinclayton과 같이 제안 , 나 또한 망할 놈의 SSH 및 TLS를 모두 사용하여 respository에 대한 액세스를 허용하는 방법과 유사 TLS, 이외에 SSH를 사용하는 솔루션을 추천 할 것입니다. 이것은 @justinclayton이 나열한 ssh 해결 방법을 사용할 수 있습니다 .

내 주장을 뒷받침할 데이터는 없지만 방화벽 뒤에서 실행되는 개인 레지스트리가 개방형 인터넷에서 실행되는 레지스트리보다 더 많을 것이라고 생각합니다. 이 경우 ssh는 구성하기 쉽고 TLS보다 안전합니다.

또한, 충분히 안전한 내부 가상 머신 내에서 실행되는 docker push 및 로컬 개인 레지스트리와 며칠 동안 싸운 후(그리고 자체 서명된 인증서를 생성하는 데 더 많은 시간을 들이고) 정말 감사하게 되었습니다. rkt --insecure-options=image,tls,http .

derekmahar 에 2016년 07월 12일

👍5

이것이 클라이언트 설정이 아니라는 것이 화가 납니다. 분명히 안전하지 않은 관행을 조장하기 때문에 기본적으로 켜져 있어서는 안 됩니다. 그러나 데몬에 설정을 지정하면 디버깅 목적이나 로컬 개발 환경에서 매우 비실용적입니다.

현재 사용 사례: docker compose로 개발 환경 실행. 환경에는 로컬 도커 레지스트리가 필요합니다. 이는 전적으로 로컬 VM에서 실행하기 위한 것입니다.

도커 방식: 각 개발자 시스템에서 보안되지 않은 레지스트리를 활성화하도록 도커 시스템을 구성하는 방법을 설명하며, 이미 도커 시스템이 있는 경우 도커 시스템을 다시 생성하거나 직접 구성을 편집해야 할 수 있습니다.

해키 솔루션: 레지스트리를 사용해야 하는 각 컨테이너에서 실행되는 socat은 로컬 호스트로 리디렉션됩니다.

일을 쉽게 만드는 것이 아니라...

mattmb 에 2016년 07월 26일

👍8

+1

--insecure 클라이언트 구성이 아닌 것이 정말 유감입니다!
그것은 우리에게 많은 고통을 줄 뿐만 아니라 위의 많은 설명과 매우 유사합니다.
기본적으로 --insecure-registry=0.0.0.0/0을 설정하십시오. pr은 docker 명령과 docker-compose 구성에 전달하는 방법을 제공합니다.

luchesar 에 2016년 10월 09일

👍8

+1

zhao-ji 에 2016년 11월 10일

+1

GongT 에 2016년 12월 13일

연례 +1 Pity Party를 다시 할 시간입니까?

2016년 12월 13일 오전 1시에 沙包妖梦[email protected]에서 다음과 같이 썼습니다.
+1
—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

jaytaylor 에 2016년 12월 13일

😕4

이미지 계층이 서명된 경우 보안을 위해 CA PKI를 사용할 필요가 없습니다. apt/yum 작동 방식도 참조하십시오. 또한 LAN에서 SSL을 사용하는 것은 거의 의미가 없으며 클라우드 환경에서는 인증서 자체를 제외하고 좋은 임의성 소스를 위해 프로비저닝해야 함을 의미합니다(https://lukehinds.github.io/2015-03 참조). -03-엔트로피-인-더-클라우드/).

간단히 말해서 필요하지 않은 경우 사용자에게 강요하지 마십시오.

방금 관련된 #29736을 열었습니다.

gm42 에 2016년 12월 27일

👍1

+1, 클라이언트 측 --insecure-registry 플래그가 옵션이 아닌 경우 docker pull 및 docker push 사용할 신뢰할 수 있는 인증서를 지정하는 방법이 있어야 합니다. 모든 사람이 OS 수준에서 인증서를 신뢰하거나 Docker 데몬을 가지고 놀 수 있는 액세스 권한이 있는 것은 아닙니다.

호스팅된 CI 서버(도커 이미지를 빌드하고 개인 레지스트리에 푸시하는 데 사용됨)는 해당 수준의 액세스 권한이 없을 수 있는 좋은 예입니다.

ajhodges 에 2017년 03월 15일

+1

ericpulvino 에 2017년 03월 23일

@ajhodges https://docs.docker.com/registry/insecure/#using -self -signed-certificates

tiborvass 에 2017년 03월 24일

@tiborvass
sudo 액세스 권한이 있는 경우에만 작동합니다...

ajhodges 에 2017년 03월 24일

+1 개발자가 도커를 사용하지 않도록 하는 좋은 방법

zadam 에 2017년 04월 03일

😕1 👍1

+1, docker login 대한 --insecure-registry도 보고 싶습니다.

당신이 의식적으로 그것을 하고 있기 때문에 나는 이것을 보안 문제로 보지 않습니다. 권한이 없는 사람이 루트 액세스 권한을 얻은 경우에도 보안이 제공되지 않습니다. 이 제한은 실제로 어떤 장점이 있습니까?

나쁜 의도가 있었다면 악성 도커 이미지 를 신뢰할 수 있는 DockerHub에 업로드하면 됩니다.

PhilippHeuer 에 2017년 04월 07일

👍1

+1 솔직히 이것은 마음을 혼란스럽게합니다.

navels 에 2017년 05월 11일

👍1

고통 열차에 +1.

Ichimonji10 에 2017년 05월 11일

게다가 빌어먹을 하나!

harindaka 에 2017년 05월 12일

😄2

이에 대한 PR이 열려 있습니까?

jaytaylor 에 2017년 05월 12일

AFAIK가 아닙니다. 위의 링크는 내 코드 중 일부가 이 문제를 참조하기 때문에 생성되었습니다. 스팸을 여기에서 진정시키기 위해 잠시 동안 해당 참조를 가져오겠습니다.

Ichimonji10 에 2017년 05월 12일

역시 +1...

waldman 에 2017년 08월 10일

+1

mmchen 에 2017년 09월 26일

+1 , deamon.json 에 설정을 추가하고 도커를 다시 시작하는 것은 매우 불편합니다.

다른 기계에는 다른 운영 체제가 있습니다. 일부는 yum 、 apt-get 에서 docker를 설치하고 일부는 바이너리를 직접 사용합니다. 그래서 나는 그것을 감지하고 dockerd를 올바르게 다시 시작해야합니다 .... 그것은 재앙입니다.

난 그냥 docker pull need --insecure-registry flag 를 강조합니다!

eromoe 에 2017년 11월 10일

👍5

3년밖에 안됐어 이제 희망을 잃지 말자

r-chris 에 2017년 12월 05일

👍13 😄9 🎉2

범프 🤣

justinclayton 에 2018년 02월 07일

+1

petr-stupka 에 2018년 03월 27일

+1

sherif84 에 2018년 04월 18일

이것이 사용자가 자신의 레지스트리를 안전한 것으로 설정하도록 부추긴다는 주장은 주제넘을 뿐만 아니라 핵심 포인트를 놓치고 있습니다. 많은 사람들이 작업 작업을 수행하기 위해 루트 계정에 액세스해야 하는 위치에 작업을 배치하고 도커 레지스트리가 많이 이동합니다.
운영 보안 관점에서 이러한 결합은 더 큰 보안 위험을 생성합니다.

둘째, 사설 네트워크(예: 다중 계층 클라우드 호스팅 응용 프로그램)에서는 레지스트리 보안이 필요하지 않으며 맨 위에 있는 기술 구현을 더욱 복잡하게 하여 보안 관리 계층(자동 도커 인증/ 새로 고침) 보안 도커 레지스트리가 사용되는 모든 곳.

최소한의 고정 표시기 데몬이 불안 레지스트리 매개 변수가 전달 될 수 있도록 구성해야한다는 움직임 보안 적절한 위치에 디자인 -. 고정 표시기 자체의 관리자의 손에, 외부.

mmpfeffer 에 2018년 04월 26일

👍10

FWIW 쉘 스크립트에서 json 구성을 패치하는 것이 주요 골칫거리이기 때문에 "안전하지 않은 레지스트리 목록에 일부 레지스트리 추가" 명령에 만족합니다.

mjambon 에 2018년 09월 13일

👍1

+1

dmwoods38 에 2018년 10월 23일

:+1: +1

TintypeMolly 에 2019년 04월 10일

+1

sakethkoduru 에 2019년 04월 29일

+1

yashpatel5400 에 2019년 05월 07일

+1

zulrang 에 2019년 07월 05일

+1

csegedicsaba 에 2019년 07월 22일

요청된 많은 구현으로 인해 Docker를 사용하는 회사가 SOC 규정 준수 요구 사항 등을 준수하는 것이 불가능합니다.

이에 대한 해결책이 있어야 하지만 이미지가 저장되고 실행되는 방식에 있어 보다 과감한 아키텍처 변경이 아닌 쉬운 해결책은 없다고 생각합니다.

그래도 그렇게 되어야 합니다.

저는 더 이상 Docker 개발에 관여하지 않으므로 언급에서 제 자신을 제거하겠습니다. 행운을 빕니다 ^_^

ewindisch 에 2019년 07월 23일

SOC 요구 사항은 좋은 점입니다. 이 경우 시스템 전체의 도커 구성에 추가할 구성 옵션으로 이 기능을 활성화해야 합니다. 그렇게 하면 SOC 요구 사항을 유지할 수 있습니다. docker 명령줄에서 --insecure-registry 플래그를 활성화하는 "ALLOW_INSECURE_REGISTY_OPTION"과 같은 것입니다.

mmpfeffer 에 2019년 07월 23일

SOC 준수를 위해 옵션을 활성화하면 안 됩니다.

mmpfeffer 에 2019년 07월 23일

+1

shqear93 에 2019년 10월 09일

3년밖에 안됐어 이제 희망을 잃지 말자

5.

grunzwei 에 2019년 11월 03일

이 제안(현재 형태)은 다양한 이유로 구현될 가능성이 매우 낮습니다.
그 중 이유;

docker 데몬을 관리하는 사람이 어떤 연결을 담당하는지 유지합니다.
데몬이 만들 수 있습니다. 이 옵션은 "라이브 다시 로드"할 수 있습니다.
따라서 구성을 변경하기 위해 데몬을 다시 시작할 필요가 없습니다.
레지스트리와 잠재적으로 상호 작용하는 모든 명령 또는 코드 경로에는
수정됨; docker pull 뿐만 아니라 docker build , docker run ,
docker plugin , docker service 및 docker stack 하위 명령 및
작업자 노드에서 이미지를 가져오는 swarmkit과 같은 오케스트레이터.
SOC 준수(위에서 언급한 대로)

최소한 도커 데몬은 안전하지 않은 것을 허용하도록 구성해야 합니다.
전달될 레지스트리 매개변수입니다. 그러면 보안 설계가 적절한
장소 - 관리자의 손에 있으며 도커 자체 외부에 있습니다.

이 경우 관리자는 관리하는 사람/팀이 될 것이라고 생각합니다.
원격에 연결하는 사용자가 아니라 도커 데몬이 실행되는 호스트
API. 이것이 이 구성이 데몬 구성인 이유입니다.

셸 스크립트에서 json 구성을 패치하는 것은 주요 문제입니다.

그것은 공정한 지적이지만 이 토론과 직교합니다. _불가능_하지 않습니다.
JSON 구성을 패치하지만 다른 것보다 더 복잡할 수 있다는 데 동의했습니다.
파일 형식. 이 구성은 플래그를 통해 설정할 수도 있습니다.
시스템 드롭인 단위 파일을 사용하여 재구성할 수 있는 데몬
데몬.

docker 명령줄에서 --insecure-registry 플래그를 활성화하는 "ALLOW_INSECURE_REGISTY_OPTION"과 같은 것입니다.

모든 레지스트리에서 안전하지 않은 가져오기를 허용하려는 경우(이는
--insecure-registry 플래그 추가), "인터넷"을 안전하지 않은 것으로 허용할 수 있습니다.
기재; 다음은 모든 IPv4 주소를 안전하지 않은 레지스트리로 사용할 수 있도록 허용해야 합니다.
(따라서 비 TLS 연결로 대체)

/etc/docker/daemon.json 구성 파일을 통해;

{"insecure-registries": ["0.0.0.0/1","128.0.0.0/2","192.0.0.0/3","224.0.0.0/4"]}

또는 옵션을 데몬의 플래그로 전달하여(systemd에서 설정할 수 있음)
재정의 파일);

dockerd \
    --insecure-registry=0.0.0.0/1 \
    --insecure-registry=128.0.0.0/2 \
    --insecure-registry=192.0.0.0/3 \
    --insecure-registry=224.0.0.0/4

thaJeztah 에 2019년 11월 03일

👍2

Moby: --insecure-registry는 "docker pull"에 있어야 합니다.

가장 유용한 댓글

모든 178 댓글

관련 문제