SPEAKER 1: Moving from on-prem to the cloud
can bring a ton of nifty features
for your company and applications.
But one of the biggest challenges, and certainly
the scariest, is how this movement can potentially
expose your systems to new vulnerabilities.
And without taking the right precautions,
you can run into the risk of exposing your system
in very problematic ways.
So in this episode, I'll be covering
how to control your traffic in and out of your instances
on GCP by creating firewall rules once you establish
hybrid connectivity to Google Cloud.
Stay tuned.
[MUSIC PLAYING]
Firewall rules are extremely important for a number
of reasons.
They allow you to isolate your internal network and instances
from unwanted access.
They allow you to monitor inbound and outbound activity
coming from your network for suspicious activity,
blocking items that are considered dangerous based
on a set of security rules.
They establish the first line of defense
against attacks, viruses, and malware,
and helps create a secure network.
So let's take a look at firewalls more closely.
In traditional on-prem systems, multiple servers
on a single internal network are supported
through the use of a cluster of firewalls
coupled with a load balancer.
A large drawback of this traditional architecture
is that it doesn't scale well.
In an on-prem environment, a firewall is generally
a dedicated piece of hardware that
has an upper limit in terms of capacity,
and this makes a firewall a choke point.
To support dynamic scaling, you'll
need to habitually run down to the server room
and replace the hardware with ones
that can handle increased load.
Of course, this creates its own challenge.
When the traffic goes back to normal,
you've now got a big piece of expensive hardware going
unused.
This is where Google Cloud platform's distributed
firewalls can make a difference.
Google's global network has a federation
of firewalls that can operate and scale
as your systems need them.
So you only end up paying for what you use
rather than making commitments for long-term expectations.
This gives you the same power of your on-site perimeter network,
which blocks all incoming traffic by default,
but allows you to scale without lifting a finger.
Now here's the important part.
Each VPC network functions as a distributed firewall.
If you want info on setting up the VPC,
check out the first episode.
A distributed firewall means that, by default, it
will handle filtering traffic.
But you need to adjust it to handle your access needs,
like applying firewall rules to tagged instances.
In this example, when a request comes in from a Compute Engine
System labeled with the red tag, it
hits the applicable firewall rule
before being allowed to communicate with the blue tag.
While firewall rules are defined at the network level,
connections are allowed or denied on a per-instance basis.
You can think of the GCP firewall rules
as existing not only between your instances
and other networks, but between individual instances
within the same network.
In Google Cloud, a firewall rule is made up of four things--
an action either to allow or deny traffic.
That is, a rule can either allow incoming, ingress,
or outgoing, egress, traffic, but not both simultaneously;
the type of protocol to which it applies,
such as TCP, UDP, and ICMP; either a source
or a destination for which the rule applies.
This cannot be both as it depends on the direction
of the firewall you create.
For example, for ingress rules you
would specify the source, which can be IP ranges, tags,
or service accounts, or a combination.
You wouldn't specify a destination
because the rule is already being
applied to a specific VM's inbound traffic.
You can specify the ports on ingress or egress rules.
For example, allowing ingress TCP traffic on port 22
to allow for SSH access.
You can also deny a VM's egress TCP traffic
on all ports for all destination VMs in an IP range.
Each of these parameters means that firewall rules
can help control traffic to and from your Google Cloud VMs
accordingly.
Let's look at what this looks like.
I have two existing servers here that
are trying to use iPerf to test network speed.
Here are my two SSH sessions with these VMs
with iPerf setup.
But note that I have to use a specific port for it,
and since that's not part of the standard firewall rules,
it doesn't work.
The only default firewall rules created
are allow egress and deny ingress traffic, and for Linux
instances, allow SSH/TCP traffic on port 22.
We're going to create a new firewall rule that
allows access for iPerf.
Go to the VPC Network tab and click Firewall Rules.
You can see there are a bunch of default firewall rules created
for the default network.
We need to create one for our custom VPC
that our instances are sitting in.
So click Add Firewall Rule.
Create a rule iPerf access.
Change the network to VPC 1.
Leave it as Ingress and change it to Allow.
The target tag will be iPerf access.
Source IP range will be the public internet.
The protocol will be TCP and port will be 5001 to run iPerf.
Once that saves, go back to the VM Instances page
and add the iPerf access tag to Instance 1.
And I'll do the same now for Instance 2.
Let's run iPerf again.
And boom, it's working.
Firewalls are an extremely important part
of your on-prem-to-cloud transition.
They're the basis at which traffic
can flow to and from individual cloud instances,
but also to and from your on-premise network
to your cloud network.
If you want to learn about more complex use cases,
check out the documentation linked below.
But to get you moving on your migration to Google Cloud,
stay tuned for the next episode on configuring IPs.
And remember, optimizing your network
means freeing up your bandwidth.
[MUSIC PLAYING]