Deadshot は、各 diff 行を既知のシークレット式のセットと照合することで、PR を介してシークレットの導入を探すプル リクエスト スキャナーです。
サービスは以下を担当します。
サービスは次のことを行いません:
Deadshot は Flask-Celery-Redis マルチコンテナ アプリケーションであり、Github アプリとしてインストールされ、Github アプリがインストールされているリポジトリのメイン ブランチに対して作成されたすべてのプル リクエストで実行されます。
Flask コンテナは、blueprints.py で定義された API ルートを公開することにより、サービスのエントリ ポイントになります。 API ルートでプル リクエストのペイロードが受信されると、サービスはそのペイロードを Redis キューに転送し、Celery コンテナがプル リクエストの差分を取得してスキャンできるようにします。セロリコンテナは、指定されたシークレット正規表現をスキャンした後、PR にコメントし、Slack がセキュリティチームチャネルに通知するか、チームがフォローアップするための JIRA チケットを作成します。 Github アプリは、Flask API URL とペイロード SHA チェックサムの生成に使用される共有秘密を使用して構成されます。
API URL を設定する方法の 1 つは、このコードをホストにデプロイし、アプリケーション ロード バランサーをこのホストに割り当てることです。
注: アプリを作成するときは、Deadshot コンテナーをデプロイするホスト用の DNS の準備ができていることと、Webhook シークレットの安全なシークレット文字列があることを確認してください。
Github 管理者は、Deadshot アプリケーションを実行またはデプロイする前に、Github 上に Github アプリケーションを作成してインストールする必要があります。 Github アプリの作成について詳しくは、このガイドをお読みください。
アプリ名: Deadshot (すべて小文字。サービスは PR に対して作成した以前のコメントを取得するためにこの名前を使用するため、これは重要です)
Webhook URL: http(s)://your-hosted-deadshot-dns/api/v1/deadshot-webhook
これをローカルでテストするには、Github アプリの Webhook セクションにフィードする ngrok エンドポイントを作成します。
このアプリケーションが動作するには、Github アプリの権限ページで次の権限とサブスクリプションを有効にする必要があります。 リポジトリの権限:
他のすべての権限は、デフォルト値の「アクセスなし」のまま変更されません。
イベントを購読する:
最後に「GitHub アプリの作成」をクリックします。アプリの作成が成功したら、アプリの Web ページの上部セクションにある「秘密キーの生成」リンクをクリックします。
秘密キーが生成されたら、安全な場所に保管します。この生成された秘密キーは、アプリの対話用のセッション トークンを生成するために使用されるデータの 1 つです。
秘密キーを生成した後、監視するすべての組織にアプリをインストールします。
これは、/bin/run.sh 経由で 3 つのコンテナ (Flask、Celery、Redis) すべてを起動するように設計されたマルチコンテナ アプリケーションです。そのため、Dockerfile イメージを実行すると、アプリケーション全体が起動するはずです。
以下の 3 つの変数は、ユーザーが指定した単一の文字列値です。
以下の環境変数は、資格情報が含まれるファイルへのパスを読み込みます。アプリケーションを実行する前に、ここで入手可能なファイルに json ファイルのキー値をロードします。
注: JSON シークレット ファイルの場所を移動しない場合は、Dockerfile または docker-compose.yaml にすでに存在する上記の 3 つの環境変数の値を更新する必要はありません。
このコマンドは、docker-compose.yaml を使用してすべてのコンテナーを起動します。以下のコマンドを実行する前に、configuration/environment/localdev.env を組織に関連する値で更新してください。
make serveこれを完了し、アプリケーションの提供に Dockerfile を使用する予定がない場合は、「サーバーのヘルスチェック」セクションに進んでください。
Dockerfile を構築して実行するには 2 つの方法があります。リポジトリには 4 つの Dockerfile が存在します。そのうちの 3 つは、このサービスが動作するために必要なコンテナごとに個別のイメージを生成するために使用されます。4 つ目は、コンテナーを起動するために使用できるイメージを作成するための Dockerfile セットアップです。指定された DEADSHOT_RUN_MODE 環境変数値 (API またはワーカー) に応じて、Flask アプリケーションまたはセロリ ワーカー 以下のいずれかの手順を実行するには、リポジトリのルート フォルダーに存在する必要があります
注: Dockerfile.api ファイルと Dockerfile.celery ファイルの環境変数が更新されていることを確認してください。
このステップに関連する Dockerfile が 3 つあります。 Dockerfile.api、Dockerfile.celery、および Dockerfile.redis
docker build -f Dockerfile.api -t deadshot-api:<version> .
docker build -f Dockerfile.celery -t deadshot-worker:<version> .
docker build -f Dockerfile.redis -t deadshot-redis:<version> .
前の手順で構築された 3 つのイメージはすべて別のネットワークで実行されるため、相互に通信することができません。コンテナ間通信を有効にするには、コンテナ ネットワークにコンテナを追加する必要があります。
docker network create deadshot-network
作成したネットワークを使用してイメージを次の順序で実行します。 Redis コンテナーを開始します。
docker run --net deadshot-network --name redis deadshot-redis:<version>
セロリコンテナを開始します。
docker run --net deadshot-network deadshot-worker:<version>
Flask API コンテナを開始します。
docker run --net deadshot-network -p 9001:9001 deadshot-api:<version>
DEADSHOT_RUN_MODE 環境変数に基づいて API および celery ワーカーを起動するための単一の Docker イメージを構築するには
make buildこのコマンドは、サービスに必要な Redis イメージも作成します
ビルドされたイメージが環境変数 DEADSHOT_RUN_MODE=api で実行される場合、Flask アプリケーションが起動します。イメージが環境変数 DEADSHOT_RUN_MODE=worker で実行される場合、セロリワーカーが開始されます。
API がリクエストを受信する準備ができたので、ブラウザでhttp://localhost:9001/api/v1/heartbeatに移動すると、有効な応答が返されるか、curl を実行できます。
curl localhost:9001/api/v1/healthcheckどちらの場合も次のメッセージが表示されるはずです: {"healthcheck": "ready"}
プル リクエスト用の Github アプリの Webhook ペイロードがある場合は、次のcurl コマンドをローカルで実行してアプリケーションをテストできます。
curl -X POST -H " content-type: application/json " -H " X-GitHub-Enterprise-Host: github.mockcompany.com " -H " X-Hub-Signature: sha1=85df4936c6396c149be94144befab41168149840 " -H " X-GitHub-Event: pull_request " -d @tests/fixtures/good_pr.json http://localhost:9001/api/v1/deadshot-webhookツールで他の種類のシークレットを監視する場合は、正規表現を regex.json ファイルに追加します。
注: エントロピー チェック フラグを使用すると、正規表現の一致に加えて、高エントロピーの検出結果を探すことができます。
現時点では、Deadshot は Github Enterprise でのみテストされていますが、Github クラウドでも同様に動作するはずです。
