Controlling Access to VPC
Networks
Philipp Maier
In this module we focus on Controlling Access to VPC Networks.
Cloud Identity and Access Management or Cloud IAM and firewall rules are some of
the ways to control access to your VPC network.
Agenda
Cloud Identity and Access
Management (Cloud IAM)
IAM members
IAM roles
Firewall rules
Lab
In this module, I will start by introducing Cloud IAM from a high-level perspective.
Then I will cover the different IAM members and focus on IAM roles. Next, we will
revisit firewall rules to cover other ways to control the targets and sources that those
rule apply to.
Finally, you will get to apply what you learned by controlling access to a VPC network
in a lab.
Agenda
Cloud Identity and Access
Management (Cloud IAM)
IAM members
IAM roles
Firewall rules
Lab
Let me start by giving a high-level overview of Cloud IAM.
Cloud Identity and Access Management
Who can do what on which resource
So what is identity access management? It is a way of identifying who can do what on
which resource.
The who can be a person, group or an application, the what refers to specific
privileges or actions, and the resource could be any GCP service.
For example, I could give you the role of Compute Network Viewer. This provides you
with read-only access to all networking resources in a project, folder, or organization.
Cloud IAM objects
Cloud IAM
Organization Folders Projects Resources Roles Members
Cloud IAM is composed of different objects, as shown on this slide. We are going to
cover each of these in this module. However, to get a better understanding of where
these fit in, let’s look at the Cloud IAM resource hierarchy.
Cloud IAM resource hierarchy
A policy is set on a resource, and
each policy contains a set of:
● Roles
● Members
Resources inherit policies from
the parent.
If the parent policy is less
restrictive, it overrides a more
restrictive resource policy.
Google Cloud Platform resources are organized hierarchically as shown in this tree
structure. The Organization node is the root node in this hierarchy, folders are the
children of the organization, projects are the children of the folders, and the individual
resources are the children of projects. Each resource has exactly one parent.
Cloud IAM allows you to set policies at all of these levels, where a policy contains a
set of roles and members. Let me go through each of the levels from top to bottom, as
resources inherit policies from their parent.
The organization resource represents your company. Cloud IAM roles granted at this
level are inherited by all resources under the organization.
The folder resource could represent your department. Cloud IAM roles granted at this
level are inherited by all resources that the folder contains.
Projects represent a trust boundary within your company. Services within the same
project have a default level of trust.
- hierarchy always follows the same path as the GCP resource hierarchy, meaning, if
you change the resource hierarchy, the policy hierarchy also changes. For example,
moving a project into a different organization will update the project's Cloud IAM
policy to inherit from the new organization's Cloud IAM policy.
Another thing to point out, is that child policies cannot restrict access granted at the
parent level. For example, if I grant you the Editor role for Department X and I grant
you the Viewer role at the bookshelf project level, then you still have the Editor role for
that project. Therefore, it is a best practice is to follow the principle of least privilege.
The principle applies to identities, roles, and resources. Always select the smallest
scope that’s necessary to reduce your exposure to risk.
Agenda
● Cloud IAM
● IAM members
● IAM roles
● Firewall rules
● Lab
Let’s talk about members, which define the “who” part of “who can do what on which
resource.”
Members
There are five different types of members: Google Accounts, Service Accounts,
Google groups, G Suite domains, and Cloud Identity domains.
A Google account represents a developer, an administrator, or any other person who
interacts with GCP. Any email address that is associated with a Google account can
be an identity, including [Link] or other domains. New users can sign up for a
Google account by going to the Google account signup page, without receiving mail
through Gmail.
A service account is an account that belongs to your application instead of to an
individual end user. When you run code that is hosted on GCP, you specify the
account that the code should run as. You can create as many service accounts as
needed to represent the different logical components of your application.
A Google group is a named collection of Google accounts and service accounts.
Every group has a unique email address that is associated with the group. Google
groups are a convenient way to apply an access policy to a collection of users. You
can grant and change access controls for a whole group at once instead of granting
or changing access controls one-at-a-time for individual users or service accounts.
A G Suite domain represents a virtual group of all the Google accounts that have
been created in an organization's G Suite account. G Suite domains represent your
organization's internet domain name such as [Link], and when you add a user
to your G Suite domain, a new Google account is created for the user inside this
virtual group such as username@[Link].
A Cloud Identity domain is like a G Suite domain because it represents a virtual group
of all Google accounts in an organization. However, Cloud Identity domain users don't
have access to G Suite applications and features.
Agenda
● Cloud IAM
● IAM members
● IAM roles
● Firewall rules
● Lab
Let’s talk more about roles, which define the “can do what on which resource” part of
Cloud IAM.
Primitive roles
Owner Editor Viewer Billing Administrator
● Invite members ● Deploy ● Read-only ● Manage billing
● Remove applications access ● Add/remove
members ● Modify code administrators
● Delete project ● Configure
● Includes Editor services
rights ● Includes
Viewer rights
There are three kinds of roles in Cloud IAM: primitive roles, predefined roles, and
custom roles.
Primitive roles are the original roles available in the GCP Console. These are the
Owner, Editor, and Viewer roles.
The owner has full administrative access. This includes the ability to add and remove
members and delete projects.
The editor role has modify and delete access. This allows a developer to deploy
applications and modify or configure its resources.
The viewer role has read-only access.
All of these roles are concentric; that is, the Owner role includes the permissions of
the Editor role, and the Editor role includes the permissions of the Viewer role.
There is also a billing administrator role to manage billing and add or remove
administrators.
Each project can have multiple owners, editors, viewers, and billing administrators.
Predefined roles
In addition to the primitive roles, Cloud IAM provides predefined roles that give
granular access to specific Google Cloud Platform resources and prevent unwanted
access to other resources. These roles are collections of permissions.
Most of the time, to do any meaningful operations, you need more than one
permission. For example, in this slide, a group of users is granted the Network Viewer
role on project_a. This provides the users of that group a lot of permissions, of which
some are illustrated on the right-hand side. The permissions are classes and methods
in the APIs.
For example, [Link] can be broken into the service, resource, and
verb, meaning that this permission is used to list all of the VPC networks that
project_a contains.
Grouping these permissions into roles, and having those roles represent abstract
functions, makes them easier to manage. Also, users can have multiple roles,
providing flexibility.
Network-related IAM roles
Role Title Description
Network Viewer Read-only access to all networking resources
Network Admin Permissions to create, modify, and delete networking
resources, except for firewall rules and SSL certificates
Security Admin Permissions to create, modify, and delete firewall rules and
SSL certificates
Let’s focus on predefined roles that provide granular access to VPC networking
resources.
There is the Network Viewer role that provides read-only access to all networking
resources. For example, if you have software that inspects your network
configuration, you could grant that software’s service account the Network Viewer
role.
Next, the Network Admin role contains permissions to create, modify, and delete
networking resources, except for firewall rules and SSL certificates. In other words,
the network admin role allows read-only access to firewall rules, SSL certificates, and
instances to view their ephemeral IP addresses.
The Security Admin role contains permissions to create, modify, and delete firewall
rules and SSL certificates.
Now, there are other predefined roles for networking resources that relate to Shared
VPC, which allows an organization to connect resources from multiple projects to a
common VPC network. We will cover Shared VPC along with those other predefined
roles in a later module of this course.
For more information on these roles, please refer to documentation linked below this
video. [[Link]
Custom roles
In addition to the predefined roles, Cloud IAM also provides the ability to create
customized Cloud IAM roles. You can create a custom Cloud IAM role with one or
more permissions, and then grant that custom role to users who are part of your
organization.
In essence, custom roles enable you to enforce the principle of least privilege,
ensuring that the user and service accounts in your organization have only the
permissions essential to performing their intended functions.
For example, you might want a user to create, modify, and delete firewall rules but
have read-only permissions to SSL certificates. In this case, the Security Admin role
provides too many permissions and the Network Admin role does not provide enough.
So, you can select the corresponding permissions for firewall rules and SSL certificate
as shown on the left-hand side along with any other permissions to create a new
custom network admin role.
Cloud IAM provides a UI and API for creating and managing custom roles. For more
information on custom roles, please refer to documentation linked below this video.
[[Link]
Demo
Custom Roles
Philipp Maier
Let me show you how to create a custom role in GCP.
My goal is to create a new network role that provides someone the network admin
permission along with the ability to create, modify or delete firewall rules.
[Demo]
That’s how it easy it is to create a custom role in GCP. Alternatively, I could have
started with the Security Admin role as a base and removed the permissions that I
don’t want the role to have.
Agenda
● Cloud IAM
● IAM members
● IAM roles
● Firewall rules
● Lab
Next, let’s revisit what we learned about Firewall rules in the previous module and
cover other ways to control the targets and sources that those rule apply to.
Firewall rules protect your VM instances from
unapproved connections
Cloud Firewall
Rules
● VPC network functions as a distributed firewall.
● Firewall rules are applied to the network as a whole.
● Connections are allowed or denied at the instance level.
● Firewall rules are stateful.
● Deny all ingress and allow all egress rules are implied.
In the previous module, we discussed that GCP firewall rules protect your virtual
machine instances from unapproved connections, both inbound and outbound, known
as ingress and egress, respectively. Essentially, every VPC network functions as a
distributed firewall.
Although firewall rules are applied to the network as a whole, connections are allowed
or denied at the instance level. Let’s explore this concept more deeply by controlling
access to specific target instances and from specific source instances, not by their IP
range but by using network tags and service accounts.
Firewall rule parameters: Target and Source
Target: Source:
● All instances in the network ● IP ranges
● Specified target tags ● Subnets
● Specified service accounts ● Source tags
● Service account
A firewall rule is composed of several parameters. Let’s revisit the target and source
parameters:
The target parameter of a firewall rule defines the instances to which the firewall rule
is intended to apply. This parameter has 3 choices, as shown on this slide. “All
instances in the network” specifies that the firewall rule applies to all instances in the
network, which we explored in the previous module.
To provide more granularity, firewall rules can also be applied to only those VM
instances that match specific service accounts or network tags, which are
user-defined strings that you can apply to your VM instances.
The source parameter of a firewall rule is intended for ingress traffic and defines the
allowed sources of the traffic. Similar to the target parameter, firewall rules can be
applied to traffic coming from VM instances that match a specific network tag or use a
specific service account.
Because service accounts are controlled through Cloud IAM, they are considered
more secure than tags. For more information on filtering by service account versus
network tag, please refer to documentation linked below this video.
[[Link]
Lab
Controlling Access
to VPC Networks
Philipp Maier
Now, it’s time for you to apply some of the concepts that we just discussed in a lab.
In this lab, you create two nginx web servers and control external HTTP access to the
web servers using tagged firewall rules. Then, you explore IAM roles and service
accounts.
Lab Review
Controlling Access
to VPC Networks
Philipp Maier
In this lab, you created two nginx web servers and controlled external HTTP access
using a tagged firewall rule. Then, you created a service account with first the
Network Admin role and then the Security Admin role to explore the different
permissions of these roles.
If your company has a security team that manages firewalls and SSL certificates and
a networking team that manages the rest of the networking resources, then grant the
security team the Security Admin role and the networking team the Network Admin
role.
Review
Controlling Access
to VPC Networks
Philipp Maier
In this module, we looked at ways to control access to VPC networks. You learned
about Cloud IAM and predefined roles for VPC networks that provide granular
permissions for users or service accounts. You also learned that networks tags and
service accounts can be used to define the target and source components of your
firewall rules.
Then, you got to apply some of those concepts in a lab and explored the permissions
of the Network Admin and Security Admin roles.
Now that we have covered some of the ways to control access your VPC networks,
let’s focus on sharing networks across projects.