NetworkPolicy in Kubernetes Ingress and Egress
Network policies are an important construct in Kubernetes to control traffic flow between pods and namespaces in a cluster. They allow implementing restrictions and zero-trust security models for communications within a Kubernetes environment.
In this comprehensive tutorial, we will learn how to use network policies for ingress and egress traffic management in a Kubernetes cluster.
We will start by covering the prerequisites like ensuring network policy support is enabled in your Kubernetes offering and the necessary admission controllers are configured. After that, we dive into ingress network policies - defining rules to restrict inbound traffic to pods from authorized namespace, IP blocks or selector criteria. Useful examples are provided to allow traffic only from specific labeled pods or namespaces.
We also extensively cover egress network policies which regulate the outbound connections allowed from pods in the cluster. Egress rules can limit outbound traffic to approved destination IP ranges, namespaces or pod selections. Default deny all egress rules are explained which provide baseline security by blocking all traffic and requiring explicit access to be allowed through policies.
Finally, the tutorial covers policy examples to implement default ingress and egress deny configurations. These establish secure-by-default paradigms through blocking all access by default, which then needs to be selectively opened up through allow policies. Detailed examples are provided to create such default deny behaviors for namespaces and labeled pods.
By the end, you will gain a comprehensive understanding of the various techniques to control pod-level traffic using Kubernetes network policies for both ingress and egress. This will help you secure pod communications and implement zero-trust models effectively within your Kubernetes clusters.
Prerequisites
Ingress NetworkPolicies
Ingress NetworkPolicies control the incoming traffic allowed to reach pods in a namespace. By default, pods accept traffic from any source (pod, node, external IP). Defining ingress rules allows restricting access to authorized sources only.
Some ways ingress policies can be defined:
podSelector:
matchLabels:
app: backend
Select Pods by Labels
The podSelector field selects target pods by label. We can select pods with labels like app=foo or role=backend.
Allow Traffic from Pods
Use from rules to allow ingress from specific pod sources:
from:
- podSelector:
matchLabels:
role: frontend
This allows traffic from pods with label role=frontend.
Namespace based Selection
Accept traffic from pods in particular namespaces only:
from:
- namespaceSelector:
matchLabels:
project: myapp
IP Block Allow List
Ingress can be allowed from IP blocks:
from:
- ipBlock:
cidr: 192.168.0.0/16
This allows IPs in 192.168.0.0/16 subnet.
Default Deny All
A default policy blocks all ingress traffic:
from: []
We then need to specify allow rules to open up access.
Multiple from Rules
Different from sources can be combined:
from:
- namespaceSelector:
matchLabels:
user: admin
- podSelector:
matchLabels:
role: monitoring
This allows the selected pods to receive traffic from namespaces labeled user=admin OR pods labeled role=monitoring. That covers some of the main patterns for controlling ingress traffic using Network Policies in Kubernetes.
Egress NetworkPolicies
Egress policies control the outbound traffic allowed from pods in namespaces. By default pods can connect to any remote IP address or destination. Defining egress rules allows restricting outgoing access.
Some ways egress can be limited:
Select Pods by Labels
The podSelector field selects pods by label to apply the policy:
podSelector:
matchLabels:
app: internal
Allow Access to IP Blocks
Egress can be allowed to specific IP blocks:
Recommended by LinkedIn
to:
- ipBlock:
cidr: 192.168.0.0/24
Access is allowed to IPs in 192.168.0.0/24 range.
Namespace based Egress
Allow connections to pods in specific namespaces:
to:
- namespaceSelector:
matchLabels:
name: prod
Pod Selector for Egress
Policies can allow egress to pods matching label selectors:
to:
- podSelector:
matchLabels:
role: frontend
Default Deny All
A default egress policy blocks all outgoing traffic:
to: []
Explicit allow rules needed then to allow access.
Combining Egress Rules
Different to rules can be provided allowing egress traffic to multiple destinations:
to:
- ipBlock:
cidr: 10.0.0.0/24
- namespaceSelector:
matchLabels:
name: staging
This allows the selected pods to connect to 10.0.0.0/24 CIDR range OR pods in the staging namespace.
That covers some of the main patterns for controlling egress using NetworkPolicies in Kubernetes.
Default Policies
Defining default ingress or egress deny policies is a good way to enforce restrictions by default. Any pod matching the NetworkPolicy selector will have all ingress/egress traffic blocked. We then need to explicitly define allow rules for specific traffic.
Some examples of default deny policies:
Ingress Default Deny
Block all incoming traffic:
ingress:
- from: []
Egress Default Deny
Disallow all outgoing traffic:
egress:
- to: []
Pod Selector
Apply default deny on pods labeled restricted=true:
podSelector:
matchLabels:
restricted: "true"
egress:
- to: []
Namespace Selector
Use a namespaceSelector to apply default policy to an entire namespace:
podSelector: {}
namespaceSelector:
matchLabels:
name: restricted
egress:
- to: []
This blocks egress for all pods in the restricted namespace.
We then define allow rules to open up authorized access for selected pods/namespaces:
ingress:
- from:
- namespaceSelector:
matchLabels:
name: allow
This allows ingress traffic from the allow namespace. Default deny makes policy intent and security configuration clearer. Allow rules then document specific access requirements rather than insecure defaults being opened.
Conclusion
And that wraps up our comprehensive overview of network policies for ingress and egress traffic management in Kubernetes. In this detailed tutorial, we started by covering the basic concepts and capabilities that network policies provide for regulating traffic between pods in a Kubernetes cluster.
We then explored a variety of practical examples and techniques to control ingress traffic into pods using namespace, IP block and pod selectors for authorization. Useful patterns were discussed such as allowing traffic only from pods with specific labels or namespaces. We also implemented similar egress network policies to restrict and limit outbound traffic from pods to approved destinations.
Importantly, we looked at applying default deny ingress and egress rules which establish a secure-by-default posture for pod traffic. These require explicit allow policies before any access is opened up. We also discussed recommendation to define namespace and pod level default deny rules to enforce zero-trust models.
By now you should have a good foundational understanding of the motivation behind network policies, the security capabilities they enable and some real-world techniques to leverage them for regulating ingress and egress pod traffic. These controls allow enforcing strict traffic management and zero-trust models within your Kubernetes clusters.
As next steps, go through the Kubernetes documentation to explore additional policy use cases and examples. Start applying network policies for your namespaces and try out some of the patterns discussed in this tutorial. They are a simple yet powerful construct to enhance security and zero-trust in your Kubernetes applications.