Kubernetes: 'x509 : 알 수없는 기관에서 서명 한 인증서'오류와 함께 이미지를 가져 오지 못했습니다.

나는 여기에 질문했다 : http://stackoverflow.com/q/43150437/969784

자체 서명 된 인증서를 사용한다고 가정하면 --skip-tls-verify를 사용하더라도 CA는 여전히 로컬 신뢰 저장소에 추가되어야합니다.

헉헉

• 처음 --insecure-skip-tls-verify 는 kubectl create 대한 유효한 인수가 아닙니다.
• 실제로 x509 error 은 docker 쪽에 있습니다. 데몬이 안전하지 않은 레지스트리에서 이미지를 가져 오지 못했습니다. 레지스트리 보안을 신뢰 / 건너 뛰는 방법에 대해서는 안전하지 않은 도커 레지스트리 를 참조 할 수 있습니다.

@dixudx 나는 그것을 언급하는 것을 잊었다. 이 kubernetes 마스터 노드에 전역 적으로 서버 인증서를 설치 한 다음 실행중인 docker 서비스를 다시 시작했습니다. 그 후 docker pull 10.78.0.228:5000/monitorms 사용하여 해당 이미지를 수동으로 가져올 수 있습니다. 그 전에는 해당 이미지를 수동으로 가져 오는 동안이 오류 메시지가 표시되었습니다.

Kubernetes 노드에 인증서가 설치되어 있지 않기 때문에 오류가 발생합니까?

@dixudx 또한 kubectl options 는 "전역"옵션 중 하나로 --insecure-skip-tls-verify 을 나열하고 모든 Kubernetes 명령에 전달할 수 있다고 말합니다.

--insecure-skip-tls-verify 은 도커 레지스트리가 아닌 서버의 인증서 확인을 건너 뛰기 때문에 문제를 해결할 수 없습니다. 오류는 이미지를 가져 오는 동안 Docker 데몬에서 발생합니다.

이 kubernetes 마스터 노드에 전역 적으로 서버 인증서를 설치 한 다음 실행중인 docker 서비스를 다시 시작했습니다.

k8s 마스터가 아닌 포드를 보유하는 k8s 노드에서 docker pull 10.78.0.228:5000/monitorms 명령을 시도해야 할 수도 있습니다.

이것은 kubectl create 대한 유효한 인수이지만 kubectl과 API 서버 간의 신뢰 만 제어합니다.

풀 오류는 노드와 도커 레지스트리 사이에 있습니다. 노드는 인증서를 신뢰하거나 해당 레지스트리를 신뢰할 수없는 레지스트리로 처리해야합니다 (노드가 TLS 확인 오류를 허용하도록 함).

@supereagle k8s 노드의 도커 구성 파일에 안전하지 않은 레지스트리 옵션을 추가하겠습니다. 잘하면 그게 트릭을해야

당신은 이것이 지금까지 해결되었다고 생각할 것입니다.

CA 인증서

무단 접근 방지 실제 기록 사례 : ZERO
CA 인증서를 툴링에 제대로 통합하지 않는 툴링으로 인해 낭비되는 수많은 개발자 시간 : 수백만 시간의 시간.

이야기의 교훈. CA 인증서를 버리십시오. 함께 일할 도구를 얻으려고 할 때마다 그런 발란스. 그것이 어떻게 작동하는지 아무도 모릅니다. 아무도. 그것을 사용하는 소프트웨어는 작동하지 않습니다. 결국 모든 인증서를 모든 기계와 토스터에 복사하기 만하면 망할 x509 : 알 수없는 기관에 의해 서명 된 인증서는 도구를 사용하려고 할 때마다 헛소리 오류가 발생합니다.

이제 Docker를 처리하는 kubernetes의 비밀은 무용지물이기 때문에이 클러스터의 핵심으로 바로 가서 인증서를 설치해야합니다.

피 묻은 CA 인증서를 사용하는 데 사용되었을 돈을 사용하고 해커가 올 때 강경 한 줄 을

/ sig auth

gcr.io를 직접 사용하는 동안 누군가가 직면 할 경우 가능한 한 가지 상황은 컴퓨터의 CA 인증서가 너무 오래되었다는 것입니다.

docker pull gcr.io/google_containers/kube-apiserver-amd64:v1.7.2
Trying to pull repository gcr.io/google_containers/kube-apiserver-amd64 ...
Get https://gcr.io/v1/_ping: x509: certificate signed by unknown authority '

RH / CentOS에서 나를 위해 일한 솔루션 :

yum check-update ca-certificates; (($?==100)) && yum update ca-certificates || yum reinstall ca-certificates
update-ca-trust extract

cc @ kubernetes / sig-node-bugs 이미지 풀링 문제

해당 노드로 이동하여 curl -v https://gcr.io/v1/_ping 시도하면 성공적인 응답이 표시됩니까? 그렇다면 노드가 이미지를 가져 오는 방식에 문제가있을 수 있습니다. 그렇지 않은 경우 해당 노드에서 루트 인증서를 업데이트하기 만하면됩니다.

이 문제에 대한 업데이트가 있습니까? 이것은 지금 우리를 때리고 있습니다.

@ srossross-tableau

내가 기억하는 한 이것은 kubernetes 문제가 아니라 도커 문제였습니다. Docker는 Linux의 CA 인증서를 사용하지 않습니다. 아무도 이유를 모릅니다.

Docker가 사용할 수 있도록 이러한 인증서를 수동으로 (해당 포드를 생성 할 수있는 모든 노드에) 설치해야합니다.

/etc/docker/certs.d/mydomain.com:1234/ca.crt

인증서를 얻기 위해 부트 스트랩 후 노드를 도살해야하므로 이는 매우 성가신 문제입니다. 그리고 kubernetes는 항상 노드를 생성합니다. 이 문제가 아직 해결되지 않은 방법은 나에게 수수께끼입니다. 완벽한 IMO입니다.

이것은 kubernetes의 비밀 메커니즘을 사용하여 실제로 해결되어야합니다. 그러나 어떻게 든 그렇지 않습니다. 누가 알아!?

@pompomJuice , 이것이 minikube 이미지 문제 일 수 있습니까? 이 사이트를 말아도 안돼

minikube ssh -- curl -I https://storage.googleapis.com
curl: (60) SSL certificate problem: self signed certificate in certificate chain

$minikube logs
...
Nov 08 18:19:06 minikube localkube[3032]: E1108 18:19:06.788101    3032 remote_image.go:108] PullImage "gcr.io/google_containers/heapster:v1.3.0" from image service failed: rpc error: code = 2 desc = error pulling image configuration: Get https://storage.googleapis.com/artifacts.google-containers.appspot.com/containers/images/sha256:f9d33bedfed3f1533f734a73718c15976fbd37f04f383087f35e5ebd91b18d1e: x509: certificate signed by unknown authority
..

정확히 내 요점. 그 컬 오류는 명백한 잘못입니다. 인증서가 있지만 자체 서명되었음을 알려줍니다. 나는 그럴 가능성이 거의 없다고 생각합니다. (어떻게 든 해킹하지 않는 한)

이는 해당 오류 메시지가 명백히 잘못되었음을 의미합니다. 이것은 거의 아무도이 물건을 올바르게 구현하지 않는다는 이전 요점과 연결됩니다.

위에서 제안한 ReSearchITEng과 같은 해당 상자의 인증서를 업데이트하십시오.

나는 같은 문제에 직면하고 있습니다. 인증서는 digicert, GCE에서 실행되는 kubernetes 클러스터, 호스트를 통해 설치된 인증서 및 /etc/docker/certs.d/에 저장되며 여전히 x509 오류입니다.

Docker 로그 :
TLS handshake error from XXXXXXXXXX: remote error: tls: bad certificate

Kub 버전 :
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState:"clean", BuildDate:"2017-11-20T05:28:34Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

주최자:
NAME = "우분투"
VERSION = "16.04.3 LTS (Xenial Xerus)"
ID = 우분투
ID_LIKE = 데비안
PRETTY_NAME = "Ubuntu 16.04.3 LTS"
VERSION_ID = "16.04"
HOME_URL = " http://www.ubuntu.com/ "
SUPPORT_URL = " http://help.ubuntu.com/ "
BUG_REPORT_URL = " http://bugs.launchpad.net/ubuntu/ "
VERSION_CODENAME = xenial
UBUNTU_CODENAME = xenial

'/etc/docker/certs.d/'에 전체 폴더 이름을 붙여 넣으십시오. 그리고 인증서의 파일 이름.

모든 노드에 해당 인증서가 설치되어 있으면 작동합니다.

root @ kubernetes-minion-group-96k7 : /etc/docker/certs.d/ "foo.bar.com": 5000 # ll
총 16
drwxr-xr-x 2 루트 루트 4096 12 월 2 일 20:43 ./
drwxr-xr-x 3 루트 루트 4096 12 월 2 일 20:07 ../
-rw-r--r-- 1 루트 루트 3332 12 월 2 일 20:23 domain.crt
-rw-r--r-- 1 개의 루트 루트 1675 년 12 월 2 일 20:43 domain.key

지금까지 클러스터에서 단 하나의 노드 :)

ca.crt 및 client.key로 변경하십시오.

여기처럼 : https://docs.docker.com/engine/security/certificates/#creating -the-client-certificates

디렉토리에서 ca.crt 및 ca.key로 변경하고 secret에서 호출 된 파일을 업데이트했습니다. 노드에서 도커 서비스를 다시 시작하고 포드를 다시 배포했지만 여전히 동일한 오류가 발생했습니다.

curl의 추가 정보는 다음과 같습니다.

curl -vvI https://foo.bar.com : 5000 / v2 /

• XXX.XXX.XXX.XXX 시도 중 ...
• TCP_NODELAY 설정
• foo.bar.com (XXX.XXX.XXX.XXX) 포트 5000 (# 0)에 연결됨
• ALPN, h2 제공
• http / 1.1을 제공하는 ALPN
• 암호 선택 : PROFILE = SYSTEM
• 인증서 확인 위치를 성공적으로 설정했습니다.
• CA 파일 : /etc/pki/tls/certs/ca-bundle.crt
  CApath : 없음
• TLSv1.2 (출력), TLS 핸드 셰이크, 클라이언트 안녕하세요 (1) :
• TLSv1.2 (IN), TLS 핸드 셰이크, 서버 hello (2) :
• TLSv1.2 (IN), TLS 핸드 셰이크, 인증서 (11) :
• TLSv1.2 (출력), TLS 경고, 서버 안녕하세요 (2) :
• SSL 인증서 문제 : 로컬 발급자 인증서를 얻을 수 없습니다.
• 일시 중지 스트림을 중지했습니다!
• 연결 닫기 0
  curl : (60) SSL 인증서 문제 : 로컬 발급자 인증서를 가져올 수 없습니다.
  자세한 내용은 여기 : https://curl.haxx.se/docs/sslcerts.html

curl은 기본적으로 "번들"을 사용하여 SSL 인증서 확인을 수행합니다.
인증 기관 (CA) 공개 키 (CA 인증서). 기본값 인 경우
번들 파일이 충분하지 않습니다. 대체 파일을 지정할 수 있습니다.
--cacert 옵션을 사용합니다.
이 HTTPS 서버가 다음에 표시된 CA에서 서명 한 인증서를 사용하는 경우
번들로 인해 인증서 확인이 실패했을 수 있습니다.
인증서 문제 (만료되었거나 이름이
URL의 도메인 이름과 일치하지 않음).
curl의 인증서 확인을 끄려면 다음을 사용하십시오.
-k (또는 --insecure) 옵션.
HTTPS-proxy에는 유사한 옵션 --proxy-cacert 및 --proxy-insecure가 있습니다.

내가 실수를 했어, 하나는 ca.key가 아니라 client.key 여야 합니다.

작동합니다.

상자에서 이미지를 수동으로 시작하여 다시 확인하십시오.

그것도 작동하지 않는 것 같았습니다 :( 같은 오류

명령 줄에서 Docker 컨테이너를 수동으로 시작하려고하면 어떻게됩니까?

노드 중 하나에서 kubectl run을 사용해야합니까 아니면 docker run을 사용해야합니까? 도 커가 실행되면 컨테이너가 시작되지만 연결이 거부됩니다. kubctl을 사용하면 error: failed to discover supported resources: an error on the server ("") has prevented the request from succeeding

kubectl 프록시를 활용하는 로컬 머신에서 kubectl을 사용한 경우 컨테이너가 시작되지만 다음이 표시됩니다.
http : 서버가 HTTPS 클라이언트에 HTTP 응답을 제공함

kubectl 명령 : kubectl run --image = registry : 2 devreg-test2 --port = 5000 --env = "DOMAIN = cluster, REGISTRY_HTTP_ADDR = 0.0.0.0 : 5000, REGISTRY_HTTP_TLS_CERTIFICATE = / certs / ca.crt, REGISTRY_HTTP_TLS_KEY = / certs /client.key "--expose = true

다음을 시도하십시오.

고유 한 도커 레지스트리를 만드십시오. 이를 위해 gitlab을 사용하면 무료입니다.

http에서 일부 이미지를 호스팅하십시오. 이 이미지로 포드를 시작해보십시오. 그런 다음보고있는도 커가 실제로 해당 포드를 실행하고 있는지 확인합니다. 그렇다면 올바른 노드가있는 것입니다.

그런 다음 docker run 이전과 같이 연결이 거부되었다는 의미를 설명해주세요.

90 일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 최신 문제로 표시합니다.
비활성 문제는 추가로 30 일 동안 사용하지 않으면 썩고 결국 종료됩니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle stale

비활성 문제는 30 일 동안 활동이 없으면 부패합니다.
/remove-lifecycle rotten 하여 최신 문제로 표시합니다.
썩은 문제는 추가로 30 일 동안 사용하지 않으면 닫힙니다.

이 문제를 지금 종료해도 안전하다면 /close 하여 종료하세요.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/ lifecycle rotten
/ remove-lifecycle stale

썩은 문제는 30 일 동안 활동이 없으면 닫힙니다.
/reopen 문제를 다시 엽니 다.
/remove-lifecycle rotten 하여 최신 문제로 표시합니다.

sig-testing, kubernetes / test-infra 및 / 또는 fejta에 피드백을
/닫기

그래서 이것에 대한 해결 방법 / 수정은 무엇입니까? 3.9에서 3.10으로 업그레이드 한 후에도 여전히 나타납니다. 이미지 "docker-registry.default. svc : 5000 / openshift / mysql @ sha256 : dfd9f18f47caf290 ... 및 오류 메시지 : v2 / : x509 : 알 수없는 기관에서 서명 한 인증서. @pompomJuice에 동의합니다. 영구적 인 수정 사항 설치 / 업그레이드가 필요하거나 완전히 리엔지니어링 한 후에도 중단되지 않습니다. 그렇지 않은 경우 프로덕션 워크로드에 사용할 수 없습니다.

Artifactory에서 우분투에서 도커 이미지를 가져 오는 작업 솔루션 (인증서는 자체 서명 됨) :

• 사용 된 모든 (루트 CA가 둘 이상있는 경우) CA 인증서를 / usr / local / share / ca-certificates에 넣습니다.
• update-ca-certificates 실행
• 도커 데몬 다시 시작 (sudo 서비스 도커 다시 시작)

gcr.io를 직접 사용하는 동안 누군가가 직면 할 경우 가능한 한 가지 상황은 컴퓨터의 CA 인증서가 너무 오래되었다는 것입니다.

docker pull gcr.io/google_containers/kube-apiserver-amd64:v1.7.2
Trying to pull repository gcr.io/google_containers/kube-apiserver-amd64 ...
Get https://gcr.io/v1/_ping: x509: certificate signed by unknown authority '

RH / CentOS에서 나를 위해 일한 솔루션 :

yum check-update ca-certificates; (($?==100)) && yum update ca-certificates || yum reinstall ca-certificates
update-ca-trust extract

이것은 실제로 나를 위해 일했습니다.

Rancher 2.x 설정의 일부로 RancherOS에서 kubernetes를 실행하고 인터넷에 연결되지 않은 개인 레지스트리가 있으므로 자체 서명 된 인증서를 사용해야하므로 x509 오류가 발생합니다. 나는이 스레드와 다른 사람을 거의 읽지 않았고 문제를 해결했습니다-가능한 경로를 제안함으로써 누군가를 도울 수있는 경우 공유하십시오.

이것은 나를 위해 일했습니다-https: //www.ctrl-alt-del.cc/2018/11/solution-rancher-2-k8s-private-registry.html

2020 년과 여전히 같은 문제입니다.
개인 항구 등록.
도커 풀은 문제없이 작동합니다.
ls /etc/docker/certs.d/registry.myharbor.com/에 인증서가 표시됩니다.
kubernetes가 imagepullbackoff 오류로 이미지를 가져 오지 못했습니다.
3 년이 지난 지금도 Kubernetes에는이 문제가 있습니다. 매우 실망스러운.

해결됨

1. 배포를 실행중인 머신 (yaml 파일, helm 패키지 등)에서 docker pull IMAGENAME 작업을 수행 할 수 있는지 확인합니다.
2. 모든 kubernetes 노드에서 다음 항목이 있는지 확인하십시오. /etc/docker/certs.d/my-private-registry.com/my-private-registry.com.crt

내 로컬 개발 환경에서 일하고 있습니다.

    OS:
       Ubuntu (bionic) 18.0.4 LTS    
    Minikube Version:
       v1.11.0
    Docker Version:
       19.03.10

Jfrog Container Registry를 내 minikube의 레지스트리로 사용하고 있습니다. 다음을 수행 할 수 있습니다.

1. 도커 로그인 localhost : 443 | 또는 | ip- 추가 : 443
2. docker push ip- add : 443 / docker-local / test : latest
3. docker pull ip- add : 443 / docker-local / test : latest

포트 443에서 수신 대기하는 Nginx 역방향 프록시 뒤에서 실행되도록 Jfrog Container Registry를 구성했습니다. 자체 서명 된 인증서를 생성했으며 Jfrog는이 인증서를 사용하고 있습니다.

자체 서명 된 인증서를 사용하도록 Docker를 다음과 같이 구성했습니다.

1. 인증서를 만들고 / usr / local / share / ca-certificates /에 복사합니다.
2. sudo update-ca-certificates
3. 인증서를 /etc/docker/cert.d/192.168.0.114:443/ca.crt에 복사합니다.
4. 도커를 다시 시작했습니다.

다음과 같이 .yaml 파일로 도커 로그인 시크릿을 사용하도록 K8을 구성하십시오.

1. base64 인코딩 ~ / .docker / config.json
2. 다음 템플릿에서 사용
   apiVersion: v1 kind: Secret metadata: name: myregistrykey namespace: awesomeapps data: .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== type: kubernetes.io/dockerconfigjson

deployment.yaml에서 ImagePullSecrets와 이름 플래그를 사용합니다.

이제 도커 풀이 터미널에서 작동하는 모든 설정이 끝나면 포드에서 x509 IP Sans라는 오류가 발생합니다.

나는 많은 문서와 K8 문제를 겪었고 https://github.com/kubernetes/kubernetes/issues/43924#issuecomment -631533150의 단계를 복제했습니다.

단계가 작동하지 않았습니다. 누구든지 내가 뭘 잘못하고 있는지 알려줄 수 있습니까? 어떻게 수정할 수 있습니까?

나는 또한 동일한 문제가 있지만이 경우 EKS에 있습니다. 이 문제를 해결하기 위해 모든 노드에서 위의 수정을 시도하기 위해 권한있는 워크로드를 배포하는 데 데몬 셋을 사용하고 있습니다 (이미지는 개인 서명 레지스트리에 있음).