知っておくべきDockerセキュリティベースライン

この記事では、サービスの構成やファイルのアクセス許可、セキュリティ監査関連の問題など、Docker のセキュリティ ベースラインに関する知識を提供します。

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

サービス構成

1. 高リスク - コンテナ間のネットワーク トラフィックの制限

説明:

デフォルトでは、同じホスト上のコンテナ間ですべてのネットワーク通信が許可されます。必要がない場合は、すべてのコンテナー間通信を制限します。相互に通信する必要がある特定のコンテナをチェーン化します。デフォルトでは、同じホスト上のすべてのコンテナ間で無制限のネットワーク トラフィックが有効になります。したがって、各コンテナは、同じホスト上のコンテナのネットワーク全体上のすべてのパケットを読み取る可能性があります。これにより、予期せぬ不必要な情報が他のコンテナに漏洩する可能性があります。したがって、コンテナ間の通信を制限します。

強化に関する推奨事項:

Docker をデーモン モードで実行し、引数として **–icc=false** を渡します。たとえば、

/usr/bin/dockerd --icc=false

systemctl を使用して docker サービスを管理する場合は、

# を編集する必要があります。

##/ usr/lib/systemd/system/docker.service

ファイルの ExecStart パラメータに

–icc=false

項目を追加し、 docker service

systemctl daemon-reload
systemctl restart docker

2. 高リスク - 特権コンテナの使用は禁止されています

説明:

-privileged フラグを使用して、すべての Linux カーネルに権限を与えますこれにより、 –cap-add および –cap-drop フラグがオーバーライドされます。絶対に使用しないようにしてください。 --privileged フラグは、コンテナーにすべての機能を提供し、デバイスの cgroup コントローラーによって強制されるすべての制限も解除します。言い換えれば、コンテナはホストが実行できるほぼすべてのことを実行できます。このフラグは、Docker 内で Docker を実行するなどの特別な使用例を許可するために存在します。

強化に関する推奨事項:

--privileged

フラグを使用してコンテナを実行しないでください

3. 高リスク - コンテナーのメモリ使用量を制限する

説明:

デフォルトでは、Docker ホスト上のすべてのコンテナーはリソースを均等に共有します。メモリ制限などの Docker ホストのリソース管理機能を使用すると、コンテナが消費するメモリの量を制御できます。デフォルトでは、コンテナーはホスト マシン上のすべてのメモリを使用できます。メモリ スロットリング メカニズムを使用すると、1 つのコンテナがホストのリソースをすべて消費し、同じホスト上の他のコンテナが意図した機能を実行できなくなることによるサービス拒否を防ぐことができます。メモリに制限がない場合、1 つのコンテナがシステム全体を簡単に不安定にして使用できなくなるという問題が発生する可能性があります。

強化に関する推奨事項

コンテナの実行に必要なメモリのみを使用します。常に

--memory

パラメーターを指定してコンテナーを実行します。次のようにコンテナを起動する必要があります: docker run --interactive --tty --memory 256m <container image name or id></container>

4. 高リスク - 変更コンテナのルート ファイル システムは読み取り専用でマウントされています

説明:

コンテナのルート ファイル システムは「ゴールデン イメージ」とみなされ、ルート ファイル システムへの書き込みはすべて避けられました。書き込み用のコンテナ ボリュームを明示的に定義する必要があります。コンテナにデータを書き込まないでください。コンテナに属するデータの量は明確に定義して管理する必要があります。これは、開発者がファイルやエラーを書き込む場所を管理者が制御する多くの状況で役立ちます。

強化に関する推奨事項:

「--read-only」フラグを追加して、コンテナーのルート ファイル システムを読み取り専用としてマウントできるようにします。これをボリュームと組み合わせて使用​​すると、コンテナーのプロセスが保存される場所にのみ書き込むように強制できます。次のようにコンテナを実行する必要があります:

docker run --interactive --tty --read-only --volume <writable-volume> <Container Image Name or ID> <Command>

k8s または他のコンテナ オーケストレーション ソフトウェアによってオーケストレーションされたコンテナの場合は、対応するセキュリティ ポリシーに従って構成するか無視してください。

5. 高リスク - ログ レベルの設定

説明:

適切なログ レベルを設定し、イベントをログに記録するように Docker デーモンを構成します。後で見たい。 「info」以上の基本ログ レベルでは、デバッグ ログを除くすべてのログがキャプチャされます。必要な場合を除き、Docker デーモンを「デバッグ」ログ レベルで実行しないでください。

強化に関する推奨事項:

次のように Docker デーモンを実行します。

dockerd --log-level=info

If you use systemctl を使用して docker サービスを管理するには、

/usr/lib/systemd/system/docker.service

の ExecStart パラメーターを編集し、--log-level="info" を追加する必要があります。高リスク - Docker による iptables への変更を許可します

説明:

iptables はセットアップに使用されます。 Linux カーネル IP パケット フィルター ルール テーブルを維持および検査します。 Docker デーモンが iptables に変更を加えられるようにします。これを選択した場合、Docker はシステムの iptables ルールを変更しません。許可されている場合、Docker サーバーは、コンテナーのネットワーク オプションの選択方法に基づいて、iptables に必要な変更を自動的に加えます。コンテナー間や外部との通信を妨げる可能性のあるネットワークの構成ミスを避けるために、Docker サーバーが自動的に iptables を変更できるようにすることをお勧めします。さらに、コンテナーの実行やネットワーク オプションの変更を選択するたびに iptables を更新する手間も省けます。

補強提案:

不使用’–iptables = false’参数运行Docker守护程序。 若以systemctl管理docker服务则需要编辑/usr/lib/systemd/system/docker.service的ExecStart参数删除--iptables = false， 重启docker服务

systemctl daemon-reload
systemctl restart docker

7.高危-禁止使用aufs存储驱动程序

描述：

“aufs”存储驱动程序是最早的存储驱动程序。 它基于Linux内核补丁集，该补丁集不太可能合并到主要Linux内核中。 并且已知“ aufs”驱动程序会导致一些严重的内核崩溃。 'aufs’刚刚获得了Docker的支持。 最重要的是，许多使用最新Linux内核的Linux发行版都不支持’aufs’驱动程序。

加固建议：

不要明确使用“ aufs”作为存储驱动程序。 例如，请勿按以下方式启动Docker守护程序： 若以systemctl管理docker服务则需要编辑/usr/lib/systemd/system/docker.service的ExecStart参数删除--storage-driver aufs重启docker服务

systemctl daemon-reload
systemctl restart docker

8.高危-禁止在容器上挂载敏感的主机系统目录

描述：

不允许将以下敏感的主机系统目录作为容器卷挂载，尤其是在读写模式下。

/boot /dev /etc /lib /proc /sys /usr

如果敏感目录以读写模式挂载，则可以对那些敏感目录中的文件进行更改。 这些更改可能会降低安全隐患或不必要的更改，这些更改可能会使Docker主机处于受损状态

如果您是k8s或其他容器编排软件编排的容器，请依照相应的安全策略配置或忽略。

加固建议：

不要在容器上挂载主机敏感目录，尤其是在读写模式下

9.高危-禁止共享主机的进程名称空间

描述

进程ID（PID）命名空间隔离了进程ID号空间，这意味着不同PID命名空间中的进程可以具有相同的PID。 这是容器和主机之间的进程级别隔离。

PID名称空间提供了流程分离。 PID命名空间删除了系统进程的视图，并允许进程ID重复使用，包括PID1。如果主机的PID命名空间与容器共享，则它将基本上允许容器内的进程查看主机上的所有进程。 系统。 这破坏了主机和容器之间的进程级别隔离的好处。 有权访问容器的人最终可以知道主机系统上正在运行的所有进程，甚至可以从容器内部杀死主机系统进程。 这可能是灾难性的。 因此，请勿与容器共享主机的进程名称空间。

加固建议：

不要使用--pid = host参数启动容器。

10.中危-为Docker启动内容信任

描述：

默认情况下禁用内容信任。 您应该启用它。 内容信任提供了将数字签名用于发送到远程Docker注册表和从远程Docker注册表接收的数据的功能。 这些签名允许客户端验证特定图像标签的完整性和发布者。 这确保了容器图像的出处

加固建议：

要在bash shell中启用内容信任，请输入以下命令：export DOCKER_CONTENT_TRUST=1 或者，在您的配置文件中设置此环境变量，以便在每次登录时启用内容信任。 内容信任目前仅适用于公共Docker Hub的用户。 当前不适用于Docker Trusted Registry或私有注册表。

文件权限

11.高危-确认docker相关文件权限适合

描述：

确保可能包含敏感参数的文件和目录的安全对确保Docker守护程序的正确和安全运行至关重要

加固建议：

执行以下命令为docker相关文件配置权限：

chown root:root /usr/lib/systemd/system/docker.service
chmod 644 /usr/lib/systemd/system/docker.service
chown root:root /usr/lib/systemd/system/docker.socket
chmod 644 /usr/lib/systemd/system/docker.socket
chown root:root /etc/docker
chmod 755 /etc/docker

若文件路径与实际系统中不同可以使用以下命令获取文件路径：

systemctl show -p FragmentPath docker.socket
systemctl show -p FragmentPath docker.service

12.高危-确保docker.sock不被挂载

描述：
docker.sock挂载的容器容易被获取特殊权限，一旦危险进入到docker中，严重影响了宿主机的安全.

加固建议：

按照提示<image name> <container name>查找启动的docker容器 ， 以非docker挂载docker.sock的形式重新启动容器

docker stop <container name>

docker run [OPTIONS] <image name>或docker run [OPTIONS]

安全审计

13.高危-审核Docker文件和目录

描述：

除了审核常规的Linux文件系统和系统调用之外，还审核所有与Docker相关的文件和目录。 Docker守护程序以“ root”特权运行。 其行为取决于某些关键文件和目录。如 /var/lib/docker、/etc/docker、docker.service、 docker.socket、/usr/bin/docker-containerd、/usr/bin/docker-runc等文件和目录

加固建议：

在/etc/audit/audit.rules与/etc/audit/rules.d/audit.rules文件中添加以下行：

-w /var/lib/docker -k docker
-w /etc/docker -k docker
-w /usr/lib/systemd/system/docker.service -k docker
-w /usr/lib/systemd/system/docker.socket -k docker
-w /usr/bin/docker-containerd -k docker
-w /usr/bin/docker-runc -k docker

然后，重新启动audit程序 service auditd restart.

推荐学习：《docker视频教程》

以上が知っておくべきDockerセキュリティベースラインの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。