Kubernetes does not come secure out of the box. There is a lot of configuration needed
to achieve a secure cluster. One important security configuration to consider is how pods
communicate with each other. This is where Network Policies come into play, making sure that
your pods are not exchanging data with unknown or malicious sources, which can compromise
Network Policies are rules on how pods can communicate
with other pods as well as endpoints. They are pretty much a firewall for your internal cluster network.
The video below provides an introduction on how to easily implement Network Policies from GitLab,
as well as a demo on testing Network Policies:
Network Policies in action
There are many different ways of configuring Network Policies within your Kubernetes cluster. You can configure
ingress from as well as the
egress to traffic. There are four kinds of selectors
which can be used to configure traffic between pods:
- podSelector: Selects provided pods in the same namespace
- namespaceSelector: Selects all pods on given namespace
- podSelector & namespaceSelector: Selects provided pods in given namespace
- ipBlock: Blocks external IP CIDR ranges provided
More information on the behavior of "to" and "from" selectors can be found in the Kubernetes documentation.
Below is an example of a Network Policy that only allows ingress traffic
to pod with label
app: "notes" from pods with label
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-notes spec: podSelector: matchLabels: app: "notes" ingress: - from: - podSelector: matchLabels: access: "true"
Installing Cilium as a GitLab-managed application
Cilium is provided by GitLab as a managed application, meaning
that GitLab installs and upgrades Cilium for you. There is no need
to worry about how to get Cilium up and running. Cilium as well as your Network
Policies can be configured as needed.
In order to install and configure Cilium as a GitLab managed application, you can follow the steps provided in
the GitLab cluster applications documentation.
This sample project Simply Simple Notes, is configured to use Cilium. It will install Cilium on the Kubernetes cluster associated with the project.
This guide can be used to test your Network Policies once Cilium has been installed.
Threat monitoring dashboard
By default Cilium installs with Hubble, a monitoring daemon which collects packet flow metrics per namespace. These
metrics are sent to the GitLab Threat Monitoring dashboard.
Packet Metrics displayed in the Threat Management dashboard
The packet flow metrics collected are:
- The total number of inbound and outbound packets for the given time period
- The proportion of packets dropped according to the configured policies
- The average rate per-second of forwarded and dropped packets for the requested time interval
Within the Threat Monitoring dashboard, you can also view and configure the Network Policies in your project. This makes it easy to navigate
your container network configuration in one interface.
Network Policies displayed in the Threat Management dashboard
Network Policies can also be created and edited through an intuitive UI. You can just select the network rules you wish to use and the YAML will be automatically created and applied to your cluster. This eliminates the need to edit the complicated YAML structure for Network Policies directly, and allows you to make sure the correct rules are being applied without confusion.
Network Rules can be created using the following rule types:
- Level 4
Policy being created in the Threat Management dashboard
Learn more about GitLab Security
I hope this blog can help get you started with Network Policies in Kubernetes. Check out some other
ways GitLab can help with security.
- How application security engineers can use GitLab to secure their projects
- How to capitalize on GitLab Security tools with external CI
- What you need to know about Kubernetes RBAC