Kubernetes: 无法提取带有“ x509：由未知授权机构签名的证书”的图像的错误

我在这里问过这个问题： http :

假设您使用的是自签名证书，即使使用--skip-tls-verify，您的CA仍需要添加到本地信任存储中。

@rushilpaul

• 对于kubectl create ，第一个--insecure-skip-tls-verify不是有效的参数；
• 实际上x509 error在docker一边。 守护程序无法从该不安全的注册表中提取映像。 您可以参考不安全的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注册表，因此无法解决问题。 错误是从Docker守护程序提取映像时发生的。

我在该kubernetes主节点上全局安装了服务器证书，然后重新启动了在其上运行的docker服务。

也许您应该在装有Pod的k8s节点上尝试命令docker pull 10.78.0.228:5000/monitorms ，而不是k8s主节点。

这是kubectl create的有效arg，但仅控制kubectl和API服务器之间的信任

拉取错误在节点和Docker注册表之间。 节点要么需要信任证书，要么将该注册表视为不受信任的注册表（这使节点可以接受TLS验证错误）

@supereagle我将不安全的注册表选项添加到k8s节点上的docker配置文件中。 希望这可以解决问题

您会认为这已经解决了。

CA证书

实际记录的防止未授权访问的案例：零
由于工具无法将CA证书正确地集成到他们的工具中，因此浪费了无数开发人员的时间：数百万个工时。

这个故事所讲的道德。 沟CA证书。 每当您尝试使工具一起工作时，都会遇到这样的麻烦。 没有人知道它是如何工作的。 没有人。 使用它的软件永远无法运行。 最后，您只需将所有证书复制到每台机器和烤面包机上，这样就不会得到该死的x509：由未知权限胡扯的

现在，我必须继续深入研究该集群的核心，以安装那些证书，因为kubernetes处理docker的秘密简直是无用的。

只需用花在试图使流血的CA证书正常工作上的钱，然后雇用带有斧头的小伙子就可以在黑客削减强硬派。 这个CA证明，如果不让授权人员进入，那不是安全的，因为整个领域只是一个会破坏您工具的巨型BUG。

/信号授权

如果有人在直接使用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证书。 没人知道为什么。

您必须手动安装这些证书（在可能产生这些Pod的每个节点上），以便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 =“ Ubuntu”
VERSION =“ 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

请将整个文件夹名称粘贴到“ /etc/docker/certs.d/”中。 以及证书的文件名。

如果您所有的节点都安装了该证书，它应该可以工作。

root @ kubernetes-minion-group-96k7 ：/etc/docker/certs.d/“ foo.bar.com”：5000＃ll
总共16
drwxr-xr-x 2根根4096 Dec 2 20:43 ./
drwxr-xr-x 3根根4096 Dec 2 20:07 ../
-rw-r--r-- 1根root 3332 Dec 2 20:23 domain.crt
-rw-r--r-- 1个根1675年2月2日20:43 domain.key

到目前为止，集群中只有一个节点:)

将其更改为ca.crt和client.key

像这里一样： https :

在目录中将它们都更改为ca.crt和ca.key，并更新secret中调出的文件。 我在节点上重新启动了docker服务，并重新部署了Pod，仍然出现同样的错误。

这是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
• ALPN，提供http / 1.1
• 密码选择：PROFILE = SYSTEM
• 成功设置证书验证位置：
• CAfile：/etc/pki/tls/certs/ca-bundle.crt
  CApath：无
• TLSv1.2（OUT），TLS握手，客户端问候（1）：
• TLSv1.2（IN），TLS握手，服务器问候（2）：
• TLSv1.2（IN），TLS握手，证书（11）：
• TLSv1.2（OUT），TLS警报，服务器问候（2）：
• SSL证书问题：无法获取本地颁发者证书
• 停止了暂停流！
• 关闭连接0
  curl：（60）SSL证书问题：无法获取本地发行者证书
  此处有更多详细信息： https :

curl默认情况下使用“捆绑包”执行SSL证书验证
认证中心（CA）公钥（CA证书）。 如果默认
捆绑文件不足，您可以指定备用文件
使用--cacert选项。
如果此HTTPS服务器使用由表示为
捆绑软件，证书验证可能由于
证书有问题（证书可能已过期，或者名称可能
与网址中的域名不匹配）。
如果您想关闭curl对证书的验证，请使用
-k（或--insecure）选项。
HTTPS-proxy具有类似的选项--proxy-cacert和--proxy-insecure。

我弄错了，应该是client.key而不是ca.key 。

它应该工作。

通过尝试在包装盒上手动启动图像来进行仔细检查。

这似乎也不起作用:(相同的错误

当您尝试从命令行手动启动Docker容器时会发生什么情况？

我应该在节点之一或docker run上使用kubectl吗？ docker运行，容器启动，但我拒绝连接。 如果我使用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运行--image =注册表：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

尝试以下方法。

制作自己的Docker注册表。 为此使用gitlab是免费的。

在http上托管一些图像。 尝试使用此图像启动容器。 然后确认您正在查看的Docker实际上正在运行该pod。 如果是，则您知道您具有正确的节点。

然后像之前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 。
/生命周期烂
/删除生命周期过时

闲置30天后，腐烂的问题关闭。
使用/reopen重新打开问题。
使用/remove-lifecycle rotten将问题标记为新问题。

将反馈发送到sig-testing，kubernetes / test-infra和/或fejta 。
/关

那么，解决方法/解决方案是什么？ 从3.9升级到3.10后，即时通讯仍能得到它。 无法提取映像“ docker -registry.default。svc

从Artifactory提取ubuntu上的docker映像的有效解决方案（证书是自签名的）：

• 将所有使用过的（如果有多个根ca的话）ca证书放入/ usr / local / share / ca-certificates
• 运行update-ca-certificates
• 重新启动docker守护进程（sudo服务docker restart）

如果有人在直接使用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，并且具有不面向Internet的私有注册表，因此我必须在其上使用自签名证书，从而导致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. 确保您能够在运行部署的机器上执行docker pull IMAGENAME （yaml文件，helm软件包等）
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. docker登录localhost：443 | 或| ip-添加：443
2. docker push ip-添加：443 / docker-local / test ：最新
3. docker pull ip-添加：443 / docker-local / test ：最新

我已将Jfrog Container Registry配置为在侦听端口443的Nginx反向代理后面运行。创建了自签名证书，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. 重新启动Docker，只要确定

将K8配置为使用.yaml文件使用docker登录密码，如下所示：

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和名称标志。

现在，在完成所有在码头上进行码头工人拉拔工作的设置之后，我在pod上看到x509 IP Sans的错误消息。

我经历了很多文档和K8问题，复制了https://github.com/kubernetes/kubernetes/issues/43924#issuecomment -631533150的步骤

复制的步骤无法解决。 谁能让我知道我做错了什么？ 以及如何纠正它。

我也有同样的问题，但是在这种情况下是在EKS上。 我正在使用守护程序集来部署特权工作负载，以尝试在所有节点上进行上述修复以解决此问题（图像位于私有签名注册表中）。