Ctrlk
Changelog NotificationsAPIAikido login
For the complete documentation index, see llms.txt. This page is also available as Markdown.

内部アプリケーション向け Aikido Broker

Aikido Broker を使って、社内ネットワーク上に存在し、インターネットから到達できないアプリケーションをスキャンおよび監視します。

ブローカーはお使いのインフラ内で動作し、Aikido のリクエストを許可した内部 URL に転送します。Docker コンテナとして、または Helm チャートを使って Kubernetes 上にデプロイできます。

ブローカーを使うタイミング

会社ネットワーク内にのみ存在するアプリケーションやサービスに対するあらゆる Aikido スキャンでブローカーを使用します。たとえば以下です:

  • オンプレミスの GitLab やその他のローカルコードプラットフォームでのコードスキャン

  • プライベートまたはオンプレミスのコンテナレジストリでのコンテナスキャン

  • 社内アプリケーションに対する AI ペネトレーションテスト

  • 社内ドメインまたはサービスに対するフロントエンドおよび API テストスキャン

要件

Aikido Broker を実行するには以下が必要です:

  • Docker (20.10+) と Docker compose (1.29+) インストール済み

    • オプションで Kubernetes 1.19+

  • Aikido にスキャンさせたいアプリケーションへのネットワークアクセス

  • へのアウトバウンド HTTPS アクセス *.aikidobroker.com

  • 小さなコンテナを実行するのに十分な CPU（1コア）とメモリ（1 GB）

インストール

1

ブローカークライアントトークンを生成して設定します

以下に移動してください Broker Clients ページ そして新しいブローカークライアントシークレットを作成します。Client Secret は次の手順のために保存してください。

このページにアクセスできない場合は、Aikido ダッシュボードのサポートにお問い合わせください

2

リソース（内部 URL）を追加

Aikido がブローカー経由でアクセスを許可される内部 URL を定義します。

これらは Aikido にスキャンさせたいアプリケーションと API です。たとえば:

  • https://api.internal.corp.local

  • http://service-a.internal:8080

  • https://10.0.5.20

これらのリソースは、一覧から既存のブローカーを選択するか、新規作成することで Aikido UI で管理できます。

リソースを保存すると、各リソースに固有の Broker URL が生成されます。Aikido では元の URL の代わりにこの Broker URL を使用してください。

3

ブローカーを起動する

Aikido にアクセスさせたい内部アプリケーションに到達できるマシンでブローカーサービスを起動します。次の値を必ず置き換えてください: CLIENT_SECRET の値を Clients ページで生成したものに置き換えてください。

ブローカーが期待どおりに実行されているかは次のコマンドで確認できます docker logs aikido-broker

Windows と Mac OS では、次を使用してください: host.docker.internal の代わりに localhost または 127.0.0.1 ローカルサービスに接続するためです。

Aikido では以下を提供しています: ブローカーをデプロイするための Helm チャート Kubernetes 環境内で。

設定する 追加パラメータ 次を使って values.yaml ファイルを使用し、次のコマンドで実行します: helm install broker-client aikido/broker-client -f values.yaml

ブローカーが実行されているかは次で確認できます kubectl logs -n aikido -l app.kubernetes.io/name=broker-client

4

ブローカーが安定するまで待機する

Aikido に接続して登録されるまで約 30 秒待ちます。

起動して接続されると、Aikido は設定した内部リソースにアクセスを開始できます。

設定

ブローカーが内部サービスへ到達する方法やホスト名の解決方法を制御できます。

ALLOWED_INTERNAL_SUBNETS

ブローカーが呼び出しを許可される CIDR 範囲の一覧です。

これを使って以下を行います:

  • ブローカーを特定の内部ネットワークに限定する

  • 関連のないインフラへの誤アクセスを防ぐ

例:

DNS_SERVERS

ブローカーが内部ホスト名を解決するために使用する DNS サーバーの任意の一覧です。

これを使うのは以下の場合です:

  • 社内 DNS ゾーンがある場合（たとえば *.corp.local）

  • 内部サービスが公開 DNS で解決できない場合

例:

カスタム CA 向けの NODE_EXTRA_CA_CERTS（内部 TLS）

内部サービスがプライベート CA で署名された証明書を使用している場合、その CA を提供してください。ブローカーが TLS を正しく検証できるようになります。

典型的なユースケース:

  • 自己署名証明書を使用する内部サービス

  • サービス間暗号化のための内部 PKI

設定方法はデプロイ環境によって異なりますが、概要は次のとおりです:

  • カスタム CA ファイルをブローカーコンテナにマウントする

  • 提供されている環境変数または設定オプションを使って、ブローカーにその CA ファイルを指定する

カスタム証明書を追加する場合、ブローカーはコンテナ内でそれらを読み取れる必要があります。追加の -v フラグで証明書フォルダをコンテナにマウントし、 NODE_EXTRA_CA_CERTS 変数でブローカーに証明書ファイルを指定してください。短い例を示します:

MTLS_PEM_PATH と MTLS_CA_PATH

内部サービスが mTLS 証明書を使用している場合、この 2 つの設定を使用できます。mTLS 証明書が自己署名でない場合、CA パスは不要です。

カスタム証明書を追加する場合、ブローカーはコンテナ内でそれらを読み取れる必要があります。追加の -v フラグで証明書フォルダをコンテナにマウントし、 MTLS_PEM_PATH と MTLS_CA_PATH 変数です。短い例を示します:

プロキシ

社内ネットワークで特定のホストやインターネットに到達するためにプロキシが必要な場合、ブローカーをそのプロキシを使用するように設定します。

これは次の場合に便利です:

  • ネットワークの外向きトラフィックが HTTP または HTTPS プロキシを経由しなければならない場合

  • 内部セグメントが中央プロキシ経由でのみ到達可能な場合

ブローカーのプロキシ設定または環境変数でプロキシ URL を設定します: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY

クライアントを設定して、特定ホストへのリクエストがプロキシを経由しないようにすることもできます。次の NO_PROXY 環境変数（-e NO_PROXY=noproxy.dev,my-domain.internal）。値は、プロキシをバイパスするホストをカンマ区切りで並べた一覧にしてください。

NODE_TLS_REJECT_UNAUTHORIZED

自己署名 TLS 証明書が原因でブローカーに問題が続く場合は、'NODE_TLS_REJECT_UNAUTHORIZED' 環境変数に 0 を指定して TLS 検証を無効にするようブローカーに指示できます:

FORCE_WEBSOCKET と FORCE_POLLING

ブローカーはデフォルトで wss トラフィックで動作し、失敗するとロングポーリングにフォールバックします。ネットワーク要件に応じて、これらの環境変数を使ってブローカーをどちらか一方に固定できます。

Aikido で Broker リソースを使う方法

ブローカーをインストールし、内部 URL をリソースとして追加すると、ブローカーは各リソースに固有の Aikido URL を生成します。これらの URL は、Aikido がブローカー経由で内部サービスに到達するための安全な入口として機能します。

すべての Aikido スキャンでこれらの Aikido Broker URL を使用してください。

重要なのは次の理由です:

  • Aikido は内部ネットワークに直接到達できない

  • ブローカーは Aikido URL を内部サービスにマッピングします

  • 内部 URL を直接使用しても機能しません

例

Domains and API スキャン（フロントエンドスキャン）を設定する際は、内部アドレスではなく Broker URL を使用してください。

たとえば:

トラブルシューティング

トラブルシューティングコマンドを実行

まずこのコマンドを実行してください。ブローカー設定に対する簡易ヘルスチェック（DNS、接続性、その他の一般的な失敗ポイント）を実行し、通常はすぐに根本原因を特定できます。

ログを確認

Docker ログで警告メッセージとエラーを確認してください:

エラー: 他のクライアントのリソースにアクセスできません

キャッシュされたクライアント ID がもはや一致しません CLIENT_SECRET 組織に。次を削除してください config/client_id ファイルを削除して再試行してください。

ブローカーをアンインストールする

まずスキャンから Broker URL を削除してください。Broker URL を指したままのスキャンは、ブローカーがなくなると失敗します。

その後、ブローカーを停止して削除します:

証明書や設定フォルダをコンテナにマウントしていた場合、それらのファイルはホスト上に残ります。不要になったら手動で削除してください。

ネームスペースがブローカー専用に作成された場合は、それも削除できます:

最後に、以下に移動して Broker Clients ページ クライアントを削除してください。これにより client secret が失効し、そのリソースと Broker URL が削除されます。

最終更新

役に立ちましたか？