However, this cluster has been installed with the CNI compliant OVNKubernetes SDN. This SDN is based on Open Virtual Network. Moving forward, this is the perfered SDN to use on OpenShift, and will be the default in future releases. OVNKubernetes is backwards compatible with OpenShiftSDN. To read more about OVNKubernetes, please read the official documentation.
Kubernetes NetworkPolicy allows projects to truly isolate their
network infrastructure inside OpenShift’s software defined network. While you
have seen projects isolate resources through OpenShift’s RBAC, the network policy
SDN plugin is able to isolate pods in projects using pod and namespace label selectors.
Only users with project or cluster administration privileges can manipulate Project network policies.
Execute a script that will create two Projects and then deploy a Deployment with a Pod for you:
support/create-net-projects.shTwo Projects were created for you, netproj-a and netproj-b. Execute the
following command to see the created resources:
oc get pods -n netproj-a -wAfter a while you will see something like the following:
NAME READY STATUS RESTARTS AGE
ose-1-66dz2 0/1 ContainerCreating 0 7s
ose-1-deploy 1/1 Running 0 16sSimilarly:
oc get pods -n netproj-b -wAfter a while you will see something like the following:
NAME READY STATUS RESTARTS AGE
ose-1-deploy 0/1 Completed 0 38s
ose-1-vj2gn 1/1 Running 0 30sWe will run commands inside the pod in the netproj-a Project that will
connect to TCP port 5000 of the pod in the netproj-b Project.
Now that you have some projects and pods, let’s test the connectivity between
the pod in the netproj-a Project and the pod in the netproj-b Project.
To test connectivity between the two pods, run:
support/test-connectivity.shYou will see something like the following:
Getting Pod B's IP... 10.129.0.180
Getting Pod A's Name... ose-1-66dz2
Checking connectivity between Pod A and Pod B... workedNote that the last line says worked. This means that the pod in the netproj-a Project was able to connect to the pod in the netproj-b Project.
This worked because, by default, the networkpolicy lets all pods in all projects can connect to each other.
With NetworkPolicy, it’s possible to restrict access in a project by creating a NetworkPolicy custom resource (CR).
For example, the following restricts all access to all pods in a Project where this NetworkPolicy CR is applied. This is the equivalent of a DenyAll default rule on a firewall:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: deny-by-default
spec:
podSelector:
ingress: []Note that the podSelector is empty, which means that this will apply to all pods in this Project. Also note that the ingress list is empty, which means that there are no allowed ingress rules defined by this NetworkPolicy CR.
To restrict access to the pod in the netproj-b Project simply apply the
above NetworkPolicy CR with:
oc create -n netproj-b -f support/network-policy-block-all.yamlSince the "block all by default" NetworkPolicy CR has been applied, connectivity between the pod in the netproj-a Project and the pod in the netproj-b Project should now be blocked.
Test by running:
support/test-connectivity.shYou will see something like the following:
Getting Pod B's IP... 10.129.0.180
Getting Pod A's Name... ose-1-66dz2
Checking connectivity between Pod A and Pod B............ FAILED!Note the last line that says FAILED!. This means that the pod in the netproj-a Project was unable to connect to the pod in the netproj-b Project (as expected).
To list all the NetworkPolicy objects, run the following:
oc get networkpolicy -n netproj-bYou should see something like the following:
NAME POD-SELECTOR AGE
deny-by-default <none> 3m19sWith NetworkPolicy, it’s possible to allow access to individual or groups of pods in a project by creating multiple
NetworkPolicy CRs.
The following allows access to port 5000 on TCP for all pods in the project
with the label run: ose. The pod in the netproj-b project has this label.
The ingress section specifically allows this access from all projects that
have the label name: netproj-a.
# allow access to TCP port 5000 for pods with the label "run: ose" specifically
# from projects with the label "name: netproj-a".
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-tcp-5000-from-netproj-a-namespace
spec:
podSelector:
matchLabels:
run: ose
ingress:
- ports:
- protocol: TCP
port: 5000
from:
- namespaceSelector:
matchLabels:
name: netproj-aNote that the podSelector is where the local project’s pods are matched
using a specific label selector.
All NetworkPolicy CRs in a project are combined to create the allowed
ingress access for the pods in the project. In this specific case the "deny
all" policy is combined with the "allow TCP 5000" policy.
To allow access to the pod in the netproj-b Project from all pods in the
netproj-a Project, apply the above NetworkPolicy CR with:
oc create -n netproj-b -f support/network-policy-allow-all-from-netproj-a.yamlListing the NetworkPolicies:
oc get networkpolicy -n netproj-bThis should show the new policy in place
NAME POD-SELECTOR AGE
allow-tcp-5000-from-netproj-a-namespace run=ose 81s
deny-by-default <none> 7m11sSince the "allow access from netproj-a on port 5000" NetworkPolicy has been applied,
connectivity between the pod in the netproj-a Project and the pod in the
netproj-b Project should be allowed again.
Test by running:
support/test-connectivity.shYou will see something like the following:
Getting Pod B's IP... 10.129.0.180
Getting Pod A's Name... ose-1-66dz2
Checking connectivity between Pod A and Pod B... workedNote the last line that says worked. This means that the pod in the
netproj-a Project was able to connect to the pod in the netproj-b
Project (as expected).