6.6. Настройки безопасности #

6.6.1. Настройка пользователя операционной системы #

Для работы pgpro-otel-collector достаточно прав непривилегированного пользователя. Однако в некоторых случаях для сбора журналов экземпляра СУБД может потребоваться доступ на чтение к каталогу журналов и файлам журналов со стороны операционной системы.

6.6.1.1. Настройка доступа для чтения журналов СУБД #

Для чтения журналов достаточно использовать группу, от имени которой запущен экземпляр СУБД. Для этого группе нужно выдать доступ на чтение файлов журнала и затем в эту же группу поместить пользователя, от имени которого запущен коллектор. Как правило, это группа postgres.

  1. Добавьте права на чтение для группы (путь к каталогу может отличаться):

    sudo chmod g+rx /var/log/postgresql/
    sudo chmod g+r /var/log/postgresql/*
  2. Добавьте пользователя otelcol в группу postgres:

    sudo usermod --groups=postgres otelcol

    Теперь коллектор может читать существующие файлы журналов.

Дополнительно требуется настроить конфигурацию экземпляра СУБД таким образом, чтобы новые файлы журналов создавались с нужными правами доступа. Это достигается путём изменения параметра log_file_mode и перезагрузки конфигурации. Параметр можно изменить напрямую через файл конфигурации, с помощью ALTER SYSTEM или используя средства автоматизации и IaC (Infrastructure as Code, инфраструктура как код).

В примере ниже изменение выполняется через подключение к экземпляру СУБД и использование ALTER SYSTEM.

psql -U postgres -c 'ALTER SYSTEM SET log_file_mode TO "0640"'
psql -U postgres -c 'SELECT pg_reload_conf()'

6.6.2. Настройка пользователя экземпляра СУБД #

Настройка пользователя СУБД включает следующие шаги:

  • Создание и настройка привилегий пользователя СУБД, от имени которого коллектор будет подключаться к экземпляру СУБД.

  • Настройка HBA-правил авторизации, которые будут разрешать коллектору подключаться к экземпляру СУБД.

  • Настройка дополнительных прав на запуск функций; шаг является необязательным и требуется только если вы действительно хотите включить сбор соответствующих данных.

6.6.2.1. Создание и настройка пользователя #

Задайте пароль при создании пользователя:

sudo -u postgres createuser --pwprompt otelcol

Для настройки прав подключитесь к экземпляру СУБД и выполните следующую команду:

GRANT pg_monitor TO otelcol;

6.6.2.2. Настройка правил HBA #

При использовании плагинов, требующих подключения к другим БД (сбор таблиц, индексов, раздувания), правила HBA (Host-Based Authentication, аутентификация на основе хоста) необходимо согласовать с правилами коллектора:

  • Базы данных, перечисленные в настройках плагина, должны быть разрешены в конфигурации HBA.

  • Если коллектор настроен на сбор данных со всех БД, то и правила HBA должны разрешать подключение ко всем БД.

СУБД PostgreSQL поддерживает большое количество методов аутентификации. При настройке правил HBA следует ориентироваться на метод, используемый в вашем случае.

Пример настройки доступа к БД postgres с помощью метода scram-sha-256:

vi pg_hba.conf

local  postgres  otelcol                 scram-sha-256
host   postgres  otelcol  127.0.0.1/32   scram-sha-256

В этом примере возможности подключения ограничены только одной базой postgres. В случае, когда коллектор настроен на сбор данных с других БД, в конфигурацию HBA необходимо внести соответствующие разрешающие правила.

После внесения изменений перезагрузите конфигурацию экземпляра СУБД:

sudo -u postgres psql -c 'SELECT pg_reload_conf()'

6.6.2.3. Настройка дополнительных прав #

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

За информацией о правах доступа, необходимых для бесперебойной работы, обратитесь к Разделу 3.1.

6.6.3. Настройка коллектора #

6.6.3.1. Подключение к экземпляру СУБД #

Параметры подключения к экземпляру СУБД регулируются в конфигурации ресивера postgrespro файла конфигурации коллектора. Учётные данные пользователя должны быть указаны в параметрах endpoint, database, username и password (пароль можно передать через переменную окружения):

receivers:
postgrespro:
  transport: tcp
  endpoint: localhost:5432
  database: postgres
  username: otelcol
  password: ${env:POSTGRESQL_PASSWORD}

6.6.4. Настройка TLS #

Для экспортёров можно настроить TLS (Transport Layer Security, защита транспортного уровня). Каждый экспортёр можно настраивать отдельно, но формат настройки будет одинаковым для всех. За подробной информацией обратитесь к документации OpenTelemetry.

Пример конфигурации экспортёра otlphttp:

exporters:
  otlphttp:
    endpoint: "https://ppem.example.org"
    tls:
      insecure: false
      ca_file: server.crt
      cert_file: client.crt
      key_file: client.key
      min_version: "1.1"
      max_version: "1.2"

6.6.5. Настройка списков разрешений и запретов #

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

Глобальные списки разрешений и запретов можно настроить для плагинов на уровне ресивера. Ниже приведён общий пример такой конфигурации:

receivers:
  postgrespro:
    acl:
      databases:
        allow:
          - name: postgres
            schemas:
              - name: public
                tables:
                  - name: table
                  - name: table_index
                    indexes:
                    - name: index1
                    - name: index2
                functions:
                  - name: function1
        deny:
          - name: db
            schemas:
              - name: schema
                tables:
                  - name: table

Здесь:

  • Раздел acl.allow определяет, из каких баз данных (и вложенных объектов) плагины будут собирать данные по умолчанию.

  • Раздел acl.deny определяет, из каких баз данных и объектов pgpro-otel-collector запрещается сбор метрик.

Рассмотрим конкретный пример, как сделать так, чтобы данные не собирались из базы zabbix:

receivers:
  postgrespro:
    max_threads: 3
    collection_interval: 60s
    initial_delay: 1s
    transport: tcp
    endpoint: localhost:5432
    database: postgres
    username: postgres
    password: ${env:POSTGRESQL_PASSWORD}
    metrics: null
    acl:
      databases:
        allow:
          - name: postgres
        deny:
          - name: zabbix
    plugins:
      activity:
        enabled: true
      bgwriter:
        enabled: true
      locks:
        enabled: true
      version:
        enabled: true
      wal:
        enabled: true
      cache:
        enabled: true

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

У отдельных плагинов может быть свой раздел настройки databases:

      tables:
        enabled: true
        databases:
          - name: demo

В этом случае игнорируется раздел acl.allow, но ограничения из раздела acl.deny действуют.

6.6.5.1. Использование регулярных выражений в ACL #

pgpro-otel-collector поддерживает регулярные выражения в конфигурации ACL (Access Control List, список контроля доступа) как для списков разрешений, так и запретов. Регулярные выражения избавляют от необходимости вручную обновлять конфигурации ACL при создании новых объектов базы данных. Вместо перечисления отдельных объектов можно задать шаблоны, которые автоматически добавляют или исключают объекты на основе их имён. Пример такого регулярного выражения приведён ниже.

receivers:
  postgrespro:
    transport: tcp
    endpoint: &endpoint localhost:5432
    database: postgres
    username: postgres
    password: ${env:POSTGRESQL_PASSWORD}
    collection_interval: 60s
    initial_delay: 1s
    max_threads: 3
    plugins:
      databases:
        allow:
          - name: db1.*
            schemas:
              - name: sch1.*
                tables:
                  - name: tb1.*
                  - name: tb2.*
                    indexes:
                    - name: idx2.*
      activity:
        enabled: true
      tables:
        enabled: true
      indexes:
        enabled: true
        # Списки разрешений можно настраивать для отдельного плагина
        # databases:
        #   - name: db1.*
        #     schemas:
        #       - name: sch1.*
        #         tables:
        #           - name: tb1.*
        #           - name: tb2.*
        #             indexes:
        #             - name: idx2.*
      functions:
        enabled: true
      bloat_tables:
        enabled: true
      bloat_indexes:
        enabled: true

6.6.6. Базовый аутентификатор #

Расширение basicauth — компонент OpenTelemetry Collector с открытым исходным кодом, который реализует базовую HTTP-аутентификацию.

Ниже приведён пример процедуры включения базовой аутентификации для экспортёра prometheus.

  1. Создайте файл конфигурации (например, auth_basic.yml) со следующим содержимым:

    extensions:
      basicauth/prometheus:
        htpasswd:
          # Путь к файлу htpasswd
          # file: .htpasswd
          #
          # Встроенное содержимое файла htpasswd
          inline: |
           ${env:BASIC_AUTH_USERNAME}:${env:BASIC_AUTH_PASSWORD}
    exporters:
      prometheus:
        endpoint: :8889
        send_timestamps: true
        auth:
          authenticator: basicauth/prometheus
    service:
      extensions: [ basicauth/prometheus ]

    Необходимо указать либо htpasswd.file, либо htpasswd.inline. Если заданы оба, приоритет отдаётся учётным данным из htpasswd.inline.

  2. Запустите коллектор, указав основной файл конфигурации и файл аутентификации:

    BASIC_AUTH_USERNAME=username BASIC_AUTH_PASSWORD=password build/pgpro-otel-collector/pgpro-otel-collector --config configs/basic.yml --config configs/auth_basic.yml
  3. Проверьте, отклоняется ли запрос без аутентификации:

    $ curl 127.0.0.1:8889/metrics
    # Должна вернуться ошибка «no basic auth provided» (базовая аутентификация не предоставлена)
  4. Убедитесь, что при верных учётных данных запрос возвращает метрики:

    $ curl -u username:password 127.0.0.1:8889/metrics
    # Должны возвращаться метрики в формате Prometheus