分散クライアントをプライベート InfluxDB データベースに接続する方法

InfluxDB は、センサーやサービスが時系列データを保存するための一般的な方法になりました。ただし、私たちが話を聞いた一部の顧客は、マネージド クラウド サービスにすべてを保存しているわけではありません。場合によっては、特定のビジネス、規制、またはコンプライアンス上の理由で、データ自体を独自のデータ センターに保存することがあります。また、災害復旧計画の一環として、Telegraf で複数の出力を使用して両方のInfluxDB Cloud にデータを送信する場合もあります。

理由が何であれ、単一のクライアントをプライベート InfluxDB データベースに安全に接続するには、ネットワーク ルートの設定、ファイアウォールの開放、NACL とセキュリティ グループの調整が必要になる可能性があります。言うまでもなく、これらすべての変更を承認して展開するために必要な内部プロセスをナビゲートする必要があります。 InfluxDB の価値は、時折 1 つのクライアントがデータを書き込むことではなく、数百以上のクライアントをサポートできることです。したがって、新しいデバイスごとに、またはデバイスのネットワーク構成が変更されるたびに、ネットワーク管理のオーバーヘッドを繰り返すと、これらの厳格なネットワーク制御を維持できなくなる状況がすぐに発生します。ほとんどの人は、次のいくつかのオプションを比較検討します: 1) リモート クライアントと InfluxDB データベースが存在するネットワークとの間に VPN を確立する必要があります。クライアントを管理している人にとっては、セットアップの負担が大きくなります。そして、VPN 経由でネットワークをあなたのネットワークに接続することを本当に望んでいるのでしょうか?または 2) InfluxDB データベースを公共のインターネットに直接公開し、認証システムがそれを保護するのに十分であると信頼します。

今日は、第 3 の選択肢について説明します。実装には数分しかかからず、ネットワークの変更は不要で、プライベート データベースをパブリック インターネットに配置する必要がなくなります。また、それが機能するようになったら、私がカバーする方法に沿って投入される他の多くの利点も得ます.

初期設定

この実際の例に直接飛び込みたい場合は、GitHub で入手できます。 InfluxDB + Telegraf + Docker の Ockam デモDocker Compose を使用してローカルで実行できます。 InfluxDB と Telegraf の公式の Docker イメージを使用し、スタートアップ スクリプトを変更して、各サービスが Ockam を使用して接続を確立するようにします。実行方法の完全な説明はREADMEに含まれています。

InfluxDB にデータを送信するクライアントのエンド ツー エンドの例をシミュレートするために、Telegraf インスタンスを開始し、CPU イベントを InfluxDB に発行させ、それら 2 つの接続方法を変更して、接続方法を示します。異なるホストまたはネットワーク間で。ただし、この例では、すべてを 1 台のマシンで実行します。

オッカム

以前に Ockam をセットアップしたことがある場合は、このセクションをスキップして、以下の InfluxDB のセットアップに直接進むことができます。

 brew install build-trust/ockam/ockam

(パッケージ管理にbrewを使用していない場合は、他のシステムのインストール手順私たちのドキュメントで）

インストールしたら、ローカル ID を Ockam Orchestrator に登録する必要があります。以下のコマンドを実行し、表示される指示に従います。

 ockam enroll

流入DB

ローカル マシンで既に InfluxDB を実行していて、書き込みに使用できる認証トークンがある場合は、このセクションをスキップして、以下の Telegraf のインストールに直接進むことができます。

このセクションの前提条件は、最初にインストールすることです。

• 流入DB
• 流入CLI

インストールしたら、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 が正常に起動しなかった場合は、いくつかの一般的な問題に関する公式ドキュメントさまざまなオペレーティング システム用です。

次に、influx CLI コマンドを使用してデータベースの初期設定を完了し、influxd がデータを受信できるようにします。セットアップ コマンドを実行し、必要なプロンプトを完了します。後で必要になるため、使用する組織名とバケット名を覚えておいてください。

 influx setup

次に、作成したばかりのユーザーのトークンをコピーする必要があります。これは auth コマンドで取得できます。

 influx auth list

テレグラフ

テレグラフをインストールする、セットアップが完了したら、入力ソースと出力先を定義する構成ファイルが必要になります。ありがたいことに、Telegraf にはそのようなファイルを生成するコマンドが含まれており、ホスト マシンの CPU 使用率を入力ソースとして、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 秒ごとに CPU 統計を発行するため、クエリを InfluxDB に送信して、過去 1 分間のすべてのデータを返すことができます。

 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 トランスポートを使用して、同じホストで実行されているこれら 2 つのサービスを接続しています。ほとんどの重要な構成では、データを送信する 1 つ以上の Telegraf ノードを持つ別のホストで InfluxDB が実行されます。本番環境では、暗号化されていないトランスポートが受け入れられる可能性は低く、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の属性でタグ付けされていることがわかります。
• 次に、 component値がtelegrafであるノードのみが TCP アウトレットに接続できることを示すポリシーをinfluxdbノードに追加しました。
• 次に、TCP アウトレットを作成します。これは、先ほど作成したinfluxdbノードから127.0.0.1:8086の TCP ポート (つまり、InfluxDB データベースがリッスンしているポート) へのパイプのようなものです。この Ockam ノードは、他のノードから受信したすべてのデータをその宛先にパイプします。ただし、その接続を確立できる唯一のノードは、前の手順で定義されたポリシーを通過するノードです。
• 最後に、プロジェクトにフォワーダーを作成します。これにより、プロジェクト内の他のノードが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

これで、これら 3 つのコマンドとその実行内容を展開できます。

• 以前と同様に、生成した登録トークンを使用して新しいノードを作成し、プロジェクトに登録しました。今回はtelegrafノードです。
• セキュリティ体制を改善するためのポリシーを再度適用しました。このポリシーは、TCP インレットの作成を許可しますが、反対側のノードにinfluxdbの値を持つ属性componentがある場合に限ります。
• 最後に、TCP インレットを作成します。これは、ノードが接続をリッスンする場所 (この場合は TCP ポート8087 ) と、そのトラフィックの転送先を定義する方法です。このノードは、以前に作成した forwader にデータを転送し、influxdb ノードにデータを渡し、InfluxDB データベースに送信します。

それでおしまい！ localhost ポート8087のリスナーは、すべてのトラフィックを InfluxDB が実行されている場所に転送します。そのデータベースがクラウドまたはプライベート データ センターで実行されている別のホスト上にある場合でも、 127.0.0.1:8087 :8087 との通信は、そのデータベースが実行されている場所であればどこでも安全に接続されます。

安全な接続を使用するように既存の構成を更新する

この例では、主に influxd サービスが同じホストで実行されていて、すでにポート8086 8087 TCP インレットを作成しました。 Telegraf と InfluxDB が別々のホストにある本番環境では、TCP インレットはポート8086でリッスンでき、このデフォルト設定を変更する必要はありません。

これは単一のホストで実行される単純化された例ですが、次の手順はデプロイに関係なく同じです。 influxdbとtelegrafノードが登録されて実行されたら、必要な唯一の変更は、telegraf.conf を更新してローカルのリッスン ポートを指すようにすることです。

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

Telegraf サービスを再起動すると、以前に使用したのと同じコマンドを使用して、まだデータが保存されていることを確認できます.z

安全に接続されたクライアントなど...

ここに示す例では、10 分もかからずに最も差し迫った問題が解決され、抽象化されているためにすぐにはわからない多くの価値ある改善が追加されています。

• プライベート データベースはプライベートなままです: InfluxDB のポートはパブリック インターネットに公開されていないため、サード パーティがアクセスするルートはありません。

  
  

• 転送中の暗号化:ノード間で確立される安全なチャネルは、エンドツーエンドで暗号化されます。各ノードは独自の暗号鍵を生成し、独自の資格情報を発行します。次に、これらを使用して、相互に信頼できる安全なチャネルを相互に確立します。キーを保存または配布するためのサードパーティ サービスへの依存を取り除くことで、脆弱性の表面領域を減らし、単一障害点を排除することができます。

  
  

• ID および属性ベースのアクセス制御: InfluxDB データベースへのルートを確立するための承認は、アクセスを要求しているクライアントの一意の ID に関連付けられています。アクセス制御に関する私たちの意図。クライアントが、自分が誰であるかという信頼を確立できる場合、パケットをデータベースにルーティングできます。これを、リモート ネットワークに関する仮定に基づいて永続的なアクセスを決定する従来のアプローチと比較してください (たとえば、この要求は、事前に承認した IP アドレスからのものですか?)。これは、InfluxDB データベース自体の認証および承認制御に加えて、これまでどおり機能し続けます。

  
  

• 安全な設計:上記のすべての組み合わせは、InfluxDB データベースにアクセスする唯一の方法が安全なチャネルを介することを意味します。つまり、すべての通信は、両端の設定ミスに関係なく、転送中に暗号化されます (HTTP/TLS など)。有効になっていません)。また、各ノードは、共通の証明書や共有暗号化キーを共有するのではなく、相互に資格情報を交換するため、次のことも確認できます。

  
  

  1. サプライ チェーンの他の関係者は、転送中のデータを変更できません。コンシューマで受信するデータは、クライアントから送信されたものとまったく同じです。

  2. 許可されたクライアントのみが InfluxDB に書き込むことができるため、トピック内のデータの信頼性が高くなります。さらに厳しい要件がある場合は、資格証明機関を制御して、きめ細かな承認ポリシーを適用できます。

     
     

• 脆弱性の表面領域の縮小: Ockam は、すべてのリモート サービスをローカル サービスとして公開することにより、クライアント アクセスの問題を簡素化します。これを仮想隣接.アプリケーションのすべてのリモート コンポーネントが他のすべてのコンポーネントに仮想的に隣接するようになると、ネットワーク全体、インフラストラクチャ全体、インターネット全体のセキュリティと信頼の複雑さが完全に抽象化されます。すべてのサード パーティの仲介者は、アプリの脆弱性の表面から削除されます。

次のステップ

• このガイドの例をまだ実行していない場合は、次のことができます。オッカムを使い始めるドキュメンテーションの指示に従って無料でダウンロードできます。
• Ockam のこれまたはその他の潜在的な使用例について具体的に話したい場合は、チームが喜んで対応します。あなたと話す.
• または、安全に設計されたアプリケーションを作成することで信頼を築きたいと考えている、成長を続ける開発者のコミュニティである私たちに参加することもできます。 Trust コミュニティの Discord サーバーを構築するまたはギットハブ.