Implementing Common Security Patterns
Understanding the NetworkPolicy
structure and the rule logic allows us to implement various security postures. Let's look at some common patterns and how you would construct the relevant parts of the networkingv1.NetworkPolicySpec
in Go. Remember, these policies need a CNI plugin that enforces them (like Calico, Cilium, etc.) to be effective.
Pattern 1: Default Deny All (Namespace Isolation)
Goal: Block all ingress and all egress traffic for every Pod in a specific namespace. This creates a "zero-trust" starting point for the namespace.
Strategy: Create a NetworkPolicy that selects all Pods in the namespace (
podSelector: {}
) and specifiespolicyTypes: [Ingress, Egress]
but provides noingress
oregress
rules.YAML Equivalent:
Go
spec
Construction:
Pattern 2: Allow All Within Namespace (After Default Deny)
Goal: After implementing a default deny, explicitly allow all Pods within the same namespace to communicate freely with each other on any port, while still blocking traffic to/from other namespaces or external IPs.
Strategy: Create a policy selecting all Pods (
podSelector: {}
). Define aningress
rule allowing trafficfrom
any Pod in the same namespace (podSelector: {}
). Define anegress
rule allowing trafficto
any Pod in the same namespace (podSelector: {}
). Omitports
to allow all ports.YAML Equivalent:
Go
spec
Construction:
Pattern 3: Allow Specific Ingress (e.g., Frontend to Backend)
Goal: Allow ingress traffic only from Pods labeled
app=frontend
to Pods labeledapp=backend
on TCP port 8080. Deny all other ingress to the backend Pods.Strategy: Create a policy selecting the
backend
Pods. SetpolicyTypes: [Ingress]
. Define oneingress
rule allowing trafficfrom
Pods matchingapp=frontend
(podSelector
) to the specificport
(TCP 8080).YAML Equivalent:
Go
spec
Construction:
Pattern 4: Allow Specific Egress (e.g., Backend to Database + DNS)
Goal: Allow Pods labeled
app=backend
to initiate connections only to Pods labeledapp=database
on TCP port 5432, and also allow them to make DNS queries (to any Pod on UDP/TCP port 53). Deny all other egress.Strategy: Create a policy selecting
backend
Pods. SetpolicyTypes: [Egress]
. Define twoegress
rules (remember, rules within the list are ORed):Rule 1: Allows traffic
to
Pods matchingapp=database
(podSelector
) onport
TCP 5432.Rule 2: Allows traffic
to
any destination (omitto
or usepodSelector: {}
) but only onports
UDP 53 and TCP 53.
YAML Equivalent:
Go
spec
Construction:Note: Allowing DNS is crucial. If you implement default egress deny, you must explicitly allow DNS traffic, otherwise, Pods won't be able to resolve Service names or external hostnames.
Pattern 5: Allow Ingress from Outside Cluster (IP Block)
Goal: Allow ingress traffic from a specific external IP range (e.g.,
198.51.100.0/24
, maybe a corporate network or monitoring service) to Pods labeledrole=ingress-gateway
on TCP port 443.Strategy: Create a policy selecting the
ingress-gateway
Pods.policyTypes: [Ingress]
. Define oneingress
rule allowing trafficfrom
anipBlock
specifying the CIDR, to the specificport
(TCP 443).YAML Equivalent:
Go
spec
Construction:
These patterns provide a starting point. By combining these techniques – default deny, specific allows based on pod/namespace selectors or IP blocks, and careful port/protocol specification – you can construct sophisticated Network Policies using client-go
to enforce least-privilege network access for your Kubernetes applications.
Last updated
Was this helpful?