About service connection policies
This document explains how network administrators can use service connection policies to provide connectivity to supported managed service instances through service connectivity automation. Before reading this document, ensure that you're familiar with the concepts explained in About service connectivity automation.
Specifications
Service connection policies have the following specifications:
You can create only one service connection policy for each combination of network, region, and service class. For example, you can have only one service connection policy for
vpc1inus-central1forgoogle-cloud-sql. This validation means that only one service connection policy governs a given Private Service Connect endpoint.Service instance administrators can use the service's administrative API or UI to deploy that service and configure connectivity by using service connectivity automation.
The subnets that are included in the service connection policy configuration provide IP addresses that are assigned to Private Service Connect endpoints. These IP addresses are automatically allocated and returned to the subnet's pool as managed service instances are created and deleted.
The subnets must be regular subnets, and they must be in the same region as the service connection policy. Regular subnets are different from Private Service Connect subnets.
As a best practice, we recommend that you avoid using the subnets for other resources. If other resources consume IP addresses from the subnet, you might run out of IP addresses to assign to endpoints.
Managed services that use service connection policies might support connecting to service instances by using IPv4 endpoints, IPv6 endpoints, or both. If the service supports both IPv4 and IPv6, service instance administrators can choose an IP version when deploying a service instance.
By default, the service instance and the endpoints that connect to the service instance must be in the same project (or in the case of Shared VPC, in connected projects).
Supported Google services let you configure a custom service instance scope.
Endpoints that are created through service connectivity automation might have labels applied to them by the service producer. For more information about labels, see Organize resources using labels.
If you want to use Private Service Connect service automation with multiple VPC networks that are in the same project, create a service connection policy for each network.
You can optionally configure a connection limit to specify the maximum number of Private Service Connect connections that a given service producer can create in the policy's VPC network and region.
Endpoints that are created through service connection policies can be made available in other VPC networks through connection propagation.
Authorization
Service connection policies let consumers delegate the deployment of connectivity to managed services. The service producer doesn't have direct access or IAM privileges for the consumer project. Instead, the producer configures a service connection map in their own project.
When the service connection map is created or updated, typically in response to a request from a consumer service administrator to the managed service's administrative API or UI, service connectivity automation performs a series of authorization checks. If all of the checks pass, Private Service Connect endpoints are created as specified in the request.
For information about authorization, see Authorization model.
Connection policies in Shared VPC networks
Service connection policies can automate connectivity to service instances that are located in host projects or in attached service projects.
If you're using Shared VPC, you must create the service connection policy in the host project. Endpoints are created in the project that is specified in the service instance configuration.
If you create a service connection policy in a Shared VPC network
and deploy a service instance in a service project, service
connectivity automation shares the subnets that are associated with the
service connection policy by updating the service project's
Network Connectivity Service Account.
This service account is granted the
Compute Network User role
(roles/compute.networkUser) on the shared subnets.
For a deployment example, see Shared VPC.
Connection policies with custom service instance scope
By default, service connectivity automation creates endpoints for service instances and associated service connection policies that are in the same Google Cloud project (or in the case of Shared VPC, in connected projects). For supported Google services, service instances and connecting endpoints can also be in different projects or organizations.
Not all Google services support configuring a custom service instance scope. To determine whether a service supports a custom service instance scope, see the documentation for the specific service.
Use the Service instance scope (--producer-instance-location)
setting to configure connectivity to service instances that are in other
Resource Manager nodes (projects, folders, and organizations).
- If it's set to
no_producer_instance_location, endpoints are created in the same project only. This is the default value. - If it's set to
custom_resource_hierarchy_levels, you specify the list of Resource Manager nodes in the--allowed-google-producers-resource-hierarchy-levelfield.
If you update the service instance scope for a service connection policy, existing endpoints aren't affected.
For a deployment example, see Google services with custom service instance scope.
Endpoint IP versions
The possible IP versions of endpoints that connect to service instances (IPv4, IPv6, or both) is determined by the service producer, not by service connectivity automation. If the service supports both IPv4 and IPv6, service instance administrators can choose an IP version when deploying an instance through a service's administrative API. For information about a service's supported IP versions, see the service's documentation.
When a service instance administrator chooses an IP version, service connectivity automation checks the service connection policy for compatible subnets to use for creating endpoint IP addresses:
- IPv4-only subnets support IPv4 endpoints.
- Dual-stack subnets support both IPv4 and IPv6 endpoints.
- IPv6-only subnets (Preview) support IPv6 endpoints.
If the service connection policy doesn't have a compatible subnet, the request fails, and no endpoint is created.
Additionally, the IP version of the endpoint must be compatible with the IP version of the service instance, which is determined by the associated service attachment's forwarding rule. Private Service Connect supports the following IP version combinations:
- IPv4 endpoint to IPv4 service attachment
- IPv6 endpoint to IPv6 service attachment
IPv6 endpoint to IPv4 service attachment
In this configuration, Private Service Connect automatically translates between the two IP versions.
Connecting an IPv4 endpoint to an IPv6 service attachment isn't supported.
If you want to let both IPv4 and IPv6 clients access a managed service instance, configure connectivity for separate IPv4 and IPv6 endpoints that connect to the same service.
Limitations
- Service connection policies only support automating the creation of Private Service Connect endpoints. Creating Private Service Connect backends or service attachments isn't supported.
- You cannot directly delete Private Service Connect endpoints that are created through service connectivity automation. To trigger deletion of these endpoints, decommission service connectivity.
- You can only update the subnets and connection limit for a service connection policy. If you want to update other fields, delete the policy and create a new one.
- Service connection policies support creating endpoints with IPv4 addresses. Creating endpoints that have IPv6 addresses isn't supported.
Pricing
Pricing for Private Service Connect is described on the VPC pricing page.