大きなスキャンファイルのアップロードサイズ制限 (Pro)
大きなスキャンファイルは、リクエスト経路上の複数の異なる箇所にある制限のいずれかによって拒否されることがあり、表示されるエラーによってどの制限に達したかがわかります。このページでは、それらの制限がどこにあるか、そしてセルフホスト型デプロイでそれらを引き上げる方法について説明します。
どの制限に達しているか
| 表示される内容 | 発生元 |
|---|---|
装飾のない、DefectDojo のページを伴わない単純な 413 Request Entity Too Large | ingress コントローラーが、リクエストがアプリケーションに到達する前に拒否した |
Report file is too large. Maximum supported size is N MB | DefectDojo 自身が報告するアプリケーション側の制限 |
| アップロードがすぐに拒否されるのではなく、しばらく実行された後で失敗する | サイズ制限ではなくタイムアウト |
外側から内側に向かって対応してください。ingress コントローラーが先にリクエストを拒否している場合、アプリケーション側の制限を引き上げても意味がありません。
アプリケーション側の制限
DefectDojo は独自にスキャンファイルの最大サイズを設定しており、それを超えるファイルは現在の制限値を示すメッセージとともに拒否されます。デフォルトは 100 MB です。
Helm チャートでは、values 内で次のように設定します。
dojo:
scanMaxFileSize: 100Docker Compose デプロイの場合は、代わりに DD_SCAN_FILE_MAX_SIZE をメガバイト単位で設定してください。
ingress側の制限
これは、リクエストがアプリケーションに到達しないために、DefectDojo のスタイルが適用されない単純な 413 が発生する原因です。
このチャートは ingress にリクエストボディの上限を設定しており、デフォルトは 2400 MB です。
django:
ingress:
maxBodySize: "2400m"この値は nginx.ingress.kubernetes.io/proxy-body-size アノテーションとして出力されます。汎用の Kubernetes だけでなく、すべてのプラットフォームで出力されます。これは、マネージドプラットフォームの手前で nginx ingress コントローラーが使われることが多いためです。空文字列を設定するとこのアノテーションは出力されなくなります。また、この設定にはデフォルトで有効になっている django.ingress.platformAnnotations.enabled が必要です。
nginx 以外のコントローラーはこのアノテーションを無視するため、それらの場合は代わりにコントローラー自身の仕組みを使って制限を引き上げてください。
| プラットフォームのデフォルトコントローラー | 制限の設定場所 |
|---|---|
| AWS Load Balancer Controller を使用する EKS | ALB の設定 |
| GCE ingress コントローラーを使用する GKE | ロードバランサーの設定 |
| Application Gateway を使用する AKS | Application Gateway のリクエストボディ制限 |
| OpenShift Route | ルーター上の HAProxy tuningOptions |
nginx がマネージドプラットフォームの手前にある場合のタイムアウト
このチャートは、read・send・connect それぞれ 1800 秒という余裕のある nginx プロキシタイムアウトと、プロキシバッファリングの無効化を出力します。これらのアノテーションは、プラットフォームが汎用の Kubernetes である場合にのみ出力されます。EKS、GKE、AKS、OpenShift では、代わりにそれぞれのプラットフォーム独自のアノテーションが出力されます。これは、そのプラットフォームのデフォルトコントローラーがそちらを読み取るためです。
これは、これらのプラットフォームのいずれかで nginx ingress コントローラーを実行している場合に重要です。ボディサイズのアノテーションはすべての環境で出力されるため得られますが、タイムアウトのアノテーションは得られません。その結果、大きなアップロードがサイズチェックを通過しても、コントローラーのデフォルトタイムアウトによって途中で打ち切られることがあります。これが上の表の 3 行目に相当するケースです。その場合は、タイムアウトを自分で設定してください。
django:
ingress:
annotations:
nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"
nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"インポートルートの制限
Kubernetes デプロイでは、スキャンのインポートは専用の Pod を通じて実行され、インポートルートの手前にある nginx には独自のボディサイズ上限があります。これは固定値ではなく、他の値から導出されます。
django:
uwsgiImport:
maxBodySizeMb: nullnull のままにしておくと、dojo.scanMaxFileSize に 5 MB(マルチパートエンコーディングのオーバーヘッドを見込んだ余裕分)を加えた値として計算されます。そのため、アプリケーション側の制限を引き上げれば、この値も連動して引き上げられ、ほとんどのデプロイではこの値を設定する必要はありません。導出された値を上書きしたい場合にのみ、整数値を設定してください。
Docker Compose デプロイ
Compose デプロイには ingress コントローラーがないため、ingress 側の制限は適用されません。デプロイに同梱されている nginx はリクエストボディを 800 MB に制限しており、これが実質的な上限になります。そして、他の環境と同様に、その上にアプリケーション側の制限が適用されます。
nginx の上限を引き上げるには、デプロイに同梱されているファイルを変更する必要がありますが、これらのファイルはカスタマイズ用ディレクトリのように保持されるのではなく、アップグレード時に置き換えられます。変更が次回のアップグレードで消えてしまわないよう、変更する前にサポートまでご連絡ください。
ご質問・サポートについて
症状に対応する制限を引き上げてもアップロードが失敗する場合は、クライアントが受け取ったレスポンスと、その試行に関する nginx またはコントローラーのログを収集したうえで、までご連絡ください。