Network Policy with Examples
Contents
Network Policy Configuration⌗
If a Network Policy object is defined in a namespace, it acts as an explicit allow list and all other traffic is denied. If there is no Network Policy object, all traffic is allowed in to that namespaces.
In order to control traffic flows in between namespaces and pods, selectors inside the Network Policy objects are used to explicitly allow traffic.
Multiple networkpolicy objects can be created in the same namespace to make it clear which rules are allowing traffic through.
Allow Pod to Pod - Same Namespace⌗
To simply allow traffic between pods in the same namespace, this would be the yaml to apply:
The key part of this is spec.ingress[0].from[0].podSelector: {}
which allows traffic between all the pods matched in that namespaces.
This configuration will disable traffic from the openshift Ingress pods.
Allow Openshift Ingress⌗
An example to allow Openshift Ingress routes to any pod in the namespace
This will not allow traffic between pods inside the namespace, but will allow Openshift routes to communicate with their backing pod inside the namespace.
Allow Pod-Pod and Openshift Ingress⌗
The spec.ingress.from
is an array of allowed rules to be applied in the network policy, so can be chained together. For example, this will allow both the Openshift Ingress routes and pod - pod traffic, but will not allow other namespaces access into these pods.
Advanced Examples⌗
For these to work, either the pod or the namespaces or both require labels.
To label a namespace:
To label a pod: (Note: this will only persist for the lifetime of the pod. It will need to be defined to persist)
All pods in project A to a specific service/pod to project B⌗
In this example, we want all pods in project1
to be able to access pod2
in project2
In this example:
project2
has an existing network policy that only allows traffic between pods in that namespace (see Allow Pod to Pod).project1
has the labelingressname=project1
pod2
inproject2
has the labelname=pod2
- Namespace label
- Pod label
This will allow traffic in from namespace project1
to just pod2
:
Once this is created
Traffic is now able to reach pod2 from pods inside project1.
Specific pod in project A to a specific service/pod to project B⌗
Similarly to allowing all traffic in from a namespace label, here we can allow traffic in from a pod label that exists in the cluster.
In this example:
project2
has an existing network policy that only allows traffic between pods in that namespace (see Allow Pod to Pod).pod3
inproject2
has the label:ingressname=pod3
project1
has the labelname=project1
pod2
inproject1
has the label:name=project1-pod2
Pod label
Namespace label
This will now allow access from pod2
in project1
to pod3
in project2
Update existing Projects⌗
In order to update existing projects, all that is required is to add a NetworkPolicy object to the namespace. Should this interfere with the operation of the pods in that namespace, removing the object will restore the previous allow all state.
And to remove the network policy in case of issues;
Update Default Project Template⌗
To add a default Network Policy to every new project that is created, a new default project template will need to be defined.
First, generate a project template yaml:
Then add the desired default NetworkPolicy to the template. In this example it will allow all pods in the same namespace to communicate and any routes access to the pods.
Then create this template in the openshift-config namespace
Once the template is created, the project resource will need to be updated to use the new template.
First edit the project.config.openshift.io/cluster
resource
Then add the project template to spec
Now new projects will be created with a default NetworkPolicy