ベースイメージのハードニング

ベースイメージのハードニングとは？

ベースイメージのハードニングとは、コンテナイメージの基盤レイヤーをセキュアにするために、その内容を最小化し、セキュリティを最優先としたデフォルト設定を施すプロセスのことです。

ハードニングされたベースイメージでは、シェル、コンパイラ、パッケージマネージャといった不要なコンポーネントを削除することで、攻撃対象領域を制限し、攻撃者がコンテナ内で制御を奪取したり権限を昇格させたりすることを難しくします。

ハードニングには、非 root ユーザーとしての実行、書き込み可能な領域の削減、イミュータビリティによる一貫性の確保といったベストプラクティスの適用も含まれます。

Docker Official Images  や Docker Verified Publisher Images  もセキュリティのベストプラクティスに従っていますが、より幅広いユースケースをサポートするために、Docker Hardened Images ほど徹底的にはハードニングされていない場合があります。

なぜ重要なのか？

ほとんどのコンテナは、使用しているベースイメージからセキュリティ姿勢を継承します。

ベースイメージに不要なツールが含まれていたり、昇格された権限で動作していたりすると、その上に構築されるすべてのコンテナが同じリスクにさらされます。

ベースイメージをハードニングすることで:

• 攻撃対象領域を削減: 悪用される可能性のあるツールやライブラリを取り除く

• 最小権限の原則を徹底: root アクセスを排除し、コンテナができることを制限する

• 信頼性と一貫性を向上: 実行時の変更や構成ドリフトを回避する

• セキュアなソフトウェアサプライチェーンに準拠: コンプライアンス基準の達成を支援する

ハードニングされたベースイメージを使用することは、コンテナで構築・実行するソフトウェアを保護するための最初の重要なステップです。

何が削除され、なぜなのか

ハードニングされたイメージでは、セキュアな本番環境においてリスクが高い、または不要とされる一般的なコンポーネントが削除されます:

Docker Hardened Images におけるベースイメージのハードニングの適用

Docker Hardened Images（DHI）は、設計段階からベースイメージのハードニング原則を取り入れています。

各イメージは、その用途に必要なものだけを含むように構築されており、アプリケーションをビルドする場合（-dev や -sdk タグ）や本番で実行する場合などに応じた構成が用意されています。

Docker Hardened Image の特徴

Docker Hardened Images は以下の特性を備えています:

• ミニマル: 必要不可欠なライブラリやバイナリのみを含む

• イミュータブル: イメージはビルド時に固定され、実行時のインストールは不可

• デフォルトで非 root: 特別な設定をしない限り、コンテナは非特権ユーザーで実行される

• 用途別スコープ: 開発用（-dev）、SDK ベースのビルド用（-sdk）、本番ランタイム用といった異なるタグを提供

これらの特性によって、開発・テスト・本番環境を通じて一貫したセキュアな挙動を実現します。

Docker Hardened Image の互換性に関する考慮点

Docker Hardened Images は多くの一般的なツールを削除しているため、すべてのユースケースでそのまま利用できるとは限りません。そのため次のような工夫が必要になる場合があります:

• マルチステージビルドを使用して、-dev イメージでコードをコンパイルや依存関係をインストールし、その成果物をハードニングされたランタイムイメージにコピーする

• シェルスクリプトを置き換える: エントリポイント用のバイナリを利用するか、必要に応じて明示的にシェルを含める

• Docker Debug  を利用して、一時的にコンテナを調査・トラブルシュートし、ベースイメージを変更せずに問題解決を行う

これらのトレードオフは意図的なものであり、セキュアで再現可能、かつ本番対応可能なコンテナを構築するためのベストプラクティスを支援します。