Как подключить распределенные клиенты к частной базе данных InfluxDB

InfluxDB стал популярным способом хранения данных временных рядов для датчиков и служб, а InfluxData делает это быстро и легко благодаря InfluxCloud. Однако некоторые клиенты, с которыми мы разговаривали, хранят не все данные в управляемом облачном сервисе. Иногда у них есть определенные деловые, нормативные или нормативные причины для хранения данных в собственном центре обработки данных. В других случаях они используют несколько выходов в Telegraf для отправки данных в оба InfluxDB Cloud в рамках своего плана аварийного восстановления.

Какой бы ни была причина, безопасное подключение одного клиента к частной базе данных InfluxDB может потребовать настройки сетевых маршрутов, открытия брандмауэров, настройки NACL и групп безопасности. Не говоря уже о навигации по любым внутренним процессам, которые могут быть задействованы для утверждения и развертывания всех этих изменений. Ценность InfluxDB заключается не в том, что один клиент время от времени записывает данные, а в том, что он может поддерживать сотни и более. Так что повторяйте эти накладные расходы на сетевое администрирование для каждого нового устройства или всякий раз, когда изменяется конфигурация сети устройства, и вы очень быстро столкнетесь с ситуацией, когда поддержание жесткого сетевого контроля становится неустойчивым. Затем большинство людей выбирают между несколькими вариантами: 1) Требовать установки VPN между удаленным клиентом и сетевой базой данных InfluxDB. более высокая нагрузка по установке для тех, кто управляет клиентами. И действительно ли они хотят, чтобы их сеть была подключена к вашей через VPN? Или 2) Предоставьте базу данных InfluxDB непосредственно общедоступному Интернету и доверьтесь системе аутентификации, чтобы защитить ее.

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

Начальная настройка

Если вы хотите сразу перейти к рабочему примеру, на GitHub есть Демонстрация InfluxDB + Telegraf + Ockam для Docker, которую можно запускать локально с помощью Docker Compose. Он использует официальные образы Docker для InfluxDB и Telegraf с изменениями в сценариях запуска, поэтому каждый сервис использует Ockam для установления соединения. Полные инструкции по его запуску включены в README.

Чтобы смоделировать сквозной пример отправки клиентом данных в InfluxDB, мы запустим экземпляр Telegraf, заставим его передавать события ЦП в InfluxDB, а затем изменим способ подключения этих двух компонентов, чтобы показать, как мы их будем соединять. между разными хостами или сетями. Однако для этого примера мы будем запускать все на одной машине.

Окам

Если вы ранее устанавливали Оккам, вы можете пропустить этот раздел и сразу перейти к настройке InfluxDB ниже.

brew install build-trust/ockam/ockam

(если вы не используете brew для управления пакетами, у нас есть инструкции по установке для других систем< /a> в нашей документации)

После установки вам необходимо зарегистрировать свою локальную идентификацию с помощью Ockam Orchestrator, выполните приведенную ниже команду и следуйте предоставленным инструкциям:

ockam enroll

InfluxDB

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

Предпосылки для этого раздела: сначала установить:

• InfluxDB
• интерфейс командной строки Influx

После установки нам нужно запустить InfluxDB, чтобы у нас было место для хранения данных метрик, которые мы собираемся сгенерировать. В большинстве систем это будет так же просто, как запустить:

influxd

Затем вы должны увидеть некоторые выходные данные журнала, а последняя строка подтверждает, что influxd теперь прослушивает порт 8086:

2023-02-21T23:49:43.106268Z info    Listening   {"log_id": "0fv9CURl000", "service": "tcp-listener", "transport": "http", "addr": ":8086", "port": 8086}

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

Теперь мы собираемся использовать команду CLI influx для завершения начальной настройки базы данных, чтобы influxd мог получать наши данные. Запустите команду установки и выполните необходимые запросы, запомните названия организации и корзины, которые вы используете, так как они понадобятся нам позже:

influx setup

Затем вам нужно будет скопировать токен только что созданного пользователя, который вы можете получить с помощью команды auth:

influx auth list

Телеграф

Установите Telegraf, и после его настройки нам понадобится файл конфигурации, определяющий нашу источник ввода и наш пункт назначения вывода. К счастью, Telegraf включает команду для создания такого файла, который мы можем указать для предварительной настройки с использованием ЦП нашей хост-машины в качестве источника ввода и с InfluxDB в качестве нашего вывода.

Чтобы сгенерировать базовую конфигурацию, выполните:

telegraf config 
  --section-filter agent:inputs:outputs 
  --input-filter cpu 
  --output-filter influxdb_v2 > telegraf.conf

Откройте сгенерированный файл telegraf.conf и найдите раздел [[outputs.influxdb_v2]], который должен выглядеть следующим образом:

[[outputs.influxdb_v2]]
  ## The URLs of the InfluxDB cluster nodes.
  ##
  ## Multiple URLs can be specified for a single cluster, only ONE of the
  ## urls will be written to each interval.
  ##   ex: urls = ["https://us-west-2-1.aws.cloud2.influxdata.com"]
  urls = ["http://127.0.0.1:8086"]

  ## Token for authentication.
  token = ""

  ## Organization is the name of the organization you wish to write to.
  organization = ""

  ## Destination bucket to write into.
  bucket = ""

Замените пустые значения для токена, организации и корзины значениями из предыдущего раздела о настройке InfluxDB и сохраните изменения. Теперь вы можете запустить Telegraf:

telegraf --config telegraf.conf 

Проверьте, все ли работает

Чтобы упростить повторное использование ваших значений для будущих команд и тестирования, сохраните соответствующие значения (т. е. замените заполнители ниже вашими фактическими значениями) в наборе переменных среды:

export INFLUX_PORT=8086 
  INFLUX_TOKEN=your-token-here 
  INFLUX_ORG=your-org 
  INFLUX_BUCKET=your-bucket

Теперь мы можем проверить, регулярно ли Telegraf отправляет данные в InfluxDB. Конфигурация, которую мы создали ранее, будет выдавать статистику ЦП каждые 10 секунд, поэтому мы можем отправить запрос в InfluxDB и получить все данные за последнюю минуту:

curl 
    --header "Authorization: Token $INFLUX_TOKEN" 
    --header "Accept: application/csv" 
    --header 'Content-type: application/vnd.flux' 
    --data "from(bucket:"$INFLUX_BUCKET") |> range(start:-1m)" 
    http://localhost:$INFLUX_PORT/api/v2/query?org=$INFLUX_ORG

Надежно подключите Telegraf + частную базу данных InfluxDB с Ockam< /а>

Приведенный выше пример соединяет эти две службы, работающие на одном хосте, с использованием незашифрованного транспорта HTTP по умолчанию. В большинстве нетривиальных конфигураций InfluxDB будет работать на отдельном хосте с одним или несколькими узлами Telegraf, отправляющими данные. В производственной среде маловероятно, что незашифрованный транспорт является приемлемым, также не всегда желательно потенциально открывать порт InfluxDB для общедоступного Интернета.

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

Создание и регистрация ваших узлов

Первый шаг — зарегистрироваться в Ockam, сохранить информацию о проекте и создать токены регистрации для узлов InfluxDB и Telegraf:

ockam enroll
ockam project information --output json > project.json
export OCKAM_INFLUXDB_TOKEN=$( 
  ockam project enroll --attribute component=influxdb)
export OCKAM_TELEGRAF_TOKEN=$( 
  ockam project enroll --attribute component=telegraf)

Теперь мы можем создать узел для нашего сервиса InfluxDB:

ockam identity create influxdb

ockam project authenticate --identity influxdb 
  --token $OCKAM_INFLUXDB_TOKEN --project-path project.json

ockam node create influxdb 
  --project project.json 
  --identity influxdb

ockam policy set 
  --at influxdb 
  --resource tcp-outlet 
  --expression '(= subject.component "telegraf")'

ockam tcp-outlet create 
  --at /node/influxdb 
  --from /service/outlet 
  --to 127.0.0.1:8086

ockam forwarder create influxdb 
  --at /project/default 
  --to /node/influxdb

В этих командах произошло несколько вещей, так что давайте быстро их распакуем:

* Мы создали новый узел с именем influxdb и зарегистрировали его в Ockam, используя созданный ранее токен. Если вы посмотрите на команду, сгенерировавшую токен, вы увидите, что мы также пометили этот токен атрибутом component=influxdb. * Затем мы добавили политику к узлу influxdb, которая гласит, что только узлы, имеющие атрибут component со значением telegraf, смогут для подключения к выходу TCP. * Далее мы создаем выход TCP. Это похоже на канал от узла influxdb, который мы только что создали, к TCP-порту 127.0.0.1:8086 (т. е. к порту, который прослушивает наша база данных InfluxDB) . Этот узел Оккама теперь будет передавать любые данные, которые он получает от других узлов, в этот пункт назначения. Однако единственные узлы, которые смогут установить это соединение, — это те, которые проходят политику, определенную на предыдущем шаге. * Наконец, мы создаем сервер пересылки в нашем проекте, который теперь позволяет другим узлам в нашем проекте обнаруживать influxdb и направлять на него трафик.

Пришло время установить другую сторону этого соединения, создав соответствующий клиентский узел для Telegraf:

ockam identity create telegraf
ockam project authenticate --identity telegraf 
  --token $OCKAM_TELEGRAF_TOKEN --project-path project.json
ockam node create telegraf 
  --project project.json 
  --identity telegraf
ockam policy set 
  --at telegraf 
  --resource tcp-inlet 
  --expression '(= subject.component "influxdb")'
ockam tcp-inlet create 
  --at /node/telegraf 
  --from 127.0.0.1:8087 
  --to /project/default/service/forward_to_influxdb/secure/api/service/outlet

Теперь мы можем распаковать эти три команды и то, что они сделали:

• Как и прежде, мы использовали сгенерированный токен регистрации, чтобы создать новый узел и зарегистрировать его в нашем проекте. На этот раз это узел telegraf.
• Мы снова применили политику для повышения уровня безопасности. Эта политика разрешает создание входа TCP, но только если узел на другом конце имеет атрибут component со значением influxdb.
• Наконец мы создаем вход TCP. Это способ определить, где узел должен прослушивать соединения (в данном случае на TCP-порте 8087) и куда он должен перенаправлять этот трафик. Этот узел будет пересылать данные созданному ранее модулю пересылки, который, в свою очередь, передает их нашему узлу influxdb, который затем отправляет их в базу данных InfluxDB.

Вот и все! Прослушиватель на локальном порту 8087 теперь перенаправляет весь трафик в InfluxDB, где бы он ни работал. Если бы эта база данных находилась на другом хосте, работала в облаке или в частном центре обработки данных, регистрация и переадресация по-прежнему обеспечивали бы безопасное соединение с 127.0.0.1:8087, где бы ни находилась эта база данных. работает.

Обновите существующую конфигурацию, чтобы использовать безопасное соединение.

В этом примере вход TCP был создан на порту 8087 прежде всего потому, что служба influxd работала на том же хосте и уже была привязана к порту 8086. В производственном развертывании, где Telegraf и InfluxDB находятся на разных хостах, вход TCP может прослушивать порт 8086, и эту конфигурацию по умолчанию не нужно менять.

Хотя это упрощенный пример, работающий на одном хосте, следующие инструкции одинаковы независимо от вашего развертывания. После того, как узлы influxdb и telegraf зарегистрированы и запущены, единственное изменение, которое вам нужно сделать, — это обновить ваш файл telegraf.conf, чтобы он указывал на локальный порт прослушивания:

[[outputs.influxdb_v2]]
  urls = ["http://127.0.0.1:8087"]

Перезапустите службу Telegraf, и мы сможем проверить, сохраняются ли данные, используя ту же команду, которую мы использовали ранее.z

Безопасно подключенные клиенты и многое другое...

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

* Частные базы данных остаются частными: ваш порт InfluxDB не был открыт для общедоступного Интернета, поэтому у третьих лиц нет доступа к вашим данным

* Шифрование при передаче. Безопасный канал, установленный между вашими узлами, полностью зашифрован. Каждый узел генерирует свои собственные криптографические ключи и получает свои собственные уникальные учетные данные. Затем они используют их для установления взаимно доверенного безопасного канала между собой. Удалив зависимость от сторонних служб для хранения или распространения ключей, вы сможете уменьшить площадь уязвимости и устранить единые точки отказа.

* Идентификация & Контроль доступа на основе атрибутов: авторизация даже для установления маршрута к базе данных InfluxDB привязана к уникальному идентификатору клиента, запрашивающего доступ, что является более гибким с точки зрения поддержки современных и часто динамических подходов к развертыванию, а также более понятным. соответствует нашим намерениям в отношении контроля доступа. Если их клиент может установить доверие, что они те, за кого себя выдают, то они могут направлять свои пакеты в базу данных. Сравните это с историческими подходами, при которых решения о постоянном доступе основаны на предположениях об удаленной сети (например, исходит ли этот запрос с предварительно авторизованного нами IP-адреса?). Это в дополнение к элементам управления аутентификацией и авторизацией в самой базе данных InfluxDB, которые будут продолжать работать, как всегда.

* Безопасность по дизайну: сочетание всего вышеперечисленного означает, что единственный способ доступа к базе данных InfluxDB — через безопасный канал, что означает, что все коммуникации зашифрованы. в пути независимо от какой-либо неправильной конфигурации на любом конце (например, HTTP/TLS не включен). А поскольку каждый узел обменивается учетными данными друг с другом, а не использует общий сертификат или общий ключ шифрования, вы также можете быть уверены, что:

1. Никакие другие стороны в цепочке поставок не могут изменять передаваемые данные. Данные, которые вы получаете от потребителя, — это именно то, что было отправлено вашими клиентами.

2. Только авторизованные клиенты могут писать в InfluxDB, что гарантирует высокую надежность данных в вашей теме. Если у вас есть еще более строгие требования, вы можете взять под контроль свой центр учетных данных и применить подробные политики авторизации.

   * Уменьшение подверженной уязвимости области: Ockam упрощает проблемы с клиентским доступом, предоставляя все удаленные службы как локальные службы. Мы называем это виртуальной смежностью. Когда все удаленные компоненты приложения становятся практически смежными с каждым другим компонентом, тогда сложность безопасности и доверия всей сети, всей инфраструктуры, всего Интернета полностью абстрагируется. Все сторонние посредники удалены из поверхности уязвимости приложения.

Дальнейшие шаги

• Если вы еще не следовали примеру из этого руководства, вы можете приступить к работе с Ockam бесплатно, следуя инструкциям в нашей документации.
• Если вы хотите обсудить конкретно этот или другие потенциальные варианты использования Оккама, команда будет рада пообщаться с вами.
• В качестве альтернативы вы можете присоединиться к нам и к постоянно растущему сообществу разработчиков, которые хотят завоевать доверие, создавая безопасные приложения, в На сервере Discord сообщества Build Trust или на Github .

:::информация Также опубликовано здесь.

:::