Prevent Kubernetes NetworkPolicy Misconfigurations with Policy as Code

 In today’s digital world, data is one of the most important assets for the world’s leading companies. Consequently, data breaches are growing tremendously where cybercriminals attack consumers, corporations, and governments.

According to the 2020 Cloud Misconfigurations Report, breaches caused by cloud misconfigurations in 2018 and 2019 exposed nearly 33.4 billion records in total. With an average cost per lost record is estimated at $150, misconfiguration cost companies worldwide nearly $5 trillion in 2018 and 2019 alone.  Among these misconfigurations, is network policies misconfigurations. Correctly configuring our infrastructure network policies is now a top requirement.

With the growing adoption of Kubernetes, Kubernetes NetworkPolicy became the way to define network security rules in our clusters. A misconfigured NetworkPolicy can expose our infrastructure to huge security risks.

In this series of articles, we will get to know how Magalix empowers organizations to define and manage custom governance policies using policy as code, applied and enforced on Kubernetes cluster resources. In this way, we can mitigate and limit Kubernetes NetworkPolicy misconfigurations.

Blocking All Outgoing Traffic Except DNS

By default, pods in Kubernetes are non-isolated; they accept traffic from any source. Pods become isolated by having a NetworkPolicy that selects them. Once there is a NetworkPolicy in a namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.

Why Should You Block All Traffic?

One of Kubernetes best practices is to block all traffic by default and whitelist the traffic you need. This can help prevent data exfiltration and downloading of malicious files. While you might have an application that does not need to communicate externally, it probably needs to resolve DNS queries so you need to allow outgoing traffic to coredns (Kubernetes cluster internal DNS server) only. For example, this can be enforced on a pod that collects incoming traffic only like logs and does not generate any outgoing traffic except DNS queries.

Kubernetes NetworkPolicy

This is how a Kubernetes NetworkPolicy resource can be configured in our cluster to block all outgoing traffic except DNS.

 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-traffic-to-kube-dns
  namespace: test
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53   

Here we specified podSelector as {} which means selecting all pods in a namespace. We can select specific pods by matching their labels as we did with the kube-dns pod.

Magalix Templates and Policies

In Magalix, we can define our custom template which is the general blueprint for a security rule. Then we define a template-based policy by passing parameters to this blueprint to make it specific for our use case.

For example:

• A template would provide you the general rule to block all traffic between two namespaces which you specify in a policy
• An enacted policy would be to deny all traffic between the staging namespace and production namespace
• Another policy based on the same template would be to deny all traffic from the testing namespace to the production namespace and so on.

You can define multiple policies based on the same template. In this way, we can define our rules to enforce correct configurations of Kubernetes resources.

Magalix templates are written in Rego, the standard language for policies. Let’s see a template that enforces a Kubernetes NetworkPolicy which blocks all outgoing traffic except DNS queries to kube-dns pod.

 
package magalix.advisor.network.allow.egress.to.coredns
 
namespace := input.parameters.namespace
 
violation[result] {
  namespace == input.metadata.namespace
  some i, j, k
  egress := input.spec.egress[i]
  ports := egress.ports[j]
  ports.protocol == "UDP"
  ports.port = 53
  to := egress.to[k]
  to_value := to.podSelector.matchLabels["k8s-app"]
  not "kube-dns" == to_value
  result = {
    "issue_detected": true,
    "msg": sprintf("Expecting value 'kube-dns', but '%v' was detected", [to_value]),
    "violating_key": sprintf("spec.egress[%v].to[%v].podSelector.matchLabels.k8s-app", [i,k]),
    "recommended_value": "kube-dns"
  }
}

Here we can see that we define a violation rule. This rule first checks that the NetworkPolicy is created in the desired namespace which we will pass to this template as a parameter. Then it loops over the egress ports to check for the UDP 53 port. Lastly, it checks the egress selector whether it matches the label of the kube-dns pod or not.

By applying this policy to our cluster, any NetworkPolicy that allows any outgoing traffic - other than DNS - from this namespace will generate a violation.

Magalix Policies in Action

Let’s see this in action in the Magalix console. First, let’s define a policy based on the template we wrote. We will create a policy with the namespace parameter as “test”.

This means we’re defining a policy to block all outgoing traffic from the namespace “test” except DNS traffic to kube-dns.

Then we will apply a violating NetworkPolicy in the test namespace which allows outgoing traffic to another pod with the label tier=another-dns:

 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-traffic-to-another-dns
  namespace: test
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          k8s-app: another-dns
    ports:
    - protocol: UDP
      port: 53

Once we apply this NetworkPolicy in our cluster, a violation will be triggered in the Magalix console showing the violation and the violating entity.

Final Thoughts

Magalix is helping companies enforce policy as code across their entire Kubernetes and cloud infrastructure. In this article, we saw one use case for preventing Kubernetes NetworkPolicy misconfigurations. More use cases are coming In the next articles so stay tuned.

Magalix Policy Enforcement Platform has 100s out-of-the-box policies and templates - PCI DSS, Application-Based Policies, and MITRE ATT&CK - enabling companies to hit the ground running with security and compliance.