Streamline Network Security with Centralized and Automated Network Policy Management

October 4, 2022

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 can be significant. 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 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 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 such as Cilium and Calico. However, there are operational overheads to managing these offerings including installation, upgrades, compatibility checks, and many more.

In addition, dependencies on cloud provider-specific CNIs such as AWS-CNI mean that you have to work with different installation paths and parameters for every cloud provider. A key aspect that customers struggle with is 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.

To scale, platform teams need a mechanism that can manage 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 without the headaches of integration challenges across different cloud providers or cluster types.

Challenge 2: Role-based access Controls

Lack of fine-tuned solutions oftentimes results in over-privileged access to developers when debugging network traffic flows, which can lead to:

• 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 network flows in a cluster, they can see information on applications they shouldn’t have access to.

Application teams should only be allowed to see the applications/namespaces they are responsible for. Managing network policies and network visibility needs to be aligned 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 on their access roles.

For example, as a namespace admin, your control is limited to your namespaces where your applications reside. In contrast, 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's insufficient for Day 2 operations in environments where continuous changes are made at DevOps scale. Historical network flows are also needed to compare and audit access patterns. Today’s market solutions often lack the simple, integrated capabilities needed for developer self-service in application troubleshooting. Historical data is not readily available and lives across different systems.

Rafay’s network visibility dashboard offers out-of-the-box access to historical traffic flows without additional setup or maintenance needed!

Conclusion

Network Policies are an essential tenet in Kubernetes governance and security that reduce lateral attack surfaces and protect workloads and infrastructure through isolation. Managing and creating them with Rafay as your Kubernetes operations platform allows platform teams to scale with proper access controls that align with your organization, and added real-time and historical visibility without the integration headaches thanks to automated deployment. Check out our Getting Started Guide to get started and experiment with network policies in Rafay in under 30 minutes!