Dockerのセキュリティについて Docker-TLS暗号化通信の問題

1. Dockerのセキュリティ問題

Docker自身の脆弱性

アプリケーションとして、Docker 自体の実装にはコード欠陥があります。 CVE は、Docker の過去のバージョンにおける 20 件を超える脆弱性を公式に記録します。ハッカーが使用する一般的な攻撃方法には、コード実行、権限昇格、情報漏洩、権限バイパスなどがあります。現在、Docker のバージョンは非常に速く更新されるため、Docker ユーザーは Docker を最新バージョンにアップグレードすることをお勧めします。

Docker ソースコードの問題

Docker は、ユーザーが作成したイメージをアップロードして他のユーザーがそれをダウンロードし、環境をすばやく構築できるようにする Docker ハブを提供します。しかし、セキュリティ上の問題も生じます。
たとえば、次の 3 つの方法があります。
（１）ハッカーが悪意のある画像をアップロードするハッカーが作成した画像にトロイの木馬やバックドアなどの悪意のあるソフトウェアを埋め込んだ場合、環境は最初から安全ではなく、将来的にもセキュリティが全く確保されなくなります。

（２）イメージには脆弱なソフトウェアが使用されている。Docker Hubでダウンロード可能なイメージのうち、75%に脆弱なソフトウェアがインストールされています。したがって、イメージをダウンロードした後、その中のソフトウェアのバージョン情報をチェックして、対応するバージョンに脆弱性がないかを確認し、適時に更新してパッチを適用する必要があります。

（３）中間者攻撃：送信中にイメージの改ざんが発生する可能性があります。新しいバージョンのDockerでは、この問題を防ぐための検証メカニズムが用意されています。

2. Dockerアーキテクチャの欠陥とセキュリティメカニズム

ハッカーがホストマシン上の一部のコンテナを制御したり、パブリッククラウド上でコンテナを構築する方法にアクセスしてホストマシンや他のコンテナを攻撃したりする攻撃シナリオなど、Docker 自体のアーキテクチャとメカニズムから問題が発生する可能性があります。

コンテナ間のLAN攻撃

ホスト上のコンテナはローカルエリアネットワークを形成できるため、ローカルエリアネットワークに対する ARP スプーフィング、スニッフィング、ブロードキャストストームなどの攻撃を使用できます。したがって、ホスト上に複数のコンテナを展開するには、適切なネットワーク構成と iptable ルールの設定が必要です。

DDoS攻撃はリソースを消耗する

cgroups セキュリティメカニズムは、このような攻撃を防ぐように設計されています。この問題は、単一のコンテナにあまり多くのリソースを割り当てないことで回避できます。

脆弱なシステムコール

Docker と仮想マシンの重要な違いは、Docker とホストマシンが同じオペレーティングシステムカーネルを共有することです。ホストカーネルに権限昇格や特権エスカレーションにつながる脆弱性があると、Docker を通常のユーザーとして実行したとしても、コンテナが侵入されたときに、攻撃者はカーネルの脆弱性を悪用してホストマシンにジャンプし、さらに多くのことを行うことができます。

共有ルートユーザー権限

コンテナをルートユーザー権限で実行すると、コンテナ内のルートユーザーにはホストマシン上のルート権限も付与されます。

3. Dockerコンテナと仮想マシンの違い

隔離と共有

仮想マシンは、ネットワークカード、メモリ、CPU などの仮想ハードウェアを仮想化するためのハイパーバイザーレイヤーを追加し、その上に仮想マシンを作成します。各仮想マシンには独自のシステムカーネルがあります。 Docker コンテナは、ファイルシステム、プロセス、デバイス、ネットワークなどのリソースを分離し、権限や CPU リソースなどを制御することで、コンテナが互いに影響を及ぼさず、ホストマシンにも影響を与えないようにします。コンテナはカーネル、ファイルシステム、ハードウェア、その他のリソースをホストと共有します。

パフォーマンスと損失

仮想マシンと比較すると、コンテナは消費するリソースが少なくなります。同じホストマシン上で作成できるコンテナの数は、仮想マシンの数より多くなります。ただし、仮想マシンのセキュリティはコンテナよりもわずかに優れています。仮想マシンからホストマシンや他の仮想マシンに侵入するには、まずハイパーバイザー層に侵入する必要があり、これは非常に困難です。 Docker コンテナはカーネル、ファイルシステム、その他のリソースをホストマシンと共有するため、他のコンテナやホストマシンに影響を与える可能性が高くなります。

Docker セキュリティベースライン標準

以下は、カーネル、ホスト、ネットワーク、イメージ、コンテナなどの 6 つの側面から Docker セキュリティベースライン標準をまとめたものです。

カーネルレベル

（１）カーネルを適時に更新する。
（２）ユーザーネームスペース（コンテナ内のルート権限はコンテナ外では非高権限状態になります）。
（３）Cgroup（リソースの割り当てとメトリクス）。
（4）SELiux/AppArmor/GRSEC（ファイルアクセス権限を制御する）。
（５）能力（権限の分担）
（6）Seccomp（制限されたシステムコール）。
（７）コンテナ名前空間をホストプロセス名前空間と共有することは禁止されている。

ホストレベル

（１）コンテナごとに独立したパーティションを作成する。
（２）必要なサービスのみ実行する。
（３）ホスト上の機密ディレクトリをコンテナにマッピングすることは禁止されています。
（4）Dockerデーモン、関連ファイル、ディレクトリを監査します。
（５）ファイル記述子の適切なデフォルト数を設定する。

(ファイル記述子: カーネルはファイル記述子を使用してファイルにアクセスします。ファイル記述子は負でない整数です。既存のファイルを開いたり、新しいファイルを作成したりすると、カーネルはファイル記述子を返します。ファイルの読み取りと書き込みでも、読み取りと書き込みの対象となるファイルを指定するためにファイル記述子を使用する必要があります)

（6）rootユーザー権限でのDocker関連ファイルのアクセス権限は644以下にしてください。
（７）各ホストのコンテナリストを定期的にチェックし、不要なコンテナをクリーンアップする。

ネットワークレベル

（1）iptablesを通じてコンテナ間のネットワークトラフィックを禁止または許可するルールを設定します。
（2）Dockerがiptablesを変更できるようにします。
（3）Dockerを他のIP/ポートまたはUnixソケットにバインドすることは禁止されています。
（４）コンテナ上の特権ポートのマッピングは禁止されている。
（５）コンテナ上では必要なポートのみが開かれる。
（６）コンテナ上でホストネットワークモードを使用することは禁止されています。
（7）ホストマシンに複数のネットワークカードがある場合は、コンテナの着信トラフィックを特定のホストネットワークカードにバインドします。

画像レベル

（1）ローカルイメージリポジトリサーバーを作成します。
（２）画像内のソフトウェアは最新バージョンです。
（3）信頼できる画像ファイルを使用し、安全なチャネルを通じてダウンロードします。
（4）コンテナとイメージにパッチを適用する代わりに、イメージを再構築します。
（５）画像タグを適切に管理し、使用されなくなった画像は適時に削除する。
（6）ミラースキャンを使用する。
（７）画像署名を使用する。

コンテナレベル

（１）コンテナと最小限のオペレーティングシステムイメージセットを最小化する。
（２）コンテナは単一のメインプロセスとして実行されます。
（３）特権タグは特権コンテナを使用することを禁止する。
（4）コンテナ上でsshサービスを実行することは禁止されています。
（５）コンテナのルートディレクトリシステムを読み取り専用モードでマウントします。
（６）コンテナに属するデータドライブ文字を明確に定義する。
(7) on-failureを設定することで、コンテナの再起動回数を制限できます。コンテナの再起動を繰り返すと、データが失われやすくなります。
（８）フォーク爆弾を防ぐためにコンテナ内で利用可能なプロセスツリーを制限する。

その他の設定

（１）ホストシステムとコンテナのセキュリティ監査を定期的に実施する。
（２）最小限のリソースと最小限の権限を使用してコンテナを実行する。
（３）同一ホスト上に多数のコンテナを展開することは避け、管理可能な数を維持する。
（4）Dockerコンテナの使用状況、パフォーマンス、その他の指標を監視します。
（５）リアルタイムの脅威検出およびインシデント対応機能を追加する。
（6）中央およびリモートログ収集サービスを使用する

Docker-TLS暗号化通信

Docker 通信中にリンクハイジャック、セッションハイジャック、その他の問題によって中間者攻撃が発生するのを防ぐには、c/s の両端で暗号化された方法で通信する必要があります。

フォルダを作成し、ホスト名を変更する（後で使用するため）

[root@server1 ~]# mkdir /tls

[root@server1 ~]# cd /tls

[root@server1 tls]# hostnamectl set-hostname マスター

[root@server1 tls]# bash

[ルート@マスター tls]#

クライアントの追加:

[root@client ~]# vim /etc/hosts

CAキーを作成し、キーパスワードを設定する

[root@master tls]# openssl genrsa -aes256 -out ca-key.pem 4096

RSA秘密鍵の生成、4096ビット長の係数

...............................................++

.............................................................................................................................................................................................................++

eは65537（0x10001）

ca-key.pem のパスフレーズを入力してください:

検証中 - ca-key.pem のパスフレーズを入力してください:

CA証明書を作成する

[root@master tls]# openssl req -new -x509 -days 1000 -key ca-key.pem -sha256 -subj "/CN=liuwei" -out ca.pem

ca-key.pem のパスフレーズを入力してください: ### パスワードを入力してください

サーバーの秘密鍵を作成する

[root@master tls]# openssl genrsa -out server-key.pem 4096

RSA秘密鍵の生成、4096ビット長の係数

...............................++

..................................++

eは65537（0x10001）

署名秘密鍵

[root@master tls]# openssl req -subj "/CN=lw" -sha256 -new -key server-key.pem -out server.csr

署名にはCA証明書と秘密鍵証明書を使用します。123456と入力します。

[root@master tls]# openssl x509 -req -days 1000 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem

署名OK

件名=/CN=lw

CA秘密鍵の取得

ca-key.pem のパスフレーズを入力してください:

クライアントキーを生成する

[root@master tls]# openssl genrsa -out key.pem 4096

署名クライアント

[root@master tls]# openssl req -subj "/CN=client" -new -key key.pem -out client.csr

設定ファイルを作成する

echo 拡張キー使用法 = clientAuth > extfile.cnf

署名証明書、123456 を入力、必須 (署名クライアント、CA 証明書、CA キー)

[root@master tls]# openssl x509 -req -days 1000 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf

署名OK

件名=/CN=クライアント

CA秘密鍵の取得

ca-key.pem のパスフレーズを入力してください:

docker設定ファイルを変更し、サービスを再起動する

ExecStart=/usr/bin/dockerd --tlsverify --tlscacert=/tls/ca.pem --tlscert=/tls/server-cert.pem --tlskey=/tls/server-key.pem -H tcp://0.0.0.0:2388 -H unix:///var/run/docker.sock

Dockerを再起動する

[root@master tls]# systemctl daemon-reload

[root@master tls]# systemctl dockerを再起動します

3つのファイル /tls/ca.pem /tls/cert.pem /tls/key.pem をクライアントにコピーします。

[root@master tls]# scp ca.pem [email protected]:/etc/docker

[root@master tls]# scp cert.pem [email protected]:/etc/docker

[root@master tls]# scp key.pem [email protected]:/etc/docker

TLSを検証する際は、秘密鍵で設定されたIDを使用する必要があるため、上記のホスト名をlwに変更する必要があります。

ローカル認証

[root@lw tls]# docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://lw:2388 バージョン

NGINXイメージをダウンロードする

[root@lw tls]# docker pull nginx

クライアント環境を展開し、TLSを検証する

/etc/dockerディレクトリに入る

クライアント側のDockerバージョンを確認する

[root@クライアント docker]# docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://lw:2388 バージョン

展開環境、TLSの検証

クライアントの画像を見る

[root@クライアント docker]# docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://lw:2388 イメージ

DockerのセキュリティとDocker-TLS暗号化通信に関する記事はこれで終わりです。Docker TLS暗号化通信についてさらに詳しく知りたい方は、123WORDPRESS.COMの過去の記事を検索するか、以下の関連記事を引き続きご覧ください。今後とも123WORDPRESS.COMをよろしくお願いいたします。

以下もご興味があるかもしれません: