Enforce Kubernetes NetworkPolicies with Cilium

Why this step matters

Selectors are the policy's identity inputs. Stable, owned labels make rules readable and prevent unexpected Pods from entering trusted source or destination sets.

What to understand

Use built-in `kubernetes.io/metadata.name` for exact namespace matching when appropriate, and organization labels for lifecycle tiers only when admission protects them.

Select application labels controlled in Deployment templates, not generated pod-template hashes or mutable debugging labels.

Before policy apply, list every selected Pod and every intended peer. An empty selector match can create false confidence; an overly broad match can cause outage.

Namespace labels affect every policy that references them. Change through reviewed manifests and search existing selectors before overwriting a value.

Admission policy should reserve trust-bearing label prefixes for platform automation or authorized groups.

System changes

• Adds or changes a namespace label that may affect current and future NetworkPolicy selectors.
• Does not modify Pod labels in this command; workload labels remain owned by deployment manifests.

Syntax explained

--overwrite

Changes an existing label value and therefore requires review of every selector using that key.

kubernetes.io/metadata.name

Stable built-in namespace label useful for exact name selection without custom label drift.

Why this step matters

Deterministic canaries turn policy intent into executable acceptance tests. Separate client labels prove selector boundaries instead of relying on one happy-path connection.

What to understand

Pin test images by digest in production repositories and remove tools after validation. The sample upstream image is illustrative and must undergo the same supply-chain review as any workload.

Disable service-account token automount because network canaries do not need Kubernetes API credentials.

Create one stable Service and named backend port, then confirm EndpointSlice readiness before policy. This separates service discovery failures from enforcement.

Run baseline probes for DNS, allowed backend port, wrong port, untrusted client, unrelated namespace, and external egress. Record exact expected transitions after each rule.

Apply restrictive Linux security context and resource limits in the complete manifest even though the excerpt focuses on networking.

System changes

• Creates disposable Deployments and a Service in {{policyNamespace}} that generate controlled test traffic.
• Introduces test image and Pod identities that must be removed after validation if not retained as continuous probes.

Syntax explained

automountServiceAccountToken:false

Keeps network testing from distributing an unrelated API credential.

targetPort:http

Maps Service traffic to the named container port while policy can allow the numeric or named port deliberately.

Why this step matters

An explicit empty allow set creates the boundary from which dependencies are added. Applying it to a canary namespace proves the implementation and selection before production.

What to understand

An empty podSelector selects all Pods in the policy namespace; it does not mean no Pods. Both policyTypes isolate both directions.

No ingress or egress arrays are present, so the policy allows nothing. Existing additive policies can still allow traffic and must be included in analysis.

Expect DNS and application probes to time out. That failure is the planned checkpoint proving enforcement, not an incident in a dedicated canary scope.

Observe drop verdicts and endpoint policy state. Application timeout alone could come from many unrelated failures.

Apply this as a separate object so rollback can delete one policy without changing future allow rules or creating a global allow.

System changes

• Selects every Pod in {{policyNamespace}} for ingress and egress isolation.
• Immediately denies traffic not allowed by another matching policy, including DNS and health dependencies.

Syntax explained

podSelector:{}

Selects all Pods in the policy namespace.

policyTypes:[Ingress,Egress]

Activates isolation for both incoming and outgoing connection initiation.

Why this step matters

Egress isolation commonly breaks service discovery first. A narrow DNS rule restores only verified DNS Pods and both transport modes instead of opening the entire system namespace.

What to understand

Inspect live CoreDNS or node-local DNS labels before substituting variables. Managed distributions may use different labels or an IP path outside ordinary Pods.

The namespaceSelector and podSelector in the same `to` entry are conjunctive: the peer must match both namespace and Pod labels.

Permit TCP 53 as well as UDP because large responses, truncation, DNSSEC, and resolver behavior can require TCP fallback.

This rule allows DNS queries but not every destination returned. Other egress remains denied until a separate policy permits it.

For Cilium FQDN policy, ensure DNS is observed through the proxy path documented by Cilium; bypass resolvers can undermine name-based enforcement.

System changes

• Allows all selected Pods in {{policyNamespace}} to send DNS traffic to the exact cluster DNS Pod identity on UDP and TCP 53.

Syntax explained

namespaceSelector + podSelector

Matches DNS Pods only when both the namespace and Pod labels are correct.

UDP/TCP 53

Supports ordinary queries and legitimate TCP fallback without opening other DNS-Pod ports.

Why this step matters

When both endpoints are isolated, the connection needs source egress and destination ingress permission. Separate policies make each selected endpoint and direction auditable.

What to understand

The podSelectors are namespaced because no namespaceSelector is present. They match only Pods in {{policyNamespace}}, preserving a simple identity boundary.

The egress rule permits checkout to ledger on one TCP port. The ingress rule permits ledger to receive only from checkout on the same port.

Stateful reply traffic returns automatically. Do not add a broad reverse initiation rule merely for responses.

Test untrusted-to-ledger, checkout-to-wrong-port, ledger-to-checkout initiation, and unrelated namespace paths as denied.

Named ports improve intent but their resolution has implementation nuances; the numeric example is explicit and must match the Service and container listener.

System changes

• Allows {{clientLabel}} Pods to initiate TCP {{backendPort}} to {{backendLabel}} Pods and permits those backends to accept that flow.
• Leaves all other ingress and egress denied by the namespace baseline unless another policy allows it.

Syntax explained

podSelector app={{clientLabel}}

Selects the source workload for egress and trusted peer for backend ingress.

port: {{backendPort}}, protocol: TCP

Restricts the allowance to the exact application listener.

Why this step matters

Cross-namespace traffic should match both a reviewed namespace and a reviewed workload identity. Separate peer entries would be ORed and could accidentally allow an entire namespace or same-namespace Pods.

What to understand

A namespaceSelector and podSelector within the same `from` item are ANDed. Two separate list items represent alternatives and therefore broaden access.

Verify the ingress controller's live labels and ownership. Distribution-specific labels may differ from the example and must not be guessed.

Use the built-in namespace-name label for exact namespace selection. Custom environment labels are useful only when protected and intentionally multi-namespace.

Test a controller Pod, a non-controller Pod in ingress-nginx, and a controller-like label in another namespace to prove conjunction.

Ingress controller source identity can change with host networking, proxies, or source NAT. Hubble evidence must show the identity actually seen at the backend.

System changes

• Allows exact ingress-controller Pods in the ingress-nginx namespace to initiate TCP {{backendPort}} to ledger.

Syntax explained

namespaceSelector and podSelector in one item

Requires both namespace and workload labels, avoiding an unintended OR.

kubernetes.io/metadata.name

Uses Kubernetes' stable namespace-name label for an exact namespace.

Why this step matters

Standard NetworkPolicy can express stable IP-based egress, but external SaaS addresses and translated in-cluster traffic may not provide a durable IP contract. Use CIDRs only when ownership and change process are explicit.

What to understand

198.51.100.40 is a documentation address and will not represent a real service. Replace it only with a reviewed destination whose operator guarantees the address range.

A /32 is narrower than a provider-wide range, but availability may require multiple addresses. Each addition needs ownership and expiry review.

IPBlock behavior can interact with pre- or post-policy NAT. Test the actual cluster routing, cloud SNAT, service mesh, and egress gateway path.

Do not use 0.0.0.0/0 with exceptions as a shortcut unless broad internet egress is the approved requirement and metadata or private ranges are controlled elsewhere.

For dynamic hostnames, use the optional Cilium FQDN rule or a controlled proxy rather than continuously chasing IPs in portable manifests.

System changes

• Allows {{clientLabel}} Pods to initiate TCP {{approvedExternalPort}} to one exact external IPv4 address.

Syntax explained

ipBlock.cidr /32

Matches one IPv4 address independently of Kubernetes Pod labels.

ports TCP {{approvedExternalPort}}

Limits connection initiation to the approved application port.

Why this step matters

Cilium's DNS-aware policy tracks IPs returned for an approved name and can express a requirement that standard NetworkPolicy cannot. Keeping it separate makes implementation dependency and rollback obvious.

What to understand

This resource requires Cilium CRDs and DNS proxy behavior. Another NetworkPolicy provider will not enforce it and may not even serve the API.

The DNS rule permits queries to the verified cluster DNS identity and asks the proxy to observe names. A broad matchPattern for DNS queries does not itself grant connectivity to every resolved destination.

`matchName` is exact. Use matchPattern only when wildcard semantics are justified, and understand that CNAME chains and DNS behavior can expand the learned address set.

FQDN policy maps names to current IPs; it does not authenticate the remote service. TLS hostname and chain validation remain necessary.

Application DNS caching, alternate resolvers, encrypted DNS, or direct IP use can conflict with this model. Force all workload DNS through the observed, approved path.

Do not combine the first FQDN rollout with L7 HTTP rules. Measure name-based behavior first, then evaluate application-layer requirements separately.

System changes

• Creates a Cilium-specific policy that redirects or observes DNS and allows current IPs learned for {{approvedExternalFqdn}} on TCP {{approvedExternalPort}}.
• Introduces an implementation dependency that must be replaced during any CNI migration.

Syntax explained

apiVersion:cilium.io/v2

Selects Cilium's extension API; it is intentionally not portable Kubernetes NetworkPolicy.

toFQDNs.matchName

Allows IPs learned from DNS responses for exactly {{approvedExternalFqdn}}.

rules.dns matchPattern:*

Lets the selected client perform DNS queries through the approved resolver so Cilium can observe responses; destination egress remains separately constrained.