—— 使用 NetworkPolicy ——
限制 Pod 相互通信
NetworkPolicy Editor(https://editor.cilium.io/)是一个很好的 UI 工具,可以用于生成 Networkploicy,下面是一个示例。
这会选择当前命名空间中的特定 Pod 来匹配该策略。 白名单入口规则列表。每个规则都允许与 from 部分匹配的流量。
可以在 ingress from 部分中指定四种选择器:
ipBlock: 会选择特定的 IP CIDR 范围以允许作为入口源。通常这是集群外部 IP,因为 Pod IP 是临时的。
podSelector: 会在与 NetworkPolicy 相同的命名空间中选择特定的 Pod,这些 Pod 应该被允许作为入口源或出口目的地。
namespaceSelector: 会选择特定的命名空间,所有 Pod 都应该被允许作为入口源或出口目的地。
namespaceSelector和 podSelector: 指定 namespaceSelector 和 podSelector 的单个 from 条目选择特定命名空间内的特定 Pod。
—— 使用 NetworkPolicy ——
配置多租户隔离
现在让我们使用 NetworkPolicy 来配置隔离。
下面的 yaml 将在不同命名空间的服务之间建立隔离,只允许同一命名空间的 Pod 相互通信,同时也允许从 ingress 和监控 Pod 传入通信:
networkPolicy.yaml
现在将策略应用于两个示例命名空间中:
应用上述 networkPolicy.yaml 后,你需要设置好 ingress Pod 或 监控 Pod 的白名单。
现在让我们再次尝试之前的 curl 来检查 Pod 之间的通信:
现在你应该看到,不同命名空间之间的通信被阻止了,但同一命名空间内是可以正常通信的。
—— 调试 NetworkPolicy 通信 ——
NetworkPolicy 能够看到由于匹配的 NetworkPolicy 而丢弃的数据包。由于网络规则是通过 KUBE-BWPLCY 链中的 iptables 部署的,我们可以在当前运行 Pod 的节点上看到这些规则。因此,让我们检查生成的 iptables。
首先,我们需要检查 Pod 是在哪个节点上运行。
登录到 node2,并获取 iptables 的 KUBE-NWPLCY 链:
现在我们观察链 KUBE-NWPLCY-EM64V3NXOUG2TAJZ(在你的环境中会有不同的名称),它是 allow-same-namespace namespace sample1,同时再次运行 curl 测试:
你会看到在运行 curl 测试期间,计数器不断变化,显示已接受和已丢弃的数据包。
被网络策略丢弃的数据包也可以被记录下来。被丢弃的数据包被发送到 iptables NFLOG,它显示了数据包的详细信息,包括阻止它的网络策略。
要将 NFLOG 转换为日志条目,可以安装 包并将 [log1] 配置为在 group=100 上读取。然后,重新启动 ulogd2 服务提交新配置。
要将所有这些数据包记录到文件中,ulogd2 需要在 中进行配置,示例如下:
修改配置文件后,重启 ulogd:
如果数据包被网络策略规则阻止,日志消息将出现在 中:
如果有大量的流量,日志文件可能增长得非常快。为了控制这种情况,通过在相关的网络策略中添加以下注释,适当地设置 "limit "和 "limit-burst "iptables 参数:
参考:
Kubernetes Network Policies:https://kubernetes.io/docs/concepts/services-networking/network-policies
K3s:https://github.com/k3s-io/k3s/blob/master/README.md
强化指南 – NetworkPolicies:https://docs.k3s.io/security/hardening-guide#networkpolicies
K3s Network Policy:https://docs.k3s.io/advanced#additional-network-policy-logging
领取专属 10元无门槛券
私享最新 技术干货