How to Enhance Protection of AWS Workloads with the Juniper cSRX Container Firewall in Amazon EKS

By Josh Dean, Sr. Partner Solutions Architect, Networking – AWS
By Sai Prashanth Ramanathan, Product Manager – Juniper Networks 

Juniper Networks

As IT organizations migrate workloads to Amazon Web Services (AWS), their applications need to be safeguarded from threats originating from the internet, and even laterally from their on-premises environment to the public cloud and vice versa.

There are multiple firewall applications in a virtual form factor that are available for protecting Amazon Elastic Compute Cloud (Amazon EC2) instances. These firewalls have advanced security features and services, such as application security, intrusion detection and prevention, sandboxing techniques, anti-virus, and web filtering.

These virtual firewalls, however, do not provide the flexibility, agility, and speedy elasticity that customers expect from their public cloud deployments. Containers provide exactly these benefits over their heavier and larger virtual machine counterparts.

With the ability to deploy the Juniper cSRX Container Firewall in an Amazon Elastic Kubernetes Service (Amazon EKS) environment, customers can leverage the benefits of the container for protecting their workloads.

Enterprises are embracing the Kubernetes orchestration platform for their DevOps and CI/CD processes. Amazon EKS makes this transition easy by managing the still relatively new Kubernetes ecosystem and ensuring IT admins can focus on the next area of innovation for their organizations.

The systems that are being deployed still need protection from external and internal threats. The Juniper cSRX, built and deployed as a Docker container with many of the advanced firewall features, like the Juniper vSRX Virtual Firewall, enables this protection in a container form factor.

In an EKS environment, the cSRX is deployed as a service behind Elastic Load Balancers (ELBs) and ensures workloads are protected from advanced threats, irrespective of their origins. Now, it’s possible to ensure the same level of protection is applied to workloads, wherever they may reside with the Juniper SRX, vSRX, and cSRX firewalls.

Let’s take a deeper look into a few scenarios where the Juniper cSRX finds applications within the AWS environment. Juniper Networks is an AWS Partner whose innovative product portfolio allows customers to seamlessly connect every workload, creating a secure and elastic hybrid cloud.

Protect Workloads from External Threats

In this scenario, the application workloads being protected are deployed within the EKS environment. The cSRX is deployed in a Kubernetes cluster either as a single pod or as part of a deployment and replica-set.

When deployed in a Kubernetes environment, the container firewall needs the Multus Container Network Interface (CNI) to attach multiple interfaces and the Flannel or Weave Networking CNIs, which enables the creation of the overlay network.

Incoming traffic from the internet hits the network/application load balancers in AWS, which route the traffic to the firewall service that is running a scalable set of container firewall instances.

Any pre-configured security services and Network Address Translation (NAT) are performed on the traffic before it’s forwarded onwards to the destination via a bridge created for forwarding the traffic.

Figure 1 – Juniper cSRX deployed in Kubernetes.

The benefits of this use case are the following:

• Protect application workloads within the EKS environment from external threats.
• Dynamic scale-up and scale-down of the cSRX based on predefined limits and the Horizontal Pod Autoscaler in Kubernetes.
• Ingress load balancer can be the Classic, Network, or Application load balancer in AWS.
• Easy and quick setup (a few seconds) and tear down of the instances.
• Initial configuration load is managed within Kubernetes using ConfigMaps.

The applications being protected can be deployed outside the cluster if they are reachable with routes from the Kubernetes pod. The cSRXs continue to be deployed within the EKS cluster. The architecture remains the same, only the protected application changes.

Figure 2 – cSRX with applications outside of the EKS cluster.

East-West Firewall

When the applications are deployed in an overlay network in EKS, using Flannel and the Multus CNI, the cSRX can segment the network based on the network-attachment-definitions that were used in creating the workloads and environment for deployment.

Here, each application workload needs to be deployed in its own network, connecting and routing traffic through the cSRX revenue interface. Zero Trust network access between the applications’ traffic can be enforced by configuring application Security on the cSRX—either through the command line interface (CLI) using Netconf or even using the Juniper Security Director to manage the cSRXs.

The out-of-band management port of the cSRX is exposed using NodePort in Kubernetes. In the topology shown in Figure 3, the cSRX is deployed as a service like in the other use cases.

Figure 3 – Out of band access to cSRX.

Conclusion

To get started with cSRX in either of the discussed models, read the eksctl/kubectl guides, deployment guide, and/or watch the video walkthrough.

The GitHub readme file offers additional context and installation information. cSRX is also available in AWS Marketplace. For more information, contact Juniper.

.

.

Juniper Networks – AWS Partner Spotlight

Juniper Networks is an AWS Partner whose innovative product portfolio allows customers to seamlessly connect every workload, creating a secure and elastic hybrid cloud.

Contact Juniper Networks | Partner Overview | AWS Marketplace

*Already worked with Juniper Networks? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.