Cilium 网络策略中的 Kubernetes 结构：命名空间、ServiceAccount 与跨集群策略完全指南

Cilium 网络策略中的 Kubernetes 结构命名空间、ServiceAccount 与跨集群策略完全指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium导读Kubernetes 的安全模型建立在命名空间隔离与标签选择之上而 Cilium 的网络策略CiliumNetworkPolicy与CiliumClusterwideNetworkPolicy在此基础上提供了更细粒度、更强大的安全控制能力。本文以 Cilium 官方安全策略文档 为主线系统讲解如何在策略中正确使用命名空间、命名空间标签、ServiceAccount 身份、多集群ClusterMesh标签以及matchExpressions并完整收录仓库中所有配套示例 YAML 供直接参考。读完本文你将掌握基于 Kubernetes 原生结构编写精确、可落地的 Cilium 网络策略的完整方法论并规避常见的命名空间边界陷阱。命名空间Namespaces在策略中的角色Kubernetes 使用 Namespaces 在集群内创建虚拟集群。所有 Kubernetes 对象——包括NetworkPolicy和CiliumNetworkPolicy——都属于某个特定命名空间。在 Cilium 的策略体系中命名空间的影响主要体现在两个层面策略资源本身的归属CiliumNetworkPolicy是命名空间级别的 CRD它创建在哪个命名空间就只对哪个命名空间的 Pod 生效。标签选择器的语义Kubernetes 会自动为每个 Pod 注入k8s:io.kubernetes.pod.namespacenamespace标签因此可以通过该标签在fromEndpoints/toEndpoints中跨命名空间匹配端点。注意如果策略是直接通过 Cilium API 导入而非 Kubernetes CRD则策略默认应用于所有命名空间除非显式指定了命名空间选择器。这与 CRD 方式的行为不同是文档明确指出的第一类陷阱。已知陷阱命名空间边界的四大注意事项1. 命名空间边界的考量默认拒绝 同命名空间放行最常见的需求是按命名空间隔离对ns1和ns2中所有 Pod 启用默认拒绝default-deny然后仅放行同一命名空间内的通信。示例 isolate-namespaces.yaml 展示了完整写法apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: isolate-ns1 namespace: ns1 spec: endpointSelector: matchLabels: {} ingress: - fromEndpoints: - matchLabels: {} --- apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: isolate-ns1 namespace: ns2 spec: endpointSelector: matchLabels: {} ingress: - fromEndpoints: - matchLabels: {}这里的关键技巧是空标签选择器{}的特殊语义endpointSelector: {}匹配当前命名空间内的所有端点注意不是集群内全部端点fromEndpoints: [{matchLabels: {}}]则匹配与源端点处于同一命名空间的所有端点。两者组合即实现了同命名空间内自由通信跨命名空间全部拒绝的边界效果。重要限制该示例只锁定了ns1和ns2中 Pod 的ingress入站流量。这意味着这些 Pod 仍然可以自由地向集群外任意目的地发起 egress出站通信——除非目的地恰好位于ns1或ns2内此时要求源与目的必须在同一命名空间。若要在 egress 方向同样实施命名空间边界需要将相同的规则以 egress 形式再声明一遍。2. 策略仅作用于自身命名空间通过 CRD 创建并导入的CiliumNetworkPolicy和 Kubernetes 原生NetworkPolicy其作用域严格限定于策略资源所在的命名空间——策略只作用于该命名空间内的 Pod。不过可以按上文所述通过显式指定源/目的命名空间标签授予来自/发往其他命名空间 Pod 的访问权。示例 namespace-policy.yaml 将ns1中带标签nameleia的 Pod 暴露给ns2中带标签nameluke的 PodapiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: k8s-expose-across-namespace namespace: ns1 spec: endpointSelector: matchLabels: name: leia ingress: - fromEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: ns2 name: luke配套的完整可运行示例见 demo-pods.yaml其中创建了ns1、ns2两个命名空间ns1中部署了带nameleia标签的 Deployment 与同名 Servicens2中部署了带nameluke和namevader标签的两个 Pod用于验证仅luke可访问leiavader被拒绝的效果。3. 在 endpointSelector、fromEndpoints、toEndpoints 中指定命名空间支持的写法在fromEndpoints和toEndpoints中通过标签k8s:io.kubernetes.pod.namespace指定命名空间是被明确支持的。禁止的写法Kubernetes 出于命名空间隔离原则禁止在endpointSelector中指定命名空间——endpointSelector永远只匹配与CiliumNetworkPolicy资源自身同命名空间的 Pod。试图在endpointSelector中加入命名空间标签是无效且违反 Kubernetes 语义的。示例 kubedns-policy.yaml 允许public命名空间内所有 Pod 与kube-system命名空间中的 kube-dns 进行 53/UDP 通信apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: allow-to-kubedns namespace: public spec: endpointSelector: {} egress: - toEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: kube-system k8s-app: kube-dns toPorts: - ports: - port: 53 protocol: UDP注意endpointSelector: {}匹配public命名空间内全部 Pod而toEndpoints通过命名空间标签 k8s-app: kube-dns精确定位kube-system中的 DNS 服务。4. 使用命名空间标签Namespace Labels进行跨命名空间匹配Cilium 提供了一种更灵活的机制命名空间级别的标签注入。命名空间自身携带的标签如faction: alliance会以如下格式注入到该命名空间下所有 Pod 的安全身份中io.cilium.k8s.namespace.labels.label-key其中label-key对应 Kubernetes 命名空间上的某个标签键。关键语义当在fromEndpoints或toEndpoints选择器中使用命名空间标签时该选择器不会被隐式限制在策略自身的命名空间内——它可以根据命名空间标签跨命名空间匹配 Pod。这是与普通标签选择器的重要区别。注意无论fromEndpoints/toEndpoints中使用了多少命名空间标签endpointSelector始终只作用于策略资源自身命名空间内的 Pod。示例 namespace-labels-policy.yaml 将rebel-basePod 的出入站流量都限制在带有faction: alliance标签的命名空间内apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: alliance-only spec: endpointSelector: matchLabels: name: rebel-base ingress: - fromEndpoints: - matchLabels: io.cilium.k8s.namespace.labels.faction: alliance egress: - toEndpoints: - matchLabels: io.cilium.k8s.namespace.labels.faction: alliance这个例子的实际价值在于Rebel Alliance义军同盟横跨多个命名空间运营通过命名空间标签faction: alliance一条策略即可覆盖所有联盟命名空间无需逐个列出命名空间名称。matchExpressionsOR 与 AND 的正确打开方式在CiliumNetworkPolicy或CiliumClusterwideNetworkPolicy中使用matchExpressions时列表内的多个值按逻辑 AND 处理。若要对多个 key 实现逻辑 OR必须使用多条独立的matchExpressions。逻辑 OR多条 matchExpressions示例 or-statement.yaml 匹配来自production命名空间或带有k8s:cilium.example.com/policystrict标签的端点apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: or-statement-policy spec: endpointSelector: {} ingress: - fromEndpoints: - matchExpressions: - key: k8s:io.kubernetes.pod.namespace operator: In values: - production - matchExpressions: - key: k8s:cilium.example.com/policy operator: In values: - strict关键在于fromEndpoints下列出了两个独立的 selector 元素每个包含一条matchExpressions。Cilium 对fromEndpoints列表中的多个元素按 OR 合并因此命中任意一个即可放行。逻辑 AND单条 matchExpressions 多键示例 and-statement.yaml 则要求端点同时满足位于production命名空间且带有k8s:cilium.example.com/policystrict标签apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: and-statement-policy spec: endpointSelector: {} ingress: - fromEndpoints: - matchExpressions: - key: k8s:io.kubernetes.pod.namespace operator: In values: - production - key: k8s:cilium.example.com/policy operator: In values: - strict注意两者结构差异AND 版本把两个表达式放在同一条matchExpressions列表中OR 版本把它们拆成两条独立的matchExpressions。理解这一结构差异是避免策略意外放宽或收窄的关键。ServiceAccount基于工作负载身份的策略Kubernetes Service Accounts 为 Pod 或进程关联身份并授权该身份访问 Kubernetes 资源与 Secret。Cilium 支持直接基于 Pod 的 ServiceAccount 身份编写安全策略。Pod 的 ServiceAccount 既可以由 service account 准入控制器admission controller自动分配也可以在 Pod/Deployment/ReplicationController 中显式指定apiVersion: v1 kind: Pod metadata: name: my-pod spec: serviceAccountName: leia # ...示例 serviceaccount-policy.yaml 允许运行在lukeServiceAccount 下的任何 Pod向运行在leiaServiceAccount 下的 Pod 发起 TCP 80 端口的HTTP GET /public请求apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: k8s-svc-account spec: endpointSelector: matchLabels: io.cilium.k8s.policy.serviceaccount: leia ingress: - fromEndpoints: - matchLabels: io.cilium.k8s.policy.serviceaccount: luke toPorts: - ports: - port: 80 protocol: TCP rules: http: - method: GET path: /public$该策略同时展示了两个核心能力身份匹配Cilium 为每个端点注入io.cilium.k8s.policy.serviceaccount标签endpointSelector与fromEndpoints均可使用L7 HTTP 规则toPorts.rules.http中通过method与path正则/public$实现应用层HTTP访问控制这是 Cilium 相对 Kubernetes 原生NetworkPolicy的差异化能力。完整可运行示例见 demo-pods.yaml其中创建了leia、luke、vader三个 ServiceAccount并将它们分别绑定到leia-deployment、luke-pod和vader-pod。多集群ClusterMesh跨集群策略与集群标签当通过 ClusterMesh 连接多个集群时Cilium 会通过标签io.cilium.k8s.policy.cluster暴露集群名可用于将策略限制到特定集群。示例 cross-cluster-policy.yaml 允许cluster1中带标签namex-wing的 Pod访问cluster2的default命名空间中带标签namerebel-base的 PodapiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: allow-cross-cluster spec: description: Allow x-wing in cluster1 to contact rebel-base in cluster2 endpointSelector: matchLabels: name: x-wing io.cilium.k8s.policy.cluster: cluster1 egress: - toEndpoints: - matchLabels: name: rebel-base io.kubernetes.pod.namespace: default io.cilium.k8s.policy.cluster: cluster2关键细节规则中显式写明了io.kubernetes.pod.namespace: default确保策略作用于cluster2的default命名空间中的rebel-base而不受cluster1中x-wing所在命名空间的影响。常见陷阱如果省略策略规则中的命名空间标签其默认值会是策略自身被应用的命名空间——在跨集群场景下这往往不是预期行为。若要放行来自/发往任意命名空间的访问应使用matchExpressions配合Exists操作符如 cross-cluster-any-namespace-policy.yaml 所示apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: allow-cross-cluster-any-ns spec: description: Allow x-wing in cluster1 to contact rebel-base in cluster2 (in any NS) endpointSelector: matchLabels: name: x-wing io.cilium.k8s.policy.cluster: cluster1 egress: - toEndpoints: - matchExpressions: - key: k8s:io.kubernetes.pod.namespace operator: Exists - key: k8s:io.cilium.k8s.policy.cluster operator: In values: - cluster2 - key: k8s:name operator: In values: - rebel-base这里对k8s:io.kubernetes.pod.namespace使用Exists操作符所有 Pod 必然带此标签等价于不限制命名空间同时仍通过In操作符精确定位cluster2中的rebel-base。集群范围策略CiliumClusterwideNetworkPolicyCiliumNetworkPolicy只能绑定到特定命名空间。当需要集群级作用域的策略时应使用CiliumClusterwideNetworkPolicyCRD——其 spec 结构与CiliumNetworkPolicy完全相同区别仅在于它不是命名空间资源。示例 clusterscope-policy.yaml 允许任意命名空间中带nameluke标签的 Pod访问任意命名空间中带nameleia标签的 PodapiVersion: cilium.io/v2 kind: CiliumClusterwideNetworkPolicy metadata: name: clusterwide-policy-example spec: description: Policy for selective ingress allow to a pod from only a pod with given label endpointSelector: matchLabels: name: leia ingress: - fromEndpoints: - matchLabels: name: luke由于是集群范围资源endpointSelector不再受单一命名空间约束可跨全部命名空间匹配nameleia。允许所有 Cilium 管理端点访问 kube-dns在集群范围场景下一个高频需求是放行集群内所有 Cilium 管理端点访问 kube-dns。示例 wildcard-from-endpoints.yaml 给出了标准写法apiVersion: cilium.io/v2 kind: CiliumClusterwideNetworkPolicy metadata: name: wildcard-from-endpoints spec: description: Policy for ingress allow to kube-dns from all Cilium managed endpoints in the cluster endpointSelector: matchLabels: k8s:io.kubernetes.pod.namespace: kube-system k8s-app: kube-dns ingress: - fromEndpoints: - {} toPorts: - ports: - port: 53 protocol: UDPfromEndpoints中的空选择器{}在此表示匹配集群内所有端点区别于命名空间策略中仅匹配同命名空间端点的语义从而放行全集群对 kube-dns 的 53/UDP DNS 查询。示例添加健康端点Health EndpointCilium 内置健康检查机制cilium-health用于验证集群连通性。示例 health.yaml 通过策略将health实体纳入所有 Cilium 管理端点以支持连通性健康检查apiVersion: cilium.io/v2 kind: CiliumClusterwideNetworkPolicy metadata: name: cilium-health-checks spec: endpointSelector: matchLabels: reserved:health: ingress: - fromEntities: - remote-node egress: - toEntities: - remote-node该策略使用reserved:health这一保留标签选中健康端点并通过fromEntities/toEntities中的remote-node实体放行健康检查流量在远程节点之间双向通行。实战要点速查表需求使用的选择器/标签关键注意点命名空间内全放行、跨命名空间拒绝endpointSelector: {}fromEndpoints: [{matchLabels: {}}]仅作用于 ingressegress 需单独声明跨命名空间指定访问k8s:io.kubernetes.pod.namespace: ns只能在fromEndpoints/toEndpoints中使用按命名空间标签匹配io.cilium.k8s.namespace.labels.key: value选择器不会隐式限制在策略自身命名空间多 key 逻辑 OR多条独立matchExpressions列表内多值为 AND多列表元素为 OR基于身份匹配io.cilium.k8s.policy.serviceaccount可叠加toPorts.rules.http实现 L7 控制跨集群限制io.cilium.k8s.policy.cluster省略命名空间标签时默认取策略自身命名空间集群级作用域CiliumClusterwideNetworkPolicyendpointSelector可跨全部命名空间放行全部端点访问某服务fromEndpoints: [{}]空选择器在集群范围策略中匹配所有端点总结Cilium 将 Kubernetes 的命名空间、标签、ServiceAccount 等原生结构深度集成进其策略引擎使安全模型既符合 Kubernetes 的隔离哲学又能跨越这些边界实现精细化管控。撰写策略时需要牢记四条核心原则作用域意识CiliumNetworkPolicy只作用于自身命名空间endpointSelector永远不能指定命名空间方向意识命名空间边界策略需同时考虑 ingress 与 egress 两个方向选择器语义理解空选择器{}在命名空间策略与集群范围策略中的不同含义以及matchExpressions的 OR/AND 结构差异标签机制命名空间标签io.cilium.k8s.namespace.labels.*与集群标签io.cilium.k8s.policy.cluster是实现跨命名空间、跨集群控制的核心工具。文中所有示例均可在仓库的 examples/policies/kubernetes 目录下找到对应 YAML 文件策略定义的完整 API 参考见 api/v1 目录下的 proto/Go 定义可直接作为编写生产级策略的模板。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考