Когда я установил наш кластер, я использовал самоподписанный сертификат нашего внутреннего центра сертификации. Все было хорошо, пока я не начал получать сертификаты об ошибках от приложений, которые я развертывал в кластере OKD. Мы решили вместо того, чтобы пытаться исправить ошибки по одному за все время, мы просто купили бы коммерческий сертификат и установили его. Поэтому мы купили сертификат SAN с подстановочными знаками (идентичными тому, который мы изначально получили от нашего внутреннего ЦС) от GlobalSign, и я пытаюсь установить его с огромными проблемами.
Имейте в виду, я пробовал десятки итераций здесь. Я просто документирую последний, который я попробовал, чтобы выяснить, в чем проблема. Это на моем тестовом кластере, который является сервером VM, и я возвращаюсь к снимку после каждого. Снимок - это операционный кластер, использующий внутренние сертификаты CA.
Итак, моим первым шагом было создание моего CA-файла, который нужно передать. Я загрузил корневые и промежуточные сертификаты для GlobalSign и поместил их в файл ca-globalsign.crt
. (В формате PEM)
когда я бегу
openssl verify -CAfile ../ca-globalsign.crt labtest.mycompany.com.pem
я получаю:
labtest.mycompany.com.pem: OK
и openssl x509 -in labtest.mycompany.com.pem -text -noout
дает мне (отредактировано)
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
(redacted)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
Validity
Not Before: Apr 29 16:11:07 2019 GMT
Not After : Apr 29 16:11:07 2020 GMT
Subject: C=US, ST=(redacted), L=(redacted), OU=Information Technology, O=(redacted), CN=labtest.mycompany.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
(redacted)
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Authority Information Access:
CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.4146.1.20
CPS: https://www.globalsign.com/repository/
Policy: 2.23.140.1.2.2
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Alternative Name:
DNS:labtest.mycompany.com, DNS:*.labtest.mycompany.com, DNS:*.apps.labtest.mycompany.com
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Key Identifier:
(redacted)
X509v3 Authority Key Identifier:
(redacted)
(redacted)
на моей локальной машине. Все, что я знаю о SSL, говорит, что сертификат в порядке. Эти новые файлы помещаются в проект, который я использую для хранения конфигов, и для моей установки OKD.
Затем я обновил файлы сертификатов в своем проекте инвентаризации и выполнил команду
ansible-playbook -i ../okd_install/inventory/okd_labtest_inventory.yml playbooks/redeploy-certificates.yml
Когда я читаю документы, все говорят мне, что он должен просто пройти через процесс и придумать новые сертификаты. Этого не происходит Когда я использую openshift_master_overwrite_named_certificates: false
в моем файле инвентаризации, установка завершается, но она заменяет только сертификат в домене *.apps.labtest
, но console.labtest
остается оригиналом, но он подключается, за исключением того факта, что мониторинг говорит bad gateway
в консоли кластера.
Теперь, если я попытаюсь запустить команду еще раз, при использовании openshift_master_overwrite_named_certificates: true
мой /var/log/containers/master-api*.log
будет залит такими ошибками, как эта
{"log":"I0507 15:53:28.451851 1 logs.go:49] http: TLS handshake error from 10.128.0.56:46796: EOF\n","stream":"stderr","time":"2019-05-07T19:53:28.451894391Z"}
{"log":"I0507 15:53:28.455218 1 logs.go:49] http: TLS handshake error from 10.128.0.56:46798: EOF\n","stream":"stderr","time":"2019-05-07T19:53:28.455272658Z"}
{"log":"I0507 15:53:28.458742 1 logs.go:49] http: TLS handshake error from 10.128.0.56:46800: EOF\n","stream":"stderr","time":"2019-05-07T19:53:28.461070768Z"}
{"log":"I0507 15:53:28.462093 1 logs.go:49] http: TLS handshake error from 10.128.0.56:46802: EOF\n","stream":"stderr","time":"2019-05-07T19:53:28.463719816Z"}
и эти
{"log":"I0507 15:53:29.355463 1 logs.go:49] http: TLS handshake error from 10.70.25.131:44424: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53:29.357218793Z"}
{"log":"I0507 15:53:29.357961 1 logs.go:49] http: TLS handshake error from 10.70.25.132:43128: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53:29.358779155Z"}
{"log":"I0507 15:53:29.357993 1 logs.go:49] http: TLS handshake error from 10.70.25.132:43126: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53:29.358790397Z"}
{"log":"I0507 15:53:29.405532 1 logs.go:49] http: TLS handshake error from 10.70.25.131:44428: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53:29.406873158Z"}
{"log":"I0507 15:53:29.527221 1 logs.go:49] http: TLS handshake error from 10.70.25.132:43130: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53
и установка зависает на задании ANLS TASK [Remove web console pods]
. Он будет сидеть там часами. Когда войдите в консоль мастера и запустите oc get pods
на openshift-web-console
, он находится в состоянии terminating
. Когда я описываю модуль, который пытается начать с pending
, он возвращается, говоря, что жесткий диск заполнен. Я предполагаю, что это потому, что он не способен обмениваться данными с системой хранения из-за всех этих ошибок TLS выше. Это просто остается там. Я могу вернуть кластер обратно, если я принудительно удаляю завершающий модуль, затем перезагружаю мастер, затем удаляю новый модуль, который пытается запустить, затем перезагружаюсь во второй раз. Затем веб-консоль подключается к сети, но все мои файлы журналов заполняются этими ошибками TLS. Но более тревожным является то, что установка зависает в этом месте, поэтому я предполагаю, что после подключения веб-консоли есть дополнительные шаги, которые также вызывают у меня проблемы.
Итак, я также попытался повторно развернуть сервер CA. Это привело к проблемам, потому что мой новый сертификат не является сертификатом CA. Затем, когда я только что запустил книгу повторного развертывания CA, чтобы кластер воссоздал серверные CA, все закончилось нормально, но когда я попытался запустить redeploy-certificates.yml
, я получил те же результаты.
вот мой файл инвентаря
all:
children:
etcd:
hosts:
okdmastertest.labtest.mycompany.com:
masters:
hosts:
okdmastertest.labtest.mycompany.com:
nodes:
hosts:
okdmastertest.labtest.mycompany.com:
openshift_node_group_name: node-config-master-infra
okdnodetest1.labtest.mycompany.com:
openshift_node_group_name: node-config-compute
openshift_schedulable: True
OSEv3:
children:
etcd:
masters:
nodes:
# https://docs.okd.io/latest/install_config/persistent_storage/persistent_storage_glusterfs.html#overview-containerized-glusterfs
# https://github.com/openshift/openshift-ansible/tree/master/playbooks/openshift-glusterfs
# glusterfs:
vars:
openshift_deployment_type: origin
ansible_user: root
openshift_master_cluster_method: native
openshift_master_default_subdomain: apps.labtest.mycompany.com
openshift_install_examples: true
openshift_master_cluster_hostname: console.labtest.mycompany.com
openshift_master_cluster_public_hostname: console.labtest.mycompany.com
openshift_hosted_registry_routehost: registry.apps.labtest.mycompany.com
openshift_certificate_expiry_warning_days: 30
openshift_certificate_expiry_fail_on_warn: false
openshift_master_overwrite_named_certificates: true
openshift_hosted_registry_routetermination: reencrypt
openshift_master_named_certificates:
- certfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.pem"
keyfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.key"
cafile: "/Users/me/code/devops/okd_install/certs/ca-globalsign.crt"
names:
- "console.labtest.mycompany.com"
# - "labtest.mycompany.com"
# - "*.labtest.mycompany.com"
# - "*.apps.labtest.mycompany.com"
openshift_hosted_router_certificate:
certfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.pem"
keyfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.key"
cafile: "/Users/me/code/devops/okd_install/certs/ca-globalsign.crt"
openshift_hosted_registry_routecertificates:
certfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.pem"
keyfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.key"
cafile: "/Users/me/code/devops/okd_install/certs/ca-globalsign.crt"
# LDAP auth
openshift_master_identity_providers:
- name: 'mycompany_ldap_provider'
challenge: true
login: true
kind: LDAPPasswordIdentityProvider
attributes:
id:
- dn
email:
- mail
name:
- cn
preferredUsername:
- sAMAccountName
bindDN: 'ldapbind@int.mycompany.com'
bindPassword: (redacted)
insecure: true
url: 'ldap://dc-pa1.int.mycompany.com/ou=mycompany,dc=int,dc=mycompany,dc=com'
что мне здесь не хватает? Я думал, что этот redeploy-certificates.yml
playbook был разработан, чтобы обновить сертификаты. Почему я не могу передать это моему новому коммерческому сертификату? Это почти как замена сертификатов на маршрутизаторе (вроде), но в процессе завинчивание сертификата внутреннего сервера. Я на самом деле здесь, в конце концов, я не знаю, что еще попробовать.