Is it possible to connect to a private bucket using Private Service Connect without passing through valid IPs?
What we need?
We need to connect from organization A (Google Cloud) to a private bucket in organization B (also Google Cloud) traveling only via internal IPs.
Possible solution: Connect organizations using Private Service Connect.
Following the PSC documentation, it is possible to connect to a bucket using Private Service Connect through an endpoint configured to access Google APIs. Access via the endpoint is via the URL storage-endpointname.p.googleapis.com, but this URL travels through valid IPs and not by internal IPs.
The second possibility is to connect to Private Service Connect through backends, but this feature is only available for regional Google APIs and the Cloud Storage API is not on this list.
Doubt
Is it possible to make a connection between an organization A and a private bucket of an organization B without going through routable IPs using the PSC or any other resource available on Google Cloud?
Solved! Go to Solution.
The way I understand Private Service Connect [1] is that you create a forwarding rule for a "publicly resolvable URL" -- such as storage.googleapis.com to point to a custom, internal IP address. If I understand this correctly, "storage-endpointname.p.googleapis.com, but this URL travels through valid IPs" is not a correct assumption. If you set up the forwarding rules in your subnet for this endpoint to point to PSC IP address, it will do so. And, at the same time, if you use the same DNS name used by storage (e.g. storage.googleapis.com), it might be possible to resolve to a public IP address but the users won't be able to connect to it.
In short, you either override the DNS entry in your subnet for *.googleapis.com or you use a different domain name and over-ride it in the GCS client.
[1] https://cloud.google.com/vpc/docs/configure-private-service-connect-apis#gcloud
Hoping to see some attention on this from the networking experts. But in the meantime, I want to be fully sure that the problem statement is clear. It sounds like you need to copy data from bucket A to bucket B and you don't want to use a publicly resolvable url (such as *googleapis.com). Is that correct? What is the risk that you see in using this such a publicly resolvable URL?
Yes, that is the definition of the problem. Users in organization A will access buckets in organization B to query and transfer data.
This connection cannot travel through publicly resolvable IPs, because these users (from organization A) will not have access to the Internet. For this reason we need an internal connection to the buckets.
This was the first connection structure via PSC. We have a private connection with services attachments that allow access to Kubernetes resources and a connection via Google APIs endpoint to the buckets, but then we discovered that the PSC endpoint connects to the bucket using public IPs.
We wanted to know if there is a way to connect to buckets with only internal IPs. To simplify:
The way I understand Private Service Connect [1] is that you create a forwarding rule for a "publicly resolvable URL" -- such as storage.googleapis.com to point to a custom, internal IP address. If I understand this correctly, "storage-endpointname.p.googleapis.com, but this URL travels through valid IPs" is not a correct assumption. If you set up the forwarding rules in your subnet for this endpoint to point to PSC IP address, it will do so. And, at the same time, if you use the same DNS name used by storage (e.g. storage.googleapis.com), it might be possible to resolve to a public IP address but the users won't be able to connect to it.
In short, you either override the DNS entry in your subnet for *.googleapis.com or you use a different domain name and over-ride it in the GCS client.
[1] https://cloud.google.com/vpc/docs/configure-private-service-connect-apis#gcloud
Yes perfectly. The concept had not been clear to us.
We performed the correct configuration, created the PSC endpoint and a new DNS route storage-endpointname.p.googleaips.com pointing to the IP address of the created endpoint, as indicated in the documentation, then the next step was to configure the routing in our firewall for our network to recognize the DNS storage-endpointname.p.googleaips.com making it possible to travel through the internal network.
Thank you for the help!
@KirTitievsky In this case, wouldn't the storage-endpointname.p.googleaips.com address still be available publicly outside of the requestors GCP networks?
Admittedly, their IAM permissions should block access, but the address would still be publicly available.
@KirTitievsky & @aline2 please could you help, we are able to resolve storage-endpointname.p.googleaips.com using private service connect but the subdomains are not resolving for example bucketname.storage-endpointname.p.googleaips.com is giving error *** UnKnown can't find bucketnamet.storage-endpointname.p.googleapis.com: Non-existent domain'
How did we configure "then the next step was to configure the routing in our firewall for our network to recognize the DNS storage-endpointname.p.googleaips.com making it possible to travel through the internal network."
in new setup PSC itself will create service directory record and DNS Zones, let me know if you need more details