How to secure your Apigee X data with VPC Service Controls

Published in

Google Cloud - Community

7 min readDec 15, 2021

TL;DR

GOAL: The article provides the list of steps necessary to secure your Apigee X deployment’s data with GCP VPC Service Controls.

While it’s meant to be a step-by-step guide, I’d recommend to automate the procedure by integrating the commands with Terraform or any infrastructure as code software tool.

Context

More and more companies are facing every day an increasing number of security risks regarding their data being exposed through different applications and, because of that, they are looking for a solution to protect themselves against these threats. Just to mention some of these risks (but not all):

Access from unauthorised networks using stolen credentials
Data exfiltration by malicious insiders, compromised code or misconfiguration
Public exposure of private data caused by misconfigured GCP Cloud IAM policies (or any of the equivalent by other cloud providers)
Access to non-compliant services from sensitive environments

One of the features offered by Google to protect your application against these threads is called VPC Service Controls (VPC SC).

VPC Service Controls improves your ability to mitigate the risk of data exfiltration from Google Cloud services such as Cloud Storage and BigQuery. You can use VPC Service Controls to create perimeters that protect the resources and data of services that you explicitly specify.

Why VPC Service Controls for Apigee?

Now that is clear why we are looking at VPC SC to protect our data, let’s understand why Apigee should be included as well to this discussion.

Every time an API request flows through the Apigee Runtime, several potentially sensitive information (if not protected) are exposed and accessible by different users browsing the Apigee Management plane.
As a possible example, think about the body response of a getBankAccount API, it might includes information such as user birthday, credit card or bank account numbers, credit rating, and social security number.

These information, even if not permanently saved anywhere inside Apigee architecture, can be accessed through the console or via API (for example during a “trace” or “debug” session) so it’s important to create a perimeter surrounding Apigee data and to control the accesses to them.

Now you may think that only the Apigee UI is the issue but let’s talk about the communication between Apigee and the backend service(es) responsible for the API response. Ideally what you want to do is disabling Egress traffic from Apigee X runtime plane to any endpoint on the public Internet and route this traffic only to a selected list of destination public IP’s via the peered VPC Network in our GCP project right? This is exactly just another example of Apigee - VPC SC integration.

Note: this doesn’t mean that every single Apigee X deployment needs to be secured with VPC Service Control, it depends on the data you are managing.

HowTo: Secure your Apigee data with VPC Service Controls

Finally, let’s dive in to the list of steps needed to get the VPC Service Controls perimeter up and running protecting our Apigee data.

1. Enable VPC Service Controls on the VPC Peering Connection

The first step is enabling “VPC Service Controls” for the peered connection from your network to the one managed by Google and including Apigee by executing the following command:

gcloud services vpc-peerings enable-vpc-service-controls --network=$NETWORK_NAME --project=$PROJECT_ID

NETWORK_NAME is the name of your VPC peering network
PROJECT_ID is the ID of the project that you created during the Apigee X deployment. Only project ID is supported.

From a technical point of view, by doing this the local default route (destination 0.0.0.0/0, next hop default internet gateway) is deleted from the service producer VPC network.

2. Create a new service perimeter surrounding the peered Project

The second step is the perimeter creation:

gcloud access-context-manager perimeters create $PERIMETER_NAME --perimeter-title=$PERIMETER_TITLE --perimeter-resources=projects/$PROJECT_NUMBER --perimeter-restricted-services=apigee.googleapis.com,apigeeconnect.googleapis.com --perimeter-type=regular --policy=$POLICY_ID

PERIMETER_NAME is the name of the perimeter. A perimeter name can have a maximum length of 50 characters, must start with a letter, and can contain only ASCII Latin letters (a-z, A-Z), numbers (0–9), or underscores (_). The perimeter name is case sensitive and must be unique within an access policy.
PERIMETER_TITLE is the human-readable title of the perimeter.
PROJECTS is a comma-separated list of one or more project numbers but in this case, we just need the one created during the Apigee deployment associated with your Apigee organisation. Only project numbers are supported.
POLICY_ID is the ID of the access policy. To retrieve this information you can use the “gcloud access-context-manager policies list” command with the organisation id as input parameter.

Of course, this is just the basic command but there are plenty of additional options and customisations you might need for the gcloud access-context-manager perimeters create command. For more information, you can take a look here.

Note: By adding “dry-run” as part of the gcloud command, you can evaluate the impact of the new perimeter on your Apigee deployment before enforcing it. This is a standard approach to VPC Service Controls, after all tests are satisfied you can switch the configuration to “enforce mode” and apply the perimeter.

3. Configure the service perimeter to allow access Apigee from any “safe” source

Once the perimeter has been setup and created, what you have to do is to create one or more “access policy” based on the number of sources you’d like to trust accessing Apigee API (and so your sensitive data) and to associate these policies to the service perimeter created during previous step.

As an example, you might want to enable access to Apigee API (and so Apigee UI) from customer’s proxy so all requests coming from OnPrem facilities will be accepted.

Based upon your need, you can grant access by IP (single or range), user, service account, device and region or a combination of these. If you use the gcloud command, the detail about the policy implementation must be included in a .yaml file and send as input.

For more information about how can you create and associate an access policy to a service perimeter check this link.

Extra: What happen to the Integrated Portal?

In every Apigee X deployment, if you create a “Developer Portal” starting from the available template (called Apigee Integrated Portal), this will be deploy “somewhere” inside the GCP Network and acts as a client to Apigee. As necessary, the developer portal sends one or more HTTP/HTTPS REST requests using the Management API to retrieve information from or send information to Apigee. Because of that, when enabling VPC Service Controls to secure the Apigee Management and Connect API services, the Integrated Portal will start receiving “403” error in return for each call performed.

How can you solve that? As mentioned in the third step of the previous chapter, you should grant the Integrated Portal access to the Apigee APIs by creating an access policy.

Let’s see the list of steps (and the pre-requisites) needed in order to do so.

PreRequisites

Before starting, four different parameters are needed as input parameters during the procedure to grant the access, here the list:

POLICY_ID is the ID of the Service Perimeter you’ve just created. You can get that as “Name” field returned by

gcloud access-context-manager policies list --organization=organizations/$ORG_ID

PERIMETER_NAME is the “Name” field returned by

gcloud access-context-manager perimeters list policy=POLICY_ID

PROJECT_ID is the ID of the project peered with Apigee
APIGEE_SA_ID is the service account used by Apigee to perform the API needed by the Integrated Portal. You can get this ID from the GCP Console under “IAM & Admin -> IAM” having the flag “Include Google-provided role grants” checked or by executing

gcloud projects get-iam-policy $PROJECT_ID | grep gcp-sa-apigee.iam.gserviceaccount.com

How to grant access to the Integrated Portal

First Step: Create a conditions file on your admin machine that specifies the service account address that will grant the portal access through the perimeter. The file can be any name you want, but it must have a *.yaml extension. Condition file text should be:

- members:
 - serviceAccount:$APIGEE_SA_ID

Second Step: Create an access level policy to grant access to the perimeter to the Apigee Service Account with the following command

gcloud access-context-manager levels create $NAME --title $TITLE --basic-level-spec $CONDITION_FILE_PATH --policy=$POLICY_ID

NAME is the unique ID of the access-level policy
TITLE is the “friendly” name

Third Step: Add the newly created access-level policy to the perimeter using the “gcloud access-context-manager perimeters update” command:

gcloud access-context-manager perimeters update $PERIMETER_NAME --add-access-levels=$NAME --policy=$POLICY_ID

NAME is the unique ID of the access-level policy created in the second step

Final Remarks

To summarise, not all the Apigee deployment needs to secure their Management and Connect APIs with a dedicated perimeter, but if you expect to manage sensitive data, VPC Service Control is the feature you are looking for, what are you waiting?

Please clap for this article if you enjoyed reading it. For more cloud-based and Apigee articles, follow the Google Cloud Community.