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   InfluxDB Cloud como parte de su plan de recuperación ante desastres. a  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  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   .   Demostración de InfluxDB + Telegraf + Ockam para Docker 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  para diferentes sistemas operativos.   documentación oficial para algunos problemas comunes  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  , 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.   Instalar Telegraf  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   que debería verse así: [[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 = ""  Reemplace los valores vacíos de token, organización y depósito con los valores de la sección anterior sobre  y guardar los cambios. Ahora puede iniciar Telegraf:   configurando InfluxDB   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   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   . influxdb component=influxdb  Luego agregamos una política al nodo   , que establece que solo los nodos que tienen un atributo   con un valor de   podrán conectarse a una salida TCP. influxdb component telegraf  A continuación, creamos una salida TCP. Esto es como una tubería desde el nodo   que acabamos de crear hasta el puerto TCP de   (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. influxdb 127.0.0.1:8086  Finalmente, creamos un reenviador en nuestro proyecto, que ahora permite que otros nodos en nuestro proyecto descubran el   y enruten el tráfico hacia él. influxdb  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   de atributo con un valor de   . component 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   ) 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. 8087  ¡Eso es todo! El oyente en el puerto localhost   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   estaría conectada de forma segura dondequiera que se esté ejecutando esa base de datos. 8087 127.0.0.1:8087   Actualice la configuración existente para usar la conexión segura  Este ejemplo creó la entrada TCP en el puerto   principalmente porque el servicio influxd se estaba ejecutando en el mismo host y ya estaba vinculado al puerto   . 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   y no sería necesario cambiar esta configuración predeterminada. 8087 8086 8086  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   y   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: influxdb telegraf   [[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:    su InfluxDB no ha tenido su puerto expuesto a la Internet pública, por lo que no hay una ruta para que terceros Las bases de datos privadas permanecen privadas:    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. Cifrado en tránsito:    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   a los controles de autenticación y autorización en la propia base de datos InfluxDB, que seguirán funcionando como siempre. Control de acceso basado en identidad y atributos: se suma    la combinación de todo lo anterior significa que la   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: Diseño seguro: única  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.  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.    Ockam simplifica las preocupaciones de acceso del cliente al exponer todos los servicios remotos como servicios locales. Llamamos a esto  . 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. Área de superficie de vulnerabilidad reducida:   adyacencia virtual   Próximos pasos  Si aún no ha seguido el ejemplo de esta guía, puede  de forma gratuita siguiendo las instrucciones de nuestra documentación.   empezar a usar Ockam  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  o en  .   Servidor Discord de la comunidad Build Trust   Github  También publicado   . aquí

Build Applications That Trust Data-in-Motion

Este audio es producido en el idioma original de la historia!

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

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps