安全性：容器应该运行 TLS 还是可以依赖它的 sidecar？

Question

我想知道安全专家如何考虑使容器流量安全。我们以一个简单的 K8S 集群为例。

我想我们都同意在每个容器中运行 HTTPS 而不是 HTTP 更安全。我通常会在 Ingress 上配置 TLS，然后路由到内部容器也会配置 TLS。

现代 mashing 解决方案通常安装代理 sidecar - 让我们以 Linkerd2 为例。Ingress 会将所有传入流量升级到 TLS，然后使用 Linkerd 的 TLS 将流量转发到 sidecar 代理。传输到这里的所有内容都是 TLS 并且是安全的。我想知道，既然安全的流量“已经到达”了 pod，容器是否也应该使用 TLS，或者它是否足够安全以在没有 TLS 的情况下与 sidecar 通信？我想听听容器与其边车之间的安全方面。Sidecar 是否应该被视为一个独立的容器，因此与容器的通信也应该受到 TLS 保护？

Answer 1

在您希望 Kubernetes 集群具有高级别安全性的环境中，现在通常应用零信任网络的原则。对于 Kubernetes 集群中的网络，这通常意味着：

• 加密所有网络流量
• 对所有网络流量使用身份验证
• 细粒度的防火墙规则 - 应用于每个应用程序周围的微分段
• 使用 RBAC、服务帐户、JWT 和 OpenPolicyAgent 的最低权限访问控制

前两点现在通常通过服务网格产品来解决，如Linkerd、Istio和云提供商提供托管解决方案，如AWS App Mesh。这些产品以 TLS 的形式在每个 Pod 之间应用加密，但也以自动方式使用客户端证书和双向 TLS、mTLS 进行身份验证。服务网格通常有一个控制平面部分，负责例如通过自动化来轮换证书。

第三点通常是使用Kubernetes 网络策略来获得动态的、但细粒度的防火墙规则应用于每个应用程序实例 (Pod)，即使它可以动态调度到集群中的不同节点。这些策略通常使用例如 Pod 标签而不是硬编码的 IP 地址在更高级别声明。

我想知道，既然安全的流量“已经到达”了 pod，容器是否也应该使用 TLS，或者它是否足够安全以在没有 TLS 的情况下与 sidecar 通信？我想听听容器与其边车之间的安全方面。Sidecar 是否应该被视为一个独立的容器，因此与容器的通信也应该受到 TLS 保护？

豆荚是调度中Kubernetes单位，它们被紧密地耦合的容器-总是一起调度。Pod 中的容器共享一些资源，例如 linux 命名空间、文件系统卷和 cgroup：

Pod 的共享上下文是一组 Linux 命名空间、cgroup 以及可能的其他隔离方面。

此外，Pod 中的容器共享网络标识、IP 地址，并使用 localhost 在 Pod 内进行通信。我会考虑 Pod 内的信任，但您应该应用细粒度的Kubernetes 网络策略来锁定，例如 Pod 可以从哪些端口接收流量，以及来自哪些 Pod。