Manage Multi-Tenant Remote Access with Cisco Secure Firewall Cloud Native on Amazon EKS
By Muffadal Quettawala, Partner Solutions Architect – AWS
By Anubhav Swami, Principal Solutions Architect – Cisco
As application workloads modernize into containerized form factors, organizations are demanding the same from the security tooling used to protect those application workloads. Customers would like to consume modernized, DevOps-friendly security controls without compromising elasticity, resiliency, and scalability.
Cisco Secure Firewall Cloud Native (SFCN) is a lightweight network firewall in a cloud-native form factor. Offering granular control and massive throughput potential, SFCN enables security at the speed of business. It offers an easy way to deploy scalable remote access virtual private network (VPN) architecture as its primary use case.
Customers or service providers can utilize SFCN to replace rigid remote access infrastructure with a cloud-native one and strengthen their security posture while reducing complexity and improving efficiency.
You can subscribe to Cisco Secure Firewall Cloud Native through AWS Marketplace and deploy it via an AWS Quick Start. Once deployed, the cluster can be managed via Cisco Defense Orchestrator (CDO), a cloud-based firewall manager that facilitates management of security policies to achieve consistent policy implementation.
The Cisco SFCN architecture adheres to the following tenets:
- Modular and scalable, as the Control Point and Enforcement Point can be scaled separately to deal with heavy control plane vs data plane requirements.
- Native Kubernetes (k8s) deployment via Custom Resource Definition and Helm charts.
- Custom metrics and Horizontal Pod Autoscaling support. The k8s pods can autoscale based on observed metrics such as average CPU utilization, average memory utilization, or any other custom metric you specify.
- Data externalization for stateless services via a high-performance Amazon ElastiCache for Redis database.
- Multi-Availability Zone (AZ), multi-region, and multi-tenant support.
Figure 1 – Cisco Secure Firewall Cloud Native architecture.
The diagram above depicts components used in Cisco Secure Firewall Cloud Native. This product combines Cisco’s security and cloud-native features to create a secure scalable edge solution.
- Control Point (CP): This component is responsible for config validation, compilation and distribution, licensing, and route management. CP k8s pods accept configuration from REST APIs, Kubectl+YAML, or Cisco Defense Orchestrator.
- Enforcement Point (EP): This component is responsible for L3/L4 and VPN traffic handling and VPN termination.
- Redirector: This is responsible for load balancing remote access VPN traffic. When the redirector receives a request, it contacts Redis DB and provides Fully Qualified Domain Name (FQDN) of the enforcement pods handling the least number of VPN sessions.
- Cloud Native Firewall (CNFW): The CNFW is a component of SFCN that provides L3/L4 firewall capability and IPsec/SSL VPN.
- Cisco Defense Orchestrator (CDO): CDO is an external cloud-based software-as-a-service (SaaS) firewall management platform for management and monitoring.
- Amazon ElastiCache for Redis: This database has information on VPN sessions, and the redirector uses this information to enable smart load balancing and recovery.
- Amazon EKS cluster: Cisco Secure Firewall runs on an Amazon EKS cluster and uses K8s constructs like Horizontal Pod Autoscaler, auto-healing, and custom metric operator.
- Amazon EFS: The CP and EP configuration files and logs are stored on Amazon EFS.
- AWS Lambda: This solution deployment implements multiple Lambda functions for orchestration and automation.
- Amazon Route 53: The integration with Amazon Route 53 enables DNS-based load balancing to each SFCN instance. The Route 53 ingress CRD makes the cluster aware of your public-facing DNS, and will automatically register any SFCN instances discovered in the namespace as backend endpoints to the load balancer
The remote access VPN traffic flow is composed of the following steps:
- CP controls configuration, routing, and Amazon Route 53 configuration for the auto-scaled EP.
- The remote VPN user sends a DNS query Amazon Route 53, which keeps track of all CNFW nodes via “A records” and uses weighted average load balancing enabled for incoming DNS requests.
- Using the Elastic IP of the CNFW node, the remote VPN user connects to the CNFW node. Each node provides a separate VPN pool for proper routing.
Cisco Secure Firewall is available in AWS Marketplace. For ease of deployment, Cisco and Amazon Wet Services (AWS) have collaborated on a Quick Start that builds the Amazon EKS cluster and installs the key components of SFCN from AWS Marketplace.
Figure 2 – Cisco Secure Firewall Cloud Native Quick Start.
The diagram above shows all of the components of Cisco Secure Firewall Cloud Native. This Quick Start builds the Cisco SFCN cluster via turnkey automation using both Cisco and AWS best practices.
Management and Monitoring
- Custom Resource Definition (CRD): For customers that prefer managing the solution via native Kubernetes APIs, Cisco provides CRDs for the configuration of the SFCN cluster. Administrators can leverage these CRDs and build upon the sample YAML configuration templates to configure and manage SFCN clusters.
- Cisco Defense Orchestrator (CDO): Customers can alternately also manage Cisco SFCN via the CDO GUI. For more information on how to manage Cisco SFCN via CDO, refer to Managing SFCN with CDO.
Figure 3 – Managing Cisco SFCN using Cisco Defense Orchestrator.
Additional Use Cases
Scalable Remote Access VPN with Smart Load Balancing and Session Resiliency
Cisco SFCN can use the optional redirector component to load balance inbound VPN sessions for remote users. The solution leverages Amazon ElastiCache for Redis to store VPN session information.
The redirector node consults the Amazon ElastiCache for Redis database to perform load balancing based on the VPN session count, instead of weighted average load balancing which is the default mechanism that Amazon Route 53 provides.
Cisco recommends using the redirector because this enables the VPN sessions to remain as long-lived sessions.
Figure 4 – Amazon Route 53-based scalable remote access VPN architecture.
Traffic flow with smart load balancing and session resiliency:
- Remote VPN user sends a DNS query for vpn.mydomain.com, and vpn.mydomain.com points to the CNFW redirector.
- Remote VPN user then sends the request to the redirector.
- CNFW redirector periodically polls the Amazon ElastiCache for Redis database to find out the FQDN of the Cisco SFCN nodes with the least number of VPN endpoints. CNFW redirector provides FQDN of the least loaded CNFW node to the remote VPN user.
- Remote user resolves FQDN, and Cisco automatically adds an “A” record for each CNFW enforcement point in Route 53.
- Remote VPN user connects to the CNFW node that has the least number of VPN sessions.
The SFCN release 1.1 also supports geolocation and latency-based DNS user redirection for multi-cluster deployment. Learn more about this feature on the Cisco blog.
Cisco SFCN provides a multi-tenant architecture for Managed Security Service Providers (MSSPs), whom can deploy the SFCN cluster in AWS and offer it as-a-service to their customers by consuming the SFCN multi-tenant aware capability that uses K8s namespaces.
SFCN also includes a licensing controller that is multi-tenant aware. In addition to K8s namespaces, this solution uses cloud-native constructs like subnet, route-table, security group to offer multi-tenant isolation.
Figure 5 – Multi-tenancy for MSSP.
The AWS Quick Start’s existing cluster template deploys additional tenants in an existing SFCN cluster. This template creates the required components to enable multi-tenancy. Adding a new tenant to an existing cluster requires the admin to provide EKS cluster-ID and namespace in addition to the other details.
Figure 6 – Scalable Secure Cloud Hub.
When multi-tenancy is enabled, the license controller (part of the Control Point) handles the allocation of SFCN licenses to the various tenants. MSSP uses a centralized Cisco Smart Licensing Account, and the license controller talks to the centralized smart account to validate licenses.
Scalable Secure Cloud Hub
With the Scalable Secure Cloud Hub use case, customers can shift their distributed security architecture towards a scalable centralized architecture.
Once an SFCN cluster is deployed, customers can connect their SFCN infrastructure to any customer workload environment such as Amazon VPCs, other cloud providers, or on-premises data center via AWS Transit Gateway.
The diagram below demonstrates the Scalable Secure Cloud Hub architecture. The current version of SFCN provides L3/L4 firewall and VPN, and a future release will add L7 security.
Figure 7 – Amazon EKS cluster name and K8s namespace.
Whether you want your secure remote access to start with a small footprint and linearly scale as your organization grows, or satisfy seasonal business and scale based on demand, Cisco Secure Firewall Cloud Native (SFCN) offers the flexibility to choose based on your organization’s needs.
In summary, Cisco SFCN features:
- Auto-scaling: Scale-up and scale-out security during times of fluctuating demand, providing elastic and agile security to meet your organization’s needs.
- Auto-healing: Automated container health checks based on policies, replacing unhealthy or crashed containers with new ones. This ensures high availability and always-on security.
- REST API support: Offers advanced integrations and programmability.
- Smart load balancing: Automate horizontal scaling thresholds with custom metrics.
- Multi-tenant aware architecture for MSSPs: Utilize k8s namespaces to segregate CNFW data planes with a unified control plane.
Get started with Cisco Secure Firewall on AWS Marketplace.
Cisco Systems – AWS Partner Spotlight
Cisco is an AWS Partner providing a range of products for transporting data, voice, and video within buildings, across campuses, and around the world.
*Already worked with Cisco? Rate the Partner
*To review an AWS Partner, you must be a customer that has worked with them directly on a project.