[Gremlin] private network integrationsによる内部ネットワーク内に対するステータスチェックとWebhookが利用可能に [Update]

2021.11.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2021年11月30日のGremlinのアップデートでprivate network integrationsの開始が発表されました。

private network integrationsは、内部ネットワーク内にあるシステムに対して既存のステータスチェックとWebhook機能を利用できるようになるといったことです。

※ 現在は オープンベータ版 となっています

概要

ステータスチェックはGremlinのシナリオの前、最中、および後のシステムの状態をチェックします。 また、システムが異常になったり応答しなくなったりした場合に、シナリオを自動的に停止することもできます。 これにはエンドポイントURLが必要です。

Webhookは攻撃を実行するときにカスタムHTTPエンドポイントURLを呼び出すことができます。 Webhookを使用すると、攻撃の状態をサードパーティのツールまたはサービスに簡単に送信できます。

この2つの機能に指定するエンドポイントURLはパブリックインターネット経由でアクセス可能である必要があり、厳しいセキュリティ管理を行っている組織では難しい場合がありました。

private network integrationsができたことにより、プライベートネットワーク内でステータスチェックとWebhookを実行できるようになり、内部エンドポイントをパブリックインターネットに公開する必要がなくなり、セキュリティを変更することなくカオス実験を強化できるようになります。

ステータスチェックをやってみる

AWS上のパブリックなフロントエンド(frontend-service)と、プライベートなAPIサービス(backend-service)で構成されているシステムを例にします。

frontend-serviceにカオスエンジニアリングの実験を行うときのステータスチェックにbackend-serviceのAPIが正常に動作しているか? を確認する といった形を考えてみましょう。

backend-serviceは現状ではパブリックインターネット経由でアクセスできないため、テストリクエストも失敗します。

Integration Agentをインストール

private network integrationsを使用するには、GremlinのIntegration Agentをインストールする必要があります

private network integrationsは、内部ネットワーク内でステータスチェックとWebhookを実行できるようにするものです。 基本的に、ステータスチェックとWebhookをプロキシして、内部システムに到達できるようにし、インターネットに公開する必要をなくします。

ネットワーク内にデプロイされたIntegration Agentのインスタンスは1つだけで大丈夫です。

Integration Agentのインストール

上記のドキュメントを参考にし、インストールします。

今回はAmazon Linux2を使用するので、以下のコマンドでインストールします。

sudo curl https://rpm.gremlin.com/gremlin.repo -o /etc/yum.repos.d/gremlin.repo
sudo yum install -y gremlin-integrations

実行後、設定ファイルを編集します。

/etc/gremlin/integrations-config.yamlを開いて、

  • team_id
  • team_secret
  • integration_agent_allow_list
    • アクセスを許可するURLを管理する

を設定します。team_idとteam_secretが必須です。

integration_agent_allow_listの例)

integration_agent_allow_list:
  - ^http://localhost:3000/api
  - ^http://host.docker.internal:8080

編集後、sudo systemctl restart gremlin-integrations を実行して設定を反映させます。

ステータスチェックの作成

Integration Agentのインストールが終わったら、ステータスチェックを作成します。

Gremlinダッシュボードにログインし、左メニューのScenariosをクリックし、ページ上部のStatus Checksタブをクリックしましょう。

New Status CheckをクリックしてNew Status Checkペインを表示させます

  • Continuous Status Checkのトグルをオンにするとシナリオの実行中に10秒ごとにステータスチェックが実行されます。
  • Status Check Nameにはこのチェックの名前を入力します。
  • Descriptionにはこのチェックの説明を入力します。
  • Endpoint URLで、Private Network Endpointにチェックを入れます。これで先ほど作成したIntegration Agentからプロキシされます。
  • URLテキストフィールドが有効になり、確認するサービスのURLを入力できるようになります。ここにチェックに使用する内部エンドポイントのURLwo記載します。
  • Header Informationには、認証資格情報などの追加データなどが必要な場合に利用しましょう

Test Requestをクリックし、期待した結果が正しく返ってくるか確認します。

Success Evaluationにはチェック成功時のステータスコードと要求タイムアウトを設定します。

最後にSaveを押して完了です。

ステータスチェックをシナリオに組み込む

作成したステータスチェックをシナリオに組み込んで実行できるようにしてみます。

公式のチュートリアルと同じように、Validate Health Checks - Latency シナリオを使います。

Customizeボタンをクリックして編集画面に行きます。

ページ下部のAdd a Status Checkをクリックして、設定欄を表示させます。

Start from a saved Status Checkで先ほど作成したステータスチェックを選択し、Add to Scenarioをクリックして追加します。

上記のように追加されます。

その後、シナリオの各ステップのペンアイコンをクリックして、攻撃の対象となるホストやコンテナを選択していく必要があります。 自身の環境に合わせて構成していきましょう。

最後にSave Scenarioをクリックして保存完了となります。

シナリオを実行してみる

更新したシナリオの画面上部にあるRun Scenarioをクリックしてシナリオを実行します。

ステータスチェックと攻撃が実行されていくことが画面上からもわかります。

Latencyの増加により、指定した要求タイムアウト以内に返ってこなかった場合などが起こってステータスチェックが失敗すると、シナリオも終了されます。

ステータスチェックが失敗の時の例)

最後に

パブリックからアクセスできないエンドポイントに対してのステータスチェックを作成し、Gremlinの攻撃を実行しました。 private network integrationsにより、内部システムに対してのチェック、Webhookが実行できるようになるので セキュリティ的に厳しくて実験ができなかった組織でもカオスエンジニアリングを実行できるようになるのではないでしょうか? Zabbixに攻撃の状態を送信したり、Jenkinsを実行してデプロイやテストを行ったりもできると思います。 内部システムの問題に出くわした時の対応策や回復方法を検討する良い機会になればと思います。