Cómo conectar clientes distribuidos a una base de datos privada de InfluxDB

InfluxDB se ha convertido en una forma popular para que los sensores y servicios almacenen datos de series temporales, e InfluxData lo hace rápido y fácil gracias a InfluxCloud. Sin embargo, algunos de los clientes con los que hemos hablado no almacenan todo en un servicio de nube administrado. A veces, tienen motivos comerciales, reglamentarios o de cumplimiento específicos para almacenar los datos ellos mismos en su propio centro de datos. Otras veces, utilizan múltiples salidas en Telegraf para enviar datos a InfluxDB Cloud como parte de su plan de recuperación ante desastres.

Cualquiera que sea el motivo, tener un solo cliente conectado a una base de datos InfluxDB privada de forma segura implica potencialmente configurar rutas de red, abrir cortafuegos, ajustar NACL y grupos de seguridad. Sin mencionar navegar por los procesos internos que puedan estar involucrados para aprobar e implementar todos esos cambios. El valor de InfluxDB no se trata de tener solo un cliente escribiendo datos ocasionalmente, se trata de poder admitir cientos o más. Por lo tanto, repita esa sobrecarga de administración de red para cada nuevo dispositivo, o cada vez que cambie la configuración de red de un dispositivo, y pronto tendrá una situación en la que mantener esos estrictos controles de red se vuelve insostenible. La mayoría de las personas sopesarían entre un par de opciones: 1) Requerir que se establezca una VPN entre el cliente remoto y la red en la que se encuentra la base de datos de InfluxDB. (Potencialmente) Menos administración en curso para los administradores de red donde se ejecuta InfluxDB, pero un mayor carga de configuración para quien administre los clientes. ¿Y realmente quieren que su red esté conectada a la tuya a través de una VPN? O 2) Exponga la base de datos InfluxDB directamente a la Internet pública y confíe en que el sistema de autenticación será suficiente para protegerla.

Hoy los llevaré a través de una tercera opción. Solo le tomará unos minutos implementarlo, no requerirá cambios en la red y evitará que tenga que poner su base de datos privada en la Internet pública. También obtendremos una gran cantidad de otros beneficios en el camino que cubriré una vez que lo tengamos funcionando.

Configuración inicial

Si desea saltar directamente a un ejemplo práctico de esto, tenemos disponible en GitHub un Demostración de InfluxDB + Telegraf + Ockam para Docker que puede ejecutar localmente con Docker Compose. Utiliza las imágenes oficiales de Docker para InfluxDB y Telegraf, con cambios en los scripts de inicio para que cada servicio utilice Ockam para establecer una conexión. Las instrucciones completas sobre cómo ejecutarlo se incluyen en el README .

Para simular un ejemplo de extremo a extremo de un cliente que envía datos a InfluxDB, iniciaremos una instancia de Telegraf, haremos que emita eventos de CPU a InfluxDB y luego cambiaremos la forma en que esos dos se conectan para mostrar cómo los conectaríamos. a través de diferentes hosts o redes. Sin embargo, por el bien de este ejemplo, ejecutaremos todo en una sola máquina.

Ockam

Si ya configuró Ockam, puede omitir esta sección y continuar directamente con la configuración de InfluxDB a continuación.

 brew install build-trust/ockam/ockam

(si no está utilizando brew para la gestión de paquetes, tenemos instrucciones de instalación para otros sistemas en nuestra documentación)

Una vez instalado, debe registrar su identidad local con Ockam Orchestrator, ejecute el siguiente comando y siga las instrucciones proporcionadas:

 ockam enroll

Influjo DB

Si ya tiene InfluxDB ejecutándose en su máquina local y tiene un token de autenticación que puede usar para escribir en él, puede omitir esta sección y continuar directamente con la instalación de Telegraf a continuación.

Los requisitos previos para esta sección son instalar primero:

• Influjo DB
• CLI de entrada

Una vez instalado, debemos iniciar InfluxDB para tener un lugar donde almacenar los datos de métricas que vamos a generar. En la mayoría de los sistemas, será tan simple como ejecutar:

 influxd

Luego debería ver algunos resultados de registro, con la línea final confirmando que influxd ahora está escuchando en el puerto 8086 :

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

Si influxd se inició correctamente, puede abrir una nueva sesión de terminal y dejar que se ejecute en segundo plano. Si influxd no se inició con éxito, verifique el documentación oficial para algunos problemas comunes para diferentes sistemas operativos.

Ahora vamos a usar el comando influx CLI para completar la configuración inicial de la base de datos para que influxd pueda recibir nuestros datos. Ejecute el comando de configuración y complete las indicaciones requeridas, recuerde la organización y los nombres de depósito que usa, ya que los necesitaremos más adelante:

 influx setup

A continuación, deberá copiar el token para el usuario que acaba de crear, que puede recuperar con el comando auth:

 influx auth list

telégrafo

Instalar Telegraf , y una vez que esté configurado, necesitaremos un archivo de configuración que defina nuestra fuente de entrada y nuestro destino de salida. Afortunadamente, Telegraf incluye un comando para generar dicho archivo, que podemos especificar para que esté preconfigurado con la utilización de la CPU de nuestra máquina host como fuente de entrada y con InfluxDB como nuestra salida.

Para generar la configuración base ejecute:

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

Abra el archivo telegraf.conf generado y busque la sección [[outputs.influxdb_v2]] que debería verse así:

 [[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 = ""

Reemplace los valores vacíos de token, organización y depósito con los valores de la sección anterior sobre configurando InfluxDB y guardar los cambios. Ahora puede iniciar Telegraf:

 telegraf --config telegraf.conf

Comprueba que todo funciona

Para facilitar la reutilización de sus valores para futuros comandos y pruebas, almacene los valores apropiados (es decir, reemplace los marcadores de posición a continuación con sus valores reales) en una serie de variables de entorno:

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

Ahora podemos comprobar que Telegraf envía datos regularmente a InfluxDB. La configuración que creamos anteriormente emitirá estadísticas de CPU cada 10 segundos, por lo que podemos enviar una consulta a InfluxDB y devolver todos los datos que tiene durante el último minuto:

 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

Conecte de forma segura Telegraf + un InfluxDB privado con Ockam

El ejemplo anterior conecta estos dos servicios, que se ejecutan en el mismo host, utilizando el transporte HTTP sin cifrar predeterminado. La mayoría de las configuraciones no triviales tendrán InfluxDB ejecutándose en un host separado con uno o más nodos Telegraf enviando datos. En producción, es poco probable que un transporte sin cifrar sea aceptable, tampoco siempre es deseable exponer potencialmente el puerto InfluxDB a Internet público.

En esta sección, le mostraremos cómo se pueden resolver ambos problemas con cambios de configuración mínimos en cualquier servicio existente.

Creando e inscribiendo sus nodos

El primer paso es inscribirse en Ockam, guardar la información de su proyecto y crear tokens de inscripción para sus nodos InfluxDB y 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)

Ahora podemos crear un nodo para nuestro servicio 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

Hay algunas cosas que han sucedido en esos comandos, así que analicémoslas rápidamente:

• Creamos un nuevo nodo llamado influxdb y lo registramos con Ockam usando el token que generamos anteriormente. Si vuelve a mirar el comando que generó el token, verá que también etiquetamos este token con un atributo de component=influxdb .
• Luego agregamos una política al nodo influxdb , que establece que solo los nodos que tienen un atributo component con un valor de telegraf podrán conectarse a una salida TCP.
• A continuación, creamos una salida TCP. Esto es como una tubería desde el nodo influxdb que acabamos de crear hasta el puerto TCP de 127.0.0.1:8086 (es decir, el puerto en el que escucha nuestra base de datos InfluxDB). Este nodo de Ockam ahora canalizará todos los datos que reciba de otros nodos a ese destino. Sin embargo, los únicos nodos que podrán establecer esa conexión son aquellos que pasen la política definida en el paso anterior.
• Finalmente, creamos un reenviador en nuestro proyecto, que ahora permite que otros nodos en nuestro proyecto descubran el influxdb y enruten el tráfico hacia él.

Ahora es el momento de establecer el otro lado de esta conexión creando el nodo de cliente correspondiente para 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

Ahora podemos descomprimir estos tres comandos y lo que han hecho:

• Como antes, usamos el token de inscripción que generamos para crear un nuevo nodo y lo registramos con nuestro proyecto. Esta vez es el nodo telegraf .
• Nuevamente hemos aplicado una política para mejorar nuestra postura de seguridad. Esta política permite que se cree una entrada TCP, pero solo si el nodo en el otro extremo tiene el component de atributo con un valor de influxdb .
• Finalmente creamos la entrada TCP. Esta es una forma de definir dónde debe escuchar el nodo las conexiones (en este caso, en el puerto TCP 8087 ) y hacia dónde debe reenviar ese tráfico. Este nodo reenviará datos al reenviador que creamos anteriormente, que a su vez los pasará a nuestro nodo influxdb, que luego los envía a la base de datos InfluxDB.

¡Eso es todo! El oyente en el puerto localhost 8087 ahora está reenviando todo el tráfico a InfluxDB, donde sea que se esté ejecutando. Si esa base de datos estuviera en un host diferente, ejecutándose en la nube o en un centro de datos privado, la inscripción y el reenvío aún garantizarían que nuestra comunicación con 127.0.0.1:8087 estaría conectada de forma segura dondequiera que se esté ejecutando esa base de datos.

Actualice la configuración existente para usar la conexión segura

Este ejemplo creó la entrada TCP en el puerto 8087 principalmente porque el servicio influxd se estaba ejecutando en el mismo host y ya estaba vinculado al puerto 8086 . En una implementación de producción donde Telegraf e InfluxDB están en hosts separados, la entrada de TCP podría escuchar en el puerto 8086 y no sería necesario cambiar esta configuración predeterminada.

Si bien este es un ejemplo simplificado que se ejecuta en un solo host, las siguientes instrucciones son las mismas independientemente de su implementación. Una vez que los nodos influxdb y telegraf están registrados y en ejecución, el único cambio que debe hacer es actualizar su telegraf.conf para que apunte al puerto de escucha local:

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

Reinicie el servicio de Telegraf, y luego podemos verificar que todavía está almacenando datos usando el mismo comando que usamos anteriormente.z

Clientes conectados de forma segura, y más...

El ejemplo aquí, en menos de 10 minutos, resolvió nuestro problema más apremiante y agregó una serie de mejoras valiosas que no son inmediatamente obvias porque se han abstraído:

• Las bases de datos privadas permanecen privadas: su InfluxDB no ha tenido su puerto expuesto a la Internet pública, por lo que no hay una ruta para que terceros

  
  

• Cifrado en tránsito: el canal seguro que se establece entre sus nodos está cifrado de extremo a extremo. Cada nodo genera sus propias claves criptográficas y recibe sus propias credenciales únicas. Luego los usan para establecer un canal seguro de confianza mutua entre ellos. Al eliminar la dependencia de un servicio de terceros para almacenar o distribuir claves, puede reducir su área de superficie de vulnerabilidad y eliminar los puntos únicos de falla.

  
  

• Control de acceso basado en identidad y atributos: la autorización para establecer incluso una ruta a la base de datos InfluxDB está vinculada a la identidad única del cliente que solicita acceso, que es más flexible en términos de compatibilidad con enfoques de implementación modernos y a menudo dinámicos y también se alinea más claramente con nuestras intenciones en torno al control de acceso. Si el cliente puede establecer la confianza de que es quien dice ser, entonces puede enrutar sus paquetes a la base de datos. Compare eso con enfoques históricos que decisiones de acceso permanente basadas en suposiciones sobre la red remota (por ejemplo, ¿esta solicitud proviene de una dirección IP que hemos autorizado previamente?). Esto se suma a los controles de autenticación y autorización en la propia base de datos InfluxDB, que seguirán funcionando como siempre.

  
  

• Diseño seguro: la combinación de todo lo anterior significa que la única forma de acceder a la base de datos de InfluxDB es a través de un canal seguro, lo que significa que todas las comunicaciones se cifran en tránsito, independientemente de cualquier configuración incorrecta en cualquiera de los extremos (p. ej., HTTP/TLS no estar habilitado). Y debido a que cada nodo intercambia credenciales entre sí en lugar de compartir un certificado común o una clave de cifrado compartida, también puede estar seguro de que:

  
  

  1. Ninguna otra parte en la cadena de suministro puede modificar los datos en tránsito. Los datos que recibe en el consumidor son exactamente los que le enviaron sus clientes.

  2. Que solo los clientes autorizados puedan escribir en InfluxDB, asegurando que los datos en su tema sean altamente confiables. Si tiene requisitos aún más estrictos, puede tomar el control de su autoridad de credenciales y aplicar políticas de autorización detalladas.

     
     

• Área de superficie de vulnerabilidad reducida: Ockam simplifica las preocupaciones de acceso del cliente al exponer todos los servicios remotos como servicios locales. Llamamos a esto adyacencia virtual . Cuando todos los componentes remotos de una aplicación se vuelven virtualmente adyacentes a todos los demás componentes, entonces la seguridad y la complejidad de la confianza de toda la red, toda la infraestructura, toda Internet se abstrae por completo. Todos los intermediarios de terceros se eliminan de la superficie de vulnerabilidad de la aplicación.

Próximos pasos

• Si aún no ha seguido el ejemplo de esta guía, puede empezar a usar Ockam de forma gratuita siguiendo las instrucciones de nuestra documentación.
• Si desea hablar específicamente sobre este u otros posibles casos de uso de Ockam, el equipo estará más que feliz de chatear contigo .
• Alternativamente, puede unirse a nosotros y a una comunidad cada vez mayor de desarrolladores que desean generar confianza creando aplicaciones que son seguras por diseño, en el Servidor Discord de la comunidad Build Trust o en Github .