LinkedIn
Twitter
Apigee X can be connected to a private VPC either via VPC-peering, or through the non-peering Private Service Connect (PSC) option, as described in the Apigee networking options docs page. Both approaches have their pros and cons - VPC-peering offers direct network integration to private IPs and hosts, but requires a /22 address space range in the target VPC, which can be difficult to reserve if address space is tight (especially in a shared VPC hub). PSC is simpler and doesn't have any VPC address space constraints, but doesn't offer DNS name resolution, and normally requires 1 PSC connection per target host, which can also be difficult to manage for a lot of backend hosts.
A relatively new option is to use Google Cloud Secure Web Proxy together with PSC for a best-of-breed solution, offering the simplicity of PSC with the flexibility of private IP and host resoultion in the target network, without the the complexity or constraints of VPC-peering. How does it work? Let's dive right in!
The result is similar to this diagram from the Secure Web Proxy overview page, just with Apigee X instead of the Compute Engine boxes.
So let's get started in setting everything up.
Step 1: Apigee X org with PSC southbound enabled.
As a starting point, you will need an Apigee X org with VPC peering disabled (so using PSC for southbound connectivity).
Step 2: Create a subnet in your network & region for SWP (PSC type)
To start we will need an extra subnet in our VPC network for SWP with type PSC. Open VPC Network in the GCP console, select your network, and create a new subnet in your region for SWP with a free-range and type Private Service Connect.
Step 3: Create a first SWP policy to allow all traffic
Now let's create the SWP and a policy to just allow all traffic through the proxy. This can be adapted later to direct and filter traffic as needed.
Open up Network Security > Secure Web Proxy in the GCP console. You might need to enable several APIs (Network Security and Certificate Management) to get it working, and it might also take a couple of page refreshes until the Secure Web Proxy screen is available. When it's ready, go to the Policies tab, and click the CREATE A POLICY button. Fill in the name, enable a rule, select your region, and in the rule MATCH field just enter true to allow everything (you can go through the syntax help for how to write more complex filters, if needed). Finish by clicking CREATE to create the policy with one rule.
Step 4: Create a Secure Web Proxy in any project.
Now go back to the WEB PROXIES tab and click + CREATE A SECURE WEB PROXY to create the proxy.
The Web proxy IP address needs to be a free IP address in the network and subnet that you select. The Ports are flexible to choose, so I just use 8080. Select the policy from the previous step for Associated Policy. Click CREATE to create the proxy.
Step 5: Create a service attachment to the SWP proxy
Now let's create a service attachment to the SWP proxy. This can then be used by Apigee X to proxy traffic through. The easiest way to create the service attachment is currently through a gcloud command.
gcloud compute service-attachments create swpatt1 \
--target-service=http://networkservices.googleapis.com/v1/projects/apigee-test38/locations/europe-west1/gateways/apigee-swp \
--nat-subnets swp-nat-subnet --connection-preference=ACCEPT_AUTOMATIC \
--region=europe-west1 --project=apigee-test38
Take care that the above command is adapted for your Google Cloud Project Id, location and subnet name (which we created in step 1), as well as any other details that might be different in your environment. The URL that is returned can then be used in Apigee X.
Step 6: Create an Apigee X Endpoint Attachment
Now go to the Apigee X Endpoint Attachments page in your project, and press the +CREATE button. Enter a name, select your project, and then select the Service Attachment that we just created.
Click CREATE to create the attachment.
After it is finished, you should have a Host IP address that can be used to connect with the service attachment from Apigee proxies.
In our case above, the IP address 7.0.16.3 can now be used to connect to our SWP from Apigee X environments.
Step 7: Configure Apigee X Forward proxying through the endpoint attachment
Apigee X can be configured to use proxy forwarding for host network communication. This means that host network requests can be forwarded through a proxy, which can take care of all host name & backend resolution, in our case from the SWP proxy (which is outside of our Apigee X network, and so can resolve completely local & private hosts in a completely different VPC).
To configure proxy forwarding for an Apigee X environment, run this command to update your Apigee X environment forward proxy configuration. If you want to remove the forward proxy, just update it with an empty string.
curl -X PUT "https://apigee.googleapis.com/v1/organizations/apigee-test38/environments/eval" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H 'Content-Type: application/json; charset=utf-8' \
--data-binary @- << EOF
{
"forwardProxyUri": "http://7.0.16.3:8080"
}
EOF
Of course, change the above command for your own Apigee X project Id and environment name, and with your own IP address and port for the SWP endpoint attachment.
After runnings this command, all traffic from the proxies in the Apigee X environment should go through the SWP. You can further tune it by testing blocking different hosts, and directing traffic to your own private hosts in your network. If traffic is blocked by the SWP you will get a 502 and fault message in the proxy with 403 not authorized. If the SWP cannot resolve a host then you will get a 503.
Conclusion
SWP opens up a lot of private & managed connectivity options for Apigee X, with internal VPC connectivity & other filtering possibilities without VPC peering, and using the simplicity of PSC to tunnel network requests into your own network. Feel free to post any questions here in the chat!
