不知道安全专家对于容器流量的安全是怎么考虑的，我们以一个简单的K8S集群为例。
我想我们都同意在每个容器内运行 HTTPS 而不是 HTTP 更安全。我通常会在 Ingress 上配置 TLS，然后路由到同样配置了 TLS 的内部容器。
现代混合解决方案通常会安装代理 sidecar - 让我们以 Linkerd2 为例。Ingress 会将所有传入流量升级到 TLS，然后使用 Linkerd 的 TLS 将流量转发到 sidecar 代理。直到这里传输的所有内容都是 TLS 和安全的。我想知道，既然安全流量“已经到达”pod，容器是否也应该使用 TLS，或者在没有 TLS 的情况下与 sidecar 通信是否足够安全？我想听听容器和其 sidecar 之间的安全方面。sidecar 是否应该被视为独立容器，因此与容器的通信也应该是 TLS 安全的？
答案1
在需要为 Kubernetes 集群提供高级别安全性的环境中，现在通常会应用以下原则零信任网络对于 Kubernetes 集群中的网络，这通常意味着：
- 加密所有网络流量
- 对所有网络流量使用身份验证
- 细粒度的防火墙规则 - 适用于每个应用程序的微分段
- 使用 RBAC、服务帐户、JWT 和 OpenPolicyAgent 进行最小特权访问控制
前两点现在通常用 Service Mesh 产品来解决，例如Linkerd，Istio云提供商提供托管解决方案，例如AWS App Mesh。这些产品以 TLS 的形式在每个 Pod 之间应用加密，但也使用客户端证书和相互 TLS、mTLS 以自动化方式进行身份验证。服务网格通常具有控制平面例如，负责证书自动化轮换的部分。
第三点通常使用Kubernetes 网络策略获得动态但细粒度的防火墙规则，应用于每个应用实例 (Pod)，即使它可以动态地调度到集群中的不同节点。这些策略通常在更高级别声明，例如使用 Pod 标签而不是硬编码的 IP 地址。
我想知道，既然安全流量“已经到达”pod，容器是否也应该使用TLS，或者在没有TLS的情况下与sidecar通信是否足够安全？我想听听容器和sidecar之间的安全方面。sidecar是否应该被视为独立容器，因此与容器的通信也应该是TLS安全的？
Pod是 Kubernetes 中的调度单位，它们是紧密耦合的容器 - 始终一起调度。Pod 中的容器共享一些资源，如 Linux 命名空间、文件系统卷和 cgroup：
Pod 的共享上下文是一组 Linux 命名空间、cgroup 以及潜在的其他隔离方面。
此外，Pod 中的容器共享网络标识、IP 地址，并使用 localhost 在 Pod 内进行通信。我会考虑在 Pod 内建立信任，但你应该应用更细粒度的信任Kubernetes 网络策略例如锁定 Pod 可以在哪些端口接收流量，以及从哪些 Pod 接收流量。