NetworkPolicy ingress rules — controlling inbound traffic

NetworkPolicy ingress rules control inbound traffic. The rules are allow-only; the union of all rules is the allow list. This lesson walks the ingress rules, the selectors, and the operational discipline.

The ingress rules

The ingress rules allow traffic from a set of sources:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: prod-app-allow-ingress
  namespace: prod-app
spec:
  podSelector:
    matchLabels:
      app: billing
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-gateway
      ports:
        - protocol: TCP
          port: 8080
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
      ports:
        - protocol: TCP
          port: 8080

The ingress rules allow traffic from the api-gateway Pods and from the monitoring namespace.

The selectors

The ingress rules support three selectors:

• podSelector: matches Pods in the same namespace.
• namespaceSelector: matches Pods in namespaces with the matching labels.
• ipBlock: matches IP blocks (e.g., external IPs).

flowchart LR
    A[Ingress rule] --> B[Pod selector]
    A --> C[Namespace selector]
    A --> D[IP block]
    B --> E[Selected Pods]
    C --> E
    D --> F[External IPs]

The selectors can be combined:

ingress:
  - from:
      - podSelector:
          matchLabels:
            app: api-gateway
      namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: prod-app

The combination is an AND; the source must match both selectors.

The default-deny ingress

The default-deny ingress is the basis of zero-trust:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: prod-app-default-deny-ingress
  namespace: prod-app
spec:
  podSelector: {}
  policyTypes:
    - Ingress

The podSelector: {} matches every Pod in the namespace. The policyTypes: Ingress declares ingress deny. The result is that every Pod in the namespace has no ingress by default.

The port rules

The ingress rules specify the ports:

ingress:
  - from:
      - podSelector:
          matchLabels:
            app: api-gateway
    ports:
      - protocol: TCP
        port: 8080
      - protocol: UDP
        port: 53

The port rules are allow-only; the union of all ports is the allow list.

The ipBlock

The ipBlock allows traffic from external IPs:

ingress:
  - from:
      - ipBlock:
          cidr: 192.0.2.0/24
          except:
            - 192.0.2.10/32
    ports:
      - protocol: TCP
        port: 8080

The ipBlock allows traffic from the IP block, with exceptions. The use case is allowing external traffic to specific services.

The failure modes

The ingress rules’ failure modes:

• Default-deny too strict: the default-deny blocks legitimate traffic. The fix is to add explicit allow policies.
• Selector mismatch: the rule does not match the intended Pods. The fix is to verify the selectors.
• Port mismatch: the rule does not match the intended ports. The fix is to verify the ports.
• CNI does not enforce: the CNI does not enforce NetworkPolicy. The fix is to switch to a CNI that enforces.

The operational discipline

The ingress rules’ operational discipline:

• Document the ingress rules. The rules are the cluster’s firewall.
• Audit the ingress rules at every change. The rules are critical security configuration.
• Test the ingress rules in staging. The rules must work for the workload.
• Monitor the ingress rules’ metrics. The CNI exposes NetworkPolicy metrics.
• Use the default-deny pattern. The default-deny is the basis of zero-trust.
• Plan the ingress rules’ evolution. The rules can be extended with CNI-specific resources.

Quiz

Production discipline

• The ingress rules are the cluster’s firewall. The cluster operator must treat them as critical security configuration.
• Document the ingress rules. The rules are the cluster’s firewall.
• Audit the ingress rules at every change. The rules are critical security configuration.
• Test the ingress rules in staging. The rules must work for the workload.
• Monitor the ingress rules’ metrics. The CNI exposes NetworkPolicy metrics.
• Use the default-deny pattern. The default-deny is the basis of zero-trust.
• Plan the ingress rules’ evolution. The rules can be extended with CNI-specific resources.
• Document the troubleshooting. The troubleshooting is the cluster’s operational reference.
• Train the security team on the ingress rules. The rules are the basis of the cluster’s security.