CNI-specific NetworkPolicy extensions — Calico and Cilium

The CNI-specific NetworkPolicy extensions include Calico GlobalNetworkPolicy (cluster-wide policies) and Cilium CiliumNetworkPolicy (FQDN, L7, and identity- based policies). The extensions enable policies that the standard NetworkPolicy cannot express. This lesson walks the extensions, the use cases, and the operational discipline.

The standard NetworkPolicy’s limitations

The standard NetworkPolicy supports:

• Pod selectors, namespace selectors, ipBlock.
• Ingress and egress rules.
• TCP, UDP, SCTP protocols.
• Named ports.

The standard NetworkPolicy does NOT support:

• Cluster-wide policies (you need to apply per- namespace).
• FQDN-based egress (you can only use IP blocks).
• L7 attributes (HTTP method, gRPC service).
• Identity-based policies (you can only use labels).

The CNI-specific extensions address these limitations.

Calico GlobalNetworkPolicy

The Calico GlobalNetworkPolicy is the cluster-wide policy:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  selector: all()
  types:
    - Ingress

The selector: all() matches every Pod in the cluster. The types: Ingress declares ingress deny. The result is that every Pod in the cluster has no ingress by default.

The GlobalNetworkPolicy supports more features than the standard NetworkPolicy:

• ICMP: filter ICMP traffic.
• Action: allow, deny, log, pass.
• ServiceAccount: filter by ServiceAccount.
• HTTP: filter HTTP methods and paths (Calico 3.28+).

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-monitoring-egress
spec:
  selector: app == 'billing'
  types:
    - Egress
  egress:
    - action: Allow
      destination:
        serviceAccounts:
          name: prometheus
          namespace: monitoring
      protocol: TCP
      destination:
        ports:
          - 9090

The Calico GlobalNetworkPolicy supports ServiceAccount- based selectors.

Cilium CiliumNetworkPolicy

The Cilium CiliumNetworkPolicy is the extended policy:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: prod-app-fqdn-egress
  namespace: prod-app
spec:
  endpointSelector:
    matchLabels:
      app: billing
  egress:
    - toFQDNs:
        - matchPattern: "api.example.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

The toFQDNs matches the FQDN. The Cilium agent resolves the FQDN via DNS and adds the IP to the policy.

sequenceDiagram
    autonumber
    participant API as API server
    participant C as Cilium agent
    participant P as Pod
    participant DNS as DNS
    C->>DNS: lookup api.example.com
    DNS-->>C: 192.0.2.10
    C->>C: add IP to policy
    P->>API: HTTP api.example.com
    API->>P: response

The Cilium agent resolves the FQDN and updates the policy dynamically.

The CiliumNetworkPolicy supports more features:

• L7 attributes: HTTP method, gRPC service, Kafka topic.
• Identity-based: Cilium identities (based on labels, ServiceAccounts, etc.).
• ICMP: filter ICMP traffic.
• DNS: filter by DNS name.

The use cases

The CNI-specific extensions’ use cases:

• Cluster-wide policies: GlobalNetworkPolicy matches every Pod in the cluster.
• FQDN-based egress: CiliumNetworkPolicy matches DNS names.
• L7 policies: CiliumNetworkPolicy matches HTTP methods and gRPC services.
• ServiceAccount-based selectors: Calico’s GlobalNetworkPolicy matches ServiceAccounts.
• Multi-tenancy: the extensions enable multi- tenant policies.

The failure modes

The extensions’ failure modes:

• CNI not supported: the CNI does not support the extension. The fix is to switch to a CNI that supports the extension.
• DNS resolution failure: the FQDN-based policy cannot resolve the DNS. The fix is to verify the DNS configuration.
• Selector mismatch: the selector does not match the intended Pods. The fix is to verify the selector.
• Migration failure: the migration from the standard NetworkPolicy to the extension fails. The fix is to verify the migration.

The operational discipline

The extensions’ operational discipline:

• Document the extensions. The extensions are the cluster’s firewall configuration.
• Audit the extensions at every change. The extensions are critical security configuration.
• Test the extensions in staging. The extensions must work for the workload.
• Monitor the extensions’ metrics. The CNI exposes NetworkPolicy metrics.
• Plan the extensions’ evolution. The extensions can be replaced with the standard NetworkPolicy or with Gateway API.
• Document the troubleshooting. The troubleshooting is the cluster’s operational reference.

Quiz

Production discipline

• CNI-specific extensions are CNI-specific. The cluster operator must verify the CNI supports the extensions.
• Document the extensions. The extensions are the cluster’s firewall configuration.
• Audit the extensions at every change. The extensions are critical security configuration.
• Test the extensions in staging. The extensions must work for the workload.
• Monitor the extensions’ metrics. The CNI exposes NetworkPolicy metrics.
• Plan the extensions’ evolution. The extensions can be replaced with the standard NetworkPolicy or with Gateway API.
• Document the troubleshooting. The troubleshooting is the cluster’s operational reference.
• Train the security team on the extensions. The extensions are the basis of the cluster’s security.
• Use the standard NetworkPolicy where possible. The standard NetworkPolicy is portable; the extensions are CNI-specific.