At Google Cloud Next ‘23, the Cloud Networking Load Balancing team announced multiple enhancements that unlock new use cases and increase your value when using Google Cloud Load Balancing. The four of the marquee features we introduced are:
mTLS support adds client-side authentication during TLS negotiation on global external Application Load Balancers. This capability allows the server to verify the client’s identity in the same way that the client verifies the server’s identity during standard TLS authentication. Thus, mTLS provides an additional security layer that helps protect against man-in-the-middle attacks and other threats.
Service Extensions callouts allow users to customize the data-plane processing of select load balancers with user-created or third-party applications. This customization empowers customers to add new capabilities and optimize how traffic is handled for their Google Cloud workloads, which improves the user experience.
Cross-region internal Application Cloud Load Balancer supports global backends! In other words, the internal load balancer can now distribute load to backends spread globally. Further, global access is built-in, that is clients from any region can access the internal Application Load Balancers. This capability introduces a new level of flexibility when it comes to architecting the hosting of backends or the location of clients.
Cross-project service referencing with global external Application Load Balancers allows organizations to configure Application Load Balancers to route traffic to hundreds of services distributed across multiple different projects. Cross-project service referencing relies on Shared VPC, which allows the connecting of resources from multiple projects to a commonVirtual Private Cloud (VPC) network so that they can securely and efficiently communicate with one another.
Additional details regarding each of these exciting new capabilities follow:
mTLS support on Google Cloud external load balancers
Authentication with HTTPS communication typically works only one way: the client verifies the identity of the server. For applications requiring the load balancer to authenticate the identity of clients that connect to it, both the global external Application Load Balancer and the classic Application Load Balancer support mutual TLS (mTLS), now in preview.
With mTLS, the load balancer requests that the client send a certificate to authenticate itself during the TLS handshake with the load balancer. You can configure a trust store that the load balancer uses to validate the client certificate’s chain of trust.
mTLS offers many benefits, including:
-
Increased security: mTLS adds an additional layer of security by requiring both the client and the server to be authenticated, which makes it more difficult for attackers to impersonate either party and gain access to sensitive data.
-
Reduced risk of man-in-the-middle attacks: Man-in-the-middle attacks (MITM) are a type of cyberattack in which an attacker intercepts and redirects traffic between two parties. mTLS helps to mitigate the risk of MITM attacks by requiring both parties to be authenticated.
-
Improved visibility: mTLS can improve network traffic visibility by allowing organizations to track which clients are connecting to their servers. This can help identify potential security threats and improve the overall security posture.
In addition to these benefits, you can use mTLS with a variety of applications including Apigee X. As a result, mTLS is becoming increasingly popular as a way to improve the security of network communications.
Service Extensions callouts on Application Load Balancers
Service Extensions callouts bring a powerful tool to inject custom logic into Google Cloud Application Load Balancers. This custom logic can address unique customer workflow requirements, offer an easy option for partners to integrate their software with Google services, or help organizations implement Cross-Cloud Network. This capability allows Google Cloud customers or partners to write their own code to perform various activities on traffic processed by a load balancer such as header rewrites, incremental security, custom logging, and custom user authentication.
With Service Extensions callouts, you instruct Google Cloud Load Balancing to forward traffic from within the load-balancing data-processing path via an RPC such as gRPC, to a user-managed application or service running anywhere. These applications can apply various policies or functions before returning the traffic to the load balancer for further processing.
Benefits of Service Extensions callouts include:
-
Bespoke implementation – Traffic handling is tailored to address unique workflow requirements and can optimize the performance of cloud applications or services.
-
Empowers users – Organizations can develop their own applications or purchase programs to change how a service is delivered to support new or custom requirements.
-
Agile delivery – Users can independently create and deploy service extensions anytime.
-
Easy partner integration – Partners can quickly and programmatically integrate their software with Google Cloud Application Load Balancer services and deliver new advanced use cases.
Availability: The public preview of Service Extensions callouts for Cloud Load Balancing will start in October 2023. Supported Application Load Balancers include the global external (not including Classic), regional external, and regional internal.
Cross-region internal Application Load Balancer
Internal Application Load Balancers distribute HTTP and HTTPS traffic to backends hosted on Compute Engine, Google Kubernetes Engine (GKE), Cloud Run, on-premises, and other clouds. Until now, Internal Application Load Balancer has been regional in its scope, i.e., the load balancer could connect with backends in the same region only. Cross-region internal Application Load Balancer removes this constraint.
A cross-region Internal Application Load Balancer is a fully Google-managed service and can be deployed as a multi-region load balancer. It provides global access out of the box; that is, clients from any Google Cloud region can access the load balancer. In addition, cross-region mode enables users to load balance traffic to backends that are globally distributed. This load balancer also enables high availability; placing backends in multiple regions helps insulate users from failures in a single region. If one region’s backends are down, traffic can gracefully fail over to another region. Further, given the load balancer can be deployed in multiple regions, it is resilient to outages that can potentially impact the availability of the load balancer service in a region.
It is important to note that the load balancer proxy instances in cross-region mode are always deployed to the specific regions you choose.
To summarize, benefits of cross-region internal Application Load Balancers include:
-
Enables global Cloud Load Balancing for internal traffic: This capability brings new flexibility to how traffic can be distributed via an active/active multi-region setup.
-
Increased high availability: Availability is improved since the impact of any zone- or region-specific issues can be reduced with failover to services in a different region.
-
Unlocks Private Service Connect (PSC) use cases: Private Service Connect allows consumers to access managed services privately from inside their VPC network.
-
Support for Google-managed certificates: This support is achieved using Certificate Manager and Certificate Authority Service.
The cross-region internal Application Load Balancer is now in preview. To learn more, please visit the Internal Application Load Balancer page.
Cross-project service referencing on global external Application Load Balancers
Cross-project service referencing allows organizations to configure one central load balancer and route traffic to hundreds of services distributed across multiple projects. You can centrally manage all traffic routing rules and policies in one URL map. You can also associate the load balancer with a single set of hostnames and SSL certificates.
In this model, the load balancer’s frontend and URL map are in a host or service project. The load balancer’s backend services and backends can be distributed across projects in the Shared VPC environment. Cross-project backend services can be referenced in a single URL map.
With support for the global External Application Load Balancers, now in preview, cross-project service referencing is now available on all application load balancers including internal Application Load Balancers and regional external Application Load Balancers.
Benefits of cross-project service referencing include:
-
Efficient deployment: Optimize the number of load balancers needed to deploy your application by connecting multiple services to a single load balancer. With fewer forwarding rules and other load balancing resources, you not only incur lower costs, but also reduce your operational overhead and quota requirements.
-
Improved administrative control: By having different projects for each functional team, customers can also achieve separation of roles within their organization. So service owners can focus on building services in service projects, while network teams can provision and maintain load balancers in another project, and both can be connected using cross-project service referencing.
To learn more about Cross-project Service Referencing, please visit the external Application Load Balancer page.