Best Practices for Using Cloud IAM and Cloud Billing in Higher Education

Universities, colleges, vocational schools, and other institutions of higher
education often have unique IT needs compared to other types of enterprises.
This guide presents best practices and outlines a number of critical issues to
resolve when setting up your institution's Google Cloud Platform (GCP)
environment.

Here are some definitions of basic terms to make the guide more
understandable.

Org node

The Organization node (Org node) represents an organization such as your
school. It's the root node in the hierarchy of GCP resources.

folder

Folders organize resources under your organization. When you configure
Cloud Identity and Access Management
(Cloud IAM) policies at the folder level, policies apply transitively
to resources that are contained in the folder.

project

The project level is where you enable and use all GCP
services, manage APIs and billing, add and remove collaborators, and manage
permissions.

Cloud IAM

Cloud IAM controls policies for your organization and projects. It
governs what level of access project members have to manage virtual machines
(VMs), logs, and other resources.

role

A role is a collection of permissions. You cannot assign permissions directly
to users; instead you grant the user a role. When you grant a role, you grant
all the permissions that the role includes.

Setting up G Suite for Education

Best practice: Set up G Suite for Education to take advantage of user
accounts and groups.

If your school is investigating the capabilities of GCP, setting up
G Suite for Education
is often the starting point. Even if you don't intend to use Gmail, setting up G
Suite for Education and disabling unused services like Gmail allows you to take
advantage of user accounts and groups for GCP identity and
authentication. For commercial entities that don't qualify for free G Suite for
Education accounts,
Cloud Identity
is an option.

Managing resources

Best practice: Implement a centralized approach to
GCP resource organization.

GCP provides a hierarchical container system that consists of
organizations, folders, and projects. Within those structures, you can organize
other resources such as Compute Engine virtual machines (VMs) and
Cloud Pub/Sub
topics. This hierarchy helps you manage aspects such as access control and
configuration settings that are common to multiple resources. You can
programmatically manage these resources by using
Resource Manager.

Large institutions, including many universities, often have numerous projects
and users that interact directly with GCP resources. To best
support existing IT governance and access control strategies, we recommend that
you implement a centralized approach to GCP resource
organization.

Organizations and folders

Best practice: Use Org nodes to organize your resources.

Resources are organized with the Org node at the root. Folders can be nested up
to four levels beneath the Org node. These folders can contain projects, which
in turn contain other resources as child nodes under the projects. Each resource
has exactly one parent. When you set access control policies and configuration
settings for a parent resource, its child resources inherit those policies and
settings.

An Org node ensures that all projects that users create in your G Suite for
Education domain are visible to the super admins. Each primary domain in G Suite
for Education has one Org node; secondary G Suite domains do not get their own
Org node. By default, the G Suite super admin has irrevocable access to set
policy for the organization. For organizations that have separate IT and cloud
administration, the G Suite super admin must assign an organization admin to
administer the organization.

The structure of a typical GCP organization might look like this:

If projects were created prior to establishment of the Org node, you can
migrate
these orphaned projects into the Org node.

Note: All recommendations presented in this document assume that you have
configured a domain Org node in your GCP Console. Additionally,
Google accounts that administer GCP resources must be part of the
[SCHOOL_NAME].edu G Suite for Education domain.

When a school with a G Suite for Education domain is adopting
GCP, the default configuration is to have a single Org node. The
following section discusses single versus multiple Org node approaches.

When to use a centralized Org node

The centralized Org node is mapped to the G Suite domain, which is the source of
truth for Cloud IAM. You can set up each folder with its own central
admins along with separate Cloud IAM and other policies.

For many schools with centralized IT governance, managing two separate
GCP environments creates additional overhead. Also, policies
among multiple Org nodes can diverge over time.

How to use folders

Folders
enable you to
organize
your GCP resources, apply policies, delegate administrative
privileges, and give departments and teams more autonomy. Folders also help you
administer policies and control access above the project level. Folders,
projects, and resources that are nested within a folder inherit the policies of
the parent folder.

Here are a few scenarios where using folders might be appropriate:

Your institution has distinct schools, such as for engineering,
business, and liberal arts, each with its own IT group.

You are mapping to an established structure that is based on an LDAP
directory, such as Microsoft Active Directory.

You want to segregate projects by use case, such as IT infrastructure,
research computing, or teaching and learning.

Projects and resources

Best practice: Manage resources by using projects.

Any GCP resources that you allocate and use must belong to a
project. Think of a project as the organizing entity for what you're building. A
project consists of the settings, permissions, and other metadata that describe
your applications. Resources within a single project work together smoothly by
communicating through an internal network, subject to rules that vary by region
or zone. The resources that each project uses remain separate across project
boundaries; you can link them only through an external network connection or a
shared Virtual Private Cloud (VPC)
network.

Each GCP project has the following:

A project name, which you provide.

A project ID, which you can provide or GCP can provide for
you.

A project number, which GCP provides.

When you set up a new project, you might base it on one of these scenarios:

Ownership of applications or projects, such as setting up a project
around a workload or small team.

Dividing an application into production and non-production projects. This
way, changes made in the non-production test environment will not affect
the production environment, and changes can be promoted or propagated by
using deployment scripts.

Segregation of computing and data resources between labs or even projects
within a lab. This segregation allows full autonomy and data separation
between projects, which is useful if a lab is working on multiple projects
with competing stakeholders.

Projects must be associated with
billing accounts,
which are covered later in this document. Note that only a user with the Billing
Account Administrator or Billing Account User role can associate a new project
with an existing billing account.

Quotas

Best practice: Pay attention to quotas and limits.

Many resources within GCP are limited by quotas. For example, a
new project that is linked to a newly associated billing account has a quota of
eight virtual CPUs on Compute Engine. You can request an increase in
your quota to add more resources or new resources, such as GPUs, that are not
issued by default.

Along with resource quotas, organizations are subject to quotas on the number of
projects they create. Even if you delete a project, it remains part of the
project quota
for a few days until the project is completely purged.

Trust boundaries

Best practice: Follow the IT principle of least privilege.

When deciding upon a project structure, consider IT trust boundaries, which
likely follow an existing IT governance or security model. For example, do
separate schools, such as engineering, business, and law, maintain trust
boundaries between each other? Do separate departments within schools trust one
another?

By applying the IT security best practice of
least-privileged access,
you can grant different roles to user accounts and service accounts within a
single project and across multiple projects. If a user has administrator-level
access to one project but should have only viewer or read-only access to another
project, you can define those roles explicitly by using the Cloud IAM
policy in GCP. For more information, see the
Cloud IAM guidance on least privilege.

Cloud IAM policies

Best practice: Use Cloud IAM service accounts, roles,
policies, and groups to manage access to resources.

Large organizations often separate operations teams, such as security and
network administration, from product teams. This separation requires using
resources that are managed by other teams and following the principle of least
privilege. You can configure the settings for this separation by using
Cloud IAM and service accounts.

With Cloud IAM, you manage access control by defining who has what
level of access to which resources. You grant roles to users by creating a
Cloud IAM policy, which is a collection of statements attached to a
resource that define and control who has what type of access to that resource.
To give granular access to specific GCP resources, use
predefined roles
or define
customized Cloud IAM roles.

Note: In GCP, the G Suite Super Admin user gets assigned the
Organization Administrator IAM role by default. This role is used to grant
permissions to other users and cannot be removed from the Super Admin user
account. The most important role to grant is the
Project Creator role
so that designated users can begin creating their own projects.

How to use privileged accounts

Following the principle of least privilege, assign Super Admin roles to
infrequently used accounts. For example, you might use jo.watanabe@school.edu
for day-to-day activities but use jo.watanabe.admin@school.edu when making
changes to the G Suite Admin Console or GCP Console.

When a service account acts as an identity, you grant it roles so that
it can access a resource, such as a Cloud Storage bucket.

When a service account acts as a resource, you must grant users permission
to access that account in the same way you grant permission to access a
BigQuery dataset. You can grant a user the role of owner, editor,
viewer, or
Service Account User.
Users who are Service Account Users can access all the resources to which
the service account has access.

When to use groups

Best practice: Use groups instead of individuals in policies.

When you use groups instead of individuals in policies, as team members join and
leave, your admins can adjust group membership. As a result, the correct policy
changes happen automatically. To implement this practice, you create groups that
are based on job function for each project or folder. You then assign multiple
roles to each group as required for the job function.

Group management is handled by
Google Groups for Business,
which is part of G Suite. A G Suite admin user or delegated admin can use the
Admin Console to access this tool.

Networking options

Best practice: Choose a networking approach that meets the
needs of your institution.

With Virtual Private Cloud (VPC), you can isolate your private cloud
services. For example, you might use VPC to set up a network, a common private
RFC 1918 IP space, that spans all your projects. You then add instances from any
project to this network or its subnetworks.

You can also attach a virtual private network (VPN) to a single network, which
all or a subset of the projects can use. The VPN connection can be used to
connect to a GCP-specific RFC 1918 IP space or extend your
on-premises network's RFC 1918 IP space.

Google offers the following options for connecting to your VPC
instances.

Interconnect

Peering

Cloud Interconnect – Dedicated

IPsec VPN

Direct Peering

Carrier Peering

Useful for extending corporate networks and RFC 1918 IP space into the
cloud.

No VPN is required for access to GCP resources in your VPC.

Useful for tunneling through the public internet to connect to Google, and
for low-volume data connections.

Useful for connecting directly to Google, and for saving 50% on egress fees
compared to VPN or public access over the internet.

Useful if you like the benefits of direct peering but are unable to meet
the peering requirements without a partner.

When to use direct peering

Any GCP customer who has a registered Autonomous System Number
(ASN) and publicly routable IP prefixes is welcome to establish
direct peering
with Google. This option uses the same interconnection model as the public
internet, except there is no service provider in the middle. Learn more about
peering with Google.

When to use carrier peering

For customers who do not have public ASNs, or who want to connect to Google by
using a service provider, Google offers the
Carrier Peering
service. Carrier Peering is designed for customers who want enterprise-grade
connectivity to the Google edge network.

Cloud Billing

Best practice: Use the GCP Console to manage your
billing and budgets.

You can use the GCP Console to manage your Cloud Billing
account. From the GCP Console, you can update account settings such
as payment methods and administrative contacts. You can also configure the
GCP Console to set budgets, trigger alerts, view your payment
history, and export billing data.

For most users, a single Cloud Billing account is sufficient.
Institution-wide discounts apply to all projects that are associated with the
account. Users make a single payment to Google to settle the monthly
invoice, and department-specific or lab-specific projects can be charged by
using an internal IT chargeback process.

The single billing account looks like this:

Billing considerations can also drive how you organize projects and folders in
GCP. Depending on your internal cost centers, you might decide to
organize as in the following diagram.

In this diagram, folders identify all the projects and assets that are
associated with a cost center, department, or IT project.

Projects organize resources. Cost is shown per project, and project IDs
are included in the billing export.

You annotate projects with labels that represent additional grouping
information, such as environment=test. Labels are included in the billing
export.

The cost center is encoded into the project name or ID.

This model works well if you align each folder with a separate internal cost
center. However, internal chargebacks are still necessary because Google sends a
single invoice for a given billing account.

Multiple billing accounts are an option if cost centers must pay a separate
invoice or, for some workloads, pay with a separate currency. This approach
might require a signed agreement for each billing account.

Administering Cloud Billing accounts

Cloud Billing account roles help you administer billing accounts. You can
assign the following billing roles at the organization level.

Grant the Billing Account Administrator role at the Org node level to allow
viewing of all the billing accounts in your organization. To limit who can
create billing accounts, and how, use the Billing Account Creator role and
restrict which users have this permission. These Google Help Center articles
provide more information:

Changing billing accounts

If you want to change Cloud Billing accounts for a project, or disable
billing altogether, follow these steps.

In the GCP Console, in the left navigation menu, click
Billing.

To the right of the project name, click the three-dot icon, and then
click Change billing account. You can also use this icon to disable
billing, which disables the project.

Creating a budget

Budgets generate alerts but don't turn off billing for projects, which means
that a project continues to run even if it exceeds the budget. If a project is
running over budget, you must disable billing manually. Or you can stop the
resources that are incurring billable charges in order to prevent further
exceeding the budget. Because the budget doesn't update in real time, you might
not discover it for a day or two from the time a project begins to overspend.

In this example, the account is already over budget for the month. Remember
that a budget does not turn off any services but rather notifies the billing
administrator when the budget is exceeded.

Enter the budget details and at what levels of budget usage you want
to receive alerts.

Under Project or billing account, choose whether you want to monitor
your overall budget or individual projects. The budgets feature works on a
calendar month period. You can determine how much you want the budget to be
for a given month.

Setting up billing export

If you want a detailed report of all the services used by your
Cloud Billing account, set up Billing export from the Billing
menu in the GCP Console. Store the details in either Cloud Storage or
BigQuery. If you opt to use Cloud Storage, you can store the data in
either JSON or CSV format.

Exporting billing data to BigQuery means you can quickly find projects
that are spending over a limit that you set. You can also see which services you
are being charged for. For example, the following query lists all projects that
have spent over $0.10 in the current month. Replace [YOUR_BIGQUERY_TABLE] with
your table name.

SELECT
project.name,
cost
FROM
[YOUR_BIGQUERY_TABLE]
WHERE
cost > 0.1
ORDER BY
cost DESC