О мониторинге сертификатов SSL

kubernetes ssl monitoring prometheus exporters metrics certificates cockroachdb

На днях развалился подопытный кластер CockroachDB из-за просроченных сертификатов на нодах. Появился повод ещё раз посмотреть по сторонам на предмет мониторинга сертификатов.

В CockroachDB, оказалось, всё уже готово. Есть группа метрик security_certificate_expiration_*, которые выдают enddate в unixtime. Для prometheus остаётся только настроить уведомления о малой разнице с time().

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

Попутно очередной раз посмотрел на предложения по мониторингу сертификатов в Kubernetes.

Kubelet предлагает гистограмму apiserver_client_certificate_expiration_seconds, которая собирает с сертификатов всех клиентов Kubernetes API значение enddate - time() и раскладывает по бакетам. Таким образом мы можем узнать, сколько клиентов API на ноде не укладывается в норматив по сроку годности сертификата. На мой взгляд метрика даёт слишком много пищи для размышлений, что и как чинить. Но если метрика написана так, значит это кому-нибудь нужно.

Интересно выглядит проект node-cert-exporter. Реализована простая идея: экспортер принимает список путей на FS, начиная с которых нужно искать сертификаты. Сертификат попадает под наблюдение, если хранится в файле с типичным для сертификата расширением имени. Время до истечения срока годности каждого сертификата выдаётся как значение метрики ssl_certificate_expiry_seconds, размеченное свойствами сертификата (путь к файлу, subject и т.д.). В результате из метрики сразу можно понять, где и с каким сертификатом проблема.

Статья How To Check SSL Certificate Expiration with Grafana описывает подробный пример использования node-cert-exporter без привязки к Kubernetes, в качестве сервиса systemd, и оформления метрик в Prometheus и Grafana.

В исходниках есть пример манифеста для установки node-cert-exporter на ноды Kubernetes. Создаётся DaemonSet, который сразу организует мониторинг основных сертификатов. Если Control Plane находится под вашим контролем, нужно добавить Tolerations в DaemonSet, хотя бы

tolerations:
- effect: NoSchedule
  key: node-role.kubernetes.io/master

чтобы под с экспортером попал на мастер-ноды.

Практика показывает, что необходим также мониторинг сертификатов, хранящихся в файлах клиентских конфигураций (например /etc/kubernetes/scheduler.conf) и в секретах Kubernetes. Эта задача, по-видимому, ещё ждёт своего героя.