我们有一个 Kubernetes 部署,其中包含一个需要在 VPN 上的应用程序。我们通过在具有提升功能的 pod 内的 sidecar 容器中运行 openvpn-client 来实现此要求:
securityContext:
capabilities:
add:
- NET_ADMIN
我们希望更好地了解这种情况的影响,以及如果这个容器被入侵我们会暴露在多大的范围内。我们希望确保此容器中的代码 exec 无法查看或修改其他 pod 或主机节点上的数据包或网络配置。
我目前的假设是,由于每个 pod 都有一个隔离的网络命名空间,因此给予CAP_NET_ADMIN
pod 中的容器只是提供该命名空间内的功能。
但是,我还没有找到任何明确讨论使用securityContext
将功能分配给容器的影响的文档。有一些文档(如下所述)强烈暗示Kubernetes / Docker 将在这里提供足够的隔离,但我不是 100% 确定。
关于资源共享的 pods 文档 [1] 在这里给出了提示:
Pod 中的应用程序都使用相同的网络命名空间(相同的 IP 和端口空间),因此可以“找到”彼此并使用
localhost
. 因此,Pod 中的应用程序必须协调它们对端口的使用。每个 Pod 在一个平面共享网络空间中都有一个 IP 地址,该网络空间与网络上的其他物理计算机和 Pod 具有完全通信。
网络模型的网络文档有这样的说法:
Kubernetes IP 地址存在于
Pod
范围内 -Pod
共享其网络名称空间中的容器 - 包括它们的 IP 地址。这意味着一个容器内的容器都Pod
可以到达彼此的端口localhost
。这也意味着容器中的容器Pod
必须协调端口的使用,但这与 VM 中的进程没有什么不同。这称为“IP-per-pod”模型。
最后,我注意到这pod.spec.hostNetwork
是可配置的,默认为 false:
$ kubectl explain pod.spec.hostNetwork
KIND: Pod
VERSION: v1
FIELD: hostNetwork <boolean>
DESCRIPTION:
Host networking requested for this pod. Use the host's network namespace.
If this option is set, the ports that will be used must be specified.
Default to false.
[1] https://kubernetes.io/docs/concepts/workloads/pods/pod/#resource-sharing-and-communication
[2] https://kubernetes.io/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model