Chapter 19 — Kubernetes network security

How it works

NetworkPolicy basics:

   - Namespaced. Selects pods by label. Applies to Ingress, Egress, or both.
   - DEFAULT: all traffic allowed. The moment ANY NetworkPolicy selects a
     pod for a direction, that pod becomes DEFAULT-DENY for that direction
     -- only explicitly-listed traffic is allowed.
   - Peers: podSelector (same ns), namespaceSelector, ipBlock (+ except),
     and ports.
   - ONLY enforced if the CNI supports it: Calico, Cilium, Antrea, Weave,
     Kube-router. flannel does NOT -> policies are silently inert.

   The must-have baseline, per namespace:
     # deny all ingress and egress
     apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata: { name: default-deny, namespace: core }
     spec:
       podSelector: {}
       policyTypes: ["Ingress", "Egress"]
   Then explicit allows:
     - allow DNS egress to kube-dns (UDP/TCP 53) -- forgetting this breaks
       everything.
     - allow ingress from the specific caller pods/namespaces on the
       service port.
     - allow egress to the specific downstream services.
     - allow egress to the API server only for pods that call it.
     - DENY egress to 169.254.169.254/32 (metadata) and to the node CIDR /
       kubelet port unless explicitly needed.

What plain NetworkPolicy can't do (use Cilium/Calico enterprise CRDs):

   - L7 rules (HTTP method/path, gRPC service/method, Kafka topic).
   - FQDN-based egress ("allow egress to api.stripe.com") -- plain policy
     is IP-based, and cloud service IPs are dynamic.
   - DNS-aware policy, cluster-wide policies, default policies, node
     egress, identity-based (not just label-based) rules.
   CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy and Calico
   GlobalNetworkPolicy give you these. FQDN egress is how you actually
   allowlist third-party APIs.

The service mesh layer (identity on every call):

   NetworkPolicy says "pod A CAN reach pod B on port 8080". It does NOT
   verify WHO is calling or authenticate the connection. A mesh (Istio,
   Linkerd, Cilium Service Mesh, Consul) adds:
     - automatic mTLS between workloads, with SPIFFE identities (Part 5) ->
       "reachable but refused" for anyone without the right identity.
     - AuthorizationPolicy: "only workloads with identity
       spiffe://.../core/web may call orders-api, method POST /orders".
     - telemetry: every call, with source and destination identity ->
       detection (Ch 54).
   Use BOTH: NetworkPolicy for coarse reachability (defence in depth,
   works even if the mesh sidecar is bypassed), mesh AuthorizationPolicy
   for identity-based L7 authz.

Other cluster-network exposure:

   [ ] Metadata endpoint: pods can hit 169.254.169.254 by default -> IMDS
       creds (Part 2). Block via NetworkPolicy egress deny + IMDSv2
       hop-limit-1 on nodes; on EKS use the "disable pod access to IMDS"
       setting or a network policy; GKE Workload Identity blocks the
       legacy metadata paths.
   [ ] The kubelet (:10250) and etcd (:2379-2380) should be unreachable
       from workload pods.
   [ ] Ingress controllers: TLS config (Part G1-7), rate limiting, WAF,
       and they often run privileged / hostNetwork -> treat as a sensitive
       workload.
   [ ] LoadBalancer/NodePort Services expose things outside the cluster --
       gate their creation by policy (Ch 18).
   [ ] DNS: CoreDNS is a high-value target (poison it -> redirect every
       service lookup). Lock down its RBAC and config; consider DNS
       policies.
   [ ] East-west by default: kube-proxy makes every Service reachable
       cluster-wide -- NetworkPolicy is the only thing narrowing it.