SPEAKER 1: Hope is not a strategy
when it comes to security.
You have to approach security from all angles
without a lot of burden on dev or psych ops.
Not the easiest task.
But there's something on Google Cloud that can go a long way.
Stay tuned.
[MUSIC PLAYING]
With an ever increasing number of end points,
networks, and attack surfaces, setting
automated and trickle-down security policies
across your cloud infrastructure can be a challenge
to say the least.
On top of that, administrators want
to set guardrails to ensure that their workloads are always
compliant to their security requirements and industry
regulations.
Public IP are one of the easiest ways
to expose your enterprise environment to the internet,
so limiting public IPs is paramount
when it comes to securing your environments.
To do that, you need to understand
what resources use public IP is in your network,
and that can include VMs, load balancers, and VPN gateways.
When you start to deploy production level systems,
you're looking at thousands of ways in which your developers
can open public IP addresses.
This is where organization policies come into play.
Org policies give you a centralized guardrail
over your organization's Google Cloud resources.
As the Org policy administrator, you
can configure restrictions across your entire resource
hierarchy.
It works like this.
You can set Org policies on the Org on folders or on projects.
They can be inherited by nested folders and projects,
or they can be overwritten on a case-by-case basis.
Using Org policies, the Org admin
can enforce constraints on Google Cloud resources
such as VMs and load balancers to adhere to basic security
requirements at all times.
In this video, we'll show you how
you can use Org 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 dive into how you can limit public IP exposure
for VMs, load balancers, and VPN gateways using Org policies.
Compute Engine instances can be exposed to the internet
directly when you assign the VM a public IP,
or when you use protocol forwarding
with the VM as its end point.
To prevent Compute Engine instances
from getting public IPs, first make
sure you have the Org policy admin role on the organization
so you can add and edit Org policies.
Then, under Org policies, search for
and edit the Org policy constraint constraints compute
VM external IP access.
This constraint lets you define the set of Compute Engine
VMs that are allowed to use public IPs on your network.
Meanwhile, all other VMs will not be able to get a public IP.
Click Edit, select Customize, replace the parent's policy
and use these roles, leave the policy value as custom,
and set policy type as allow.
Then paste the path to the only instance
you want to allow external IP creation for.
Now you've restricted public IP creation to only this instance
and prevented public IP creation for any other instances
in your organization.
To prevent protocol forwarding from being enabled,
use the Org policy constraint constraints compute restrict
protocol forwarding creation for types,
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.
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 constraints
compute restrict VPN peer IPs.
This constraint will limit the public IPs
that are allowed to initiate IPsec sessions with your VPN
gateway.
Next up, load balancers.
Google Cloud offers a variety of internal and external load
balancers.
To prevent the creation of all external load balancer types,
usually org policy constraint constraints
compute restrict load balancer creation for types,
and then make sure to add all of these external load
balancer types for the policy values.
And for ease of use, instead of manually entering,
you can also simply add in colon external,
which will always cover all types of external load
balancers.
As new load balancer types or introduced,
you can be assured your infrastructure will
remain secure.
And finally, restricting GKE surfaces.
GKE lets developers create and expose their services
to the internet very easily.
But if you add the policies for VMs and load balancers,
as we showed, no new GKE services
can be exposed to the internet without the organization
administrator's knowledge.
In this example, we've enabled our Org policy constraints.
A developer attempts to create a GKE service
with an external load balancer.
When we check the status of the service,
they get a pending external IP.
When running kubectl describe service,
they get an error due to the load balancer Org policy
constraint in place.
Pretty sweet.
Keep in mind Org policies are not retroactive.
They will only apply to new infrastructure requests
after the policy is set.
So you won't have to worry about breaking any existing workloads
when you add these policies to your Org.
And that's it.
You can apply Org policies easily and efficiently
across your entire Org hierarchy or subset
of resources from a single centralized place.
You can sleep better at night knowing
you don't have any stray resources that your teams have
assigned public IPs to that shouldn't have them.
Check out the link below to learn more.
And remember, optimizing your network
means freeing up your bandwidth.
[MUSIC PLAYING]