Streamline Network Security with Centralized and Automated Network Policy Management

In a previous blog post, Securing Your Kubernetes Environments via Network Policies, we alluded to the value that network policies bring to Kubernetes environments in terms of isolation and reducing the lateral attack surface area, while also articulating some of the challenges around operationalizing network policies. To summarize, these challenges include the following:

• Integration and standardization of network policies: The operational burden in defining and enforcing network policies across a heterogeneous fleet of clusters r can be a significant exercise. Lack of centralization and standardization can lead to poor security outcomes.
• Role-based access controls: It is extremely difficult to implement role-based access controls for network traffic flow visibility and network policy creation. Ideally, you want to restrict access based on ownership, e.g. application teams can only create network policies and view traffic flows for their namespaces.
• Visibility and data retention: For debugging and validation purposes, admins or developers would want to be able to go back in time and check how their network configuration and flows looked like but enabling this kind of functionality today is burdensome.

Without solving these challenges, you have a disjointed solution that may solve some network security challenges but can also lead to misconfigurations and misses. In this post, we will dive deeper into each of these challenges and address how Rafay’s Kubernetes operations platform enables you to solve these challenges through governance, access controls, automation, and self-service.

Challenge 1: Integration and standardization of network policies

As a platform admin, one of the biggest challenges when working with Kubernetes, in general, is integrating open source software and maintaining it across a fleet of clusters in order to meet different needs across security, compliance, and lifecycle management.

Today there are open-source Container Network Interface (CNI) offerings in the market such as Cilium and Calico. However, there are operational overheads to managing these offerings including installation, upgrades, compatibility checks, and many more. In addition, there are also dependencies on cloud provider-specific CNIs such as AWS-CNI meaning that you have to work with different installation paths and parameters for every cloud provider.

A key aspect that customers struggle with is the Day 2 operations i.e. how do you make sure that your fleet of clusters is following the standard security posture that you initially had configured? You may be able to install a default set of policies on day 0, but without visibility into whether any drift is occurring or whether those standards are continuously being met, you lose your ability to continuously secure your infrastructure and applications.

In order to scale, platform teams need a mechanism that can take care of integrating key software components on any cloud, any cluster addressing not only day 0 challenges, but also day 2 and beyond via mechanisms such as drift detection. Using blueprints, Rafay offers an integrated solution for network policy management. With the check of a box, platform admins can automatically add Cilium to a blueprint template and publish that to a fleet of clusters while not having to worry about the headaches of integration challenges across different cloud providers or cluster types. In addition, they can standardize on a set of default cluster-wide policies (e.g., Default deny ingress) that can be installed on clusters on day 0 and continuously checked via Rafay’s blueprint drift detection in order to continuously validate that the standards are being met.

Challenge 2: Role-based access Controls

Lack of fine-tuned solutions oftentimes results in over-privileged access to developers when it comes to debugging network traffic flows in and out of an application that can lead to the following:

– Siloed misconfigurations and exposure: a developer modifies a rule that fixes their application but exposes others.
– Leakage of sensitive information/data: If a developer has access to all the network flows in a cluster, they can see information on applications that they shouldn’t have access to. The application teams should only be allowed to see the applications/namespaces that they are responsible for.

Managing network policies and network visibility need to be tied with your organizational structure and policies via RBAC. Using Rafay’s network policy management solution, you can enable self-service while enforcing governance by providing users the ability to configure policies or view traffic flows based only for the resources the user should have access to based on their assigned roles.

For example, as a namespace admin, you can only control and view network policies for your namespaces where your applications live. However, as a platform admin, you have full visibility to troubleshoot cluster-wide configurations and maintain service reliability.

Challenge 3: Visibility & Data Retention
While real-time network visibility solves one aspect of application troubleshooting, it is not enough for day 2 operations in a world where continuous changes to environments and apps at devops scale are being made. Historical network flows are also needed in order to compare/contrast and audit access patterns.

Today’s solutions in the market lack the simple, integrated capabilities needed for developer self-service when it comes to application troubleshooting at the network layer. Historical data is not readily available and lives in different systems. Moreover, collecting historical information requires secure data pipelines and managing all of that infrastructure can be cumbersome.

Using Rafay’s network visibility dashboard, both developers and admins have out-of-the-box access to historical traffic flows for their applications. No extra setup or maintenance is required!

Conclusion

Network Policies are an essential tenet in Kubernetes governance and security to reduce the lateral surface attack and protect your workloads and infrastructure with isolation. Managing and creating them with Rafay as your Kubernetes operations platform allows platform teams to do it at scale, with proper access controls that are aligned with your organization, and added real-time and historical visibility without the installation and integration headaches thanks to automated deployment.

Check out our Getting Started Guide to get started and try out network policies in Rafay in under 30 minutes!

Ready to find out why so many enterprises and platform teams have partnered with Rafay to centralize Kubernetes network policy management? Sign up for a free trial.