Dockerのセキュリティ問題を解決する方法は？

1.Dockerコンテナと仮想マシンの詳細な違い

• 分離と共有

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

• パフォーマンスと損失

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

第二に、Dockerのセキュリティ問題

2.1Docker自身の脆弱性

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

2.2Dockerソースコードの問題

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

3つ目は、Dockerアーキテクチャの欠陥とセキュリティメカニズムです。

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

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

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

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

  • ④rootユーザーのアクセス許可を共有するrootユーザーのアクセス許可で
    コンテナーを実行する場合、コンテナー内のrootユーザーにはホストに対するrootのアクセス許可もあります。

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

• つまり、発生するセキュリティ問題の解決策です。
  次に、カーネル、ホスト、ネットワーク、イメージ、コンテナなどの6つの側面からDockerセキュリティベースライン標準を要約します。

4.1カーネルレベル

（1）及时更新内核。 
（2）User NameSpace（容器内的 root 权限在容器之外处于非高权限状态）。 
（3）Cgroups（对资源的配额和度量）。 
（4）SELiux/AppArmor/GRSEC（控制文件访问权限）。 
（5）Capability（权限划分）。 
（6）Seccomp（限定系统调用）。 
（7）禁止将容器的命名空间与宿主机进程命名空间共享。

4.2ホストレベル

（1）为容器创建独立分区。 
（2）仅运行必要的服务。 
（3）禁止将宿主机上敏感目录映射到容器。 
（4）对 Docker 守护进程、相关文件和目录进行审计。 
（5）设置适当的默认文件描述符数。
（文件描述符：内核（kernel）利用文件描述符（file descriptor）来访问文件。文件描述符是非负整数。
打开现存文件或新建文件时，内核会返回一个文件描述符。读写文件也需要使用文件描述符来指定待读写的文件） 
（6）用户权限为 root 的 Docker 相关文件的访问权限应该为 644 或者更低权限。 
（7）周期性检查每个主机的容器清单，并清理不必要的容器。

4.3ネットワークレベル

（1）通过 iptables 设定规则实现禁止或允许容器之间网络流量。 
（2）允许 Docker 修改 iptables。 
（3）禁止将 Docker 绑定到其他 IP/Port 或者 Unix Socket。 
（4）禁止在容器上映射特权端口。 
（5）容器上只开放所需要的端口。 
（6）禁止在容器上使用主机网络模式。
（7）若宿主机有多个网卡，将容器进入流量绑定到特定的主机网卡上。

4.4ミラーレベル

（1）创建本地镜像仓库服务器。 
（2）镜像中软件都为最新版本。 
（3）使用可信镜像文件，并通过安全通道下载。
（4）重新构建镜像而非对容器和镜像打补丁。 
（5）合理管理镜像标签，及时移除不再使用的镜像。 
（6）使用镜像扫描。 
（7）使用镜像签名。

4.5コンテナレベル

（1）容器最小化，操作系统镜像最小集。 
（2）容器以单一主进程的方式运行。 
（3）禁止 privileged 标记使用特权容器。 
（4）禁止在容器上运行 ssh 服务。 
（5）以只读的方式挂载容器的根目录系统。 
（6）明确定义属于容器的数据盘符。 
（7）通过设置 on-failure 限制容器尝试重启的次数，容器反复重启容易丢失数据。 
（8）限制在容器中可用的进程树，以防止 fork bomb。（fork炸弹，迅速增长子进程，耗尽系统进程数量）

4.6その他の設定

（1）定期对宿主机系统及容器进行安全审计。 
（2）使用最少资源和最低权限运行容器。 
（3）避免在同一宿主机上部署大量容器，维持在一个能够管理的数量。 
（4）监控 Docker 容器的使用，性能以及其他各项指标。 
（5）增加实时威胁检测和事件响应功能。 
（6）使用中心和远程日志收集服务

5、Dockerリモート呼び出しとトラフィック制限

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

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

• イントラネットIPを監視するための、dockerデーモンの起動方法は次のとおりです。

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

• ローカルリスニングアドレスとポートを開く

ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://192.168.140.22:2375

systemctl daemon-reload

systemctl restart docker

• 次に、ホストのfirewalldでIPアクセス制御を行うことができます。
  注：送信元アドレスはクライアントアドレスです。

firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="192.168.140.21" port protocol="tcp" port="2375" accept"

firewall-cmd --reload		//重新加载防火墙策略

• 最後に、リモート呼び出しはクライアント操作で実装されます

docker -H tcp://192.168.140.22 images	//在客户端查看服务端的docker镜像

5.2交通の流れを制限する

• ファイアウォールフィルターを使用して、Dockerコンテナーの送信元IPアドレス範囲を制限し、外部と通信します。

firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="192.168.140.0/24" reject"

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

1. 不在有外网ip的机器上使用Docker服务

2. 使用k8s等docker编排系统管理Docker容器

3. 宿主上Docker daemon启动命令加一个--iptables=false，然后把常用iptables写进文件里，再用iptables-restore去刷。

6、コンテナの最小化と画像のセキュリティ

6.1 容器最小化

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

docker exec -it 容器ID bash

6.2画像のセキュリティ

• Dockerイメージのセキュリティスキャン。ミラーウェアハウスクライアントで証明書認証を使用して、ダウンロードしたイメージを確認します。
  CVEデータベースと同期してミラーをスキャンすることにより、脆弱性が見つかったらユーザーに対処するよう通知されます。または、ミラーの構築を直接防ぐことができます。
• 注意：

  • ①会社が独自のミラーソースを使用している場合は、この手順をスキップできます。
    それ以外の場合は、少なくともmd5およびベースイメージの他の特性値を検証する必要があり、ベースイメージに基づいてさらに構築する前に、ベースイメージが一貫していることを確認します。

  • ②通常の状況では、信頼できるライブラリからのみイメージを取得するようにしてください。–insecure-registry = []パラメータの使用はお勧めしません。
    港のプライベートウェアハウスを使用することをお勧めします。