コンテナイメージの脆弱性スキャン
アプリケーションに脆弱性が含まれないようにするのを開発者にゆだねるのではなく、自動的にスキャンを行うしくみを整備するのがよいでしょう。
ローカル環境でのスキャン
デスクトップで実行できるスキャナーを使用すると、個々の開発者は開発マシン上のローカルイメージをスキャンして問題を見つけることができ、ソースコードリポジトリにプッシュする前に問題を修正できます。
ビルド環境でのスキャン
ビルドパイプラインの中でイメージスキャンを組み込んでください。もしスキャンで深刻な脆弱性が明らかになった場合は、ビルドを失敗させてデプロイされないように制御できます。
コンテナレジストリでのスキャン
コンテナレジストリ上に格納されたイメージをスキャンします。例えば、Azureの場合、Microsoft Defender for Containersを使うとレジストリにプッシュしたイメージをスキャンできるだけでなく、過去30日以内にプルされたイメージもスキャンされます。
CIS Benchmarksは、米国のCIS(Center For Internet Security)が発行しているシステムを安全に構成するための構成基準およびベストプラクティスが記載されたガイドラインであり、下記のサイトで公開されています。
CIS Benchmarks https://www.cisecurity.org/cis-benchmarks/
CIS(Center for Internet Security)は政府機関と、企業、学術機関などが協力しセキュリティ標準化に取り組む目的で2000年に設立された団体の略称です。
本稿では、すべてを紹介しきれなかった脆弱性・対策も含めて、セキュリティベストプラクティスに則ったチェックができる代表的なスキャナーを紹介します。
dockle
dockleはGoodwith社が中心となっている開発しているOSSのプロダクトです。dockleを利用するとイメージがベストプラクティスに沿って実装されているかを検査できます。
CISDockerBenchmark_v1.3.1の4章にContainer Images and Build File Configurationが定められており、DockleでCIS Benchmarkにもとづくチェック項目はこのガイドラインに対応します。
dockleによって検査できるのは下記の項目です。
# | チェック項目 | Dockle |
---|---|---|
1 | コンテナ用のユーザーを作る | ✔ |
2 | 信頼できるコンテナのベースイメージを利用する | ▲ |
3 | 必要ないパッケージをコンテナに入れない | - |
4 | 最新のセキュリティパッチを取り込むためにイメージを再ビルドする | - |
5 | Content trust for Docker(電子署名を利用したイメージの改ざんチェック)を有効にする | ✔ |
6 | DockerFile内にHealthチェック記載する | ✔ |
7 | OSのパッケージマネージャーの更新をDockerfile内の1行で実行しない(キャッシュされるため) | ✔ |
8 | イメージ内のsetuidとsetgidパーミッションを削除する(特権昇格の防止) | ✔ |
9 | ADDの代わりにCOPYを利用する(ADDだと圧縮ファイルの展開やリモートファイルの取得が行われる) | ✔ |
10 | Dockerfileの中にsecretを保持しない | ✔ |
11 | 検証されたパッケージのみをインストールする | - |
Dockle独自のチェック項目は以下の通りです。
# | チェック項目 |
---|---|
12 | nullパスワードのユーザーを利用しない |
13 | UIDが重複するユーザーやGIDが重複するグループが存在しないか |
14 | sudoコマンドを利用しない |
15 | センシティブなディレクトリをmountしない |
16 | apt-get upgrade, apk upgrade, dist-upgradeをさける |
17 | apk addを利用する際に--no-cacheを利用する |
18 | apt-getのキャッシュをクリアする |
19 | latestタグを避ける |
trivy
trivyはAqua Security社が中心となっている開発しているOSSのプロダクトです。 trivyを使うと脆弱性データベースを元にOSやプログラム言語のパッケージの脆弱性を検査できます。
2022-03-29時点で対応するのは以下です。
項目 | 対応する検査対象 |
---|---|
OS | Alpine, Red Hat Universal Base Image, Red Hat Enterprise Linux, CentOS, AlmaLinux, Rocky Linux, CBL-Mariner, Oracle Linux, Debian, Ubuntu, Amazon Linux, openSUSE Leap, SUSE Enterprise Linux, Photon OS and Distroless |
プログラミング言語 | Java, .NET, Go, Rust, Node.js, PHP, Python, Ruby |
まとめ
コンテナアプリケーションの観点では、アプリケーションの脆弱性を減らすための工夫やシークレットの管理、適切なアクセス権限を設定することでコンテナブレイクアウトを防ぐための方法について説明しました。さらに脆弱性チェックをCI/CDパイプラインに組み込み自動化することで、ベストプラクティスに則ったアプリケーション開発ができるようになります。
コンテナアプリケーションの脅威を正しく知り、開発の早い段階で適切な対応を取ることで、セキュリティ事故を未然に防ぐことができます。
著者プロフィール
NRIデジタル株式会社 湯川勇太(ゆかわ ゆうた)
前職で大手家電量販店のECモールの立ち上げとECサイトの刷新プロジェクトを経験。NRI入社後は製造業の商品検索システムを担当した。現在は大手物流企業向けの基幹システムの方式設計や技術検証、トラブル対応を行っている。
Microsoft 阿佐 志保 (あさ しほ)
金融系シンクタンク で 都市銀⾏情報系基盤システム統廃合、証券バックオフィスシステム共通 ミドルウエア 開発などの金融案件を経験。出産で離職後 Linux やオープンソースソフトウエアなどを独学で勉強し Docker/Kubernetesに関する書籍を執筆。現在は日本マイクロソフト株式会社で、お客様向けにAzureの技術支援を行っています。