Страница описывает замену собственных TLS-сертификатов Stronghold: сертификата listener API и сертификатов, используемых узлами для взаимодействия в кластере Raft. Выпуск сертификатов для приложений описан в разделе PKI.

Контролируйте срок действия сертификатов с помощью алертов из раздела «Мониторинг» и заменяйте их заранее.

Stronghold в Linux

Сертификат и ключ listener задаются параметрами tls_cert_file и tls_key_file блока listener "tcp". Файл сертификата должен содержать полную цепочку: сначала сертификат сервера, затем промежуточные сертификаты CA.

Проверка текущего сертификата

Чтобы посмотреть субъект, издателя, срок действия и SAN текущего сертификата, выполните команду:

openssl x509 -in /opt/stronghold/tls/node-1-cert.pem -noout -subject -issuer -dates -ext subjectAltName

Замена сертификата без перезапуска

Stronghold перечитывает файлы сертификата и ключа listener при получении сигнала SIGHUP. Изменение путей к файлам при этом не применяется, поэтому новые файлы размещайте по тем же путям.

Выполните на каждом узле по очереди:

  1. Выпустите новый сертификат с теми же SAN (DNS-имена и IP-адреса узла, адрес балансировщика, если он используется).

  2. Проверьте, что сертификат соответствует ключу:

    openssl x509 -in node-1-cert.pem -noout -pubkey | sha256sum
    openssl pkey -in node-1-key.pem -pubout | sha256sum

    Хеши должны совпадать.

  3. Сохраните резервную копию текущих файлов и замените их новыми, сохранив владельца и права доступа:

    cp -a /opt/stronghold/tls /opt/stronghold/tls.bak-$(date +%F)
    install -o stronghold -g stronghold -m 0600 node-1-key.pem /opt/stronghold/tls/node-1-key.pem
    install -o stronghold -g stronghold -m 0644 node-1-cert.pem /opt/stronghold/tls/node-1-cert.pem
  4. Отправьте процессу сигнал SIGHUP:

    systemctl reload stronghold
  5. Проверьте, что сервер отдаёт новый сертификат:

    openssl s_client -connect raft-node-1.demo.tld:8200 </dev/null 2>/dev/null | openssl x509 -noout -dates
  6. Проверьте журналы на ошибки перезагрузки сертификата:

    journalctl -u stronghold.service --since "5 minutes ago"

Если ключ зашифрован паролем, при перезагрузке по SIGHUP пароль должен совпадать с исходным.

Сертификаты retry_join (leader_client_cert_file, leader_ca_cert_file, leader_client_key_file) по SIGHUP не перечитываются: они загружаются при попытке присоединения к кластеру, поэтому новые файлы применяются после перезапуска узла. Перечитывание по SIGHUP поддерживают только TLS-сертификаты listener.

Замена CA

При смене CA, выпустившего сертификаты узлов, соблюдайте порядок, чтобы узлы и клиенты не потеряли доверие друг к другу:

  1. Добавьте новый CA в доверенные на всех клиентах и в файлы leader_ca_cert_file на всех узлах (файл может содержать несколько сертификатов CA).
  2. Перезапустите узлы по одному, начиная со standby-узлов, и дождитесь, пока каждый узел вернётся в кластер (d8 stronghold operator raft list-peers). Узлы с Shamir seal после перезапуска нужно распечатать.
  3. Замените сертификаты узлов на выпущенные новым CA, как описано выше.
  4. После замены на всех узлах удалите старый CA из доверенных.

Перезапуск нужен: файлы leader_ca_cert_file читаются только при присоединении узла.

Stronghold в DP

В DP поддерживаются следующие способы внешнего доступа (инлеты): Ingress, GatewayAPI, LoadBalancer, NodePort и None. Для LoadBalancer, NodePort и None обязателен режим https.mode: CustomCertificate. Сертификат для домена stronghold.<домен> выпускается и хранится согласно настройкам https, описанным в разделе «Настройка Stronghold».

Stronghold использует два вида сертификатов:

  • Внешний сертификат: секрет ingress-tls в режиме CertManager или секрет ingress-tls-customcertificate в режиме CustomCertificate в неймспейсе d8-stronghold. Монтируется в под в /stronghold/tls и используется listener API на порту 8200.
  • Внутренний сертификат: секрет stronghold-tls (ca.crt, tls.crt, tls.key). Выпускается хуком модуля как самоподписанный и монтируется в /stronghold/tls-internal. Используется на портах 8300, 8301 и 8500 (взаимодействие между подами и с прокси). В SAN входят 127.0.0.1, stronghold, *.stronghold-internal, stronghold.d8-stronghold и stronghold.d8-stronghold.svc. Им управляет модуль, заменять его вручную не требуется.
СпособОбновление сертификата
CertManager с ClusterIssuer (Let’s Encrypt или собственный CA)Автоматически, средствами cert-manager
CustomCertificateВручную, обновлением секрета в неймспейсе d8-system

В режиме CertManager модуль создаёт Certificate в неймспейсе d8-stronghold: stronghold при инлете Ingress или stronghold-httproute при инлете GatewayAPI. Оба записывают сертификат в секрет ingress-tls. При других инлетах Certificate нет.

Проверка сертификата

Чтобы проверить состояние Certificate и срок действия сертификата, выполните команды:

d8 k -n d8-stronghold get certificate
d8 k -n d8-stronghold get secret ingress-tls -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -subject -issuer -dates

Команды приведены для режима CertManager. В режиме CustomCertificate используйте секрет ingress-tls-customcertificate (Certificate при этом нет).

Сертификаты cert-manager

cert-manager продлевает сертификат автоматически до истечения срока действия. Если сертификат не обновился, проверьте объекты CertificateRequest:

d8 k -n d8-stronghold get certificaterequest
d8 k -n d8-stronghold describe certificaterequest <NAME>

Чтобы принудительно перевыпустить сертификат, удалите секрет ingress-tls — cert-manager выпустит его заново.

Собственный сертификат

В режиме CustomCertificate замените содержимое секрета в неймспейсе d8-system, имя которого задано в параметре https.customCertificate.secretName в ModuleConfig stronghold. Если параметр https модуля не задан, применяются глобальные настройки modules.https Deckhouse, и имя секрета берётся из них:

d8 k -n d8-system create secret tls <SECRET_NAME> --cert=kubernetes_fullchain.crt --key=kubernetes.key --dry-run=client -o yaml | d8 k apply -f -

В этой команде <SECRET_NAME> — имя секрета, kubernetes_fullchain.crt — файл с цепочкой сертификатов, kubernetes.key — файл ключа.

Deckhouse скопирует обновлённый сертификат в неймспейсы модулей. Проверьте, что Stronghold отдаёт новый сертификат:

openssl s_client -connect stronghold.mycompany.tld:443 </dev/null 2>/dev/null | openssl x509 -noout -dates

Если CA изменился и в модуле user-authn используется dexCAMode: FromIngressSecret, убедитесь, что Dex получил новый CA, иначе вход через OIDC перестанет работать.

Модуль не перезапускает поды stronghold при изменении секрета с сертификатом (в StatefulSet контрольные суммы заданы только для конфигурации и лицензии), а Stronghold перечитывает сертификаты listener только по SIGHUP. Если TLS на порту 8200 завершает сам под (инлеты LoadBalancer и NodePort), после обновления секрета перезапустите поды по одному или отправьте процессу SIGHUP.