ビデオリサーチ公式テックブログ

ビデオリサーチ公式テックブログ

Docker版OWASP ZAPをCloud Runにデプロイしてみる

こんにちは、ビデオリサーチのオジサンです。
とある案件にて外部機関による本格的な脆弱性診断を受ける前に、試しにWebアプリケーションの脆弱性診断を実施したいという要望がありました。
そこで今回はIPAでも推奨しているオープンソースのWebアプリケーションの脆弱性診断ツールとして公開されているOWASP ZAPを使用してみることにしました。 このOWASP ZAPですが、OWASP TOP10と呼ばれる重大なセキュリティの診断、自動スキャン、手動スキャンに加え、プロキシによる通信の分析まで出来ます。
実行環境についてもWindows, LinuxMac、Dockerと複数用意されていますが、今回はDocker版OWASP ZAPを使用しました。 コンテナならGoogle CloudのCloud Runにデプロイしてみようということで、その手順をまとめてみました。


作業手順の流れ

今回はDocker版を利用しますので、下記の手順で作業を進めます。

  1. Dockerfileの用意
  2. コンテナイメージの作成
  3. ArtifactRegistoryへの登録
  4. Cloud Runにデプロイ
  5. おまけ:Compute Engineでも動かしてみる

1.Dockerfileの用意

公式のドキュメントにある記載の通り、Docker版を起動するだけなら2行で終わります。
以上。。。。

docker pull ghcr.io/zaproxy/zaproxy:stable
docker run -v $(pwd):/zap/wrk/:rw -t zaproxy/zap-stable zap.sh -cmd -autorun /zap/wrk/zap.yaml

今回はCloud Runで起動させることを想定し、公式のDocker版owapszapをベースにDockerfileを用意します。
ZAP Desktop GUIを起動するようにしたいので下記のようにしました。

FROM ghcr.io/zaproxy/zaproxy:stable
USER root
ENV TZ=Asia/Tokyo
RUN  apt-get update && \
     apt-get -y install fonts-noto-cjk
USER zap
EXPOSE 8080
EXPOSE 8090
CMD ["zap-webswing.sh"]

2.コンテナイメージの作成

用意したDockerfileをDockerイメージにビルドします。

docker build -t asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap/owaspzap-proxy:latest .

[PROJECT_ID]GCPのプロジェクトIDに置き換えてください。


3.ArtifactRegistoryへの登録

最初にArtifact Registryにowaspzapの名称でリポジトリを作成しておきます。
次に作成したイメージをGCPのArtifact Registryにプッシュします。

gcloud config set project [PROJECT_ID]
gcloud auth configure-docker
docker push asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap-proxy

[PROJECT_ID]GCPのプロジェクトIDに置き換えてください。

※Container Registryは、2025年3月18日以降提供終了となりますので、Artifact Registryを利用しましょう。


4.Cloud Runにデプロイ

Cloud Runにowaspzapをデプロイするには、以下のコマンドを実行します。

gcloud run deploy owasp-zap \
    --image asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap/owaspzap-proxy:latest \
    --platform managed \
    --region asia-northeast1 \
    --allow-unauthenticated \
    --memory 2Gi

パラメータ解説

  • --image: デプロイするコンテナイメージを指定。
  • --platform: Cloud Runのマネージドプラットフォームを使用。
  • --region: デプロイ先のリージョンを指定。
  • --allow-unauthenticated: 認証なしでアクセスを許可。
  • --memory: 割当メモリ量。

メモリは最低2GBぐらい必要なようです。1GBでは起動できませんでした。
今回はテスト的に起動を試したので、 --allow-unauthenticated を指定して起動確認をしました。
このままだと誰でもアクセスできてしまうので、本運用する際には --no-allow-unauthenticated を指定し、ロードバランサやCloudArmorを利用してIP制限等掛ける必要があるでしょう。
検査対象によってはvpc-connectorを用意し、VPC内の環境にアクセスできるようにすることも必要になると思います。
owaspzapのレポート等は/zap/wrkに出力されます。結果を残しておきたい場合は、CloudStorageにボリュームを作成しマウントしておくと良いでしょう。

以上でビルドからデプロイまでが完了しました。
デプロイしたCloud RunのURL https://起動したアドレス/zap/ にブラウザでアクセスするとowaspzapのWebSwing版画面が表示されるはずです。

※Dockerコンテナ内では8080ポートで起動しますが、自動的にポートマッピングされてます。


5.おまけ:ComputeEngineでも動かしてみる

owaspzapにはproxyとして利用する機能があります。こちらはデフォルトで8090ポートを使用します。
Cloud Runでは2つのポート番号を同時使用できないため、このままでは利用できません。
(リバースプロキシもコンテナ内に組み込めばなんとかなる気もしますが試してません)

proxyも使えるようにしたかったため、Compute Engineで動くようにしてみました。
せっかくなので今回用意したDockerfileを使用して起動させます。

Compute Engineの箱を用意するのは説明不要かと思いますので省略します。
※ e2-mediumでDebianを使用しました。

起動したCompute EngineにSSHでログインし、下記手順にて作業を行います。

5.1 Dockerのインストール

パッケージ情報を最新にし、 Dockerをインストールします。

sudo apt update
sudo apt install -y docker.io

5.2 Dockerサービスの起動

Dockerサービスを起動し、OS再起動時も自動起動するようにします。

sudo systemctl start docker
sudo systemctl enable docker

5.3 Dockerイメージのダウンロード

「3.ArtifactRegistoryへの登録」の手順まで実施済みであれば、リポジトリへのイメージ登録まで終わってますので、その前提でイメージのダウンロードを実施します。

gcloud auth configure-docker
docker pull asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap/owaspzap-proxy:latest

[PROJECT_ID]GCPのプロジェクトIDに置き換えてください。

5.4 Dockerコンテナの実行

Dockerコンテナを起動して、owaspzapを利用できるようにします。
--restart unless-stopped を指定することで、再起動しても自動起動するようにします。

docker run -d --name owaspzap-proxy --restart unless-stopped -p 8080:8080 -p 8090:8090 asia-northeast1-docker.pkg.dev/[PROJECT_ID]/owaspzap/owaspzap-proxy:latest

[PROJECT_ID]GCPのプロジェクトIDに置き換えてください。

ブラウザで、 https://Compute EngineのグローバルIPアドレス:8080/zap/ にアクセスするとWebSwing版画面が表示されます。
プロキシの設定でIPアドレスにCompute EngineのグローバルIPアドレスを指定し、ポート番号は8090を指定することで、プロキシとして使用できるようになります。


まとめ

Cloud Runを使用すると、簡単にデプロイ、実行でき、インフラ管理の負担を減らせて使った分のコストだけで済むので、制約はあるものの使い勝手が良いですね。良い時代になりました。
最後のおまけで記載したように、Compute Engineを採用する場合でも、Dockerコンテナを起動するようにすることで、簡単に起動させることができました。
何よりポータブルなのでAWSやローカル環境等でも使えます。

今回はインフラの話でしたが、オジサンのメインスキルは開発なので、機会があれば開発系の記事でも書いてみたいと思います。
最後まで読んでいただきありがとうございました!