Network security
Module goals
-
Review the Network Dashboard
-
Create Network Policies that improve our CIS compliance.
Understanding the Network UI
The Network UI is broken into two tabs: the Network Graph & the Listening Endpoints tab.
The Network Graph
The Network Graph in RHACS provides a visual representation of the network traffic and relationships between different components within a Kubernetes cluster. This feature is crucial for understanding and managing the network security of Kubernetes clusters, as endpoint detection is not enough with containers. In Kubernetes and OpenShift, you need visibility on exposed services.
RHACS Network Graph helps you visualize network traffic by displaying the flow of network traffic between different pods, services, and namespaces within a Kubernetes cluster. The Network Graph also helps identify unusual or unexpected network traffic patterns. If there are unexpected connections or traffic flows between components that should not be communicating, these anomalies can be quickly spotted and investigated. By understanding the actual network traffic, security teams can create more precise network policies to restrict unnecessary communication paths and reduce the attack surface. The Network Policies can be generated at deploy-time or runtime.
The Exposed Ports dashboard
The Exposed Ports Dashboard gives users a clear and organized view of all the services in their Kubernetes cluster that are exposed to external networks.
BONUS: The roxctl netpol CLI command
The roxctl netpol command in Red Hat Advanced Cluster Security (RHACS) for Kubernetes offers several advantages that enhance network security management within Kubernetes environments. This command is part of the roxctl CLI tool, which is designed to interact with RHACS. The roxctl netpol command can automatically generate Kubernetes network policies based on the OpenShift and Kubernetes assets. This can be done in deploy-time by developers OR operators to help accerate network policy adoption.
Hands-on with the RHACS Network UI
CIS compliance reminder
In this module, we will focus on the backend namespace. Also, hopefully, you remember the complaint section where we were told how we could become CIS-compliant by applying network policies.
Run the following two commands to remember which namespaces are currently compliant.
cd ~/
export TUTORIAL_HOME="$(pwd)/demo-apps"
oc get --all-namespaces networkpolicies -o json | jq '[.items[] | select((.metadata.namespace | startswith("openshift") | not) and (.metadata.namespace | startswith("kube-") | not) and .metadata.namespace != "default") | .metadata.namespace] | unique'
Sample output
[
"medical",
"stackrox",
"vault"
]
Now, let’s aim to get the backend namespace on that list.
The Network Graph UI
-
Start by heading to the Network → Network Graph.
The graph does not display any results by default. This is a performance choice as large environments will become unweildly in a dashboard like this.
-
Use the filters at the top to select ONLY the backend namespace.
-
Review the legend at the bottom left of the page.
Notice how there is a namespace type labeled Related namespace. You should see two other namespaces related to the backend namespace. This is because there is network traffic between these three namespaces.
You can also filter by "Active flows" or "Inactive flows."
-
Click on the Network policy generator on the top right of the dashboard.
-
Click the View active YAMLS tab.
You should see no active YAMLs in the namespace since we have not created any network policies in the backend namespace.
-
Click the Simulate network policies and click Generate and simulate network policies
-
Click the Compare tab on the right side of the page.
This view is useful for making any changes to network policies. You will be able to visualize the changes in the UI.
We know the backend namespace needs some work. And while we can copy the simulated network policies from the UI, let’s do it later from the roxctl UI.
Using the roxctl netpol CLI
We’re going to use the roxctl netpol command to generate network policies based on the Backend applications.
First, let’s take a look at the four applications and all of their associated services.
-
Run the following command.
export TUTORIAL_HOME="$(pwd)/demo-apps"
cat $TUTORIAL_HOME/kubernetes-manifests/medical-application/backend/everything.yml
Sample output
# Deployment named "varnish"
# Listens on :8080
apiVersion: apps/v1
kind: Deployment
metadata:
name: varnish
.....
You can see the manifest contains EVERYTHING about the applications in the namespace.
The netpol command only looks at the services and deployment manifests to generate network policies. This is why it is extremely important that the deployments and service are properly configured first. |
-
Run the following command.
roxctl netpol connectivity map $TUTORIAL_HOME/kubernetes-manifests/medical-application/backend/everything.yml
....
backend/postgres[Deployment] => backend/api-server[Deployment] : All Connections
backend/postgres[Deployment] => backend/backend-atlas[Deployment] : All Connections
backend/postgres[Deployment] => backend/varnish[Deployment] : All Connections
backend/varnish[Deployment] => 0.0.0.0-255.255.255.255 : All Connections
backend/varnish[Deployment] => backend/api-server[Deployment] : All Connections
backend/varnish[Deployment] => backend/backend-atlas[Deployment] : All Connections
backend/varnish[Deployment] => backend/postgres[Deployment] : All Connections
This output is telling us that all connections are currently authorized into the backend namespace. The goal is to only allow the connections that are necessary for the applications to function.
-
Run the following command. This command will copy the network policy output to a "everything" file and will display what was added.
roxctl netpol generate $TUTORIAL_HOME/kubernetes-manifests/medical-application/backend/everything.yml >> $TUTORIAL_HOME/kubernetes-manifests/medical-application/backend/everything.yml
roxctl netpol generate $TUTORIAL_HOME/kubernetes-manifests/medical-application/backend/everything.yml
Now we have network policies! Time to put them to work
-
Apply the network policies with the following command.
oc apply -f $TUTORIAL_HOME/kubernetes-manifests/medical-application/backend/everything.yml
networkpolicy.networking.k8s.io/api-server-netpol created
networkpolicy.networking.k8s.io/backend-atlas-netpol created
networkpolicy.networking.k8s.io/postgres-netpol created
networkpolicy.networking.k8s.io/varnish-netpol created
networkpolicy.networking.k8s.io/default-deny-in-namespace-backend created
-
And go and verify that everything is green in the dashboard.
-
Lastly let’s check the netpol connecitons output AND our compliance command!
roxctl netpol connectivity map $TUTORIAL_HOME/kubernetes-manifests/medical-application/backend/everything.yml
oc get --all-namespaces networkpolicies -o json | jq '[.items[] | select((.metadata.namespace | startswith("openshift") | not) and (.metadata.namespace | startswith("kube-") | not) and .metadata.namespace != "default") | .metadata.namespace] | unique'
INFO: in file: /home/lab-user/demo-apps/kubernetes-manifests/medical-application/backend/everything.yml, skipping object with type: Secret
...
backend/varnish[Deployment] => backend/api-server[Deployment] : TCP 9001
[lab-user@bastion ~]$ oc get --all-namespaces networkpolicies -o json | jq '[.items[] | select((.metadata.namespace | startswith("openshift") | not) and (.metadata.namespace | startswith("kube-") | not) and .metadata.namespace != "default") | .metadata.namespace] | unique'
[
"backend",
"medical",
"stackrox",
"vault"
]
And we see that there is only ONE! External connection to the namespace. All other connections are shut down.
A task to complete on your own.
LAST ONE
Use the 'roxctl netpol generate' command on the rest of the Kubernetes manifests in the $TUTORIAL_HOME/kubernetes-manifests/ folder. Apply these changes and view the updates in the Network Graph UI.
What is the CIS compliance standard percentage at now? == Summary
In this module you got hands-on in the Network graph UI and used the netpol generate command to create and apply network policies to the OpenShift cluster.
Congrats!!!
You’ve made it through the Roadshow! There are a few extra modules for you to work through.
Thank you for all of your hard work!