Private Service Connect security

This page provides an overview of Private Service Connect security.

Private Service Connect provides several controls for managing access to Private Service Connect resources. You can control who can deploy Private Service Connect resources, whether connections can be established between consumers and producers, and which network traffic is allowed to access those connections.

These controls are implemented by using the following elements:

• Identity and Access Management (IAM) permissions determine which IAM principals are allowed to deploy Private Service Connect resources, such as endpoints, backends, and services. An IAM principal is a Google Account, service account, Google group, Google Workspace account, or Cloud Identity domain that can access a resource.
• Private Service Connect accept and reject lists and organization policies determine whether Private Service Connect connections can be established between individual consumers and producers.
• VPC firewall rules determine whether certain TCP or UDP traffic is allowed to access Private Service Connect connections.

Figure 1 describes how these controls interact on the consumer and producer sides of a Private Service Connect connection.

Figure 1. IAM permissions, organization policies, accept and reject lists, and VPC firewall rules work together to help secure the consumer and producer sides of a Private Service Connect connection (click to enlarge).

Note: Private Service Connect documentation distinguishes Private Service Connect connections from TCP connections or UDP datagrams. A Private Service Connect connection is the logical binding between consumer and producer Private Service Connect resources. A TCP connection or UDP datagram refers to the method of data transmission.

IAM

Resources: all

Each Private Service Connect resource is governed by one or more IAM permissions. These permissions let administrators enforce which IAM principals can deploy Private Service Connect resources.

IAM doesn't govern which IAM principals can connect to or use a Private Service Connect connection. To control which endpoints or backends can establish a connection with a service, use organization policies or consumer accept lists. To control which clients can send traffic to Private Service Connect resources, use VPC firewalls or firewall policies.

For more information about IAM permissions, see IAM permissions.

For information about the permissions that are required to create an enpdoint, see Create an endpoint.

For information about the permissions that are required to create a service attachment, see Publish a service with explicit approval.

Connection statuses

Resources: endpoints, backends, and service attachments

Private Service Connect endpoints, backends, and service attachments have a connection status that describes the state of their connection. The consumer and producer resources that form the two sides of a connection always have the same status. You can view connection statuses when you view endpoint details, describe a backend, or view details for a published service.

The following table describes the possible statuses.

Connection status	Description
Accepted	The Private Service Connect connection is established. The two VPC networks have connectivity, and the connection is functioning normally.
Pending	The Private Service Connect connection is not established, and network traffic can't travel between the two networks. A connection might have this status for the following reasons: The service attachment requires explicit approval, and the consumer is not in the consumer accept list. The number of connections exceeds the service attachment's connection limit. The number of propagated connections that are associated with an endpoint exceeds the service attachment's propagated connection limit. Connections that are blocked for these reasons remain in the pending state indefinitely until the underlying issue is resolved.
Rejected	The Private Service Connect connection is not established. Network traffic can't travel between the two networks. A connection might have this status for the following reasons: A producer organization policy rejected the connection. A consumer reject list rejected the connection.
Needs attention or Unspecified	There is an issue on the producer side of the connection. Some traffic might be able to flow between the two networks, but some connections might not be functional. For example, the producer's NAT subnet might be exhausted and unable to allocate IP addresses for new connections.
Closed	The service attachment was deleted, and the Private Service Connect connection is closed. Network traffic can't travel between the two networks. A closed connection is a terminal state. To restore the connection, you must recreate both the service attachment and the endpoint or backend.

Service attachment configuration

You can control which consumers can connect to a service attachment by using the following features.

Connection preference

Resources: endpoints and backends

Each service attachment has a connection preference that specifies whether connection requests are automatically accepted. There are three options:

• Automatically accept all connections. The service attachment automatically accepts all inbound connection requests from any consumer. Automatic acceptance can be overridden by an organization policy that blocks incoming connections.
• Accept connections for selected networks. The service attachment only accepts inbound connection requests if the consumer VPC network is on the service attachment's consumer accept list.
• Accept connections for selected projects. The service attachment only accepts inbound connection requests if the consumer project is on the service attachment's consumer accept list.

We recommend that you accept connections for selected projects or networks. Automatically accepting all connections might be appropriate if you control consumer access through other means and want to enable permissive access to your service.

Accept and reject lists

Resources: endpoints and backends

Consumer accept lists and consumer reject lists are a security feature of service attachments. Accept and reject lists let service producers specify which consumers can establish Private Service Connect connections to their services. Consumer accept lists specify whether a connection is accepted, and consumer reject lists specify whether a connection is rejected. Both lists let you specify consumers by the VPC network or project of the connecting resource. If you add a project or network to both the accept list and the deny list, connection requests from that project or network are rejected. Specifying consumers by folder is not supported.

Consumer accept lists and consumer reject lists let you specify projects or VPC networks, but not both at the same time. You can change a list from one type to the other without interrupting connections, but you must make the change in a single update. Otherwise, some connections might temporarily change to the pending state.

Caution: Consumer accept lists specify VPC networks by name. If a VPC network that's included in an accept list is deleted and recreated with the same name in the same project, connections to consumers that are created in the same network are still accepted.

Consumer lists control whether an endpoint can connect to a published service, but they don't control who can send requests to that endpoint. For example, say a consumer has a Shared VPC network that has two service projects attached to it. If a published service has service-project1 in the consumer accept list, and service-project2 in the consumer reject list, the following applies:

• A consumer in service-project1 can create an endpoint that connects to the published service.
• A consumer in service-project2 can't create an endpoint that connects to the published service.
• A client in service-project2 can send requests to the endpoint in service-project1, if there are no firewall rules or policies preventing that traffic.

When you update a consumer accept or reject list, the effect on existing connections varies depending on whether connection reconciliation is enabled. For more information, see Connection reconciliation.

For information about how to create a new service attachment that has consumer accept or reject lists, see Publish a service with explicit project approval.

For information about how to update consumer accept or reject lists, see Manage requests for access to a published service.

Connection limits

Resources: endpoints and backends

Consumer accept lists have connection limits. These limits set the total number of Private Service Connect endpoint and backend connections that a service attachment can accept from the specified consumer project or VPC network.

Producers can use connection limits to prevent individual consumers from exhausting IP addresses or resource quotas in the producer VPC network. Each accepted Private Service Connect connection subtracts from the configured limit for a consumer project or VPC network. The limits are set when you create or update consumer accept lists. You can view a service attachment's connections when you describe a service attachment.

Propagated connections don't count toward these limits.

For example, consider a case where a service attachment has a consumer accept list that includes project-1 and project-2, both with a limit of one connection. The project project-1 requests two connections, project-2 requests one connection, and project-3 requests one connection. Because project-1 has a limit of one connection, the first connection is accepted, and the second remains pending. The connection from project-2 is accepted, and the connection from project-3 remains pending. The second connection from project-1 can be accepted by increasing the limit for project-1. If project-3 is added to the consumer accept list, that connection transitions from pending to accepted.

Organization policies

Organization policies let you broadly control which projects can connect to VPC networks or organizations by using Private Service Connect.

The organization policies described on this page can block or reject new Private Service Connect connections, but they don't affect existing connections.

An organization policy applies to descendants of the resource that it refers to according to hierarchy evaluation. For example, an organization policy that restricts access to a Google Cloud organization also applies to the organization's child folders, projects, and resources. Similarly, listing an organization as an allowed value also allows access to that organization's children.

For more information about organization policies, see Organization policies.

Consumer-side organization policies

You can use list constraints to control the deployment of endpoints and backends. If an endpoint or backend is blocked by a consumer organization policy, the creation of the resource fails.

• Use the restrictPrivateServiceConnectProducer list constraint to control which service attachments endpoints and backends can connect to based on the producer organization.
• Use the disablePrivateServiceConnectCreationForConsumers list constraint to control the deployment of endpoints based on the endpoint's connection type. You can block the deployment of endpoints that connect to Google APIs, or you can block the deployment of endpoints that connect to published services.

Block endpoints or backends from connecting to producer organizations

Resources: endpoints and backends

Organization policies that use the restrictPrivateServiceConnectProducer list constraint with allowed values block endpoints and backends from connecting to service attachments unless the service attachments are associated with one of the policy's allowed values. A policy of this type blocks connections even if they are allowed by the service attachment's consumer accept list.

For example, the following organization policy applies to an organization named Org-A:

name: organizations/Org-A/policies/compute.restrictPrivateServiceConnectProducer
spec:
  rules:
    – values:
        allowedValues:
        - under:organizations/ORG_A_NUMBER
        - under:organizations/433637338589

Figure 2 shows the result of this organization policy. The policy has allowed values for Org-A (ORG_A_NUMBER) and Google-org (433637338589). Endpoints and backends created in Org-A can communicate with service attachments in Org-A, but not with service attachments in Org-B.

Figure 2. An organization policy lets the endpoint psc-1 connect to the service attachment sa-1 and blocks psc-3 from connecting to service attachments in Org-B. Endpoints and backends in Org-A can connect to service attachments that are owned by Google (click to enlarge).

You can allow instances of the following types of resources to create endpoints with the compute.restrictPrivateServiceConnectProducer constraint:

• Organizations
• Folders
• Projects

For information about how to create an organization policy that uses the compute.restrictPrivateServiceConnectProducer constraint, see Block endpoints and backends from connecting to unauthorized service attachments.

Block the creation of endpoints by connection type

Affected resources: endpoints

You can use the disablePrivateServiceConnectCreationForConsumers list constraint to block the creation of endpoints based on whether they are connecting to Google APIs or published services (service attachments).

For information about how to create an organization policy that uses the disablePrivateServiceConnectCreationForConsumers constraint, see Block consumers from deploying endpoints by connection type.

Producer-side organization policies

Affected resources: endpoints and backends

You can use organization policies with the compute.restrictPrivateServiceConnectConsumer list constraint to control which endpoints and backends can connect to Private Service Connect service attachments within a producer organization or project. If an endpoint or backend is rejected by a producer organization policy, the creation of the resource succeeds, but the connection enters the rejected state.

Controlling access in this way is similar to using accept and reject lists, except that organization policies apply to all service attachments in a project or organization rather than an individual service attachment.

You can use organization policies and accept lists together, with organization policies broadly enforcing access to a managed service and accept lists controlling access to individual service attachments.

Organization policies that use the compute.restrictPrivateServiceConnectConsumer constraint reject connections from endpoints and backends unless the endpoint or backend is associated with one of the policy's allowed values. A policy of this type rejects connections even if they are allowed by an allowlist.

For example, the following organization policy applies to an organization named Org-A:

name: organizations/Org-A/policies/compute.restrictPrivateServiceConnectConsumer
spec:
  rules:
    - values:
        allowedValues:
        - under:organizations/ORG_A_NUMBER

Figure 3 shows the result of this organization policy. The policy has an allowed value for Org-A (ORG_A_NUMBER). Endpoints in other VPC networks in Org-A can connect to service attachments in Org-A. Endpoints in Org-B that try to connect are rejected.

Figure 3. An organization policy lets psc-1 connect to sa-1, while it blocks psc-2 from connecting (click to enlarge).

An organization policy applies to descendants of the resource that it refers to according to hierarchy evaluation. For example, an organization policy that restricts access to a Google Cloud organization also applies to the organization's child folders, projects, and resources. Similarly, listing an organization as an allowed value also allows access to that organization's children.

You can allow instances of the following types of resources to create endpoints with the restrictPrivateServiceConnectConsumer constraint:

• Organizations
• Folders
• Projects

For more information about using organization policies with service producers, see Producer organization policies.

Interaction between consumer accept lists and organization policies

Both consumer accept lists and organization policies control whether a connection can be established between two Private Service Connect resources. Connections are blocked if either an accept list or an organization policy denies the connection.

For example, a policy with the restrictPrivateServiceConnectConsumer constraint can be configured to block connections from outside of the producer's organization. Even if a service attachment is configured to automatically accept all connections, the organization policy still blocks connections from outside of the producer's organization. We recommend using both accept lists and organization policies together to help provide layered security.

Firewalls

Resources: all

You can use VPC firewall rules and firewall policies to control network-level access to Private Service Connect resources.

For more information about VPC firewall rules in general, see VPC firewall rules.

For more information about using VPC firewall rules to limit access to endpoints or backends in a consumer VPC network, see Use firewall rules to limit access to endpoints or backends.