Networking Solutions in Kubernetes Clusters Without NetworkPolicy Support

Kubernetes provides powerful network security features through its NetworkPolicy API, allowing administrators to restrict communications between pods based on labels, namespaces, IP blocks, and more. However, NetworkPolicy is not supported on all Kubernetes distributions or cloud services. For clusters that lack built-in NetworkPolicy support, alternative solutions must be used to limit pod networking. In this tutorial, we will explore methods to add network security to Kubernetes clusters without direct NetworkPolicy capabilities. We will cover options like Calico's Network Security Policies, leveraging Pod Security Policies, using third-party network control utilities, and utilizing cloud provider Network Security Groups to augment missing NetworkPolicy features. With the right tools and configuration, network traffic can still be restricted in Kubernetes even without access to the native NetworkPolicy resources.

Use Network Security Policies with Calico

Calico is a popular CNI plugin that provides NetworkPolicy support. If you are running Calico for networking, you can use Calico Network Security Policies (NSPs) even if your Kubernetes version doesn't support NetworkPolicy.

To use NSPs:

1. Deploy Calico in your cluster.
2. Create NSPs using calicoctl or the Calico API. NSPs work similarly to NetworkPolicies.
3. Enforce policies at the network level rather than the Kubernetes API.

This allows you to get NetworkPolicy-like functionality without needing Kubernetes support.

Leverage Pod Security Policies

Kubernetes Pod Security Policies allow you to control the runtime permissions of pods. Though not a complete network security solution, PodSecurityPolicies can be used to limit network access at the pod level.

To use PodSecurityPolicies for network control:

1. Create a default "restrictive" policy that denies all outbound network access for pods.
2. Define additional policies that allow network access, tied to specific user/group roles. For example: Allow developers access to make outbound connections on ports 80 and 443. Allow infrastructure pods access to make outbound connections on any port.
3. Require that all pods are tied to a PodSecurityPolicy by default, so they inherit the correct network permissions.

With this model you can grant network access on a role-based policy model rather than individual pod selections.

Benefits of this approach:

• Allows network restriction without NetworkPolicy support.
• Integrates with Kubernetes' native role-based access control system.
• Less granular than NetworkPolicy, but can limit broad network access by role.

The main limitation is that rules apply uniformly to all a pod's traffic, instead of restricting access between specific pods/IP blocks. However overall, PodSecurityPolicies can be a useful tool for restricting network usage in clusters without full NetworkPolicy capabilities.

For example, you can:

• Deny all outbound network access from pods by default.
• Create role-based policies that allow certain pods network access.

While less flexible than NetworkPolicy, this can provide some control over pod-level network permissions.

Use Network Security Utilities

There are various open source utilities that can enforce network security policies at the node level rather than the Kubernetes API:

Weave Net: Allows you to block pod-to-pod traffic through iptables rules.

Cilium: Support security rules in clusters without NetworkPolicy.

Twistlock: Provides firewall capabilities to limit network traffic.

These provide alternate ways to restrict pod communication without relying on Kubernetes NetworkPolicy support.

Wrap Pods in Network Security Groups

Major cloud providers like AWS, Azure, and GCP allow you to define network security groups (NSGs) or firewall rules. If running your Kubernetes cluster in a virtual private cloud, NSGs can be used to restrict pod communication.

To implement NSGs for pods:

1. Plan node subnets and route tables to isolate pods in individual networks. This allows NSG rules to be applied per node pool.
2. Define NSGs or firewalls rules per subnet to only allow required traffic. For example: Allow nodeports only from the frontend subnet to backend pods. Block Internet access for database nodes.
3. Assign pods to appropriate node pools and subnets using nodeSelectors and tolerations.
4. Use cloud SDKs/tools to manage NSGs separately from Kubernetes.

With proper network architecture, NSGs can provide Kubernetes-independent network security groups.

Benefits of this model:

• Leverages cloud-native tools for firewall policies.
• Allows restrictions between nodes or pod subsets.
• Does not rely on Kubernetes NetworkPolicy support.

The downside is increased operational complexity from managing networking both within and external to Kubernetes. Overall, NSGs are most viable for clusters running on managed cloud networks, where pod subnets can be pre-structured.

Conclusion

Kubernetes NetworkPolicy is a powerful tool for securing pod communications, but not the only option for clusters lacking support. With careful planning and configuration, Calico policies, Pod Security Policies, node-based firewalls, and cloud Network Security Groups can all help restrict network traffic at the pod and node level. Each solution has trade-offs and requires different levels of integration with the Kubernetes networking model. Teams should evaluate their environment, resources, and security requirements when choosing an approach. While not as integrated as built-in NetworkPolicy, these alternatives provide ways to gain control over pod networking without access to those Kubernetes APIs. With the solutions outlined here, administrators can craft secure network schemes for their clusters, even without direct NetworkPolicy capabilities. Proper network security is achievable on any Kubernetes distribution through defense in depth and blending complementary open source and cloud-native tools.

?