GCP – Limiting public IPs on Google Cloud

You’ve heard this saying: Hope is not a strategy when it comes to security. You have to approach security from all angles, while minimizing the burden on dev and SecOps. But with an ever increasing number of endpoints, networks, and attack surfaces, setting automated and trickle down security policies across your cloud infrastructure can be a challenge. On top of that administrators need to set guardrails to ensure that their workloads are always compliant with security requirements and industry regulations. 

Public IPs are among the most common ways that enterprise environments are exposed to the internet, making them susceptible to attacks and data exfiltration. That’s why limiting public IPs is paramount in securing these environments. On Google Cloud Platform, it’s important to understand what resources use public IPs in your network, which can include:

• VMs
• Load balancers
• VPN gateways

When you start to deploy production level systems, you’re looking at potentially thousands of instances in which your developers can deploy public IP addresses. 

Organization Policies

Organization policies give you centralized control over your organization’s Google Cloud resources. As the organization policy administrator, you can configure restrictions across your entire resource hierarchy. 

For example, you can set organization policies on your top-level GCP organization, on nested folders, or on projects. These policies can be inherited by nested folders and projects, or they can be overridden on a case by case basis. Using organization policies, you can enforce constraints on Google Cloud resources, such as VMs and load balancers to adhere to basic security requirements at all times. 

You can use organization policies as guardrails to ensure no public IPs are allowed in your Google Cloud network. It’s a perfect tool for IT or Security Admins to ensure all cloud deployments adhere to their security standards. Let’s walk through how to set them up.

Limit public IPs for VMs

Compute Engine instances can be exposed to the internet directly when you:

• Assign the VM a public IP
• Use protocol forwarding with the VM as its endpoint

To prevent Compute Engine instances from getting public IPs, first make sure you have the Org Policy Admin role in the organization, so you can add and edit org policies. 

Then, on the Organization policies page in the Google Cloud Console, search for and edit the org policy constraint named constraints/compute.vmExternalIpAccess. This constraint lets you define the set of Compute Engine VMs that are allowed to use public IPs in your network. (No other VMs will be able to be assigned a public IP.) Edit the policy with the following values:

Under Custom values, paste the path to any instance for which you want to want to allow external IP creation, for example: projects/{project-id}/zones/{zone}/instances/{instance-name}.

Now you’ve restricted public IP creation to only the instances you’ve explicitly specified, and prevented public IP creation for any other instances in your organization.

Prevent protocol forwarding to a VM

To prevent protocol forwarding from being enabled, use the org policy constraint named constraints/compute.restrictProtocolForwardingCreationForTypes, and set it to the following values. Note that the policy value is case sensitive.

This constraint lets you limit virtual hosting of public IPs by Compute Engine VM instances in your organization.

Limit public IPs of VPN gateways

For VPNs, a VPN gateway requires a public IP address for you to connect your on-premises environment to Google Cloud. To ensure that your VPN gateway is protected, use the org policy constraint named constraints/compute.restrictVpnPeerIPs. This constraint will limit the public IPs that are allowed to initiate IPSec sessions with your VPN gateway.

Limit Public IPs of Load Balancers

Google Cloud offers a variety of internal and external load balancers. To prevent the creation of all external load balancer types, use the org policy constraint named  constraints/compute.restrictLoadBalancerCreationForTypes. Then make sure to add all external load balancers for the policy values, as shown below:

Instead of manually entering each load balancer, you can also simply add in:EXTERNAL, which will always cover all types of external load balancers. As new load balancer types are introduced, you can be assured your infrastructure will remain secure.

Restricting GKE services

Google Kubernetes Engine (GKE) lets developers create and expose their services to the internet easily. But if you apply the previously discussed policies for VMs and load balancers, no new GKE services can be exposed to the internet without the org admin’s knowledge. 

For example, if a developer attempts to create a GKE service with an external load balancer, the forwarding rule for the required load balancer can’t be created with the org policy constraint in place. Furthermore, checking the status of the GKE service will deliver a pending external IP. When they run kubectl describe service, they’ll get an error due to the load balancer org policy constraint in place.

Keep in mind organization policies are not retroactive. They will only apply to new infrastructure requests after the policy is set. So you don’t have to worry about breaking any existing workloads when you add these policies to your org. You can apply org policies easily and efficiently across your entire org hierarchy or on a subset of resources from a single, centralized place, and prevent stray resources from being assigned public IPs when they shouldn’t have them. Try it out for yourself, and learn more in the organization policy constraints documentation.

For more cloud content, follow me on Twitter @stephr_wong.