trust-manager: раздавать внутренний CA в поды вместо копии бандла в томе #77

New issue

Open

opened 2026-09-20 19:18:44 +00:00 by hermes · 1 comment

hermes commented

2026-09-20 19:18:44 +00:00

(Migrated from git.grachevko.ru)

Зачем

Вход в дашборд Hermes падал на CERTIFICATE_VERIFY_FAILED, потому что discovery к https://sso.домен идёт к envoy-internal с сертификатом от нашего internal-ca, а в образе системного стора этого CA нет. Сейчас закрыто копией бандла в томе (/opt/data/ca-internal-bundle.pem + SSL_CERT_FILE/REQUESTS_CA_BUNDLE/CURL_CA_BUNDLE) — PR #76.

Минус этого решения: копия. internal-ca ротируется (без duration — дефолт ~90 дней, лист шлюза 160h), после ротации файл устареет и вход снова упадёт с той же ошибкой, причём молча — никто не следит за mtime файла в PVC.

Что сделать

Поставить trust-manager (чарт oci://quay.io/jetstack/charts/trust-manager, 0.25.x) — в kubesearch он в ~24 деплоях.
Bundle, источник — наш внутренний CA (Certificate/internal-ca с isCA: true, ключ tls.crt), цель — ConfigMap с ключом ca.crt в те namespace, чьим подам нужен CA (минимум grachevko).
В hermes: монтировать этот ConfigMap read-only и указать SSL_CERT_FILE/REQUESTS_CA_BUNDLE на него вместо файла в томе; удалить копию из PVC.
Заодно проверить остальных потребителей: любые поды, которые ходят по https на *.домен (а не по внутрикластерному http-адресу).

Критерий готовности

Ротация CA больше не требует ручной правки (Bundle обновляет ConfigMap сам, поды могут перечитывать по рестарту).
grep -r ca-internal-bundle.pem kubernetes/ пусто; копии CA нет ни в git, ни в Vault, ни в PVC.

Рецепт и разбор альтернатив — скилл home-ops-cluster, references/oidc-internal-provider.md (раздел «Про раздачу CA»); BackendTLSPolicy для этой цели не подходит (caCertificateRefs — только свой namespace).

## Зачем Вход в дашборд Hermes падал на `CERTIFICATE_VERIFY_FAILED`, потому что discovery к `https://sso.домен` идёт к `envoy-internal` с сертификатом от нашего `internal-ca`, а в образе системного стора этого CA нет. Сейчас закрыто копией бандла в томе (`/opt/data/ca-internal-bundle.pem` + `SSL_CERT_FILE`/`REQUESTS_CA_BUNDLE`/`CURL_CA_BUNDLE`) — PR #76. **Минус этого решения:** копия. `internal-ca` ротируется (без `duration` — дефолт ~90 дней, лист шлюза 160h), после ротации файл устареет и вход снова упадёт с той же ошибкой, причём молча — никто не следит за mtime файла в PVC. ## Что сделать 1. Поставить `trust-manager` (чарт `oci://quay.io/jetstack/charts/trust-manager`, 0.25.x) — в kubesearch он в ~24 деплоях. 2. `Bundle`, источник — наш внутренний CA (`Certificate/internal-ca` с `isCA: true`, ключ `tls.crt`), цель — ConfigMap с ключом `ca.crt` в те namespace, чьим подам нужен CA (минимум `grachevko`). 3. В `hermes`: монтировать этот ConfigMap read-only и указать `SSL_CERT_FILE`/`REQUESTS_CA_BUNDLE` на него вместо файла в томе; удалить копию из PVC. 4. Заодно проверить остальных потребителей: любые поды, которые ходят по https на `*.домен` (а не по внутрикластерному http-адресу). ## Критерий готовности - Ротация CA больше не требует ручной правки (Bundle обновляет ConfigMap сам, поды могут перечитывать по рестарту). - `grep -r ca-internal-bundle.pem kubernetes/` пусто; копии CA нет ни в git, ни в Vault, ни в PVC. Рецепт и разбор альтернатив — скилл `home-ops-cluster`, `references/oidc-internal-provider.md` (раздел «Про раздачу CA»); `BackendTLSPolicy` для этой цели не подходит (`caCertificateRefs` — только свой namespace).

hermes commented

2026-09-20 19:26:53 +00:00

(Migrated from git.grachevko.ru)

Решение владельца (2026-09-20): trust-manager не ставим. После остановки Deckhouse этот кластер публикуется наружу и получает сертификаты Let's Encrypt — внутренний CA перестаёт быть нужен подам, и вся ветка с раздачей internal-ca становится неактуальной сама собой. Копия бандла в PVC (/opt/data/ca-internal-bundle.pem + SSL_CERT_FILE/REQUESTS_CA_BUNDLE/CURL_CA_BUNDLE, PR #76) выбрана как сознательный временный костыль.

Дедлайн, который важно не проспать: Certificate/internal-ca в кластере — renewalTime 2026-11-15T19:27:51Z, notAfter 2026-12-15T19:27:51Z (проверено в кластере). Для isCA: true + selfsigned перевыпуск — это новая пара ключей, то есть копия в томе перестанет проверять лист шлюза и вход в дашборд упадёт с тем же CERTIFICATE_VERIFY_FAILED. Значит к 15.11.2026 нужно одно из двух:

кластер уже отдаёт публичные сертификаты (цель) — тогда ничего делать не надо, внутренний CA в цепочке больше не участвует;
публикация не случилась — обновить копию вручную (взять tls.crt из Secret internal-ca в ns cert-manager и пересобрать бандл с системными корнями) и обновить эту задачу.

Если окажется, что публичных сертификатов ждать долго (не один цикл ротации), задача снова становится актуальной — тогда вернуться к варианту с trust-manager (рецепт в скилле home-ops-cluster, references/oidc-internal-provider.md).

**Решение владельца (2026-09-20): trust-manager не ставим.** После остановки Deckhouse этот кластер публикуется наружу и получает сертификаты Let's Encrypt — внутренний CA перестаёт быть нужен подам, и вся ветка с раздачей `internal-ca` становится неактуальной сама собой. Копия бандла в PVC (`/opt/data/ca-internal-bundle.pem` + `SSL_CERT_FILE`/`REQUESTS_CA_BUNDLE`/`CURL_CA_BUNDLE`, PR #76) выбрана как сознательный временный костыль. **Дедлайн, который важно не проспать:** `Certificate/internal-ca` в кластере — `renewalTime 2026-11-15T19:27:51Z`, `notAfter 2026-12-15T19:27:51Z` (проверено в кластере). Для `isCA: true` + `selfsigned` перевыпуск — это новая пара ключей, то есть копия в томе перестанет проверять лист шлюза и вход в дашборд упадёт с тем же `CERTIFICATE_VERIFY_FAILED`. Значит к 15.11.2026 нужно одно из двух: 1. кластер уже отдаёт публичные сертификаты (цель) — тогда ничего делать не надо, внутренний CA в цепочке больше не участвует; 2. публикация не случилась — обновить копию вручную (взять `tls.crt` из Secret `internal-ca` в ns `cert-manager` и пересобрать бандл с системными корнями) и обновить эту задачу. Если окажется, что публичных сертификатов ждать долго (не один цикл ротации), задача снова становится актуальной — тогда вернуться к варианту с trust-manager (рецепт в скилле `home-ops-cluster`, `references/oidc-internal-provider.md`).

No labels

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

grachevko/home-ops#77

No description provided.

Rows
Columns