Пошаговое руководство по настройке безопасности конвейеров наблюдаемости с помощью Vector от Datadog
Перевод оригинальной статьи A Step-by-Step Guide to Securing Observability Pipelines Using Vector by Datadog.
Перевод сделан специально для телеграм-канала Мониторим ИТ. Подписывайтесь! Там еще больше полезных постов о мониторинге.
В сложном мире современных распределенных программных систем наблюдаемость является ключевым компонентом, позволяющим обеспечить высокую производительность и надёжность.
Независимо от того, являетесь ли вы начинающим специалистом или опытным инженером, который ищет рекомендации по построению конвейеров наблюдаемости, эта статья будет полезна для любого уровня подготовки.
Почему Vector?
Начнём с нашего сценария использования. В DV мы часто упаковываем и поставляем приложения нашим партнёрам, которые затем устанавливают их в своей инфраструктуре. Чтобы обеспечить надёжность, нам необходимо собирать данные о производительности этих приложений.
Поскольку инфраструктура наших партнеров часто остается для нас "черным ящиком", мы пришли к выводу, что нам необходим инструмент, отвечающий следующим требованиям:
- Мы могли бы включить его в наше приложение для сбора необходимых данных о производительности.
- Процесс сбора данных оказывает минимальное воздействие на систему как с точки зрения использования памяти, так и загрузки процессора.
- Возможность безопасно передавать собранные данные в наши централизованные системы мониторинга.
Несмотря на наличие множества решений для корпоративного мониторинга и инструментов с открытым исходным кодом, Vector от Datadog выделился среди прочих благодаря своей лёгкости и высокой производительности.
Vector — инструмент с открытым исходным кодом для построения конвейеров наблюдаемости. Он настраивается для сбора, преобразования и маршрутизации логов, метрик и трассировок в любую поддерживаемую систему назначения из списка поддерживаемых Datadog получателей.
В этой статье я покажу, как собирать метрики Prometheus из приложения, работающего в кластере Kubernetes, и передавать их в экземпляр Prometheus, размещённый на виртуальной машине в другом географическом регионе, используя Prometheus Remote Write.
Предварительные требования
Для понимания этой статьи вам потребуется:
- Практические навыки работы с Kubernetes и использования Kubectl.
- Практические навыки установки и настройки Helm-чартов.
- Запущенный кластер Kubernetes как минимум с одним узлом (в примере используется кластер GKE).
- Запущенный экземпляр Prometheus с включённой поддержкой Remote Write (в примере Prometheus установлен на виртуальной машине в GCP).
- Все необходимые сетевые коммуникации между Vector и Prometheus.
- Сертификаты 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 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"По умолчанию 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.
Надеюсь, было полезно. Спасибо за прочтение!
Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!