きっとあなたにもこんな経験があるでしょう。個人用の容器を組み立てようとして、それをより安全にするために 特権のないコンテナ そして突然、権限エラーの迷路に迷い込んでしまう。ユーザーのホームディレクトリにフォルダを設定するのに何時間も費やした挙句、コンテナがそこに書き込めなかったり、書き込めたとしてもホスト上のファイルが破損していたりすることが判明するのは、実に苛立たしい。 管理不可能 なぜなら、それらは架空のユーザーに属しているからです。
現実には、コンテナ化によってソフトウェアの配信は迅速化されたものの、相当なリスクも生じています。最近のデータによると、本番環境のイメージの大部分には[不明瞭 - おそらく「不明瞭」または「不明瞭」]が含まれています。 重大な脆弱性そのため、セキュリティは譲ることのできない重要な柱となります。ハッカーによる攻撃を防ぐだけでなく、システムの仕組みを理解することも重要なのです。 プロセスの分離 インフラがザルにならないようにするためです。
コンテナセキュリティのエコシステムを理解する
権限について推測するのをやめるには、まず何を保護しているのかを知る必要があります。コンテナのアーキテクチャは、いくつかの重要なレイヤーに分かれています。まず、 コンテナの画像これはオリジナルの設計図です。これが脆弱な場合、デプロイするすべてのインスタンスが安全ではなくなります。そのため、 信頼できるベースイメージ そして、それらを常に最新の状態に保ってください。
そして、 ランタイムホストオペレーティングシステムとアプリケーション間の仲裁役として機能します。ランタイムが古い場合、 コンテナ脱出 劇的に増加します。これに加えて、Kubernetes のようなオーケストレーションも考慮する必要があります。 ロールベースのアクセス制御（RBAC） これは、管理APIへの不正アクセスを防ぐ唯一の真の障壁です。
私たちは忘れることができません ホストオペレーティングシステム攻撃者がホストカーネルを侵害することに成功した場合、攻撃者はドメイン全体の鍵を握ることになります。ここでの推奨事項は明確です。 最小限のオペレーティング システム 攻撃対象領域を減らすため。最後に、ネットワークは最も一般的な侵入ポイントです。侵害のほぼ30%は接続障害が原因で発生しているため、 ネットワークセグメンテーションとTLS/SSL暗号化 それらは必須です。
権限とルートユーザーの厄介な問題
趣味で使う人にとってよくある問題は、ボリュームを使ったワークフローです。フォルダを作成してマウントすると、突然エラーが発生します。 許可が拒否されましたこれは、デフォルトでは多くのコンテナがrootとして起動するためです。 UIDとGIDが0の場合 ホストユーザーと一致させるには、危険なブリッジを作成することになります。コンテナがこれらのIDの設定を許可しない場合、アプリケーションがどの内部ユーザーを使用して実行しているかを突き止めようとして午後を無駄にすることになります。 chown マニュアル。
効率的な解決策は、 最小特権の原則絶対に必要な場合を除き、root権限で何も実行しないでください。コンテナが作成したファイルをホスト上で削除できない問題を解決するには、Dockerfileに以下の指示を設定することが不可欠です。 USERアプリケーション起動前に、権限のないユーザーを定義する。
Podman を使用する場合、 ルートレスコンテナ これはネイティブで非常に便利ですが、ホストユーザーがコンテナユーザーにどのようにマッピングされるかを理解する必要があります。権限が制御不能になるのを防ぐため、理想的にはアプリケーションは特定のルートに書き込むように設計する必要があります。 ボリュームマッピング これは、プロセスを起動したユーザーの実際のUIDを考慮して行われます。
装甲イメージを構築するための戦略
苦しみから解放されたいなら、イメージの構築方法を変えなければならない。非常に効果的なテクニックの一つは… 多段階構築基本的には、すべてのビルドツールを含む大容量イメージを使用してバイナリを生成し、その後、そのファイルだけを最終イメージにコピーします。 非常に軽い.
画像を使えばさらに先に進むこともできます スクラッチこれにより、シェルもパッケージマネージャもアプリケーションも一切ない、まったく何もないコンテナが作成されます。これにより、攻撃者が侵入できたとしても、悪意のあるコマンドを実行することは事実上不可能になります。 コマンドインタープリタはありません 利用できる。
もう一つのセキュリティ対策は、権限を持つバイナリのイメージをクリーンアップすることです。 setuid または setgidこれらの権限により、ファイルは起動したユーザーではなく、ファイル所有者の権限で実行されることになり、これは... 権限昇格イメージ作成時にこれらの部分を検索して削除する簡単なコマンドがあれば、多くの手間を省くことができます。
特権モードの危険性とLinuxの機能
権限の問題を解決できない絶望感から、フラグを使用する誘惑に駆られることがあります。 –特権階級そんなことは考えない方がいい。特権モードを使うとコンテナの隔離が破られ、ホストのデバイスに完全にアクセスできてしまう。まるで庭の門の開け方がわからないというだけで、見知らぬ人に家の鍵を渡すようなものだ。
代わりに、 Linuxの機能Docker は一連のデフォルトの権限 (CAP_CHOWN や CAP_NET_RAW など) を割り当てます。アプリケーションが低レベルでネットワークを操作する必要がない場合は、最も賢明なアプローチは 不要な機能を排除する そして、厳密に必要なものだけを追加する --cap-add.
より深刻な環境を管理する人々のために、 認証プラグイン 例えば、opa-docker-authzなどです。これらは、DockerデーモンのAPIへの呼び出しを傍受し、特権モードでコンテナを起動しようとする試みをブロックすることで、たとえ誤ってであっても、ホストへのアクセス権を漏らすことがないようにします。
環境の最適化と維持管理
Alpine Linuxを使用する際に、5MBのイメージサイズがライブラリとの互換性の問題を引き起こす場合は、そのサイズにこだわる必要はありません。場合によっては、少し大きめのDebianイメージの方が好ましいこともあります。 安定していて、 チームによって。重要なのは、 脆弱性スキャン イメージが本番環境にデプロイされる前にCVEを検出する自動化されたCI/CDパイプライン。
ストレージに関しては、アプリケーションがルートファイルシステムに書き込むのを防ぎます。 読み取り専用ファイルシステム（rootfs） そして、永続化する必要のあるデータのみに特定のボリュームを定義します。これはセキュリティが向上するだけでなく、よりクリーンなアーキテクチャを強制し、 不動産を持たない水平方向の規模拡大を容易にする。
スケジュールされたプロセスについては、ウェブサイトコンテナ内に cron ジョブを配置しないでください。黄金律は コンテナごとに1つのプロセス最もクリーンな方法は、アプリのイメージを使用してタスクを実行し、その後自身を破棄する一時的なコンテナを起動するか、コマンドを使用してコンテナエンジンを呼び出すことでホストからcronを管理することです。
コンテナセキュリティは、ルートアクセスを排除し、カーネル機能を制限し、コンテナイメージから不要なツールを削除するなど、継続的なプロセスです。特権を持たないユーザーとランタイムのセキュリティ強化、そして継続的な監視を組み合わせることで、ホストシステムの整合性を損なうことなく機能を実現できる環境が構築されます。
バイトの世界とテクノロジー全般についての情熱的なライター。私は執筆を通じて自分の知識を共有するのが大好きです。このブログでは、ガジェット、ソフトウェア、ハードウェア、技術トレンドなどについて最も興味深いことをすべて紹介します。私の目標は、シンプルで楽しい方法でデジタル世界をナビゲートできるよう支援することです。