Безопасность observability-конвейеров: настройка mTLS между Vector и Prometheus

Безопасность observability-конвейеров: настройка mTLS между Vector и Prometheus

В современных распределенных системах сбор метрик производительности часто выходит за рамки одного изолированного контура. Типичный сценарий: ваше приложение развернуто в изолированном кластере Kubernetes, а центральная система мониторинга находится в другом географическом регионе. Передача данных мониторинга через публичный интернет требует надежной защиты.

Для решения этой задачи используется связка из агента сбора данных Vector и системы мониторинга Prometheus. Чтобы гарантировать безопасность, канал связи защищают с помощью взаимной TLS-аутентификации (mTLS). В отличие от обычного HTTPS, mTLS требует, чтобы и сервер, и клиент предъявили друг другу цифровые сертификаты.

В этом руководстве разберем процесс настройки безопасного канала передачи метрик из Kubernetes в удаленный Prometheus с использованием Nginx в качестве защитного шлюза.

Терминология

Перед началом работы определим ключевые понятия:

• mTLS (Mutual TLS): Двусторонняя шифрованная связь, при которой обе стороны проверяют сертификаты друг друга. Это исключает перехват данных и отправку поддельных метрик.
• CA (Certificate Authority): Корневой сертификат и закрытый ключ, используемые для подписи всех остальных сертификатов в нашей системе.
• Vector: Легкий и быстрый агент для сбора, фильтрации и отправки метрик и логов.
• Prometheus Remote Write: Протокол, позволяющий внешним агентам принудительно отправлять (пушить) метрики в базу данных Prometheus.
• Nginx: Веб-сервер, работающий как обратный прокси (reverse proxy) — принимает зашифрованные запросы от Vector, проверяет его сертификат и перенаправляет трафик в Prometheus.
• Kubernetes Secret: Объект в Kubernetes для безопасного хранения конфиденциальных данных (сертификатов и ключей).

Архитектура решения

Поток данных выглядит следующим образом:

1. Агент Vector в Kubernetes собирает метрики приложений.
2. Vector отправляет эти метрики по протоколу Prometheus Remote Write на удаленный адрес Nginx, передавая свой клиентский сертификат.
3. Nginx на удаленном сервере принимает запрос, проверяет сертификат с помощью корневого ca.crt и перенаправляет запрос в локальный Prometheus.

Шаг 1: Подготовка инфраструктуры (Prerequisites)

Вам понадобятся:

1. Установленная утилита kubectl (официальная документация).
2. Установленный Helm (официальная документация) для развертывания Vector.
3. Удаленный сервер с установленным Prometheus и Nginx. Prometheus должен быть запущен с флагом --web.enable-remote-write-receiver.
4. Доменное имя (например, prometheus.my-domain.com), направленное на IP-адрес удаленного сервера.

Шаг 2: Генерация сертификатов mTLS

Все команды выполняются на вашем локальном компьютере.

!IMPORTANTБезопасность закрытых ключей: Файлы с расширением .key содержат секретные закрытые ключи. Ни в коем случае не передавайте их третьим лицам и не публикуйте в репозиториях кода. В случае компрометации ключа всю цепочку сертификатов придется перевыпускать.

1. Создание корневого центра сертификации (CA)

openssl req \
  -new \
  -x509 \
  -nodes \
  -days 30 \
  -subj '/CN=my-ca.my-domain.com' \
  -keyout ca.key \
  -out ca.crt

Этот шаг создаст закрытый ключ ca.key и корневой сертификат ca.crt со сроком действия 30 дней.

2. Генерация ключа и сертификата для сервера (Prometheus / Nginx)

Создаем запрос на подпись сертификата (CSR) для сервера и подписываем его нашим CA. В поле CN (Common Name) укажите доменное имя вашего сервера:

openssl genrsa -out server.key 4096
openssl req \
  -new \
  -key server.key \
  -subj '/CN=prometheus.my-domain.com' \
  -out server.csr
openssl x509 \
  -req \
  -in server.csr \
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -days 30 \
  -out server.crt

3. Генерация ключа и сертификата для клиента (Vector)

Аналогично создаем сертификат для агента Vector:

openssl genrsa -out client.key 4096
openssl req \
  -new \
  -key client.key \
  -subj '/CN=vector.my-domain.com' \
  -out client.csr
openssl x509 \
  -req \
  -in client.csr \
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -days 30 \
  -out client.crt

Лишние файлы запросов .csr и файл серийных номеров .srl можно удалить.

Шаг 3: Настройка сервера (Nginx)

Выполняется на удаленном сервере. Скопируйте туда файлы ca.crt, server.crt и server.key (например, в директорию /etc/nginx/certs/).

Настройте виртуальный хост в конфигурационном файле Nginx, используя директивы модуля ngx_http_ssl_module:

server {
    listen 9090 ssl;
    server_name prometheus.my-domain.com;

    # Сертификаты сервера Nginx
    ssl_certificate /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;

    # Включение проверки клиентских сертификатов
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    ssl_verify_client on;

    location /api/v1/write {
        proxy_pass http://127.0.0.1:9090/api/v1/write;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

После изменения конфигурации перезапустите Nginx:

sudo systemctl restart nginx

Шаг 4: Настройка клиента (Vector в Kubernetes)

Выполняется на вашем локальном компьютере с помощью утилиты kubectl.

1. Создание пространства имен и загрузка сертификатов

kubectl create namespace vector

Загружаем сгенерированные клиентские сертификаты и корневой сертификат CA в Kubernetes Secret. Обратите внимание на имена файлов при импорте:

kubectl create secret generic vector-certs \
  --namespace vector \
  --from-file=ca.crt=ca.crt \
  --from-file=client.crt=client.crt \
  --from-file=client.key=client.key

2. Создание конфигурации Vector

Создайте файл конфигурации vector.yaml на локальном диске:

data_dir: /var/lib/vector
sources:
  app_scrape:
    type: prometheus_scrape
    endpoints:
      - "http://app.my-namespace.svc.cluster.local:8384/metrics"
    scrape_interval_secs: 15
sinks:
  prometheus_remotewrite:
    type: prometheus_remote_write
    inputs:
      - app_scrape
    endpoint: https://prometheus.my-domain.com:9090/api/v1/write
    healthcheck:
      enabled: true
    tls:
      ca_file: "/run/secrets/tls/ca.crt"
      crt_file: "/run/secrets/tls/client.crt"
      key_file: "/run/secrets/tls/client.key"

!WARNINGСопоставление имен файлов: Убедитесь, что пути к файлам в секции tls (ca_file, crt_file, key_file) точно указывают на смонтированные файлы из созданного ранее Secret. Если в Secret вы указали другие имена при импорте, измените пути в конфигурации.

3. Создание ConfigMap и деплой через Helm

kubectl create configmap vector-custom-configs \
  --namespace vector \
  --from-file=vector.yaml=vector.yaml

Подключите официальный репозиторий Vector Helm (официальный гайд по Helm-установке) и установите агент:

helm repo add vector https://helm.vector.dev
helm repo update
helm upgrade --install my-vector-release vector/vector \
  --namespace vector \
  -f my-vector-custom-values.yaml

Шаг 5: Проверка работоспособности (Verification)

1. Проверка статуса подов в Kubernetes:

   kubectl get pods -n vector
   

   Статус пода должен быть Running.
2. Анализ логов Vector:

   kubectl logs -n vector -l app.kubernetes.io/name=vector
   

   В логах не должно быть ошибок с меткой [sinks.prometheus_remotewrite].
3. Анализ логов Nginx на сервере: В файле /var/log/nginx/access.log вы должны увидеть входящие запросы POST /api/v1/write с кодом ответа 200. Если вы видите код 400 или 403, значит, клиентский сертификат не прошел проверку.

Шаг 6: Безопасность и эксплуатация (Safety & Operations)

• Ротация сертификатов: В данном примере срок действия сертификатов составляет всего 30 дней. Для продуктивных сред (production) рекомендуется настроить автоматическое продление с помощью cert-manager в Kubernetes или HashiCorp Vault.
• Проверка имени узла (Hostname Verification): Никогда не отключайте проверку имени узла (параметр verify_hostname в Vector) в продуктивных средах. Без нее mTLS становится уязвим для атак класса Man-in-the-Middle (MitM).
• Масштабирование и буферизация: При передаче метрик между регионами настройте дисковый буфер во Vector (параметр buffer.type = "disk"), чтобы агент мог накапливать метрики локально во время сетевых сбоев.