PrivateEndpoint

A VPC endpoint policy (gateway or interface) granting access to principals in another AWS account enables cross-account access to the backing PaaS service via the endpoint path. The endpoint policy resource is the trust artifact (modeled as ResourcePolicy source).

An available Interface VPC Endpoint (PrivateLink) makes the backing AWS or third-party service reachable from compute within the VPC via private networking, without traversing the public internet. Source is any Compute node in the VPC that has network access to the endpoint ENI.

An available Interface VPC Endpoint (PrivateLink) makes the backing AWS or third-party service reachable from compute within the VPC via private networking, without traversing the public internet. Derived from the endpoint state and VPC co-location facts.

A PrivateLink producer endpoint with an explicit permission granting access to a foreign account principal is exposed to cross-account consumption. This is a structural fact representing the intended cross-account data-plane exposure.

A principal with ec2:ModifyVpcEndpointServicePermissions can grant or revoke access to a PrivateLink producer endpoint, controlling which principals (including foreign accounts) can consume the service.

A ServiceNetworkResourceAssociation with status ACTIVE grants PrivateReachability from connected-VPC clients to the resource through the resource gateway.

An AFD Premium origin configured with a sharedPrivateLinkResource makes the target PaaS service reachable via a private endpoint inside the customer VNet. A compute foothold in the same VNet as the PE subnet can reach the same service privately (without traversing the internet).

If the backing PaaS resource (Key Vault, Storage, etc.) has a non-empty autoApprovalSubIds list in its privateEndpointConnections properties, and a PE is created in a subscription matching that list, the connection is auto-approved (no manual approval step required). Creating a PE in that subscription immediately grants the consumer VNet private access to the resource.

An Approved private endpoint connection that crosses subscription boundaries extends private network reach across the subscription boundary: a foothold in the consumer VNet (sub A) gains private network access to the PaaS resource in the provider subscription (sub B).

A Microsoft.Network/privateEndpoints ARM record where the PE subscription differs from the backing resource's subscription (cross-subscription connection) directly establishes cross-subscription private reachability. The connection is approved and DNS-configured, so network traffic flows across the subscription boundary.

Write access to a private endpoint's privateDnsZoneGroups lets an attacker re-link the PE to an attacker-controlled private DNS zone, redirecting DNS resolution of the PaaS service FQDN for that specific PE to an arbitrary IP.

An Approved private endpoint with a working private DNS zone group makes the backing PaaS resource (Key Vault, Storage, SQL, etc.) reachable at a private IP from any compute in the same VNet or a peered VNet - bypassing the public firewall.

A Microsoft.Network/privateEndpoints ARM record with provisioningState=Succeeded, connection status=Approved, and a privateDnsZoneGroup attachment directly establishes that the backing PaaS resource is privately reachable from compute in the same or peered VNet. This is a structural fact observed in the PE resource properties.

Write access to a private endpoint object (privateEndpoints/write) grants full control of that PE - NIC, DNS zone groups, and subnet placement - enabling the attacker to reconfigure where private traffic flows.

When a consumer PE is Approved and connected to an attacker-controlled Private Link Service, network traffic from the consumer VNet is routed to the attacker's backend. This models the realized traffic-interception attack scenario (distinct from the write capability).

Write access to a Private Link Service (PLS) lets an attacker create or modify a PLS that fronts an attacker-controlled backend. This edge models the control-plane write capability (can create/modify a PLS), not the data-plane traffic interception (which is conditional on a consumer connecting to it).

A private endpoint (emitted from explicit azure-vnet-private-endpoint-record) makes a PaaS service (Key Vault, Storage, SQL, Service Bus, etc.) reachable at a private VNet IP. Compute resources located in the endpoint's VNet (via LocatedIn edges) gain network-layer access to that service without traversing the internet.

A principal with iap.tunnelDestGroups.accessViaIAP can reach hosts in a TunnelDestGroup via IAP TCP forwarding. DestGroups enable IAP tunnels to non-GCE endpoints (Cloud Run internal, on-prem hosts, or other private services reachable within the VPC). This provides private-network reach to those endpoints without a VPN.

An internal Application Load Balancer or internal passthrough NLB (loadBalancingScheme INTERNAL or INTERNAL_MANAGED) is reachable only from within the VPC, peered VPCs, or connected on-premises networks. A compute resource with a foothold in the same VPC can reach the internal LB frontend and, through it, the backends.

An identity with compute.forwardingRules.create and compute.subnetworks.use on the target subnet can create a new PSC consumer forwarding rule pointing at any Service Attachment the consumer project is authorized to connect to. This opens a new private channel to the producer service that did not previously exist. compute.addresses.create is only required when reserving a static IP; PSC endpoints with ephemeral IPs do not require it.

An identity with compute.serviceAttachments.create can publish a new Internal Load Balancer backend as a Private Service Connect service attachment, making it reachable by any PSC consumer that has the Service Attachment URI and can create a forwarding rule. This is a high-value capability for lateral movement or service hijacking attacks: the attacker can intercept traffic intended for a legitimate service or exfiltrate data through a honeypot endpoint. The published service is visible to all projects in ACCEPT_AUTOMATIC mode (default) or to explicitly listed projects in ACCEPT_MANUAL mode.

An identity with compute.forwardingRules.delete on a PSC consumer endpoint (forwarding rule with purpose=PRIVATE_SERVICE_CONNECT) can remove it. This is a destructive capability that disrupts private connectivity to the producer service, purely an availability impact rather than privilege escalation or data access.

An identity with compute.serviceAttachments.update can modify the consumerAcceptLists of a Service Attachment (or change connectionPreference to ACCEPT_AUTOMATIC), adding unauthorized consumer projects and granting them private access to the producer's Internal LB backend.

A PSC consumer forwarding rule targeting the all-apis or vpc-sc Google API bundle gives workloads in the consumer VPC private IP access to Google APIs (Cloud Storage, Secret Manager, BigQuery, etc.) without a public IP or internet egress. An in-network attacker with code running on a consumer-VPC workload can call any Google API the workload's SA is permitted to call over this private path.

A PSC consumer forwarding rule targeting a Service Attachment (producer-published service) gives workloads in the consumer VPC private IP access to the producer's Internal Load Balancer backend (Cloud SQL, Cloud Run, GCE-based service, etc.). An in-network attacker can reach the producer backend over this private channel without traversing the public internet.

A Private Service Connect consumer endpoint (forwarding rule targeting a serviceAttachment) provides a private internal-IP path from the consumer VPC to the producer service, without internet traversal.