Skip to content

Reduce blast radius: NetworkPolicies

Note

This section helps you implement ISO 27001, specifically:

  • A.13.1.1 Network Controls
  • A.13.1.2 Security of Network Services
  • A.13.1.3 Segregation in Networks

Important

  • This safeguard is enabled by default with the enforcement action deny since Compliant Kubernetes apps v0.19.0. As a result, resources that violate this policy will not be created.
  • The default enforcement action for this safeguard has been changed to warn instead of deny since Compliant Kubernetes apps v0.29.0. As a result, resources that violate this policy will generate warning messages, but will still be created.

NetworkPolicies are useful in two cases: segregating tenants hosted in the same environment and further segregating application components. Both help you achieve better data protection.

Segregating tenants hosted in the same environment

Say you want to host a separate instance of your application for each tenant. For example, your end-users may belong to different -- potentially competing -- organizations, and you promised them to take extra care of not mixing their data. Say you want to reduce complexity by hosting all tenants inside the same environment, but without compromising data protection.

Each application instance could be installed as a separate Helm Release, perhaps even in its own Namespace. These instances should be segregated from other application instances using NetworkPolicies. This ensures that network traffic from one application instance cannot reach another application instance. Besides reducing attack surface, it also prevents embarrassing mistakes, like connecting one application to the database of another.

Further segregation of application components

If you run several applications -- e.g., frontend, backend, backoffice, database, message queue -- in a single Kubernetes cluster, it is a best practice to segregrate them. By segregating your applications and only allowing required ingress and egress network traffic, you further reduce blast radius in case of an attack.

Compliant Kubernetes helps enforce segregation

Compliant Kubernetes allows you to segregate applications by installing suitable NetworkPolicies. These are a bit like firewalls, but in the container world: Since containers are supposed to be deleted and recreated frequently, they change IP address a lot. Clearly the old "allow/deny IP" method does not scale. Therefore, NetworkPolicies select source and destination Pods based on labels or namespace labels.

To make sure you don't forget to configure NetworkPolicies, the administrator can configure Compliant Kubernetes to deny creation of Pods with no matching NetworkPolicies.

If you get the following error:

Error: admission webhook "validation.gatekeeper.sh" denied the request: [denied by require-networkpolicy] No matching networkpolicy found

Then you are missing NetworkPolicies which select your Pods. The user demo gives a good example to get you started.

If your administrator has not enforced this policy yet, you can view current violations of the policy by running: 

kubectl get k8srequirenetworkpolicy.constraints.gatekeeper.sh require-networkpolicy -ojson | jq .status.violations

Further Reading