Enter NeuVector, your trusted security convoy ensuring a safe and sound passage for your containerized applications. Think of NeuVector as the vigilant escort that not only shields your cargo from potential threats but also orchestrates a seamless journey, navigating through the ever-evolving terrains of the digital realm
hNeuVector adapts to the nuances of containerized environments. It provides an end-to-end security platform, resembling a dynamic security roadmap, offering protection from vulnerabilities, monitoring behavior, and responding to security events in real-time. In this guide, we'll explore how NeuVector stands as the guardian of your digital cargo, implementing robust network and response rules, ensuring your applications traverse the digital highways securely and reach their destination unscathed.
An Example Use Case
Let us explore the practical application of NeuVector's network and response rules through a real-life example. Picture this: you are orchestrating a comprehensive e-commerce application comprising 12 microservices, all seamlessly operating within your Kubernetes cluster. Security is a top priority, and you want to eliminate any potential risks posed by certain containers. NeuVector steps in as your security enforcer, allowing you to meticulously define rules that govern container communication.
In this particular scenario, let's say you have identified a critical security concern – you want to establish a network rule that prohibits communication between the frontend and cart service. Additionally, you've strategically set up a response rule for network violations specifically targeting the frontend pod. If a network violation occurs within the frontend service, NeuVector swiftly implements a quarantine in response to network rule defined earlier, isolating the affected pod from the network. For this use case, we are using Google’s Online Boutique Shop application which is a cloud-first microservices demo application. The application is a web-based e-commerce app where users can browse items, add them to the cart and purchase them. You can find the link of application on the GitHub repo here.
We have deployed the application on an RKE2 Kubernetes cluster. As you can see below, there are multiple services like front-end service, cart service, payment service, etc. deployed on the cluster.
Log in to you Neuvector Console. If you have set it up earlier, the default username and password will be "admin".
Click on the Network Activity section. Here you can see a graphical map of your containers and the conversations between containers.
Below, you can have a close look at our deployed micro-service application. You can see communication between the different pods as well as communication between the front-end and cart service for which we will set up a network rule.
Below you can see the Boutique Shop application GUI, which are accessing from the front-end service.
Now, click on the "Response Rules" tab under the Policy section, where you can see some predefined response rules.
Click on the "Add to Top" option and configure it as shown below. When done, click on "Add" to save the rule.
For more details about Neuvector response rules, click here.
Below, you can see the response rule is set for “nv.frontend.boutique-shop” group.
Now, we will define a deny network rule between the front-end pod and cart service pod.
Click on the "Network Rules" tab under the Policy section.
Click on the "Add to Top" option and configure it as shown below. Once done, click on "Add" for adding the rule.
For more detail about Neuvector network rules click here.
Click on the "Save" button for saving the network rule. After saving you will see a screen similar to the one below.
Here, we have defined a deny rule between the front-end and cart service. The application protocol is HTTP and we have not specified any port, so you can see "Any" in the ports column.
Click on the "Security Events" tab under notification section. We can see an event for a network violation between the front-end and the cart service.
In the Network Activity section, you can see a red circle around the front-end pod, which means it has been quarantined due to network violation, which we have defined earlier. All the incoming and outgoing network traffic is blocked.
Now, if you try to access the web console of our application, it will throw an error message “No endpoints available for service front-end”.
To make it accessible again, we need to disable the response rule, and then click on the disable rule icon under the Response section as shown in the screenshot below.
Then head out to the Network Activity section. Right click on the quarantined pod and click on the Un-quaratined option.
Since, we have not deleted the network rule, you can see a red arrow indication between the pods which signifies network violation.
Wait for few seconds. You shall be able to access the web console like you did earlier.
To Conclude
This blog post helped to understand and explore NeuVector's network and response rules. We delved into a practical use case involving a sophisticated e-commerce application with 12 microservices. Within the Kubernetes cluster, NeuVector emerged as a pivotal security enforcer, providing meticulous control over container communication. With security being of paramount importance, NeuVector allowed for the strategic implementation of network rules, addressing a specific concern by prohibiting communication between the front-end and cart services.
This use case demonstrated NeuVector's dynamic response to security events. In response to a network violation targeting the frontend pod, NeuVector swiftly enforced a quarantine, effectively isolating the affected pod from the network. Leveraging Google's Online Boutique shop, a cloud-native microservices application, we navigated the complexities of securing diverse services within an RKE2 Kubernetes cluster.