Implementing Private Service Connect in Macquarie Bank’s journey to 100% cloud native

By Pranita Praveen, Director of Engineering and Delivery and James Davidson, Cloud Platform Engineer at Macquarie Bank

Summary

The attraction to cloud-based technologies continues to grow, with more and more businesses seeking out third-party providers to tap into their services and products, making it easier for them to focus on what they do best.

For Macquarie Bank to take full advantage of what’s available requires, amongst other things, a simple and secure way to connect to third party services from our applications. This challenge has always come with complexities around mitigating security risks with intercepting connections through firewalls and Intrusion Prevention Services (IPS), which at times seemed more difficult to solve than simply setting up the required service in-house.

With the introduction of Private Service Connect (PSC) for Google Cloud Platform (GCP) services, the challenge of simple and secure connectivity to SaaS services has been solved. Private Service Connect (PSC) is a Google Cloud networking capability that allows consumers to access managed services privately from inside their VPC network. It is designed to allow customers like Macquarie Bank to be able to access Google SaaS and third party services securely without traffic needing to traverse over the internet.

Features of PSC such as layer 7 load balancing using GCP Internal Load Balancer, and connection via the Cloud Interconnect across to other clouds or on-premise services are key in using PSC for Macquarie Bank applications.

The use case of integration with MongoDB Atlas, a fully managed NoSQL database service for our Payments and Cards applications data store is demonstrated below to illustrate the benefits of PSC for Macquarie Bank.

The challenge we faced and resulting opportunities

Before MongoDB Atlas became available through a PSC connection, VPC peering between MongoDB Atlas VPC and Macquarie Bank’s AWS VPC was used to connect our Payments and Cards applications to MongoDB Atlas.

The drawbacks of this solution were:

• A risk of overlapping IPs due to the peering between the Macquarie Bank and MongoDB Atlas VPCs
• Security risks as services within the Macquarie-peered VPC could be exposed to MongoDB Atlas with incorrect configuration
• A layer 3 network connection between the Macquarie Bank and MongoDB Atlas VPCs when VPC peered, increasing security risk
• Mitigation of these security risks involved using firewall and VPN tunnels services to connect to the internal Macquarie Bank application, adding complexity to operations and reducing reliability

It is clear from these drawbacks that there were several opportunities for us to simplify our connection to MongoDB Atlas and reduce the operational load on the supporting engineers, such as:

• Removal of VPN tunnels in our connectivity to MongoDB Atlas if possible, as this would improve the reliability of our connection
• Removal of the need for a firewall and associated firewall rules, and no longer be impacted by firewall maintenance activities
• Make the transition of the solution between platform support engineers longer term by reducing the number of different components deployed and configured

How we solved it:

With the availability of MongoDB Atlas Private Service Connections via interconnect, we’ve moved away from VPC peering and simplified our connection pattern.

Our primary use cases for MongoDB Atlas via Private Service Connect were:

1. Access via SSL protocol to MongoDB Atlas database from our container platforms on GCP
2. Access via SSL protocol to MongoDB Atlas database from our container platform on AWS
3. Access via SSL protocol to MongoDB Atlas database from developer laptops

The first use case involved setting up a PSC endpoint and service attachment within the GCP network fabric and enabling a dedicated and secure point-to-point connection.

Use cases two and three were a little more complicated. These point-to-point connections required access to MongoDB Atlas from outside of the GCP network fabric, via a cloud interconnect connection. The PSC via interconnect feature enables us to connect from either AWS or on-premise sources by traversing via the GCP Palo Alto firewall, through the cloud interconnect and onto the GCP PSC endpoint, which connects to the MongoDB Atlas service attachment.

Each PSC endpoint uses one IP within the subnet, and connects to the MongoDB Atlas VPC through a GCP network fabric Layer 7 connection. Routing of the application connections into the MongoDB Atlas clusters will be through the DNS CNAME entry, assigned automatically to each MongoDB Atlas cluster upon creation.

For SaaS services which do not offer dynamic creation of DNS entries for each PSC endpoint, this segmentation can come from a Layer 7 Internal Load Balancer through which all outbound traffic into GCP PSC endpoints can be passed through. This can enable filtering of all connections using DNS CNAME — providing additional segmentation of traffic to satisfy network and security requirements.

The image above shows the design of the connectivity between Macquarie Bank’s on-premise and AWS endpoints through the GCP Private Service Connect subnet to our MongoDB Atlas projects.

To move towards a connection between the Macquarie Bank application and MongoDB Atlas using Private Service Connect, we followed the below steps:

1. Allocated a CIDR range for each of our non-production and production PSC consumer and producer endpoints. This step must come first, as it allows all new PSC connections to be allocated within one subnet and provides network segmentation between production and non-production.
2. Created an endpoint service attachment within MongoDB Atlas. This provided the target connection IP for our Macquarie Bank Payments connections.
3. Created a PSC service endpoint using an IP from the allocated PSC CIDR range. You need the Mongo GCP Project ID and Service attachment details from the MongoDB Atlas service attachment, so you have to create the service attachment before the service endpoint.
4. Uploaded the PSC service endpoint details to MongoDB Atlas and connected to the cluster.
5. For connections from the Macquarie Bank application outside GCP, firewall rules in the GCP firewall have been added to allow traffic to the Internal Load Balancer through the interconnect.

The creation of PSC service endpoints within the Macquarie Bank network were put in code using Python, and these files have been templated for use in creating PSC endpoints for other third-party services.

The benefits we’ve seen

We have now successfully created our first production Private Service Connect connection to MongoDB Atlas for use in our Payments and Cards platform. This has reduced the overhead on our support team with the move away from unreliable VPN tunnels and complex VPC Peering rulesets.

Security approvals for new SAAS connections have been made simpler with the use of PSC. The segmentation between PSC endpoints in the Macquarie Bank GCP environment and other controls described, have been incorporated within a PSC pattern for the use in new service integrations.

The Private Service Connect deployment templates make it simple for new service endpoints to be added for MongoDB Atlas, as well as new SAAS services to be connected. While service attachments remain a manual task to be created on the provider SAAS, automation of the PSC endpoints within Macquarie Bank GCP subnets simplify operational and production support tasks.

Where to next?

We continue to work towards moving away from hosting our own infrastructure services where possible, with a north star to be 100% on cloud native services and achieving 99.9% availability of our payments services. The simplicity of Private Service Connect takes us even further on this goal, with automated, highly available and secure connectivity to SAAS services, and we will continue to leverage it for our third party connections wherever possible.