Docker公式イメージは、 Docker Hubでホストされている Dockerリポジトリのキュレーションされたセットであり、一般的な言語ランタイムとフレームワーク、クラウドファーストユーティリティ、データストア、Linuxディストリビューション用に事前設定された幅広いイメージを提供します。 これらのイメージは維持および精査され、セキュリティ、ユーザビリティ、およびバージョン管理のベスト プラクティスを満たしていることが確認されるため、開発者はさまざまな環境で一貫してアプリケーションをデプロイおよび実行しやすくなります。
Dockerオフィシャルイメージは、ソフトウェアサプライチェーンとオープンソースソフトウェアの両方のセキュリティに対するDockerの取り組みの重要な要素です。 Docker Official Images には、直接使用したり、独自のイメージを構築する際のベースイメージとして使用したりできる何千ものイメージが用意されています。 たとえば、Alpine Linux、NGINX、Ubuntu、PostgreSQL、Python、Node.js用のDocker公式イメージがあります。Docker Hubにアクセスして、現在利用可能なDocker公式イメージを検索してください。
このブログ記事では、 Dockerオフィシャルイメージ に関するよくある3つの誤解を取り上げ、ソフトウェアサプライチェーンの保護に役立つ7つの方法について概説します。
Docker公式イメージに関するよくある誤解3
Docker Official Images は 10 年以上前から存在し、何十億回も使用されてきましたが、やや誤解されています。 Dockerの公式イメージを「所有」しているのは誰ですか? これらすべてのタグには何がありますか? Docker公式イメージをどのように使用する必要がありますか? よくある誤解をいくつか取り上げてみましょう。
誤解 1:Dockerの公式イメージはDockerによって制御されています
Docker公式イメージは、アップストリームのメンテナー、コミュニティのボランティア、Dockerエンジニアのパートナーシップによって維持されています。 外部の開発者がDocker公式イメージの大部分をDockerfileで管理し、Dockerエンジニアが洞察とレビューを提供して、Docker公式イメージカタログ全体のベストプラクティスと統一性を確保します。 さらに、DockerはDocker公式イメージのビルドインフラストラクチャとロジックを提供および維持し、Docker公式イメージが 10 以上のアーキテクチャ/オペレーティングシステムの組み合わせをサポートできるようにする一貫性のある安全なビルド環境を保証します。
誤解 2:Docker公式イメージは単一のユースケース向けに設計されています
ほとんどのDocker公式イメージリポジトリは、いくつかのイメージバリアントを提供し、サポートされている複数のバージョンを維持しています。 言い換えれば、Docker公式イメージのタグは、 latest ユースケースにとって適切な選択ではない可能性があります。
Docker Official Images タグ
各 Docker 公式イメージ リポジトリのドキュメントには、「サポートされているタグとそれぞれの Dockerfile リンク」セクションがあり、現在のすべてのタグと、それらのタグを使用してイメージを作成した Dockerfile へのリンクが一覧表示されています (図 1)。 このセクションは、初めてのユーザーにとっては少し気が引けるかもしれませんが、いくつかの規則を念頭に置いておくことで、初心者でも、利用可能な画像バリアントと、さらに重要なことに、どのバリアントがユースケースに最も適しているかを理解できます。
- 同じ行にリストされているタグはすべて、同じ基になるイメージを参照しています。 (複数のタグで同じ画像を指すことができます。 たとえば、図 1 は Docker Official Images リポジトリーを示し
ubuntuており、、、20.04focal-20240216focalタグはすべて同じイメージを参照しています。
- 多くの場合、Docker公式イメージリポジトリのタグは
latest使いやすさのために最適化されており、Docker公式イメージにパッケージされているメインソフトウェアを使用する際に役立つが、厳密には必要ではないさまざまなソフトウェアが含まれています。 たとえば、イメージには、多くの場合、latestGit やビルド ツールなどのツールが含まれています。 画像は使いやすく、適用範囲が広いため、latest入門ガイドでよく使用されます。
- 一部のオペレーティング システムおよび言語ランタイム リポジトリは、インストールされているパッケージが少ないため、サイズが小さい "スリム" バリアントを提供します。 たとえば、イメージには
python:3.12.2-bookwormPython ランタイムだけでなく、Python アプリケーションをビルドしてパッケージ化するために必要なツール (570 個以上のパッケージ) も含まれています。これをpython:3.12.2-slim-bookworm、約 150 個のパッケージを含む画像と比較してください。
- 多くのDocker公式イメージリポジトリは、DebianやUbuntuではなく、 Alpine Linuxディストリビューション 上に構築された「alpine」バリアントを提供しています。 Alpine Linuxは、コンテナイメージの小さく、シンプルで、安全なベースを提供することに重点を置いており、Docker公式イメージのアルパインバリアントは、通常、必要なパッケージのみをインストールすることを目的としています。 その結果、Docker Official Images の alpine バリアントは、通常、「スリム」バリアントよりもさらに小さくなります。 たとえば、linux/amd64 イメージ
node:latestは 382 MB、node:slimイメージは 70 MB、node:alpineイメージは 47 MB です。
- トイ・ストーリーのキャラクターに似た単語(本の虫、ブルズアイ、トリクシーなど)や形容詞(jammy、focal、bionicなど)を含むタグが表示されている場合、それらはベースイメージとして使用するLinuxディストリビューションのコードネームを示しています。 Debianリリースのコードネーム はトイストーリーのキャラクターに基づいており、 Ubuntuリリース は頭韻形容詞-動物の呼称を使用しています。 Linuxディストリビューションインジケーターは、多くのDocker公式イメージが、基盤となる複数のディストリビューションバージョン(たとえば
postgres:bullseye、postgres:bookworm)に基づいて構築されたバリアントを提供しているため、役立ちます。
- タグには、画像バリアントの目的に関するその他のヒントが含まれている場合があります。 多くの場合、これらは Docker 公式イメージ リポジトリのドキュメントで後で説明されています。 「この画像の使用方法」または「画像のバリエーション」セクションを確認してください。
誤解 3:Docker公式イメージはソフトウェア開発のベストプラクティスに従っていません
一部の批評家は、Dockerの公式イメージは、コンテナプロセスをrootとして実行しないなど、ベストプラクティスの粒度に反していると主張しています。 ユーザーがいくつかの独自の標準を採用することを推奨しているのは事実ですが、ユースケースが異なれば必要なアプローチも異なることも認識しています。 たとえば、一部のユースケースでは、ワークロードに対して昇格された特権が必要な場合があり、それを安全に行うためのオプションを提供しています。
Dockerオフィシャルイメージがソフトウェアサプライチェーンの保護に役立つ7つの方法
Microsoft は、セキュリティが継続的なプロセスであることを認識しており、ユーザーに可能な限り最高のエクスペリエンスを提供することをお約束します。 2013年の創業以来、Dockerはソフトウェアサプライチェーンのリーダーであり、オープンソースセキュリティを含むセキュリティへの取り組みは、その過程で開発者を新たな脅威から守るのに役立ってきました。
オープンソースソフトウェアが利用できるようになったことで、強力なアプリケーションやサービスを効率的に構築することがこれまで以上に容易になりました。 オープンソースの透明性により、作成したソフトウェアのセキュリティ体制について、これまでにない洞察を得ることができます。 しかし、オープンソースソフトウェアの力と透明性を活用するには、ソフトウェアサプライチェーンのセキュリティを全面的に採用することが不可欠です。 Docker公式イメージは、開発者がより安全なソフトウェアサプライチェーンを構築するのに役立ついくつかの方法は次のとおりです。
- ビルドプロセスを開く
可視性はソフトウェアサプライチェーンの重要な側面であるため、Docker公式イメージは透過的でオープンなビルドプロセスから作成されます。 Dockerfileのインプットとビルドスクリプトはすべてオープンソースであり、すべてのDocker公式イメージのアップデートはパブリックプルリクエストプロセスを通過し、すべてのDocker公式イメージビルドのログを検査できます(Jenkins / GitHub Actions)。
- 最小特権の原則
Docker Official Images ビルドシステムは、各アーキテクチャの書き込みをアーキテクチャ固有のビルドエージェントに制限するなど、最小特権の原則 (POLP) に厳密に準拠しています。
- ビルドシステムの更新
Docker公式イメージのビルドとイメージのセキュリティを確保することは最も重要です。 Docker Official Images ビルドシステムは、自動ビルド、定期的なセキュリティ監査、アップストリームプロジェクトとのコラボレーション、継続的なテスト、およびセキュリティパッチを通じて最新の状態に保たれています。
- 脆弱性レポートと継続的な監視
Docker Scout のご厚意により、脆弱性に関する洞察はすべての Docker 公式イメージで利用でき、新しい脆弱性が発見されると継続的に更新されます。私たちは、セキュリティ上の問題がないか画像を継続的に監視し、迅速に対処することをお約束します。 例えば、 私たちは、最近のxzサプライチェーン攻撃に対して、合理的なガイダンスと修復策をいち早く提供しました。 また、Docker Scout のインサイトと修復ガイダンスを使用して、 20+ CVE データベースからの CVE の結果を 20分から60 分ごとに更新することで、実用的なインサイトをほぼリアルタイムで表示します。
- ソフトウェア部品表 (SBOM) と来歴証明
私たちは、すべてのDocker公式イメージの署名付き構成証明として、完全で正確なSBOMと詳細なビルドの来歴を提供することをお約束します。 これにより、ユーザーはDocker公式イメージの出所に自信を持ち、潜在的な脆弱性を簡単に特定して軽減することができます。
- 署名の検証
現在、署名検証をイメージのプルおよびビルド プロセスに統合することに取り組んでいます。 これにより、すべてのDocker公式イメージが使用前に検証され、ユーザーに追加のセキュリティレイヤーが提供されます。
- 更新頻度の増加
Dockerオフィシャルイメージは、Linuxディストリビューションの安定バージョンに基づいて構築された、必要なソフトウェアの最新バージョンという、両方の長所を提供します。 これにより、Linuxディストリビューションからの新しいパッケージを待ったり、Linuxディストリビューションの不安定なバージョンの使用を余儀なくされたりすることなく、実行しているソフトウェアの最新機能と修正を使用できます。 さらに、Docker 公式イメージのビルド インフラストラクチャのスループットを向上させ、より広範囲の Docker 公式イメージのより頻繁な更新をサポートできるようにしています。 この取り組みの一環として、GitHub Actions と Docker Build Cloud でビルドを試験的に実施しています。
結論
セキュリティとオープンソースソフトウェアの保護におけるDockerのリーダーシップは、Docker公式イメージや、お客様に提供するその他の 信頼できるコンテンツ を通じて確立されています。 私たちは、ベストプラクティス、ツール、コミュニティエンゲージメントに重点を置いた セキュリティへの包括的なアプローチを取り、上流のプロジェクトやSIGと緊密に連携して、セキュリティの問題に迅速かつ積極的に対処しています。
Docker公式イメージは、開発者がアプリケーションを構築、出荷、テスト、および実行するための柔軟で安全な方法を提供します。 Docker公式イメージは、Docker公式イメージコミュニティ、上流のメンテナー/ボランティア、Dockerエンジニアのパートナーシップを通じて維持されており、Docker公式イメージカタログ全体でベストプラクティスと統一性を確保しています。 各Docker公式イメージには、さまざまなユースケースに対応する多数のイメージバリアントが用意されており、各バリアントの目的を示すタグが付いています。
開発者は、アプリケーションが安全で透過的な基盤の上に構築されていることを知っているので、Dockerツールと製品を使用して自信を持って構築できます。
飛び込みたいですか? 今すぐ Docker Official Images でビルドを始めましょう。
さらに詳しく
- 利用可能なDocker公式イメージを参照します。
- hub.docker.com にアクセスして、開発を開始してください。
- Dockerの公式イメージはGitHubで検索できます。
- Docker Hub の詳細については、こちらをご覧ください。
- 読む：