基于Calico的Kubernetes多Namespace服务访问限制问询及示例需求

Great questions! Let's break them down one by one with practical examples:

1. Restricting Service Access Within Namespace A Using Kubernetes Network Policy #

Absolutely—this is exactly what Kubernetes Network Policies were built for! By default, all pods in a cluster can communicate freely, so we can define a policy to explicitly allow traffic from Service B to Service A while blocking all other unapproved traffic (including Service C).

First, ensure your pods have consistent labels to target:

• Service A's pods: add a label like app: service-a
• Service B's pods: add a label like app: service-b
• Service C's pods: add a label like app: service-c

Here's a ready-to-use Network Policy for Namespace A:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-service-b-to-service-a
  namespace: namespace-a
spec:
  podSelector:
    matchLabels:
      app: service-a  # Targets all pods running Service A
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: service-b  # Only allows traffic from Service B's pods
    ports:
    - protocol: TCP
      port: 8080  # Replace with Service A's actual listening port

How this works: #

• The policy uses a whitelist model: any traffic not explicitly allowed gets blocked automatically.
• It only permits incoming traffic to Service A's pods from pods labeled app: service-b (Service B) on the specified port.
• Service C's pods will be denied access to Service A since they don't match the allowed pod selector.

2. Cross-Namespace Access Restrictions with Calico #

Yes, Calico handles this scenario perfectly—and it does so by fully supporting Kubernetes native Network Policies, plus offering extended capabilities if you need more granular control. Let's split this into two actionable steps:

Step 1: Block all traffic from Namespace B to Namespace A #

First, we'll set a default deny policy for Namespace A (blocks all incoming traffic unless explicitly allowed), then add a rule to reinforce the block on Namespace B:

# Default deny all ingress to Namespace A
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: namespace-a
spec:
  podSelector: {}  # Applies to every pod in Namespace A
  policyTypes:
  - Ingress

Step 2: Allow specific services from Namespace C to specific services in Namespace A #

Now, create a policy to explicitly permit traffic from your approved pods in Namespace C to target services in Namespace A. Let's assume:

• Target services in Namespace A: labeled app: critical-service-a
• Approved pods in Namespace C: labeled app: trusted-service-c

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-trusted-namespace-c-services
  namespace: namespace-a
spec:
  podSelector:
    matchLabels:
      app: critical-service-a  # Target specific services in Namespace A
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: namespace-c  # Target Namespace C
      podSelector:
        matchLabels:
          app: trusted-service-c  # Only allow these specific pods
    ports:
    - protocol: TCP
      port: 9090  # Replace with the target service's actual port

Why Calico works here: #

Calico fully implements the Kubernetes Network Policy API, so these rules will work out of the box. If you need more advanced controls (like IP range restrictions, HTTP header-based rules, or global policies), you can leverage Calico's custom ProjectCalico.org/v3 NetworkPolicy CRD for even more flexibility—but the native K8s policies above are sufficient for this use case.

内容的提问来源于stack exchange，提问作者user1578872