Yesterday

Пошаговое руководство по настройке безопасности конвейеров наблюдаемости с помощью Vector от Datadog

Перевод оригинальной статьи A Step-by-Step Guide to Securing Observability Pipelines Using Vector by Datadog.

Перевод сделан специально для телеграм-канала Мониторим ИТ. Подписывайтесь! Там еще больше полезных постов о мониторинге.

В сложном мире современных распределенных программных систем наблюдаемость является ключевым компонентом, позволяющим обеспечить высокую производительность и надёжность.

Независимо от того, являетесь ли вы начинающим специалистом или опытным инженером, который ищет рекомендации по построению конвейеров наблюдаемости, эта статья будет полезна для любого уровня подготовки.

Почему Vector?

Начнём с нашего сценария использования. В DV мы часто упаковываем и поставляем приложения нашим партнёрам, которые затем устанавливают их в своей инфраструктуре. Чтобы обеспечить надёжность, нам необходимо собирать данные о производительности этих приложений.

Поскольку инфраструктура наших партнеров часто остается для нас "черным ящиком", мы пришли к выводу, что нам необходим инструмент, отвечающий следующим требованиям:

  1. Мы могли бы включить его в наше приложение для сбора необходимых данных о производительности.
  2. Процесс сбора данных оказывает минимальное воздействие на систему как с точки зрения использования памяти, так и загрузки процессора.
  3. Возможность безопасно передавать собранные данные в наши централизованные системы мониторинга.

Несмотря на наличие множества решений для корпоративного мониторинга и инструментов с открытым исходным кодом, Vector от Datadog выделился среди прочих благодаря своей лёгкости и высокой производительности.

Vector — инструмент с открытым исходным кодом для построения конвейеров наблюдаемости. Он настраивается для сбора, преобразования и маршрутизации логов, метрик и трассировок в любую поддерживаемую систему назначения из списка поддерживаемых Datadog получателей.

В этой статье я покажу, как собирать метрики Prometheus из приложения, работающего в кластере Kubernetes, и передавать их в экземпляр Prometheus, размещённый на виртуальной машине в другом географическом регионе, используя Prometheus Remote Write.

Предварительные требования

Для понимания этой статьи вам потребуется:

  1. Практические навыки работы с Kubernetes и использования Kubectl.
  2. Практические навыки установки и настройки Helm-чартов.
  3. Запущенный кластер Kubernetes как минимум с одним узлом (в примере используется кластер GKE).
  4. Запущенный экземпляр Prometheus с включённой поддержкой Remote Write (в примере Prometheus установлен на виртуальной машине в GCP).
  5. Все необходимые сетевые коммуникации между Vector и Prometheus.
  6. Сертификаты mTLS, подписанные доверенным центром сертификации (для этой демонстрации используются самоподписанные сертификаты).

Что такое mTLS?

Mutual TLS, или сокращенно mTLS, — это механизм взаимной аутентификации. mTLS гарантирует, что обе стороны сетевого соединения действительно являются теми, за кого себя выдают, проверяя наличие корректного закрытого ключа у каждой из сторон. Дополнительная проверка осуществляется на основе информации, содержащейся в соответствующих TLS-сертификатах.

mTLS часто используется в рамках концепции безопасности «нулевого доверия» для проверки пользователей, устройств и серверов организации.

Архитектурная схема

Далее — самая интересная часть: внедрение!

Шаг 1: Создание самоподписанных mTLS-сертификатов

Сначала мы создаём центр сертификации (ЦС), которому доверяют как клиент, так и сервер.

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

Эта команда выводит два файла, ca.key и ca.crt, оба в формате PEM.

Далее мы создаём ключ сервера, а затем сертификат.

openssl genrsa -out server.key 4096

Теперь давайте создадим запрос на подписание сертификата (CSR), который будет подписан нашим центром сертификации:

openssl req \
 -new \
 -key server.key \
 -subj '/CN=prometheus.my-domain.com' \
 -out server.csr

Используя запрос на подписание сертификата (CSR), давайте создадим сертификат сервера:

openssl x509 \
 -req \
 -in server.csr \
 -CA ca.crt \
 -CAkey ca.key \
 -CAcreateserial \
 -days 30 \
 -out server.crt

Обратите внимание на следующий вывод команды, а также на созданный PEM-файл server.crt:

Certificate request self-signature ok
subject=CN=prometheus.my-domain.com

Теперь повторим этот процесс для создания клиентского сертификата и закрытого ключа. Как и ранее, начнём с генерации ключа.

openssl genrsa -out client.key 4096

Теперь создадим запрос на подпись сертификата (CSR), который также будет подписан нашим центром сертификации.

openssl req \
 -new \
 -key client.key \
 -subj '/CN=vector.my-domain.com' \
 -out client.csr

Используя запрос на подписание сертификата (CSR), создайте клиентский сертификат:

openssl x509 \
 -req \
 -in client.csr \
 -CA ca.crt \
 -CAkey ca.key \
 -CAcreateserial \
 -days 30 \
 -out client.crt

Обратите внимание на приведенный ниже вывод, а также на PEM-файл client.crt:

Certificate request self-signature ok
subject=CN=vector.my-domain.com

Теперь в текущей рабочей директории должны находиться следующие файлы:

ca.crt
ca.key
ca.srl
client.crt
client.csr
client.key
server.crt
server.csr
server.key

Мы будем работать с файлами ca.crt, ca.key, client.crt, client.key, server.crt и server.key. Переместите их в такое место, где Vector сможет получить доступ к клиентским сертификатам, а Prometheus — к серверным.

Можете смело удалять файлы ca.srl, client.csr и server.csr — они нам больше не нужны.

Шаг 2: Создание Namespace для Vector и Kubernetes Secret с сертификатами mTLS

Создайте своё пространство имён:

kubectl create namespace vector

Затем создайте Kubernetes Secret с сертификатами:

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

Шаг 3: Установка и настройка Vector с помощью Helm

Добавьте репозиторий Helm:

helm repo add vector https://helm.vector.dev
helm repo update

Подготовьте пользовательскую конфигурацию для Vector.

Давайте создадим пользовательский файл и определим в нём наши конвейеры наблюдаемости.

В приведённом ниже примере Vector настроен на получение метрик с конечной точки http://app.my-namespace.svc.cluster.local:8384/metrics в секции source, а затем на передачу данных на конечную точку https://prometheus.my-domain.com:9090/api/v1/write в секции sink (получателя) с использованием TLS.

## my-vector-custom-configs.yaml
data_dir: /var/lib/vector
sources:
  app_scrape:
    type: prometheus_scrape
    endpoints:
    - "http://app.my-namespace.svc.cluster.local:8384/metrics" ## Enpoint that exposes application performance 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 ## Endpoint that receives p8s metrics
    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"

Теперь давайте создадим Kubernetes ConfigMap, используя указанный выше файл, и подключим его к поду Vector. Вам также необходимо подключить ранее созданный Secret, чтобы Vector мог использовать TLS-сертификаты при передаче данных на Prometheus Remote Write.

Создайте ConfigMap для Kubernetes:

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

Подготовьте пользовательский файл values, который подключит и ConfigMap, и Secret к поду Vector:

## my-vector-custom-values.yaml
args:
  - --config
  - "/opt/vector/vector.yaml"

extraVolumeMounts:
  - name: secret
    mountPath: /run/secrets/tls/
  - name: custom-configs
    mountPath: /opt/vector
    readOnly: true

extraVolumes:
  - name: secret
    secret:
      secretName: "vector-certs"
  - name: custom-configs
    configMap:
      name: "vector-custom-configs"

Установите Helm Chart Vector.

По умолчанию Vector запускается как StatefulSet в роли Aggregator. В качестве альтернативы он может работать как Deployment в роли Stateless-Aggregator либо как DaemonSet в роли Agent. Эти свойства можно переопределить в файле custom-values.yaml по мере необходимости. Для получения дополнительной информации можно также обратиться к файлу default-values.yaml .

helm upgrade --install my-vector-release vector/vector \
--namespace vector \
-f my-vector-custom-values.yaml

После успешной установки в терминале вы должны увидеть вывод Helm со статусом «STATUS: deployed» и шаблоном запуска Vector.

Если настройка прошла успешно, вы увидите, что поды Vector StatefulSet находятся в состоянии Running без сообщений об ошибках в логах.

Наблюдаемость: ключ к эффективному управлению данными.

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

Vector обладает мощными и адаптируемыми возможностями сбора данных, что делает его незаменимым решением для построения надежных конвейеров мониторинга. Однако, помимо сбора метрик Prometheus, Vector может построить несколько конвейеров для сбора логов и трассировок (traces), которые затем могут быть отправлены в другие системы мониторинга, такие как Loki, Splunk, Datadog или Elastic.

Надеюсь, было полезно. Спасибо за прочтение!

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!