是的，您需要保护流量。

阅读 docs.docker.com：

“如果您需要通过网络以安全的方式访问 Docker，您可以通过指定 tlsverify 标志并将 Docker 的 tlscacert 标志指向受信任的 CA 证书来启用 TLS。在守护进程模式下，它只允许来自经过身份验证的客户端的连接由该 CA 签署的证书。在客户端模式下，它仅连接到具有该 CA 签署的证书的服务器。

在Jeff Hale的文章Top 20 Docker Security Tips 中，作者写道

“Docker 也提供私有容器网络。这可以防止容器获得对同一主机上其他容器的网络接口的特权访问。因此 Docker 环境在某种程度上是孤立的，但对于您的用例而言，它可能不够独立。”

这篇文章带来了更多加强 Docker 安全性的想法，包括：

1. 限制特权
2. 避免以 root 身份运行
3. 使用受信任和签名的图像
4. 使用最少的图像和资源
5. 安全地管理密钥
6. 更新库
7. 考虑 Docker 企业版

来源：

• docs.docker.com/engine/security/https

• docs.docker.com/engine/security/security

与安全领域的大多数事情一样，答案是视情况而定。以下是一些相关信息，看看这对您是否重要。

Docker 提供了一个默认的桥接网络（docker0在默认安装中）。这只是一个标准的 Linux 桥接网络。您的威胁模型可能是两种情况之一

1. 攻击者可以访问同一网桥上的另一个容器
2. 攻击者可以访问底层主机。

在这两种情况下，攻击者都需要足够的权限来嗅探该网络上的流量和/或 ARP 欺骗。这通常涉及对root主机具有特权或具有与NET_RAW流量嗅探和 ARP 欺骗相关的能力。

在第一种情况下，不幸的是（从安全的角度来看）Docker 默认为所有容器提供了NET_RAW功能，因此默认安装，没有加固将允许攻击者访问一个容器来攻击该网络上的其他容器。NET_RAW您可以通过从容器权限中删除来缓解这种情况。

在第二种情况下，如果攻击者对运行容器的主机具有特权访问权限，他们可以访问该网络，但他们也可以访问您的所有容器，因此您可能不需要担心流量嗅探:)

这一切都假设标准 Docker 网络，如果您使用 Kubernetes，则有更多变量在起作用，因为那里有多种网络选项可用。

关于这个主题的一些很好的附加材料。这里有一份白皮书讨论了这个问题。Liz Rice 今年在 Kubecon 上就这个话题做了很好的讨论（视频在这里）。

另一个注意事项是，在 Docker 默认网络上，而不是在 Docker 创建的任何其他网络上，您可以设置--icc=false阻止任何容器间通信，这些通信未通过容器之间的链接明确列入白名单。这是一个遗留选项，所以我不会依赖它，继续前进。

您需要考虑到 docker 容器可以共享一个桥接设备，因此如果两个容器都位于同一主机上，则可以从另一个容器中嗅探来自一个容器的所有流量。

另一个需要考虑的变量是错误。docker 主机可能存在允许 docker 实例嗅探不应被允许的流量的错误。因此，如果您正在考虑这种情况，最好对流量进行加密。