Untangling Network Policies on K8s
Network Policy is a critical part of building a robust developer platform, but the learning curve to address complex real-world policies is not tiny. It is painful to get the YAML syntax right. There are many subtleties in the behavior of the network policy specification (e.g., default allow/deny, wildcarding, rules combination, etc.). Even an experienced Kubernetes YAML-wrangler can still easily tie their brain in knots working through an advanced network policy use case.
We have learned a lot about the everyday challenges while working with companies implementing a developer platform, so we wanted to share how Shipa Cloud can assist you in your journey with Kubernetes Network Policies.
How can Shipa Cloud help?
The best way to understand how a tool can help you achieve your goal is to understand how it helps you deliver your day-to-day tasks, so let’s explore a few common scenarios users go through when defining Network Policies.
Scenario 1: Allow an application to receive data only from a specific app
Consider a scenario where we have a central payment service that connects with Stripe and processes payments. We want this payment service only to accept connections (ingress) from a specific application (booking application).
If we were to implement that manually, we would have to deal with different YAML files, understand Kubernetes related concepts around network policy, pod selectors, labels, and more. If you are using Shipa Cloud, you can quickly implement this policy directly from the dashboard:
We just had to select the limits we want to apply to our application’s ingress by selecting Apps and Ports. We specified that our payment service could only receive ingress from the booking application, on port 300.
Once you apply the rule, you can see it in effect using Shipa’s network policy-map:
Pretty simple, right? We quickly secured our payment application ingress connections and noticed how the change affected our application’s connection flow.
You can also try implementing that policy yourself here.
Scenario 2: You want your applications to communicate only with the applications that are in the same namespace
It is a common scenario to want your applications to have limited external access, both ingress and egress. If doing this directly on Kubernetes, you would need to deal with DNS rules (yep, DNS, my friend), labels, selectors, and others.
Let’s see how we can do it using Shipa Cloud:
Here we are just selecting kube-dns as a rule, so our applications can only communicate using their internal DNS addresses.
Additionally, we also specified that our payment service could only communicate with applications that are part of the same namespace or framework if you are speaking Shipa 🙂
You can also try implementing that policy yourself here.
Scenario 3: Egress data to an external service
One common scenario is when users want to allow their services to communicate with an external service to the cluster. You may think this is an easy task to achieve using Kubernetes directly, but let’s see how a small mistake can open a large number of threats:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-to-external-service spec: podSelector: matchLabels: app: payment-service egress: - to: - ipBlock: cidr: xx.xx.xx.xx/32 - ports: - port: 27017
This looks pretty simple, right?
While this is a valid YAML and network policy, one minor extra character in the file makes a huge difference and allows a lot more connectivity than expected. The additional “-” in front of “ports” meant that this is interpreted as two different rules, one that allows all traffic to the IP on any port, and another rule that allows all traffic to port 27017, regardless of the destination IP address!
Let’s see how Shipa Cloud could help with that scenario:
Using Shipa Cloud, we have entered the port number (27017) and CIDR that we want to allow our payment service to send data to, which reduces the chances of misconfiguring YAML files and opening security threats drastically.
Once we apply the rule, we can quickly see it in effect in our network map:
What’s Next?
We hope you found these examples useful, and we would love to hear from you if you have other examples of common Network Policy scenarios you use in your day-to-day.
Sign up for Shipa Cloud and try building your network policies.
Resources:
Sign up for Shipa Cloud: https://apps.shipa.cloud
Shipa home: https://www.shipa.io
