Docker-TLSの詳細

まず、Dockerのセキュリティ問題

1.1、Docker自身の脆弱性

■アプリケーションとして、Docker自体の実装にコード上の欠陥があります。CVEは、Dockerの履歴バージョンに20を超える脆弱性を公式に記録しています

■ハッカーが一般的に使用する主な攻撃方法は、コードの実行、特権の昇格、情報漏えい、特権のバイパスです。現在のDockerバージョンは非常に迅速に変更されます

■Dockerユーザーは、Dockerを最新バージョンにアップグレードするのが最適です

1.2、Dockerソースコードの問題

DockerはDockerハブを提供します。これにより、ユーザーは作成されたイメージをアップロードして、他のユーザーがダウンロードして環境をすばやく構築できます。しかし、それはまたいくつかのセキュリティ問題をもたらします。たとえば、次の3つの方法があります。

• ハッカーは悪意のある画像をアップロードします。作成された画像にハッカーがトロイの木馬、バックドア、その他の悪意のあるソフトウェアを埋め込むと、環境は最初から安全でなくなり、将来的にはセキュリティが失われます。
• ミラーは脆弱なソフトウェアを使用します。DockerHubにダウンロードできるミラーのうち、75％のミラーに脆弱なソフトウェアがインストールされています。したがって、イメージをダウンロードした後、
  内部のソフトウェアのバージョン情報、対応するバージョンに脆弱性があるかどうかを確認し、時間内に更新してパッチを適用する必要があります
• ミラーイメージを改ざんするman-in-the-middle攻撃は、送信プロセス中に改ざんされる可能性があります。新しいバージョンのDockerは、この問題を防ぐための対応する検証メカニズムを提供しています。

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

Docker独自のアーキテクチャとメカニズムが問題を引き起こす可能性があります。たとえば、このような攻撃シナリオでは、ハッカーがホスト上のいくつかのコンテナを制御したり、パブリッククラウド上にコンテナを構築する方法を取得したりして、ホストに対して攻撃を開始したり、他のコンテナ。攻撃

1.3.1、コンテナ間のLAN攻撃

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

1.3.2、DDoS攻撃はリソースを使い果たします

Cgroupsのセキュリティメカニズムは、このような攻撃を防ぐためのものです。このような問題を回避するために、単一のコンテナに多くのリソースを割り当てないでください。

1.3.3、脆弱なシステムコール

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

1.3.4、rootユーザーの権限を共有する

rootユーザー権限でコンテナーを実行する場合、コンテナー内のrootユーザーはホストマシンでのroot権限も持っています

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

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

1.4.1、カーネルレベル

• 時間内にカーネルを更新します
• ユーザー名前空間（コンテナー内のrootアクセス許可は、コンテナー外の非高アクセス許可状態にあります）
• Cgroups（リソースの割り当てと測定）
• SELiux / AppArmor / GRSEC（制御ファイルアクセス機関）
• 機能（認可部門）
• Seccomp（限定システムコール）
• コンテナの名前空間をホストプロセスの名前空間と共有することは禁止されています

1.4.2、ホストレベル

• コンテナ用に別のパーティションを作成します
• 必要なサービスのみを実行する
• ホスト上の機密ディレクトリをコンテナにマッピングすることを禁止します
• Dockerデーモン、関連ファイル、およびディレクトリを監査します
• 
  ファイル記述子の適切なデフォルト数を設定します（ファイル記述子：カーネルはファイル記述子を使用してファイルにアクセスします。ファイル記述子は負でない整数です。
  既存のファイルを開くとき、または新しいファイルを作成するとき、カーネルはファイルの説明を返します。文字。読み取りまた、ファイルの書き込みでは、ファイル記述子を使用して、読み取りおよび書き込みを行うファイルを指定する必要があります）
• rootとしてユーザー権限を持つDocker関連ファイルのアクセス権限は644以下である必要があります
• 各ホストのコンテナリストを定期的にチェックし、不要なコンテナをクリーンアップします

1.4.3、ネットワークレベル

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

1.4.4、ミラーレベル

• ローカルミラーウェアハウスサーバーを作成する
• ミラー内のソフトウェアは最新バージョンです
• 信頼できるミラーファイルを使用し、安全なチャネルからダウンロードします
• コンテナとイメージにパッチを適用する代わりに、イメージを再構築します
• ミラータグを合理的に管理し、使用されなくなったミラーをタイムリーに削除します
• ミラースキャンを使用する
• ミラー署名を使用する

1.4.5、コンテナレベル

• 最小化されたコンテナ、オペレーティングシステムイメージの最小セット
• コンテナは単一のメインプロセスとして実行されます
• 特権コンテナを使用するための特権タグの禁止
• コンテナでのsshサービスの実行を禁止する
• コンテナのルートディレクトリシステムを読み取り専用でマウントします
• コンテナに属するデータドライブ文字を明確に定義する
• on-failureを設定してコンテナーの再起動の試行回数を制限することにより、コンテナーが繰り返し再起動した場合にデータが失われやすくなります。
• フォーク爆弾を防ぐために、コンテナで使用可能なプロセスツリーを制限します。（フォーク爆弾、子プロセスの急速な成長、システムプロセスの数の枯渇）

1.4.6、その他の設定

• ホストシステムとコンテナのセキュリティ監査を定期的に実施します
• 最小限のリソースと権限でコンテナーを実行する
• 同じホストに多数のコンテナーをデプロイすることを避け、管理可能な数を維持します
• Dockerコンテナーの使用状況、パフォーマンス、およびその他のインジケーターを監視します
• リアルタイムの脅威検出およびインシデント対応機能を追加します
• 中央およびリモートのログ収集サービスを使用する

1.5、容器最小化

コンテナ内で必要なサービスのみが実行されている場合、SSHなどのサービスを簡単に開いてコンテナに接続することはできません。通常、次の方法を使用してコンテナに入力します

docker exec -it a661258f6bfe bash

1.6、DockerリモートAPIアクセス制御

Dockerのリモート呼び出しAPIインターフェースには不正アクセスの脆弱性があり、少なくとも外部ネットワークアクセスを制限する必要があります。アクセスにはSocketを使用することをお勧めします。内部ネットワークIPを監視するための、dockerデーモンの起動方法は次のとおりです。

docker -d -H uninx:///var/run/docker.sock -H tcp://192.168.195.128:2375
或者
vim /usr/lib/systemd/system/docker.service

1.6.1、例

1.6.1.1、サーバー構成は次のとおりです

[root@docker ~]# vim /usr/lib/systemd/system/docker.service

[root@docker ~]# systemctl daemon-reload
[root@docker ~]# systemctl restart docker
[root@docker ~]# docker images

1.6.1.2、クライアント操作はリモートコールを実現します

[root@docker1 ~]# docker -H tcp://192.168.140.20 images

1.7、トラフィックの流れを制限する

使用防火墙过滤器限制Docker容器的源IP地址范围与外界通讯
firewall-cmd --permanent --zone=public --add-rich-rule="rule familyg="ipv4" source address="192.168.195.0/24" reject"

多くの問題は、Dockerコンテナポートの外部リリースによって引き起こされる脆弱性によって引き起こされます。オペレーティングシステムアカウントのアクセス許可制御の問題に加えて、Dockerデーモンのプロセス管理における隠れた危険でもあります。教会で現在使用されているDockerバージョンは、ホストjptablesを管理するためにDockerデーモンをサポートしています。プロセスが開始され、-p host_port：guest_portのポートマッピングが追加されると、Dockerデーモンは対応するFORWARDチェーンと-jACCEPTを直接増やします。デフォルトのDROPルールはINPUTチェーンで行われることであり、dockerに制限がないため、非常に深刻なセキュリティリスクが残ります。したがって、次のことをお勧めします。

• 外部ネットワークIPを備えたマシンでDockerサービスを使用しないでください
• k8sなどのDockerオーケストレーションシステムを使用してDockerコンテナを管理する
• ホストのDockerデーモン起動コマンドに–iptables = falseを1つ追加し、一般的に使用されるiptablesをファイルに書き込んでから、iptables-restoreを使用して更新します。

1.8、画像セキュリティ

Dockerイメージのセキュリティスキャン。ミラーウェアハウスクライアントで証明書認証を使用して、ダウンロードしたイメージを確認します。CVEデータベースと同期してミラーをスキャンすることにより、脆弱性が見つかった場合に対処するようにユーザーに通知されます。または、ミラーがビルドを続行するのを直接防ぐことができます。
会社が独自のミラーソースを使用している場合は、この手順をスキップできます。それ以外の場合は、少なくともベースイメージのmd5およびその他の特性値を確認し、それらが一貫していることを確認してから、ベースイメージに基づいてさらにビルドする必要があります。一般に、信頼できるライブラリからのみイメージを取得するようにしてください。–insecure-registry = []パラメータを使用することはお勧めしません。また、港のプライベートウェアハウスを使用することをお勧めします。

2つ目は、Docker-TLS暗号化通信です。

リンクハイジャックやセッションハイジャックなどの問題により、通信中に途中の人がDockerを攻撃するのを防ぐために、c / sの両端は暗号化を介して通信する必要があります。

2.1。実装手順

[root@docker ~]# mkdir tls     #创建tls目录用来存放证书信息
[root@docker tls]# hostnamectl set-hostname master  #更改主机名
[root@docker tls]# su
[root@master tls]# vim /etc/hosts

[root@master tls]# openssl genrsa -aes256 -out my-key.pem 4096    创建my密钥

[root@master tls]# openssl req -new -x509 -days 1000 -key my-key.pem -sha256 -subj "/CN=*" -out my.pem   #创建my证书
[root@master tls]# openssl genrsa -out server-key.pem 4096  #创建服务器私钥
[root@master tls]# openssl req -subj "/CN=*" -sha256 -new -key server-key.pem -out server.csr   #签名私钥
[root@master tls]# openssl x509 -req -days 1000 -sha256 -in server.csr -CA my.pem -CAkey my-key.pem -CAcreateserial -out server-cert.pem  
#使用ca证书与私钥证书签名，生成服务端证书 

[root@master tls]# openssl genrsa -out key.pem 4096   #生成客户端密钥
[root@master tls]# openssl req -subj "/CN=client" -new -key key.pem -out client.csr   #签名客户端
[root@master tls]# echo extendedKeyUsage=clientAuth > extfile.cnf
#创建配置文件
[root@master tls]# openssl x509 -req -days 1000 -sha256 -in client.csr -CA my.pem -CAkey my-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf   #签名证书，需要（签名客户端，ca证书，ca密钥），sha256:哈希，做数据完整性验证
[root@master tls]# rm -rf my.srl client.csr extfile.cnf server.csr  #删除多余文件
[root@master tls]# vim /usr/lib/systemd/system/docker.service   #修改配置文件

[root@master tls]# systemctl daemon-reload   #重启进程
[root@master tls]# systemctl restart docker      #重启docker服务
[root@master tls]# netstat -napt | grep 2376

2.2.3つのファイル/tls/my.pem/tls/cert.pem/tls/key.pemを別のホストにコピーします

[root@master tls]# scp my.pem root@192.168.140.30:/etc/docker
[root@master tls]# scp cert.pem root@192.168.140.30:/etc/docker
[root@master tls]# scp key.pem root@192.168.140.30:/etc/docker

[root@docker1 ~]# cd /etc/docker/
[root@docker1 docker]# ls

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

2.3、ローカル検証

[root@docker1 docker]# docker --tlsverify --tlscacert=my.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://master:2376 images

[root@docker1 docker]# docker --tlsverify --tlscacert=my.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://master:2376 pull tomcat
[root@docker1 docker]# docker images