Найкращі практики конфігурації Collector

Під час налаштування OpenTelemetry (OTel) Collector враховуйте ці найкращі практики для захисту вашого екземпляра Collector.

Створення безпечних конфігурацій

Дотримуйтесь цих рекомендацій, щоб захистити конфігурацію вашого Collector та його конвеєри.

Зберігайте конфігурацію захищено

Конфігурація Collector може містити конфіденційну інформацію, включаючи:

• Інформацію для автентифікації, таку як API токени.
• TLS сертифікати, включаючи приватні ключі.

Ви повинні зберігати конфіденційну інформацію захищено, наприклад, на зашифрованій файловій системі або в сховищі секретів. Ви можете використовувати змінні середовища для обробки конфіденційних та неконфіденційних даних, оскільки Collector підтримує розширення змінних середовища.

Використовуйте шифрування та автентифікацію

Конфігурація вашого OTel Collector повинна включати шифрування та автентифікацію.

• Для шифрування звʼязку дивіться Налаштування сертифікатів.
• Для автентифікації використовуйте механізм автентифікації OTel Collector, як описано в розділі Автентифікація.

Мінімізуйте кількість компонентів

Ми рекомендуємо обмежити набір компонентів у конфігурації вашого Collector до лише тих, які вам потрібні. Мінімізація кількості використовуваних компонентів мінімізує експоновану поверхню атаки.

• Використовуйте OpenTelemetry Collector Builder (ocb) для створення дистрибутиву Collector, який використовує лише необхідні компоненти.
• Видаліть невикористовувані компоненти з вашої конфігурації.

Налаштовуйте з обережністю

Деякі компоненти можуть збільшити ризик небезпеки у ваших конвеєрів Collector.

• Приймачі, експортери та інші компоненти повинні встановлювати мережеві зʼєднання через захищений канал, можливо, також автентифікований.
• Приймачі та експортери можуть експонувати налаштування буфера, черги, навантаження та робітників за допомогою параметрів конфігурації. Якщо ці налаштування доступні, ви повинні діяти з обережністю перед зміною стандартних значень конфігурації. Неправильне налаштування цих значень може експонувати OpenTelemetry Collector до додаткових векторів атаки.

Встановлюйте дозволи обережно

Уникайте запуску Collector від імені користувача root. Деякі компоненти можуть вимагати спеціальних дозволів. У таких випадках дотримуйтесь принципу найменших привілеїв і переконайтеся, що ваші компоненти мають лише той доступ, який їм потрібен для виконання своєї роботи.

Спостерігачі

Спостерігачі реалізовані як розширення. Розширення — це тип компонентів, які додають можливості поверх основних функцій Collector. Розширення не потребують прямого доступу до телеметрії та не є частиною конвеєрів, але вони все ще можуть становити ризики безпеки, якщо вони вимагають спеціальних дозволів.

Спостерігач виявляє мережеві точки доступу, такі як podʼи Kubernetes, контейнери Docker або локальні порти, що слухають, від імені receiver creator. Для виявлення сервісів спостерігачі можуть вимагати більшого доступу. Наприклад, k8s_observer вимагає дозволів на основі ролей (RBAC) у Kubernetes.

Управління конкретними ризиками безпеки

Налаштуйте ваш Collector для блокування цих загроз безпеки.

Захист від атак відмови в обслуговуванні

Для приймачів та розширень, що працюють як сервери, ви можете захистити ваш Collector від експонування в інтернет або до ширших мереж, ніж необхідно, привʼязуючи точки доступу цих компонентів до адрес, які обмежують зʼєднання до авторизованих користувачів. Намагайтеся завжди використовувати конкретні інтерфейси, такі як IP podʼа, або localhost замість 0.0.0.0. Для отримання додаткової інформації дивіться CWE-1327: Привʼязка до необмеженої IP-адреси.

З Collector v0.110.0, стандартно хостом для всіх серверів у компонентах Collector є localhost. Для попередніх версій Collector змініть стандартну точку доступу з 0.0.0.0 на localhost у всіх компонентах, увімкнувши функціональну можливість component.UseLocalHostAsDefaultHost .

Якщо localhost розвʼязується до іншої IP через ваші налаштування DNS, тоді явно використовуйте IP зворотнього виклику: 127.0.0.1 для IPv4 або ::1 для IPv6. Наприклад, ось конфігурація IPv4 з використанням порту gRPC:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 127.0.0.1:4317

У налаштуваннях IPv6 переконайтеся, що ваша система підтримує як IPv4, так і IPv6 адреси зворотнього виклику, щоб мережа працювала належним чином у середовищах з подвійним стеком та застосунках, де використовуються обидві версії протоколу.

Якщо ви працюєте в середовищах з нестандартними мережевими налаштуваннями, таких як Docker або Kubernetes, localhost може не працювати як очікується. Наступні приклади показують налаштування для точки доступу приймача OTLP gRPC. Інші компоненти Collector можуть потребувати подібної конфігурації.

Docker

Ви можете запустити Collector у Docker, привʼязуючись до правильної адреси. Ось файл конфігурації config.yaml для експортера OTLP у Docker:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: my-hostname:4317 # Використовуйте те саме імʼя хоста з вашої команди docker run

У вашій команді docker run використовуйте аргумент --hostname, щоб привʼязати Collector до адреси my-hostname. Ви можете отримати доступ до Collector з зовні цієї мережі Docker (наприклад, у звичайній програмі, що працює на хості), підключившись до 127.0.0.1:4567. Ось приклад команди docker run:

docker run --hostname my-hostname --name container-name -p 127.0.0.1:4567:4317 otel/opentelemetry-collector:0.146.1

Docker Compose

Подібно до звичайного Docker, ви можете запустити Collector у Docker, привʼязуючи до правильної адреси.

Файл Docker compose.yaml:

services:
  otel-collector:
    image: otel/opentelemetry-collector-contrib:0.146.1
    ports:
      - '4567:4317'

Файл конфігурації Collector config.yaml:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: otel-collector:4317 # Використовуйте імʼя сервісу з вашого файлу Docker compose

Ви можете підключитися до цього Collector з іншого контейнера Docker, що працює в тій самій мережі, підключившись до otel-collector:4317. Ви можете отримати доступ до Collector з зовні цієї мережі Docker (наприклад, у звичайній програмі, що працює на хості), підключившись до 127.0.0.1:4567.

Kubernetes

Якщо ви запускаєте Collector як DaemonSet, ви можете використовувати конфігурацію, як показано нижче:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: collector
spec:
  selector:
    matchLabels:
      name: collector
  template:
    metadata:
      labels:
        name: collector
    spec:
      containers:
        - name: collector
          image: otel/opentelemetry-collector:0.146.1
          ports:
            - containerPort: 4317
              hostPort: 4317
              protocol: TCP
              name: otlp-grpc
            - containerPort: 4318
              hostPort: 4318
              protocol: TCP
              name: otlp-http
          env:
            - name: MY_POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP

У цьому прикладі ви використовуєте API Kubernetes Downward для отримання IP вашого podʼа, а потім привʼязуєтеся до цього мережевого інтерфейсу. Потім ми використовуємо опцію hostPort, щоб переконатися, що Collector експонується на хості. Конфігурація Collector повинна виглядати так:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: ${env:MY_POD_IP}:4317
      http:
        endpoint: ${env:MY_POD_IP}:4318

Ви можете надсилати дані OTLP до цього Collector з будь-якого podʼа на вузлі, підключившись до ${MY_HOST_IP}:4317 для надсилання OTLP через gRPC та ${MY_HOST_IP}:4318 для надсилання OTLP через HTTP, де MY_HOST_IP - це IP-адреса вузла. Ви можете отримати цю IP-адресу з API Downward:

env:
  - name: MY_HOST_IP
    valueFrom:
      fieldRef:
        fieldPath: status.hostIP

Видалення конфіденційних даних

Процесори — це компоненти Collector, які знаходяться між приймачами та експортерами. Вони відповідають за обробку телеметрії перед її аналізом. Ви можете використовувати redaction процесор OpenTelemetry Collector для обфускації або видалення конфіденційних даних перед експортом їх до бекенду.

redaction процесор видаляє атрибути точок даних відрізків, логів та метрик, які не відповідають списку дозволених атрибутів. Він також маскує значення атрибутів, які відповідають списку заблокованих значень. Атрибути, які не входять до списку дозволених, видаляються перед будь-якими перевірками значень.

Наприклад, ось конфігурація, яка маскує значення, що містять номери кредитних карток:

processors:
  redaction:
    allow_all_keys: false
    allowed_keys:
      - description
      - group
      - id
      - name
    ignored_keys:
      - safe_attribute
    blocked_values: # Регулярні вирази для блокування значень дозволених атрибутів відрізків
      - '4[0-9]{12}(?:[0-9]{3})?' # Номер кредитної картки Visa
      - '(5[1-5][0-9]{14})' # Номер MasterCard
    summary: debug

Дивіться документацію щоб дізнатися, як додати redaction процесор до конфігурації вашого Collector.

Захист використання ресурсів

Після впровадження заходів захисту використання ресурсів у вашій інфраструктурі хостингу, розгляньте також додавання цих заходів до конфігурації вашого OpenTelemetry Collector.

Пакетування вашої телеметрії та обмеження памʼяті, доступної для вашого Collector, може запобігти помилкам через нестачу памʼяті та пікам використання. Ви також можете обробляти піки трафіку, налаштовуючи розміри черг для управління використанням памʼяті, уникаючи втрати даних. Наприклад, використовуйте exporterhelper для управління розміром черги для вашого експортера otlp:

exporters:
  otlp:
    endpoint: <ENDPOINT>
    sending_queue:
      queue_size: 800

Фільтрація небажаної телеметрії — це ще один спосіб захисту ресурсів вашого Collector. Фільтрація не тільки захищає ваш екземпляр Collector, але й зменшує навантаження на ваш бекенд. Ви можете використовувати filter процесор для видалення логів, метрик та відрізків, які вам не потрібні. Наприклад, ось конфігурація, яка видаляє не-HTTP відрізки:

processors:
  filter:
    error_mode: ignore
    traces:
      span:
        - attributes["http.request.method"] == nil

Ви також можете налаштувати ваші компоненти з відповідними обмеженнями часу очікування та повторних спроб. Ці обмеження повинні дозволити вашому Collector обробляти збої без накопичення надто великої кількості даних у памʼяті. Дивіться документацію exporterhelper для отримання додаткової інформації.

Нарешті, розгляньте можливість використання стиснення з вашими експортерами для зменшення розміру відправлених даних та збереження мережевих та процесорних ресурсів.Стандартно, otlp експортер використовує стиснення gzip.