Comment connecter des clients distribués à une base de données InfluxDB privée

InfluxDB est devenu un moyen populaire pour les capteurs et les services de stocker des données de séries chronologiques, et InfluxData rend cela rapide et facile grâce à InfluxCloud. Cependant, certains des clients avec lesquels nous avons parlé ne stockent pas tout dans un service cloud géré. Parfois, ils ont des raisons commerciales, réglementaires ou de conformité spécifiques pour stocker les données eux-mêmes dans leur propre centre de données. D'autres fois, ils utilisent plusieurs sorties dans Telegraf pour envoyer des données à InfluxDB Cloud dans le cadre de leur plan de reprise après sinistre.

Quelle que soit la raison, la connexion sécurisée d'un seul client à une base de données InfluxDB privée implique potentiellement la configuration de routes réseau, l'ouverture de pare-feu, l'ajustement des NACL et des groupes de sécurité. Sans parler de la navigation dans tous les processus internes pouvant être impliqués pour faire approuver et déployer tous ces changements. La valeur d'InfluxDB n'est pas d'avoir un seul client qui écrit occasionnellement des données, mais d'être capable d'en prendre en charge des centaines ou plus. Répétez donc cette surcharge d'administration réseau pour chaque nouveau périphérique, ou chaque fois que la configuration réseau d'un périphérique change, et vous vous retrouvez très rapidement dans une situation où le maintien de ces contrôles réseau stricts devient insoutenable. La plupart des gens peseraient alors entre deux options : 1) Exiger qu'un VPN soit établi entre le client distant et la base de données réseau InfluxDB. (Potentiellement) Moins d'administration en cours pour les administrateurs réseau où InfluxDB est en cours d'exécution, mais un fardeau de configuration plus élevé pour celui qui gère les clients. Et veulent-ils vraiment que leur réseau soit connecté au vôtre via un VPN ? Ou 2) Exposez la base de données InfluxDB directement à l'Internet public et faites confiance au système d'authentification pour le protéger.

Aujourd'hui, je vais vous présenter un troisième choix. Cela ne prendra que quelques minutes à mettre en œuvre, ne nécessitera aucun changement de réseau et vous évitera d'avoir à mettre votre base de données privée sur l'Internet public. Nous bénéficierons également de toute une série d'autres avantages en cours de route que je couvrirai une fois que cela fonctionnera.

La configuration initiale

Si vous souhaitez passer directement à un exemple concret de cela, nous avons disponible sur GitHub un Démo InfluxDB + Telegraf + Ockam pour Docker que vous pouvez exécuter localement avec Docker Compose. Il utilise les images Docker officielles pour InfluxDB et Telegraf, avec des modifications des scripts de démarrage afin que chaque service utilise Ockam pour établir une connexion. Des instructions complètes sur la façon de l'exécuter sont incluses dans le README .

Pour simuler un exemple de bout en bout d'un client envoyant des données dans InfluxDB, nous allons démarrer une instance Telegraf, lui faire émettre des événements CPU à InfluxDB, puis changer la façon dont ces deux se connectent pour montrer comment nous les connecterions sur différents hôtes ou réseaux. Pour les besoins de cet exemple, nous exécuterons tout sur une seule machine.

Ockam

Si vous avez déjà configuré Ockam, vous pouvez ignorer cette section et passer directement à la configuration d'InfluxDB ci-dessous.

 brew install build-trust/ockam/ockam

(si vous n'utilisez pas brew pour la gestion des packages, nous avons instructions d'installation pour d'autres systèmes dans notre documentation)

Une fois installé, vous devez inscrire votre identité locale auprès d'Ockam Orchestrator, exécutez la commande ci-dessous et suivez les instructions fournies :

 ockam enroll

InfluxDB

Si vous avez déjà InfluxDB en cours d'exécution sur votre ordinateur local et que vous disposez d'un jeton d'authentification que vous pouvez utiliser pour y écrire, vous pouvez ignorer cette section et passer directement à l'installation de Telegraf ci-dessous.

Les conditions préalables pour cette section sont d'installer d'abord :

• InfluxDB
• Afflux CLI

Une fois installé, nous devons démarrer InfluxDB afin d'avoir un endroit où stocker les données de métriques que nous allons générer. Sur la plupart des systèmes, cela sera aussi simple que d'exécuter :

 influxd

Vous devriez alors voir une sortie de journal, avec la dernière ligne confirmant que influxd écoute maintenant sur le port 8086 :

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

Si influxd a démarré avec succès, vous pouvez ouvrir une nouvelle session de terminal et la laisser s'exécuter en arrière-plan. Si influxd n'a pas démarré avec succès, vérifiez le documentation officielle pour certains problèmes courants pour différents systèmes d'exploitation.

Nous allons maintenant utiliser la commande CLI influx pour terminer la configuration initiale de la base de données afin qu'influxd puisse recevoir nos données. Exécutez la commande setup et complétez les invites requises, souvenez-vous des noms d'organisation et de compartiment que vous utilisez car nous en aurons besoin plus tard :

 influx setup

Ensuite, vous devrez copier le jeton de l'utilisateur que vous venez de créer, que vous pourrez récupérer avec la commande auth :

 influx auth list

Télégraphe

Installer Telegraf , et une fois configuré, nous aurons besoin d'un fichier de configuration qui définit notre source d'entrée et notre destination de sortie. Telegraf inclut heureusement une commande pour générer un tel fichier, que nous pouvons spécifier pour être préconfiguré avec l'utilisation du processeur de notre machine hôte comme source d'entrée et avec InfluxDB comme sortie.

Pour générer la configuration de base, exécutez :

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

Ouvrez le fichier telegraf.conf généré et trouvez la section [[outputs.influxdb_v2]] qui devrait ressembler à ceci :

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

Remplacez les valeurs vides pour le jeton, l'organisation et le compartiment par les valeurs de la section précédente sur mise en place d'InfluxDB et enregistrez vos modifications. Vous pouvez maintenant démarrer Telegraf :

 telegraf --config telegraf.conf

Vérifiez que tout fonctionne

Pour faciliter la réutilisation de vos valeurs pour de futures commandes et tests, stockez les valeurs appropriées (c'est-à-dire, remplacez les espaces réservés ci-dessous par vos valeurs réelles) dans une série de variables d'environnement :

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

Nous pouvons maintenant vérifier que Telegraf envoie régulièrement des données à InfluxDB. La configuration que nous avons créée précédemment émettra des statistiques CPU toutes les 10 secondes, nous pouvons donc envoyer une requête à InfluxDB et lui renvoyer toutes les données dont il dispose au cours de la dernière minute :

 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

Connectez en toute sécurité Telegraf + un InfluxDB privé avec Ockam

L'exemple ci-dessus connecte ces deux services, s'exécutant sur le même hôte, en utilisant le transport HTTP non chiffré par défaut. La plupart des configurations non triviales auront InfluxDB exécuté sur un hôte séparé avec un ou plusieurs nœuds Telegraf envoyant des données. En production, il est peu probable qu'un transport non chiffré soit acceptable, il n'est pas toujours souhaitable d'exposer potentiellement le port InfluxDB à Internet public.

Dans cette section, nous allons vous montrer comment ces deux problèmes peuvent être résolus avec des modifications de configuration très minimes des services existants.

Création et inscription de vos nœuds

La première étape consiste à vous inscrire auprès d'Ockam, à enregistrer les informations de votre projet et à créer des jetons d'inscription pour vos nœuds InfluxDB et 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)

Nous pouvons maintenant créer un nœud pour notre service 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

Il y a quelques choses qui se sont produites dans ces commandes, alors décompressons-les rapidement :

• Nous avons créé un nouveau nœud appelé influxdb et l'avons inscrit auprès d'Ockam à l'aide du jeton que nous avions généré précédemment. Si vous revenez sur la commande qui a généré le jeton, vous verrez que nous avons également marqué ce jeton avec un attribut de component=influxdb .
• Nous avons ensuite ajouté une politique au nœud influxdb , qui stipule que seuls les nœuds qui ont un attribut component avec une valeur de telegraf pourront se connecter à une prise TCP.
• Ensuite, nous créons une prise TCP. C'est comme un tuyau du nœud influxdb que nous venons de créer vers le port TCP de 127.0.0.1:8086 (c'est-à-dire le port sur lequel notre base de données InfluxDB écoute). Ce nœud Ockam dirigera désormais toutes les données qu'il reçoit d'autres nœuds vers cette destination. Cependant, les seuls nœuds qui pourront établir cette connexion sont ceux qui passent la politique définie à l'étape précédente.
• Enfin, nous créons un transitaire sur notre projet, qui permet désormais aux autres nœuds de notre projet de découvrir influxdb et d'y acheminer le trafic.

Il est maintenant temps d'établir l'autre côté de cette connexion en créant le nœud client correspondant pour 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

Nous pouvons maintenant décompresser ces trois commandes et ce qu'elles ont fait :

• Comme précédemment, nous avons utilisé le jeton d'inscription que nous avons généré pour créer un nouveau nœud et l'avons enregistré avec notre projet. Cette fois c'est le noeud telegraf .
• Nous avons de nouveau appliqué une politique pour améliorer notre posture de sécurité. Cette stratégie permet de créer une entrée TCP, mais uniquement si le nœud à l'autre extrémité a le component d'attribut avec une valeur de influxdb .
• Enfin, nous créons l'entrée TCP. C'est une façon de définir où le nœud doit écouter les connexions (dans ce cas sur le port TCP 8087 ) et où il doit transférer ce trafic. Ce nœud transmettra les données au redirecteur que nous avons créé précédemment, qui les transmettra à son tour à notre nœud influxdb, qui les enverra ensuite à la base de données InfluxDB.

C'est ça! L'écouteur sur le port 8087 de l'hôte local transfère maintenant tout le trafic vers InfluxDB, où qu'il soit en cours d'exécution. Si cette base de données se trouvait sur un hôte différent, s'exécutant dans le cloud ou dans un centre de données privé, l'inscription et le transfert garantiraient toujours que notre communication avec 127.0.0.1:8087 serait connectée en toute sécurité partout où cette base de données est en cours d'exécution.

Mettre à jour la configuration existante pour utiliser la connexion sécurisée

Cet exemple a créé l'entrée TCP sur le port 8087 principalement parce que le service influxd s'exécutait sur le même hôte et était déjà lié au port 8086 . Dans un déploiement de production où Telegraf et InfluxDB sont sur des hôtes séparés, l'entrée TCP pourrait écouter sur le port 8086 et cette configuration par défaut n'aurait pas besoin de changer.

Bien qu'il s'agisse d'un exemple simplifié s'exécutant sur un seul hôte, les instructions suivantes sont les mêmes quel que soit votre déploiement. Une fois que les nœuds influxdb et telegraf sont inscrits et en cours d'exécution, la seule modification que vous devez apporter est de mettre à jour votre telegraf.conf pour qu'il pointe vers le port d'écoute local :

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

Redémarrez le service Telegraf, et nous pourrons alors vérifier qu'il stocke toujours des données en utilisant la même commande que nous avons utilisée précédemment.z

Clients connectés en toute sécurité, et plus encore...

L'exemple ici a, en moins de 10 minutes, résolu notre problème le plus pressant tout en ajoutant un certain nombre d'améliorations précieuses qui ne sont pas immédiatement évidentes car elles ont été abstraites :

• Les bases de données privées restent privées : votre InfluxDB n'a pas eu son port exposé à l'Internet public, et il n'y a donc aucun moyen pour les tiers de

  
  

• Chiffrement en transit : le canal sécurisé établi entre vos nœuds est chiffré de bout en bout. Chaque nœud génère ses propres clés cryptographiques et reçoit ses propres informations d'identification uniques. Ils les utilisent ensuite pour établir entre eux un canal sécurisé de confiance mutuelle. En supprimant la dépendance à un service tiers pour stocker ou distribuer des clés, vous pouvez réduire votre surface de vulnérabilité et éliminer les points de défaillance uniques.

  
  

• Contrôle d'accès basé sur l'identité et les attributs : l'autorisation d'établir même une route vers la base de données InfluxDB est liée à l'identité unique du client demandant l'accès, qui est à la fois plus flexible en termes de prise en charge des approches de déploiement modernes et souvent dynamiques et s'aligne également plus clairement sur nos intentions concernant le contrôle d'accès. Si le client est en mesure d'établir la confiance qu'il est bien celui qu'il prétend être, il est alors en mesure d'acheminer ses paquets vers la base de données. Comparez cela aux approches historiques qui prennent des décisions d'accès permanentes basées sur des hypothèses sur le réseau distant (par exemple, cette requête provient-elle d'une adresse IP que nous avons pré-autorisée ?). Cela s'ajoute aux contrôles d'authentification et d'autorisation sur la base de données InfluxDB elle-même, qui continueront à fonctionner comme ils l'ont toujours fait.

  
  

• Sécurisé dès la conception : la combinaison de tout ce qui précède signifie que le seul moyen d'accéder à la base de données InfluxDB est via un canal sécurisé, ce qui signifie que toutes les communications sont cryptées en transit, indépendamment de toute mauvaise configuration à chaque extrémité (par exemple, HTTP/TLS n'est pas activé). Et parce que chaque nœud échange des informations d'identification entre eux plutôt que de partager un certificat commun ou une clé de chiffrement partagée, vous pouvez également être sûr que :

  
  

  1. Aucune autre partie de la chaîne d'approvisionnement n'est en mesure de modifier les données en transit. Les données que vous recevez chez le consommateur sont exactement celles qui ont été envoyées par vos clients.

  2. Seuls les clients autorisés peuvent écrire sur InfluxDB, ce qui garantit que les données de votre sujet sont hautement fiables. Si vous avez des exigences encore plus strictes, vous pouvez prendre le contrôle de votre autorité d'identification et appliquer des politiques d'autorisation granulaires.

     
     

• Surface de vulnérabilité réduite : Ockam simplifie les problèmes d'accès client en exposant tous les services distants en tant que services locaux. Nous appelons cela contiguïté virtuelle . Lorsque tous les composants distants d'une application deviennent pratiquement adjacents à tous les autres composants, la complexité de la sécurité et de la confiance de l'ensemble du réseau, de l'ensemble de l'infrastructure, de l'ensemble de l'Internet est complètement supprimée. Tous les intermédiaires tiers sont supprimés de la surface de vulnérabilité de l'application.

Prochaines étapes

• Si vous n'avez pas encore suivi l'exemple de ce guide, vous pouvez commencer à utiliser Ockam gratuitement en suivant les instructions de notre documentation.
• Si vous souhaitez parler spécifiquement de cela ou d'autres cas d'utilisation potentiels pour Ockam, l'équipe serait plus qu'heureuse de vous discuter avec toi .
• Vous pouvez également nous rejoindre, ainsi qu'une communauté toujours croissante de développeurs qui souhaitent instaurer la confiance en créant des applications sécurisées dès la conception, dans le Serveur Discord de la communauté Build Trust ou sur GithubGenericName .