Kubernetes: 「x509：不明な機関によって署名された証明書」エラーでイメージをプルできませんでした

私はここで質問をしました： http ：

自己署名証明書を使用している場合、-skip-tls-verifyを使用している場合でも、CAをローカルのトラストストアに追加する必要があります。

@rushilpaul

• 最初の--insecure-skip-tls-verifyはkubectl create有効な引数ではありません;
• 実際、 x509 errorはdocker側にあります。 デーモンは、その安全でないレジストリからイメージをプルできませんでした。 レジストリのセキュリティを信頼/スキップする方法については、安全でないDockerレジストリを参照できます。

@dixudx私はそれについて言及するのを忘れました。 このkubernetesマスターノードにサーバー証明書をグローバルにインストールしてから、そこで実行されているDockerサービスを再起動しました。 その後、 docker pull 10.78.0.228:5000/monitormsを使用してそのイメージを手動でプルすることができます。 その前は、その画像を手動でプルしているときにこのエラーメッセージが表示されていました。

Kubernetesノードに証明書がインストールされていないためにエラーが発生しますか？

@dixudxまた、 kubectl optionsは、「グローバル」オプションの1つとして--insecure-skip-tls-verifyをリストし、任意のKubernetesコマンドに渡すことができることを示しています

--insecure-skip-tls-verifyは、Dockerレジストリではなく、サーバーの証明書検証をスキップするだけなので、問題を解決することはできません。 エラーは、イメージのプル中にDockerデーモンから発生します。

このkubernetesマスターノードにサーバー証明書をグローバルにインストールしてから、そこで実行されているDockerサービスを再起動しました。

たぶん、k8sマスターではなく、ポッドを保持するk8sノードでコマンドdocker pull 10.78.0.228:5000/monitormsを試す必要があります。

これはkubectl create有効な引数ですが、kubectlとAPIサーバー間の信頼を制御するだけです。

プルエラーは、ノードとDockerレジストリの間にあります。 ノードは、証明書を信頼するか、そのレジストリを信頼されていないレジストリとして扱う必要があります（これにより、ノードはTLS検証エラーを許容します）

@ supereaglek8sノードのDocker構成ファイルに安全でないレジストリオプションを追加します。 うまくいけば、それはトリックを行う必要があります

これはもう解決したと思うでしょう。

CA証明書

不正アクセスを防止した実際の記録事例：ゼロ
CA証明書をツールに適切に統合しないツールが原因で無駄になる開発者の時間は数え切れないほどあります。数

この話の教訓。 CA証明書を捨てる。 あなたがツールを一緒に働かせようとするたびにそのようなバラチ。 それがどのように機能するかは誰にも分かりません。 誰も。 それを使用するソフトウェアは決して機能しません。 結局のところ、すべての証明書をすべてのマシンとトースターにコピーするだけで、その神の気にしない、未知の権限によって署名された証明書がでたらめなエラーになります。

Dockerを処理するためのkubernetesの秘密はまったく役に立たないため、これらの証明書をインストールするために、このクラスターのコアに直接ドリルダウンする必要があります。

血まみれのCA証明書を機能させるために費やされたであろうお金を使って、ハッカーが来たときに強硬を

/ sig auth

gcr.ioを直接使用しているときに誰かがそれに直面した場合、考えられる状況の1つは、マシンの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-画像プルの問題のバグ

問題のノードに移動してcurl -v https://gcr.io/v1/_pingを試してみると、成功した応答が表示されますか？ その場合、ノードがイメージをプルする方法に問題がある可能性があります。 そうでない場合は、そのノードのルート証明書を更新する必要があります

この問題に関する更新はありますか？ これは今私たちを襲っています。

@ srossross-tableau

私が覚えている限り、これはDockerの問題であり、kubernetesの問題ではありませんでした。 DockerはLinuxのca証明書を使用しません。 理由は誰にもわかりません。

Dockerがそれらを使用できるように、これらの証明書を手動で（これらのポッドを生成する可能性のあるすべてのノードに）インストールする必要があります。

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

これらの証明書を取得するためにブートストラップ後にノードをブッチャーする必要があるため、これは非常に厄介な問題です。 そして、kubernetesは常にノードを生成します。 この問題がまだ解決されていない方法は私には謎です。 それは完全なショートッパーIMOです。

これは、kubernetesのシークレットメカニズムを使用して実際に解決する必要があります。 しかし、どういうわけかそうではありません。 知るか！？

@pompomJuice 、これはミニクベ画像の問題でしょうか？ このサイトをカールすることすらできません

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 root root 4096 Dec 2 20:43 ./
drwxr-xr-x3ルートルート4096Dec 2 20:07 ../
-rw-r--r--1ルートルート3332Dec 2 20:23 domain.crt
-rw-r--r--1ルートルート1675Dec 2 20:43 domain.key

これまでのところ、クラスター内の1つのノードのみ:)

それらをca.crtとclient.keyに変更し

ここのように： https ：

ディレクトリ内の両方をca.crtとca.keyに変更し、シークレットで呼び出されたファイルを更新しました。 ノードでDockerサービスを再起動し、ポッドを再デプロイしましたが、それでも同じエラーが発生します。

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ハンドシェイク、クライアントhello（1）：
• TLSv1.2（IN）、TLSハンドシェイク、サーバーhello（2）：
• TLSv1.2（IN）、TLSハンドシェイク、証明書（11）：
• TLSv1.2（OUT）、TLSアラート、サーバーhello（2）：
• SSL証明書の問題：ローカル発行者証明書を取得できません
• 一時停止ストリームを停止しました！
• 接続を閉じる0
  curl：（60）SSL証明書の問題：ローカル発行者証明書を取得できません
  詳細はこちら： https ：

curlは、「バンドル」を使用して、デフォルトでSSL証明書の検証を実行します
認証局（CA）の公開鍵（CA証明書）。 デフォルトの場合
バンドルファイルが適切ではありません。代替ファイルを指定できます
--cacertオプションを使用します。
このHTTPSサーバーがで表されるCAによって署名された証明書を使用する場合
バンドルの場合、証明書の検証はおそらく
証明書に問題がある（有効期限が切れているか、名前が間違っている可能性があります）
URLのドメイン名と一致しません）。
curlによる証明書の検証をオフにする場合は、
-k（または--insecure）オプション。
HTTPS-proxyには、同様のオプション--proxy-cacertと--proxy-insecureがあります。

私は間違いを犯しました。1つはca.keyではなくclient.keyである必要があり

動作するはずです。

ボックスで画像を手動で開始して、再確認してください。

それもうまくいかなかったようです:(同じエラー

コマンドラインから手動でDockerコンテナを起動しようとするとどうなりますか？

ノードの1つでkubectlrunを使用するか、docker 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

次のことを試してください。

独自のDockerレジストリを作成します。 これにはgitlabを使用してください。無料です。

httpでいくつかの画像をホストします。 この画像でポッドを開始してみてください。 次に、表示しているDockerが実際にそのポッドを実行していることを確認します。 その場合は、正しいノードがあることがわかります。

次に、前のdocker runように、接続が拒否されたことの意味を説明してください。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

古い問題は、30日間操作がないと腐敗します。
/remove-lifecycle rottenして、問題を新規としてマークします。
腐った問題は、さらに30日間操作がないと終了します。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ライフサイクル腐敗
/ remove-lifecyclestale

腐った問題は、30日間操作がないと終了します。
/reopen問題を再開します。
/remove-lifecycle rottenして、問題を新規としてマークします。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/閉じる

では、これに対する回避策/修正は何ですか？ 3.9から3.10にアップグレードした後もまだ取得しています。 イメージ "docker-registry.default。svc ：5000 / openshift / mysql @ sha256 ：dfd9f18f47caf290 ...のプルに失敗し、エラーメッセージ：v2 /：x509：不明な機関によって署名された証明書。

ArtifactoryからubuntuのDockerイメージをプルするための実用的なソリューション（証明書は自己署名されています）：

• 使用されているすべての（複数のルートCAがある場合）CA証明書を/ usr / local / share / ca-certificatesに配置します
• update-ca-certificatesを実行します
• dockerデーモンを再起動します（sudo service docker restart）

gcr.ioを直接使用しているときに誰かがそれに直面した場合、考えられる状況の1つは、マシンの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年とまだ同じ問題。
プライベートハーバーレジストリ。
dockerpullは問題なく動作します。
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

minikubeのレジストリとしてJfrogContainerRegistryを使用しています。 私は次のことができます：

1. docker login localhost：443 | または| ip- add：443
2. docker push ip- add：443 / docker-local / test ：latest
3. docker pull ip- add：443 / docker-local / test ：latest

ポート443でリッスンしているNginxリバースプロキシの背後で実行するようにJfrogコンテナレジストリを構成しました。自己署名証明書を作成し、Jfrogはこれらの証明書を使用しています。

次のように、自己署名証明書を使用するようにDockerを構成しました。

1. 証明書を作成し、/ usr / local / share / ca-certificates /にコピーします
2. sudoupdate-ca-certificates
3. 証明書を/etc/docker/cert.d/192.168.0.114:443/ca.crtにコピーします
4. Dockerを再起動しました。

次のように、.yamlファイルによるdockerログインシークレットを使用するように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と名前フラグを使用します。

Dockerプルがターミナルで機能しているこのすべてのセットアップの後、ポッドでx509 IPSansというエラーが発生します。

多くのドキュメントとK8の問題を確認し、 https： //github.com/kubernetes/kubernetes/issues/43924#issuecomment-631533150の手順を複製しました。

複製された手順はうまくいきませんでした。 誰かが私が間違っていることを教えてもらえますか？ どうすれば修正できますか。

私も同じ問題を抱えていますが、この場合はEKSです。 デーモンセットを使用して特権ワークロードをデプロイし、この問題を解決するためにすべてのノードで上記の修正を試みています（イメージはプライベート署名付きレジストリにあります）。