Kubernetes: Не удалось получить изображение с ошибкой «x509: сертификат, подписанный неизвестным центром»

Я задал вопрос здесь: http://stackoverflow.com/q/43150437/969784

Предполагая, что вы используете самоподписанный сертификат, ваш центр сертификации все равно необходимо добавить в локальное хранилище доверенных сертификатов, даже если вы используете --skip-tls-verify.

@rushilpaul

• Первый --insecure-skip-tls-verify не является допустимым аргументом для kubectl create ;
• На самом деле x509 error находится на стороне docker . Демону не удалось получить образ из незащищенного реестра. Вы можете обратиться к небезопасному реестру докеров, чтобы узнать, как доверять / пропустить безопасность реестра.

@dixudx Я забыл об этом упомянуть. Я установил сертификат сервера глобально на этом главном узле Kubernetes, а затем перезапустил службу докеров, работающую на нем. После этого я могу вручную вытащить это изображение с помощью docker pull 10.78.0.228:5000/monitorms . До этого я получал это сообщение об ошибке при ручном извлечении этого изображения.

Ошибка возникает из-за того, что на узлах Kubernetes не установлен сертификат?

@dixudx Кроме того, kubectl options перечисляет --insecure-skip-tls-verify как один из «глобальных» параметров и говорит, что его можно передать любой команде Kubernetes.

--insecure-skip-tls-verify просто пропускает проверку сертификата сервера, а не реестр докеров, поэтому не может решить проблему. Ошибка исходит от демона Docker при загрузке образа.

Я установил сертификат сервера глобально на этом главном узле Kubernetes, а затем перезапустил службу докеров, работающую на нем.

Возможно, вам стоит попробовать команду docker pull 10.78.0.228:5000/monitorms на узлах k8s, которые содержат модуль, а не на мастере k8s.

Это допустимый аргумент для kubectl create но он просто контролирует доверие между kubectl и сервером API.

Ошибка извлечения находится между узлом и реестром докеров. Узлу необходимо либо доверять сертификату, либо рассматривать этот реестр как ненадежный реестр (что делает узел допускающим ошибки проверки TLS).

@supereagle Я собираюсь добавить параметр небезопасного реестра в файл конфигурации докеров на узлах k8s. Надеюсь, это поможет

Можно подумать, что сейчас это решено.

Сертификаты CA

Фактические зафиксированные случаи предотвращения несанкционированного доступа: НОЛЬ
Бессчетное количество времени разработчика, потраченного впустую из-за инструментов, которые не интегрируют сертификаты CA в свои инструменты должным образом: миллионы человеко-часов.

Мораль истории. Сертификаты CA Ditch. Такая баллэша каждый раз, когда вы пытаетесь заставить инструменты работать вместе. Никто не знает, как это работает. Никто. Программное обеспечение, которое его использует, никогда не работает. В конце концов, вы просто копируете все сертификаты на каждую машину и на свой тостер, чтобы не получить этот чертов x509: сертификат, подписанный неизвестным авторитетом, ерунда, каждый раз, когда вы пытаетесь использовать какие-либо инструменты.

Теперь мне нужно перейти прямо к ядру этого кластера, чтобы установить эти сертификаты, потому что секреты 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 , увидите ли вы успешный ответ? Если да, то может быть проблема в том, как узел извлекает изображения. если нет, вам просто нужно обновить корневые сертификаты на этом узле

Есть новости по этой проблеме? это нас сейчас бьет.

@ sross-tableau

Насколько я помню, это была проблема с докером, а не с кубернетами. Docker не использует CA-сертификаты Linux. Никто не знает почему.

Вы должны установить эти сертификаты вручную (на каждом узле, который может порождать эти модули), чтобы докер мог их использовать:

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

Это очень неприятная проблема, так как вам нужно разделить свои узлы после начальной загрузки, чтобы получить эти сертификаты. И кубернетес все время порождает узлы. Как этот вопрос до сих пор не решен - для меня загадка. Это полная остановка ИМО.

Это действительно должно быть решено с помощью механизма секретов кубернетов. Но почему-то это не так. Кто знает!?

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

Совершенно моя точка зрения. Эта ошибка curl просто неправильна. Он говорит вам, что у вас есть сертификаты, но они самоподписаны. Я считаю это маловероятным. (Если только вы их там не взломали)

Это означает, что это сообщение об ошибке просто неверно. Это связано с моим предыдущим замечанием о том, что почти никто не реализует это правильно.

Попробуйте обновить сертификаты в этом поле, как было предложено выше в ReSearchITEng.

Я столкнулся с той же проблемой. Сертификаты взяты из digicert, кластер kubernetes, работающий в GCE, сертификаты, установленные через хост и помещенные в /etc/docker/certs.d/, и все еще ошибка x509.

Журналы Docker:
TLS handshake error from XXXXXXXXXX: remote error: tls: bad certificate

Куб версия:
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"}

хост:
ИМЯ = "Ubuntu"
ВЕРСИЯ = "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 2 дек 20:43 ./
drwxr-xr-x 3 root root 4096 2 дек 20:07 ../
-rw-r - r-- 1 root root 3332 2 дек 20:23 domain.crt
-rw-r - r-- 1 root root 1675 2 дек 20:43 domain.key

Пока только один узел в кластере :)

Измените их на ca.crt и client.key

Как здесь: https://docs.docker.com/engine/security/certificates/#creating -the-client-Certificates

Изменил их на ca.crt и ca.key как в каталоге, так и обновил файлы, указанные в секрете. Я перезапустил службу докеров на узле и повторно развернул модули, но все равно ошибка.

Вот дополнительная информация из 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
• Выбор шифра: ПРОФИЛЬ = СИСТЕМА
• успешно установить места проверки сертификата:
• Файл CA: /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.haxx.se/docs/sslcerts.html

curl по умолчанию выполняет проверку сертификата SSL, используя "пакет"
открытых ключей центра сертификации (CA) (сертификаты CA). Если по умолчанию
файл пакета не подходит, вы можете указать альтернативный файл
используя параметр --cacert.
Если этот HTTPS-сервер использует сертификат, подписанный ЦС, представленным в
пакет, проверка сертификата, вероятно, не удалась из-за
проблема с сертификатом (срок его действия может истек или имя может
не соответствует имени домена в URL-адресе).
Если вы хотите отключить проверку сертификата curl, используйте
параметр -k (или --insecure).
HTTPS-прокси имеет аналогичные параметры --proxy-cacert и --proxy-insecure.

Я ошибся, должен быть client.key, а не ca.key .

Он должен работать.

Дважды проверьте, пытаясь запустить изображение вручную на коробке.

Это тоже не сработало :( та же ошибка

Что происходит, когда вы пытаетесь запустить контейнер докера вручную из командной строки?

я должен использовать kubectl run на одном из узлов или 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: сервер дал HTTP-ответ клиенту HTTPS

Команда 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_HTTPEY_TL / certs / ca.crt, REGISTRY_HTTPEY_TL /client.key "--expose = true

Попробуйте следующее.

Создайте свой собственный реестр докеров. Используйте для этого gitlab бесплатно.

Разместите на нем несколько изображений на http. Попробуйте начать с этого образа. Затем убедитесь, что докер, на который вы смотрите, действительно запускает этот модуль. Если это так, то вы знаете, что у вас правильный узел.

Затем, как раньше, docker run и объясните мне, что вы имеете в виду под отказом в соединении.

Проблемы становятся устаревшими после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

Старые выпуски гниют после 30 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle rotten .
Гнилые проблемы закрываются после дополнительных 30 дней бездействия.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл гнилой
/ remove-жизненный цикл устаревший

Гнилые проблемы закрываются после 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. Постоянное исправление, которое не ломается после того, как требуется установка / обновление, или полностью переработать его. В противном случае он не готов для производственных рабочих нагрузок.

рабочее решение для извлечения образа докера на ubuntu из Artifactory (сертификат самоподписанный):

• поместите все используемые (если есть более одного корневого CA) сертификаты CA в / usr / local / share / ca-Certificates
• запустить update-ca-Certificates
• перезапустить демон докера (sudo service 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

Это действительно сработало для меня.

Я запускаю kubernetes на RancherOS как часть установки Rancher 2.x и имею частный реестр, который не выходит в Интернет, поэтому мне приходится использовать на нем самозаверяющий сертификат, что приводит к ошибке x509. Я прочитал эту ветку и несколько других и решил проблему - поделился, если это может кому-то помочь, если не напрямую, то предложив возможный путь.

Это сработало для меня - https://www.ctrl-alt-del.cc/2018/11/solution-rancher-2-k8s-private-registry.html

2020 год и все та же проблема.
реестр частных портов.
docker pull работает без проблем.
ls /etc/docker/certs.d/registry.myharbor.com/ показывает сертификат.
kubernetes не может получить изображения с ошибкой imagepullbackoff.
Прошло 3 года, и у kubernetes все еще есть эта проблема. Очень разочаровывает.

Решено

1. Убедитесь, что вы можете выполнить docker pull IMAGENAME с машины, на которой вы запускаете развертывание (файлы yaml, пакеты helm и т. Д.)
2. Убедитесь, что на всех нодах кубернетов присутствует следующее: /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- add: 443 / docker-local / test : последний
3. docker pull ip- добавить: 443 / docker-local / test : последний

Я настроил реестр контейнеров Jfrog для работы за обратным прокси-сервером Nginx, прослушивающим порт 443. Создал самозаверяющие сертификаты, и Jfrog использует эти сертификаты.

Настроил докер для использования самозаверяющих сертификатов следующим образом.

1. Создайте сертификаты, скопируйте их в / usr / local / share / ca-Certificates /
2. sudo update-ca-сертификаты
3. скопируйте сертификат в /etc/docker/cert.d/192.168.0.114:443/ca.crt
4. перезапустил докер, просто убедитесь

Настройте K8 для использования секрета входа в докер с помощью файла .yaml следующим образом:

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 pull работает на терминале, я получаю сообщение об ошибке на модулях с надписью x509 IP Sans.

Я просмотрел много документации и проблем с K8, повторил шаг https://github.com/kubernetes/kubernetes/issues/43924#issuecomment -631533150

повторил шаги не сработали. Может ли кто-нибудь сообщить мне, что я делаю не так? и как я могу это исправить.

У меня такие же проблемы, но в данном случае на EKS. Я использую набор демонов для развертывания привилегированной рабочей нагрузки, чтобы попытаться исправить указанные выше исправления на всех узлах для решения этой проблемы (изображения находятся в закрытом подписанном реестре).