これはSnykの友人からのゲストブログです。 もともと ここに登場しました。
本日、人気の高いDockerとSnykの脆弱性チートシートのアップデートを発表できることを嬉しく思います。 2020年以降、何百万人ものMacOSおよびWindows開発者が、日常の開発の一環として、docker scanを使用してローカル環境でコンテナを分析できるようになりました。 この機能により、チームはアクティブな開発時にフィードバックを提供し、サイクルを高速化できます。
更新されたチートシートには、 Snyk と Dockerによる他の多くの投稿でカバーされているLog4jの脆弱性に関する情報と焦点が含まれています。 この投稿では、チートシートと強化されたガイダンスのいくつかの概要を説明します。
1. コンテナイメージをスキャンする
画像のスキャンはdocker scanを実行するのと同じくらい簡単で、開発中に画像をスキャンする習慣を身に付けることを強くお勧めします。 docker scanを使用すると、イメージの作成時にイメージのフィードバックをすばやく取得できるだけでなく、スキャン操作の結果を使用してタスクをゲートすることもできます。これは、フラグを使用してパイプラインのステップを失敗させる場合に特に役立ちます。
docker scan <imagename>公開されている画像の一般的なdocker scanを示すために使用する例を次に示します。 プロセスの一部として、パブリックイメージの脆弱性をスキャンする必要があります。 これは、Docker Hub でホストされているイメージの内容を調べる場合に便利です。
$ docker scan alpine:3.15.0 --severity high
Testing alpine:3.15.0...
Organization: atlassian-bitbucket
Package manager: apk
Project name: docker-image|alpine
Docker image: alpine:3.15.0
Platform: linux/amd64
Base image: alpine:3.15.0
Licenses: enabled
✔ Tested 14 dependencies for known issues, no vulnerable paths found.
According to our scan, you are currently using the most secure version of the selected base imageLog4jへの最近の関心を考慮して、脆弱性(CVE-2021-44228およびCVE-2021-45046)を特にスキャンするために使用するコマンドを次に示します。
snyk container test wavefronthq/proxy:9.2 --app-vulns
docker scan test wavefronthq/proxy:9.2 --app-vulns2.イメージで公式の最新のJDKを使用する
JDKバージョンには多くのオプションがあり、サポートされている最新の修正に追いつくために公式バージョンを利用することをお勧めします。 利用可能なバリエーションはたくさんあり、チームはカスタムやバリエーションを使用する必要があると感じるかもしれません。 また、これらのバージョンを常に把握する必要があるという追加の負担と責任も理解します。
最新のJDKリビジョンを使用することは、セキュリティ修正との同期を維持することを意味し、チーム全体がより安定した主流のバージョンに依存することが容易になります。
一部の公式バージョンは、理解しやすいタグに依存しています。 たとえば、openjdk イメージには、言語サポートの異なるバージョンを表す異なるタグがあります。 JDK のバージョン 11 は、openjdk:11でサポートされています。
3. JDKをアップグレードするだけでは不十分
Log4Shellの脆弱性の修正サイクルは反復的なプロセスであり、最初の修正バージョンの後に追加の修正が続きました。 影響を受けるLog4jバージョンには、2.14、2.15、2.17、およびいくつかのマイナーバージョンが含まれていました。 これは、人々が脆弱性を見つけてパッチを適用すると、より多くの人々がコードをテストおよび調査して、より多くの脆弱性を発見したためです。
初期の考えの1つは、根本的な原因に対処するために機能する新しいライブラリを取得するためにJDKを更新することでした。 後で、人々はあなたも設定を変更する必要があることに気づきました
com.sun.jndi.ldap.object.trustURLCodebase falseに.
この設定には、そもそも脆弱性の根本的な原因であったURLの使用を防ぐ効果があります。 この値が本当に必要な場合にのみ true に設定し、ほとんどのアプリケーションではそうしない可能性があります。
4.ドッカーハブでスキャンされた画像を特定します
Docker は Snyk と緊密に連携して結果を Docker Hub に統合し、できるだけ多くのユーザーが Log4j の結果をすばやく簡単に確認できるようにしました。 その結果、画像に脆弱性が含まれていることが判明したかどうかを示すインライン レポートが作成されます。 これは、ステータスを確認するための優れた方法を提供するため、ユーザーにとって大きな利点です。
Docker のスキャン結果が DockerHub に含まれるようになりました。 これにより、エンドユーザーは、Log4Shell CVE-2021-44228および CVE-2021-45046 についてスキャンされた イメージと、脆弱性が検出されたかどうかを簡単に識別できます。
たとえば、これはタグにあるインジケーターです。
別のビューには、 LOG4SHELL が検出されなかったイメージの緑色のバッジ、検出されたイメージの赤いバッジ、検出された脆弱性の数などの詳細が表示されます。
5.ドッカーデスクトップ4.3.1+を使用する docker scan 0.11.0+
Docker Desktop は、お使いのバージョンが古くなっているかどうかを既に通知しており、最新バージョンには Log4Shell の脆弱性を最適に検出するための更新プログラムが含まれています。 Docker Desktop 4.3.1 および docker scan 0.11.0 以降、これらのコンポーネントは MacOS および Windows ユーザー向けに最新の状態になっています。 Dockerデスクトップの最新バージョンは、こちらのリンクから入手できます。
Linux ユーザーは docker-ce でサポートされており、アップグレード パスが異なります。 Linux ユーザー向けの詳細については、この Docker Log4j ブログを参照してください。
6.ルートとして実行しないでください
長年にわたり、私たちは経験に基づいて知識を蓄積してきました。 注目すべきナゲットは、「ルートとして実行しないでください」です。 多くの人は、既定で実行することからコンテナーの旅を開始しますが、その影響を考慮することは起こりません。 過去のデプロイからの適切なキャリーオーバーは、サービス アカウントで実行することです。 以前は、IT/運用担当者がサービスのユーザーをプロビジョニングし、そのユーザーとしてそのサービスを実行していました。
コンテナーでは、この操作では、Linux 環境でグループとユーザーの両方を作成する必要があります。 コマンドは、次の組み合わせです。
RUN addgroup ... \
adduser ... \
chmod and chown
USERLinux ユーザーは、アプリケーションのアカウントを作成するための addgroup コマンドと adduser コマンドに精通しています。chmod コマンドと chown コマンドは、ディレクトリで実行する権限を持つユーザーに制限を設定するために存在します。これらのコマンドは、実行中のコンテナを保護するためのガードレールを確立します。 アプリケーションがrootとして実行され、侵害された場合、攻撃者はシステム全体を利用できます。
詳細については、Kubernetes セキュリティ コンテキストのブログ投稿のポイント #1 と、さまざまなsecurityContext設定とその使用方法を確認するチートシートを参照してください。
7.読み取り専用のルートファイルシステムを使用する
この単純な変更は、アプリケーション全体にとって大きなメリットがあります。 アプリケーションは、限られた数のフォルダーにファイルを書き込む可能性があります。 したがって、他のフォルダーは読み取り専用に設定することでメリットが得られます。 キー フォルダーを読み取り専用に設定すると、攻撃者のオプションは一時ファイルやスクリプトを作成する場所が制限されます。
たとえば、API サービスを提供するアプリケーションは、通常、情報の導管と見なされ、多くのデータを格納しません。 データをディスクに永続化するための要件は限られているため、読み取り専用のルートファイルシステムを利用する絶好の機会があります。
1 つのオプションは、読み取り専用マウントを利用することです。 開発中は、開発チームに読み取り専用ボリュームを–read-onlyでマウントし、実行中のコンテナーがまだ機能することを確認することをお勧めします。 ローカルで開発する場合、チームはdocker runコマンドを簡単に反復処理して、読み取り専用ファイルシステムのより最適なセットアップを見つけることができます。
チームがローカルの読み取り専用ボリュームマウントのソリューションを見つけたら、次のステップは、本番環境で同じ機能を複製することです。 通常、ボリュームはオーケストレーターによって異なる方法で管理され、優先するオーケストレーターには、同様の読み取り専用マウントを構成するオプションがあります。
Kubernetes クイック ヒット: SecurityContext を使用して読み取り専用ファイル システムでコンテナーを実行する ビデオで説明を、前述の チート シート のポイント #7 で Kubernetes の例をご覧ください。
8. Log4jのバージョンを最新バージョンにアップグレードします
Log4jの脆弱性が最初に検出されたとき、いくつかの修正が立て続けにリリースされました。 チームが少なくとも2.17.1を使用することをお勧めします。
Snyk で Git リポジトリをスキャンすると、Log4J の脆弱性があるかどうかを示す結果が表示され、プルリクエストを開いて修復するオプションがあります。 これは、アプリケーションを更新するための簡単で自動的な方法です。
Log4jライブラリを直接使用している場合は、ビルドファイル(通常はgradleまたはmavenプロジェクト)の依存関係を更新する必要があります。 依存関係リストで、バージョンを 2.17.1 以降に更新します。
ただし、推移的な依存関係がある場合は、古いlog4jバージョンを取り込むライブラリを更新する必要があります。
Maven では、次のようなコマンドを実行して、依存関係の更新を見つけることができます。
mvn versions:display-dependency-updates9. コンテナーを特権モードで実行しない
開発チームは、コンテナーを特権モードで実行して、アイデアや実験をテストしたり、トラブルシューティングの一環として実行したりできる場合があります。 特権モードで実行すると、root 権限と機能が付与されます。
Docker のこの ドキュメント では、特権モードで使用できる機能について説明します。 チームが特権モードで実行する必要があると感じた場合は、機能を制限するように促します。
ほとんどのアプリケーションは実際には昇格された特権を必要とせず、docker run --privileged コマンドで始まるため、通常、オーケストレーターで動作させるには追加の作業が必要です。
同じ Kubernetes クイック ヒット ビデオ を確認して、コンテキストと ポイント #5 を確認することをお勧めします。
10.コンテナの設置面積を最小限に抑える
ほとんどの開発チームは、コードが機能し、リソースが効率的であるように感じるため、たまたまコンパクトであるときにそれを気に入っています。 コンテナ開発でも、同じ考え方から恩恵を受けることができます。 軽量コンテナを出荷する場合、全体的なサイズと速度だけでなく、セキュリティなど、いくつかの要因で一般的に全体的に優れています。
アプリケーションがコンテナーにcurlまたはwget存在する必要がない場合は、削除する必要があります。 攻撃者がコンテナでコマンドを実行できる新しい脆弱性がある場合は、システムでアクセスを有効にするために使用できるオプションを制限する必要があります。 その未使用でありながらまだ存在するwgetは、攻撃者が実行中のスクリプトをシステムに取り込むためのお気に入りの方法である可能性があります。
Log4Shellの脆弱性は、攻撃者がシステムのほぼどこにでもお気に入りのコードを挿入できるようにするタイプの脆弱性です。 さまざまな例には、独自の意味を持つある種のコードを実行するためのJavaスニペットが含まれています。 しかし、攻撃者がスクリプトの武器を持っている場合、攻撃者はシステムのファイルシステムにファイルを作成する方法を見つけようとします。
お気をつけて!
Log4Shellなどのソフトウェアの脆弱性から身を守るためのヒントと説明をいくつか紹介しました。 より多くのヒントを組み込むほど、既存および将来の脆弱性に対処する可能性が高くなります。 これらのヒントを習慣にし始めると、あなたとあなたのチームはより良いフィードバックサイクルを持つことができます。
フィードバック
「DockerコンテナをLog0Shellから安全に保つための10のヒント」に関する4つの考え