This is the first part of a series of posts which will look into different types of network policies and create conflicting rules to observe the outcome. Tests in this series of posts have been performed using Minikube with the Cilium CNI, using a different CNI may change the observed results.
Demo environment
The Kubernetes environment used for this post will start with the following:
- 2 Namespaces
- np-deepdive-one
- np-deepdive-two
- 2 types of pods
- Web to test ingress policies
- BusyBox to perform the tests from
- A service for the web pod
Additional objects will be created through out the examples.
Manifests
Busybox pod
|
|
Web pod
|
|
Web service
|
|
Testing traffic flows
Traffic flow will be testing by running the following commands
Traffic within the same namespace:
|
|
Traffic different namespace:
|
|
We will know that traffic flow is allowed the web server responds with the default nginx page
|
|
Default Deny and Allow Policies
A default policy selects all pods in the namespace by setting the value of .spec.podSelector
to {}
, the value {}
specifies no criteria to filter anything from the list.
Default allow all ingress
The below manifest uses .spec.ingress[]: {}
to state that any traffic sources are ok.
|
|
Applying this to our namespace won’t have any noticeable affect as the default state is to allow all traffic.
All traffic tests pass with this network policy in place.
Default deny all ingress
To below manifest omits the .spec.ingress
field, stating that there are not valid traffic sources.
|
|
All traffic tests fail with this network policy in place as the traffic is not permitted into the web VM.
Default allow all egress
To below manifest uses uses .spec.egress[]:{}
to state that all destinations are valid.
|
|
All traffic tests will pass with this network policy in place.
Default deny all egress
To below manifest omits the .spec.egress
field which means there is no valid destination for traffic to go.
|
|
All tests fail with this policy applied.
Default rule what if scenarios
What happens if I apply both a default allow and a default deny ingress rule to the same namespace?
If have applied both the deny and allow ingress policies to the np-deepdive-one
namespace.
|
|
All tests pass because network rules are additive and the allow rule selects all pods. The same behaviour can be expected when applying a default deny and allow egress rules.
What happens if I apply both a default allow ingress and a default deny egress rule to the same namespace?
If have applied both the deny and allow ingress policies to the np-deepdive-one
namespace.
|
|
Tests from the busybox on on np-deepdive-one namespace fail. The nginx pod does not record any connection attempt in it’s debug log.
Tests from the busybox on on np-deepdive-two namespace pass because the egress deny rule only applies to pods in the np-deepdive-one namespace.
What happens if I apply both a default deny ingress and a default allow egress rule to the same namespace?
If have applied both the deny and allow ingress policies to the np-deepdive-one
namespace.
|
|
All tests fail as we are blocking all traffic into the web pod regardless of the source. The web pod show no connection activity as the traffic is dropped before reaching the pod.
Summary
In this post we looked at network policies which select all pods in the namespace and apply to all traffic sources and destinations; these policies are referred to as ‘default’ policies.
In the next network policy deepdive we will look at policies with different scopes and observe the behaviour of new conflicting policy sets.