Использование идентификатора сертификата пограничного / прокси-узла - PullRequest
Новая
       9

Использование идентификатора сертификата пограничного / прокси-узла

0 голосов
/ 09 июля 2019

Я использую haproxy в качестве шлюза бастионного сервера / кластера, так как только некоторые узлы в моей сети имеют прямой доступ к внешней сети.Мои внутренние узлы являются частью кластера kubernetes и должны иметь возможность извлекать образы из частного реестра, внешнего по отношению к моему кластеру, для которого требуются идентификаторы сертификатов.

внутренний узел кластера k8s -> haproxy на пограничном узле -> реестр docker

Я пытаюсь настроить свой back_end в моем haproxy.cfg для маршрутизации в реестр docker и обновить запросс удостоверением личности пограничного узла.(Внутренний узел не имеет сертификатов, приемлемых для реестра докеров, и мне не разрешено размещать сертификаты внешнего узла на внутреннем узле.) То, что у меня сейчас есть, выглядит следующим образом: 

frontend ft_ssl
   bind <boxIP>:443
   mode http
   default_backend bk_global_import_registry_certs

backend bk_global_import_registry_certs
   mode http
   balance roundrobin
   server registry_alias-0 <registryIP>:443 ssl ca-file fullyqualified/ca.crt crt fullyqualified/file.pem check
   server registry_alias-1 <registryIP2>:443 ssl ca-file fullyqualified/ca.crt crt fullyqualified/file.pem check

В настоящее время у меня установлена ​​ HTTPS_PROXY в /etc/systemd/system/docker.service.d/http-proxy.conf, и я получаю 400 неверных запросов.Ниже вычеркнуто сообщение журнала, с изменениями только при удалении IP-адресов или опечаток.

InternalIP: randomPort [09 / Jul / 2019: 13: 28: 08.659] ft_ssl bk_global_import_registry_certs 0/0/10/5 /15 400 350 - - ---- 1/1/0/0/0 0/0 {} "CONNECT externalFQDN: 443 HTTP / 1.1"

Для тех, кто смотрит на это через kubernetes илиТеги docker. Я также рассмотрел вопрос о настройке pull-through кеша , но понял, что это работает только с общедоступным реестром Docker - см. open Docker GitHub, выпуск 1431 для других людей, пытающихся найти способыи пройди мимо этого.

Ответы [ 2 ]

1 голос
/ 11 июля 2019

Публикация ответа, который разрешил ситуацию для нас, на случай, если это поможет другим ...

Весь трафик от внутреннего узла теперь направляется через HAProxy.

Я недольше использовать настройку HTTPS_PROXY в /etc/systemd/system/docker.service.d/http-proxy.conf.Прокси-сервер не подходит, так как я не могу использовать сертификат своего внутреннего узла для аутентификации в реестре докера.

На внутреннем узле я теперь отношусь к реестру докера как к небезопасному реестру, добавляя его адрес в/etc/docker/daemon.json в незащищенных реестрах: [].

Теперь мы можем получить доступ к нашему внутреннему частному реестру, используя сертификаты, передаваемые в форвард на серверной части HAProxy.Мы проверяем сертификат во внешнем интерфейсе, но поскольку у нас есть реестр, указанный в незащищенных реестрах, Docker принимает несоответствие имени сертификата.

Заметил один побочный эффект: извлечение изображения из реестра докера «по умолчанию» без указания префикса не позволяет использовать наше решение.Например, чтобы вытащить из Docker, вам нужно вытащить из реестра-1.docker.io/imageName:imageVersion, а не просто imageName: imageVersion.

0 голосов
/ 10 июля 2019

Возможно, я ошибаюсь, но насколько я знаю, Haproxy нельзя использовать в качестве прямого HTTP-прокси, он действует только как обратный HTTP-прокси.Вы должны использовать Squid или что-то подобное, чтобы быть прямым HTTP-прокси.

Если вы хотите, чтобы Haproxy прекратил SSL для вас, как вы, то вам нужно будет изменить часть имени хоста вашего образа Docker на имя хоста вашего узла Haproxy.Вы также должны убедиться, что ваши демоны Docker доверяют сертификату Haproxy или добавить Haproxy в список INSECURE_REGISTRIES на всех узлах Kube.

...