Kubernetes: Falha ao obter imagem com o erro "x509: certificado assinado por autoridade desconhecida"

Eu fiz a pergunta aqui: http://stackoverflow.com/q/43150437/969784

Supondo que você esteja usando um certificado autoassinado, sua CA ainda precisa ser adicionada ao armazenamento confiável local, mesmo se você estiver usando --skip-tls-verify.

@rushilpaul

• Primeiro --insecure-skip-tls-verify não é um argumento válido para kubectl create ;
• Na verdade, x509 error está do lado de docker . O daemon falhou ao extrair a imagem desse registro inseguro. Você pode consultar o registro inseguro do docker para saber como confiar / ignorar a segurança do registro.

@dixudx esqueci de mencionar isso. Instalei o certificado do servidor globalmente neste nó mestre do kubernetes e reiniciei o serviço docker em execução nele. Depois disso, consigo extrair manualmente essa imagem usando docker pull 10.78.0.228:5000/monitorms . Antes disso, eu recebia esta mensagem de erro ao fazer uma extração manual dessa imagem.

O erro está ocorrendo porque os nós do Kubernetes não têm o certificado instalado?

@dixudx Além disso, o kubectl options lista --insecure-skip-tls-verify como uma das opções "globais" e diz que pode ser passado para qualquer comando do Kubernetes

--insecure-skip-tls-verify apenas ignora a verificação de certificado do servidor, não o registro do docker, portanto, não pode resolver o problema. O erro é do daemon do Docker ao extrair a imagem.

Instalei o certificado do servidor globalmente neste nó mestre do kubernetes e reiniciei o serviço docker em execução nele.

Talvez você deva tentar o comando docker pull 10.78.0.228:5000/monitorms nos nós k8s que contêm o pod, não no mestre k8s.

Esse é um argumento válido para kubectl create mas apenas controla a confiança entre o kubectl e o servidor da API

O erro de pull está entre o nó e o registro do docker. O nó precisa confiar no certificado ou tratar esse registro como um registro não confiável (o que faz com que o nó tolere erros de verificação de TLS)

@supereagle Vou adicionar a opção de registro inseguro ao arquivo de configuração do docker nos nós k8s. Esperançosamente, isso deve resolver

Você pensaria que isso está resolvido agora.

Certificados CA

Casos reais registrados de prevenção de acesso não autorizado: ZERO
Uma quantidade incontável de tempo do desenvolvedor desperdiçado por causa de ferramentas que não integram os certificados CA em suas ferramentas de maneira adequada: milhões de gases de horas de trabalho.

Moral da história. Ditch CA certs. É uma dor de cabeça toda vez que você tenta fazer o ferramental funcionar em conjunto. Ninguém sabe como funciona. Ninguém. O software que o usa nunca funciona. No final, você apenas copia todos os certificados para cada máquina e sua torradeira, para não obter aquele maldito x509: certificado assinado por autoridade desconhecida erro de merda toda vez que você tentar fazer qualquer ferramenta.

Agora eu tenho que ir e perfurar até o núcleo deste cluster para instalar esses certificados, porque os segredos do Kubernetes para lidar com o docker são simplesmente inúteis.

Basta usar o dinheiro que teria sido gasto tentando fazer com que os malditos certificados da CA funcionassem e contratar um capanga com um machado que cortaria a linha dura quando o hacker chegasse. Este CA certe que não é segurança se não permitir a entrada de pessoas autorizadas, porque todo o campo é apenas um BUG gigante que irá obstruir seu ferramental.

/ sig auth

se alguém encarar isso ao usar diretamente o gcr.io, uma situação possível é que os certificados CA em sua máquina sejam muito antigos.

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 '

solução que funcionou para mim no 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 para problema de extração de imagem

se você for ao nó em questão e tentar curl -v https://gcr.io/v1/_ping , você vê uma resposta bem-sucedida? em caso afirmativo, pode haver um problema com a maneira como o nó está puxando as imagens. caso contrário, você simplesmente precisa atualizar os certificados raiz nesse nó

Alguma atualização sobre este problema? isso está nos atingindo agora.

@ srossross-tableau

Pelo que me lembro, esse era um problema do docker, não do Kubernetes. O Docker não usa os ca certs do Linux. Ninguém sabe por quê.

Você deve instalar esses certificados manualmente (em cada nó que pode gerar esses pods) para que o docker possa usá-los:

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

Este é um problema altamente irritante, pois você tem que destruir seus nós após a inicialização para obter esses certificados lá. E o kubernetes gera nós o tempo todo. Como esse problema ainda não foi resolvido é um mistério para mim. É uma IMO detonadora completa.

Isso realmente deve ser resolvido usando o mecanismo de segredos do kubernetes. Mas de alguma forma não é. Quem sabe!?

@pompomJuice , pode ser um problema com a imagem do minikube? Eu não consigo nem mesmo curvar este site

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
..

Exatamente meu ponto. Esse erro de curl é simplesmente errado. Ele está dizendo que você possui os certificados, mas eles são autoassinados. Acho isso altamente improvável. (A menos que você os hackeado de alguma forma)

Isso significa que essa mensagem de erro está simplesmente errada. Isso se conecta com meu ponto anterior de que quase ninguém implementa essas coisas corretamente.

Tente atualizar os certificados nessa caixa, como ReSearchITEng sugerido acima.

Estou tendo o mesmo problema. Os certificados são do digicert, cluster do kubernetes em execução no GCE, certificados instalados por meio do host e colocados em /etc/docker/certs.d/ e ainda erro x509.

Registros do Docker:
TLS handshake error from XXXXXXXXXX: remote error: tls: bad certificate

Versão 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"}

hospedeiro:
NAME = "Ubuntu"
VERSÃO = "16.04.3 LTS (Xenial Xerus)"
ID = ubuntu
ID_LIKE = debian
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

Cole o nome da pasta inteira em '/etc/docker/certs.d/' por favor. E os nomes dos arquivos dos certs.

Deve funcionar se todos os seus nós tiverem esse certificado instalado.

root @ kubernetes-minion-group-96k7 : /etc/docker/certs.d/ "foo.bar.com": 5000 # ll
total 16
drwxr-xr-x 2 root root 4096 Dec 2 20:43 ./
drwxr-xr-x 3 root root 4096 Dec 2 20:07 ../
-rw-r - r-- 1 root root 3332 Dec 2 20:23 domain.crt
-rw-r - r-- 1 root 1675 Dec 2 20:43 domain.key

Até agora, apenas um nó no cluster :)

Altere-os para ca.crt e client.key

Como aqui: https://docs.docker.com/engine/security/certificates/#creating -the-client-certificates

Alterou-os para ca.crt e ca.key no diretório, bem como atualizou os arquivos chamados no segredo. Reiniciei o serviço docker no nó e reimplantei os pods e ainda, o mesmo erro.

Aqui estão mais informações do curl:

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

• Tentando XXX.XXX.XXX.XXX ...
• TCP_NODELAY definido
• Conectado a foo.bar.com (XXX.XXX.XXX.XXX), porta 5000 (# 0)
• ALPN, oferecendo h2
• ALPN, oferecendo http / 1.1
• Seleção de cifra: PROFILE = SYSTEM
• definir com êxito os locais de verificação de certificado:
• CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: nenhum
• TLSv1.2 (OUT), handshake TLS, Olá do cliente (1):
• TLSv1.2 (IN), handshake TLS, servidor hello (2):
• TLSv1.2 (IN), handshake TLS, Certificado (11):
• TLSv1.2 (OUT), alerta TLS, servidor Olá (2):
• Problema com o certificado SSL: não é possível obter o certificado do emissor local
• interrompeu o fluxo de pausa!
• Fechando conexão 0
  curl: (60) Problema com o certificado SSL: não foi possível obter o certificado do emissor local
  Mais detalhes aqui: https://curl.haxx.se/docs/sslcerts.html

curl realiza verificação de certificado SSL por padrão, usando um "pacote"
de chaves públicas da Autoridade de Certificação (CA) (certificados de CA). Se o padrão
arquivo de pacote não é adequado, você pode especificar um arquivo alternativo
usando a opção --cacert.
Se este servidor HTTPS usa um certificado assinado por uma CA representada em
o pacote, a verificação do certificado provavelmente falhou devido a um
problema com o certificado (pode estar expirado ou o nome pode
não corresponde ao nome de domínio no URL).
Se você gostaria de desligar a verificação curl do certificado, use
a opção -k (ou --insecure).
HTTPS-proxy tem opções semelhantes --proxy-cacert e --proxy-insecure.

Eu cometi um erro, deveria ser client.key, não ca.key .

Deve funcionar.

Verifique novamente tentando iniciar a imagem manualmente na caixa.

Isso também não pareceu funcionar :( mesmo erro

O que acontece quando você tenta iniciar o contêiner do docker manualmente na linha de comando?

devo usar kubectl run em um dos nós ou docker run? docker executado, o contêiner é iniciado, mas recebo a conexão recusada. Se eu usar kubctl, error: failed to discover supported resources: an error on the server ("") has prevented the request from succeeding

Se eu usei kubectl em minha máquina local que está aproveitando o proxy kubectl, o contêiner será iniciado, mas obtenho o seguinte:
http: o servidor deu resposta HTTP ao cliente HTTPS

Comando 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

Experimente o seguinte.

Faça seu próprio registro do docker. Use o gitlab para isso, é grátis.

Hospede algumas imagens nele em http. Tente iniciar um pod com esta imagem. Em seguida, verifique se a janela de encaixe que você está procurando está de fato executando aquele pod. Se for, você sabe que tem o nó correto.

Então, como antes de docker run e me explique o que você entende por conexão recusada.

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

Problemas obsoletos apodrecem após 30 dias de inatividade.
Marque o problema como novo com /remove-lifecycle rotten .
Problemas podres são encerrados após 30 dias adicionais de inatividade.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle podre
/ remove-lifecycle stale

Problemas podres são encerrados após 30 dias de inatividade.
Reabra o problema com /reopen .
Marque o problema como novo com /remove-lifecycle rotten .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/Fechar

Então, qual é a solução / solução para isso? Ainda estou conseguindo depois de atualizar do 3.9 para o 3.10. Falha ao obter a imagem "docker-registry.default. Svc: 5000 / openshift / mysql @ sha256 : dfd9f18f47caf290 ... e com mensagem de erro: v2 /: x509: certificado assinado por autoridade desconhecida. Concordo com @pompomJuice. Uma correção permanente para isso não quebra após a instalação / atualização é necessário ou reengenharia isso completamente. Caso contrário, não está pronto para cargas de trabalho de produção.

solução de trabalho para puxar a imagem docker no ubuntu a partir do Artifactory (o certificado é autoassinado):

• coloque todos os certificados usados ​​(se houver mais de um ca raiz) em / usr / local / share / ca-certificados
• execute update-ca-certificates
• reiniciar docker daemon (sudo service docker restart)

se alguém encarar isso ao usar diretamente o gcr.io, uma situação possível é que os certificados CA em sua máquina sejam muito antigos.

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 '

solução que funcionou para mim no RH / CentOS:

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

Isso realmente funcionou para mim.

Eu executo o kubernetes no RancherOS como parte da configuração do Rancher 2.x e tenho um registro privado que não é voltado para a Internet, então tenho que usar um certificado autoassinado nele, resultando em erro x509. Li este tópico e alguns outros e resolvi o problema - compartilhando no caso de poder ajudar alguém, se não diretamente, então sugerindo um caminho possível.

Isso funcionou para mim - https://www.ctrl-alt-del.cc/2018/11/solution-rancher-2-k8s-private-registry.html

2020 e ainda o mesmo problema.
registro de porto privado.
docker pull funciona sem problemas.
ls /etc/docker/certs.d/registry.myharbor.com/ mostra o certificado.
O kubernetes falha ao extrair imagens com erro imagepullbackoff.
Faz 3 anos e o kubernetes ainda tem esse problema. Muito decepcionante.

Resolvido

1. Certifique-se de que você é capaz de fazer docker pull IMAGENAME na máquina onde está executando as implantações (arquivos yaml, pacotes de helm, etc.)
2. Em todos os nós do kubernetes, certifique-se de que o seguinte está presente /etc/docker/certs.d/my-private-registry.com/my-private-registry.com.crt

Estou trabalhando em meu ambiente de desenvolvimento local

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

Estou usando o Jfrog Container Registry como registro do meu minikube. Sou capaz de fazer o seguinte:

1. docker login localhost: 443 | ou | ip- add: 443
2. docker push ip- add: 443 / docker-local / test : mais recente
3. docker pull ip- add: 443 / docker-local / test : mais recente

Eu configurei o Jfrog Container Registry para rodar atrás do Nginx Reverse Proxy ouvindo na porta 443. Criei certificados autoassinados e o Jfrog está usando esses certificados.

Docker configurado para usar certificados autoassinados conforme a seguir.

1. Crie certificados, copie para / usr / local / share / ca-Certificados /
2. sudo update-ca-certificates
3. copie o certificado para /etc/docker/cert.d/192.168.0.114:443/ca.crt
4. reiniciou o docker, apenas certifique-se

Configure o K8 para usar o segredo de login do docker pelo arquivo .yaml da seguinte forma:

1. codificação base64 ~ / .docker / config.json
2. use-o no seguinte modelo
   apiVersion: v1 kind: Secret metadata: name: myregistrykey namespace: awesomeapps data: .dockerconfigjson: UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== type: kubernetes.io/dockerconfigjson

No deployment.yaml, uso ImagePullSecrets e o flag de nome.

Agora, depois de toda essa configuração em que o docker pull está funcionando no terminal, recebo um erro nos pods dizendo x509 IP Sans.

Passei por muita documentação e problemas com o K8, repliquei a etapa de https://github.com/kubernetes/kubernetes/issues/43924#issuecomment -631533150

replicou as etapas não funcionou. Alguém pode me dizer o que estou fazendo de errado? e como posso corrigir isso.

Eu também estou tendo os mesmos problemas, mas no EKS neste caso. Estou usando um daemonset para implantar uma carga de trabalho privilegiada para tentar as correções acima em todos os nós para resolver este problema (as imagens estão em um registro assinado privado).