In this blog, we will focus on IT as a service use case, where the standard IT services like Microsoft AD, Print, DNS, NTP, or DHCP services could be hosted in a common/shared VPC which is shared across different VPCs.
Let’s look at how shared services are implemented in a native Cloud Service Provider (CSP) environment.
Shared Services Using CSP
In the case of a native CSP environment, shared services are typically created in a single VPC; these services include a database, active directory, or DHCP services. The reachability to this VPC from other host VPCs will be using a transit construct such as the AWS Transit Gateway, Microsoft Azure Virtual WAN or Google Cloud Network Connectivity Center.
To maintain isolation between prod and non-prod environments in the case of native CSP, the customer will have to use separate routing tables or security domains when connecting to a transit networking construct such as a AWS Transit Gateway, Microsoft Azure Virtual WAN or Google Cloud Network Connectivity Center.
Another point to note is that if the customer wants to connect these prod and non-prod environments to a shared services VPC, then, in that case, they will have to inspect that traffic when it reaches the shared services VPC which requires placement of inline firewall services. This is a complex routing configuration and requires deep knowledge of CSP networking and security concepts.
Figure 1: Native CSP Architecture for Shared Services
Alkira Approach: Simplifying Connectivity with Cloud Area Networking
When enterprise customers use segmentation on the Alkira CXP, they can keep different business functions separate and achieve better manageability and security for their applications. However, even with segmentation, they still need the ability to share specific applications across their entire organization or some applications with a specific business entity.
Using the Alkira solution, customers can handle the shared services use case using the Resource Sharing feature. This allows them to choose specific resources by identifying the network prefixes to be shared across two segments and enabling additional capability to allow an inline firewall to inspect the traffic for Resource sharing.
Customers can define a resource as a network prefix or network prefixes with a Prefix List. They can choose cloud VPC connectors from where they learn the Prefixes to be shared; those will be from the shared services VPC.
Customers can choose to configure whether they need Bidirectional traffic origination or Unidirectional. If Unidirectional, it will only allow traffic to originate from one end to another.
Figure 3: Resource Sharing Between 2 VNETs
Customers can define a resource (End-A) in Segment 2 as Prefix A1 and resource (End-B) in Segment 3 as Prefix B1 as shown in the above diagram. They can then define a Resource Share between the two segments that install traffic policies on the Alkira infrastructure, allowing the traffic from the End-A resource to the End-B resource and vice versa.
Figure 4: Resource Sharing in Segment 1
Figure 5: Resource Sharing in Segment 2
Inserting Inline Firewall Services
When an Enterprise customer enables Resource Sharing, they might want the ability also to enable Inline Firewall (e.g., Palo Alto VM-Series, Fortinet, Checkpoint etc.) offered on the Alkira Marketplace. This helps them to ensure security by way of inspecting the Traffic being sent to and from the Resources to be secure.
As part of the Alkira configuration workflow, the customer can choose if they want to enable the inline firewall for the Resource Share and choose the specific FW instance. On creating the Resource Share, Alkira also provisions a Resource Group for End-A and a Resource Group for End-B. The firewall is provisioned in a Designated Segment of the customer’s choice. The customer will then be able to map their Firewall Zones to the Resource Group(s) and configure their Firewall Policies on the PAN between these Zones.
Figure 6: Enabling Resource Sharing between Segments with Traffic Inspection
Day 2 Troubleshooting
Enterprise Admins also want the capability to troubleshoot live problems. Alkira allows the ability to Troubleshoot or Diagnose problems using the Diagnostics Dashboard. The Enterprise Admin would get complete visibility into the Active Flows pertinent to a Resource Share to debug any live issues. It would show the complete five-tuple visibility; if the flow has NAT, then the translated Address, Application, Forward and Reverse packets, etc.
Visibility
Once Resource Sharing is enabled and provisioned on the system, the Enterprise admin would like to see the Network Prefixes shared. Alkira provides a Route Visualization dashboard that shows the Network Prefixes learned as part of a Resource Share and the associated information like Connector, Group, etc. If NAT is enabled, it will show the Translated Prefix in the routing table and the Original Prefix if the customer desires.
After the Enterprise admin confirms the behavior, they will likely want to see the Resource Sharing traffic over a period of time. Alkira provides a Resource Sharing Dashboard, which allows customers to view all their Resource Shares in the system, Top Communicators on the End-A and End-B, Inbound and Outbound Bandwidth, Top Applications, and Top Policy Hits. It allows the Enterprise admin to tweak their Resources if needed.
Figure 7: Visibility into Shared prefixes between Segments
Figure 8: Traffic Policy Inspector between Segments
Modernize your cloud network with Alkira
To learn more about how Alkira can help simplify cloud networking for your organization, reach out and schedule a demo today.
You can also try our Cloud Insights tool for free here, giving you instant inventory and insights into your cloud networking resources.
About the Authors: Ahmed Abeer & Deepesh Kumar
Ahmed Abeer
