Onboarding best practices for state, local, and education organizations

Last reviewed 2022-10-15 UTC

State, local, and education (SLED) organizations often have unique IT needs compared to other enterprises. This guide defines onboarding considerations and best practices for creating a Google Cloud and Google Workspace environment for a SLED organization. This document is intended for administrators who are setting up Google Cloud and Google Workspace or Google Workspace for Education for their organization.

Identity overview

Before you create a Google Cloud environment, you must understand how Google Cloud provides authentication, authorization, and auditing. Three cloud services work together for authentication, access control, and auditing:

Cloud Identity

Cloud Identity is an identity as a service (IDaaS) product that lets you centrally manage users and groups who access Google Cloud, Google Workspace, or Google Workspace for Education resources. Cloud Identity is available in both a free or paid (premium) version. During the onboarding to Google Cloud process, Cloud Identity provides primary domain validation using a TXT record. The benefits of using Cloud Identity are the following:

  • Lets you create and manage groups using the Google Workspace Admin console.
  • Provides account security control including single sign-on (SSO) and two-factor authentication (2FA).
  • Can be used as an identity provider for third-party applications because it supports Security Assertion Markup Language (SAML) and LDAP.

Set up identity

At a high level, the recommended steps for establishing an identity are the following:

  1. If you are not already using Cloud Identity, Google Workspace, or Google Workspace for Education, start with one of the following signup pages:

    Use an administrator account to navigate the in-console checklist.

  2. Use Cloud Identity to verify your domain. Domain verification automatically creates an organization, which serves as the root node of the Google Cloud resource hierarchy.

    If you encounter an error that states that a domain is already claimed, complete the domain reclaim process. This process can take up to five business days.

  3. After domain verification, log in to the Google Workspace Admin Console with the newly created administrator account.

  4. Identify the organization administrators who will manage the new Google Cloud organization in the Google Cloud console.

  5. Add users using Workforce identity federation

    or Cloud Identity. With Cloud Identity, you can add users using one of the following ways:

Manage resources

This section describes the best practices for managing resources in a SLED organization.

Implement a centralized approach to Google Cloud resource management

Google Cloud 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), databases, and Cloud Storage buckets. 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 organizations often have many projects and users that interact directly with Google Cloud resources. To best support existing IT governance and access control strategies, we recommend that you implement a centralized approach to Google Cloud resource organization.

Use organization nodes to organize your resources

Resources are organized with the organization node at the root. Folders can be nested up to four levels beneath the organization node. These folders can contain projects, which in turn contain other resources as children below 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 organization node ensures that all the projects that users create in your domain are visible to the super administrators. Each primary domain has one organization node. By default, the Google Workspace super administrator has irrevocable access to set the policy for the organization. For organizations that have separate IT and cloud administrations, the Google Workspace super administrator must assign an organization administrator to manage the organization. For more information, see Super administrator account best practices.

If projects were created before you created the organization node, you can migrate these unaffiliated projects into the organization node.

When you begin using Google Cloud, the default configuration is to have a single organization node. The following sections discuss single versus multiple organization node approaches. For more information about these options, see Decide a resource hierarchy for your Google Cloud landing zone.

Option 1: Single organization node

In this option, you map a single organization node to the Workspace domain, which is the source of truth for IAM. Each folder can have its own administrators along with separate roles and other policies. The following diagram shows a single organization node, using an education institution as an example. You can add further subfolders for teams and environments as needed.

A single organization node.

You can host global resources such as cross-project networks and shared images in a folder with permissions that allow access to all users in the organization.

For more information, see the following:

Option 2: Separate organization nodes

If you want to treat departments within your organization as isolated entities with no central administration, consider creating separate organizations. The following diagram shows separate organization nodes, using a school as an example.

Separate organization nodes.

To implement this configuration, you set up school.edu and lab3.school.edu as separate primary Google Workspace domains, resulting in discrete organization nodes. Use this option only if all of the following items are true:

  • You want to maintain separate identity domains.
  • You must keep access controls, custom roles, billing, quota, and configuration settings for the second organization distinct from the central school.edu organization node.

For many organizations with centralized IT governance, managing two separate Google Cloud environments creates additional overhead. For example, security policies among multiple organization nodes can diverge over time unless administrators are careful to keep the policies synchronized.

For more information about the implications of this approach, see Use a single organization node.

Use folders to organize resources

Folders let you organize your Google Cloud resources, apply policies, delegate administrative privileges, and give departments and teams more autonomy. Folders also help you administer policies and control access for a group of projects at the same time. Folders, projects, and resources that are nested within a folder inherit the policies of the parent folder.

The following are a few scenarios where using folders might be appropriate:

  • Your organization has distinct business units, each with its own IT group.
  • You're 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.

For more information, see Manage your Google Cloud resources.

Use projects to organize resources

Any Google Cloud resources that you allocate and use must belong to a project. A project is 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 by communicating through an internal network. The resources that each project uses remain separate across project boundaries. You can link resources only through an external network connection or a shared Virtual Private Cloud (VPC) network.

Each Google Cloud project has the following:

  • A project name, which you provide.
  • A project ID, which you can provide or Google Cloud can provide for you.
  • A project number, which Google Cloud provides.

When you create a project, consider the following:

  • Determine the ownership of projects and create separate projects for different workloads or teams.
  • Use separate projects to divide an application into production and non-production environments. This way, changes made in the non-production environment don't affect the production environment, and changes can be promoted or propagated by using deployment scripts.
  • Separate the computing and data resources between labs or even work within a lab. This separation allows for full autonomy and data separation between projects, which is useful if a lab is working on multiple projects with competing stakeholders.

When you create a project, you must associate it with a billing account. You must have the Billing Account Administrator role or Billing Account User role on the target billing account to be able to associate a new project with an existing billing account.

Use Active Assist to manage resources at scale

As your organization grows, the amount of complexity generally increases. Projects become unused, VMs sit idle, and permissions get granted but aren't removed when they are no longer needed. To reduce complexity, we recommend keeping an up-to-date asset inventory and reviewing it using the recommendations and insights from Active Assist. Active Assist provides recommendations for finding idle VMs, removing excess IAM permissions, deleting or reclaiming unused projects.

Using these recommendations can have significant benefits to your organization. These benefits include reducing unnecessary spending and decreasing security risks, and increasing the performance and manageability of your organization.

To access an inventory and history of all Google Cloud projects and associated resources, you can use Cloud Asset Inventory. You can export asset history to BigQuery or Cloud Storage.

Manage access controls

This section describes best practices for managing access to Google Cloud and Google Workspace services.

Use groups for policy management

It's an IAM best practice to use groups instead of individuals in policies. As team members join and leave, you can adjust group membership, and the correct policy changes happen automatically. To implement this practice, create Google Groups that are based on job functions for each project or folder. You then assign multiple roles to each group as required for the job function.

To manage groups, a super administrator or delegated administrator can use the Google Workspace Admin Console.

Use least privilege to create trust boundaries

When you decide on a project structure, consider IT trust boundaries, which likely follow an existing IT governance or security model. For example, consider if your organization includes separate departments, such as engineering, business, and law, that must maintain trust boundaries between each other.

When you apply the security best practice of least privilege, you can grant different roles to user accounts and service accounts across projects. If a user has administrator-level access to one project but only requires viewer access to another project, you can define those roles explicitly by using an allow policy. For more information, see the IAM guidance on least privilege.

Use service accounts, roles, and policies to manage access to resources

Large organizations often separate operations teams, such as security and network administration, from other departments. This separation requires using resources that are managed by other teams and following the principle of least privilege. Configure this separation using IAM and service accounts.

With IAM, you manage access control by defining who has what level of access to which resources. You grant roles to users by creating an allow policy. To give granular access to specific Google Cloud resources, use predefined roles or define custom roles.

In Google Cloud, a super administrator in Google Workspace gets assigned the Organization Administrator role by default. This role is used to grant permissions to other users and cannot be removed from the super administrator account. The most important role for a super administrator to grant is the Project Creator role so that designated users can begin creating their own projects.

For more information about service accounts, see Understanding service accounts.

Create privileged accounts sparingly

Following the principle of least privilege, assign super administrator roles to separate accounts from your administrators' regular accounts. For example, you might use alex@school.edu for day-to-day activities but use alex.admin@school.edu when you make changes to the Google Workspace Admin Console or Google Cloud console.

Create identities for workloads

Google Cloud uses service accounts to invoke Google API calls to ensure that user credentials aren't directly involved. These accounts are treated as both an identity and as a resource in the following ways:

  • When a service account acts as an identity, you grant it roles so that it can access a resource, such as a storage bucket.
  • When a service account acts as a resource, you must grant users the permission to access that account in the same way that 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 have the Service Account Users role can access all the resources to which the service account has access.

Manage billing

There are two types of Cloud Billing accounts: self-serve (or online) account and invoiced (or offline) account.

The features of a self-serve account are the following:

  • If supported in your country or region, payment is made using a payment instrument such as a credit card, debit card, or ACH direct debit.
  • Costs are charged automatically to the payment instrument that is connected to the Cloud Billing account.
  • You can sign up for self-serve accounts without help from us.
  • The documents generated for self-serve accounts include statements, payment receipts, and tax invoices. You can access these documents from the console.

The features of an invoiced account are the following:

  • Payment is made using a check or wire transfer.
  • Invoices are sent by mail or electronically.
  • You can access invoices and payment receipts from the console.
  • You must be eligible for invoiced billing. For more information, see invoiced billing eligibility.

The following sections describe the best practices for both types of Cloud Billing accounts.

Export Cloud Billing data to BigQuery for analysis

To analyze your usage and costs, export your billing data to a BigQuery dataset.

Exporting billing data to BigQuery can help you find projects that are spending over a limit that you set. You can also query the list of services you're being charged for. For example, the following query lists all projects that have spent over $0.10 in the current month:

SELECT
  project.name,
  cost
FROM
  YOUR_BIGQUERY_TABLE
WHERE
  cost > 0.1 AND usage_month IN "YYYY-MM"
ORDER BY
   cost DESC

Replace the following:

  • YOUR_BIGQUERY_TABLE with your table name.
  • YYYY-MM with the current month and date. For example, 2022-10.

Use a single billing account to manage your billing and budgets

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

For most organizations, a single billing account for all projects is sufficient. Organization-wide discounts apply to all projects that are associated with the billing account. You can make a single payment to Google to settle the monthly invoice, and you can charge agency-specific, department-specific, or lab-specific projects using an internal IT chargeback process.

The following diagram shows how the single billing account works:

Single billing account.

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

Using multiple folders.

In this diagram, folders identify all the projects and assets that are associated with a cost center, department, or IT project. Cost is shown for each project, and project IDs are included in the billing export to BigQuery.

Consider multiple billing accounts if cost centers must pay a separate invoice or if your organization has workloads that must pay with a separate currency. This approach might require a signed agreement for each billing account or engagement with a Google Cloud reseller.

Assign billing account roles

Billing account roles help you manage billing accounts. You can assign the following billing roles to specific users at the organization level.

Role Description
Billing Account Administrator Manages all billing accounts in the organization.
Billing Account Creator Creates billing accounts in the organization.
Billing Account User Links projects with billing accounts.
Project Billing Manager Provides access to assign a project's billing account or disable project billing.
Billing Account Costs Manager Manages budgets and views and exports cost information for billing accounts (but cannot view or export pricing information).
Billing Account Viewer Views billing account cost information and transactions.

To let users view all the billing accounts in your organization, grant the Billing Account Administrator role at the organization level. To limit who can create billing accounts and how, use the Billing Account Creator role and restrict which users have this permission. For more information, see Create, modify, or close your billing account and Overview of billing access control.

To change the billing account for a project, see How to change the project's billing account.

Create budgets and alerts to monitor billing

To monitor your billing account and individual projects, you can create budgets and send email alerts to billing administrators and billing users.

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. In addition, because the budget doesn't update in real time, you might not discover the overspending issue for a day or two.

To send budget alerts to users who are not billing administrators or billing users, configure Cloud Monitoring notification channels.

Organize resources using labels

Labels are key-value pairs that help you organize your Google Cloud resources. Labels are forwarded to the billing system and are included in the billing export to BigQuery. Labels let you query your billed charges by label.

Adding labels to resources by department, college, workload, or lab can help associate billed charges to the right entity, without requiring you to create separate billing accounts for each new project. For more information on labels, see Creating and managing labels.

Monitor quotas and limits

Many resources within Google Cloud 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 monitor your quota usage in the Google Cloud console. Also, you can request a quota increase to access more resources or new resources, such as GPUs.

Manage your network

This section describes best practices for managing your Google Cloud network.

Choose a networking approach

Isolate your cloud services with VPC. For example, use VPC to set up a network, which includes a common and private RFC 1918 IP space that spans all your projects. You then add instances from any project to this network or its subnetworks. A default VPC network is created for each new project. This default network is suitable for testing or development, but you should replace it with a custom VPC network for production.

You can also attach a Cloud VPN connection to a single network, which can be used by all or a subset of the projects. Use the VPN connection to connect to a Google Cloud-specific RFC 1918 IP space or to extend the RFC 1918 IP address space of your on-premises network.

The following table describes two of the most common networking options in Google Cloud.

Networking option Description
Direct peering If you have a registered Autonomous System Number (ASN) and you have publicly routable IP prefixes, connect to Google using direct peering. This option uses the same interconnection model as the public internet. However, unlike the public internet, there is no service provider. For more information, see Google edge network.
Carrier Peering If you do not have public ASNs, or you want to connect to Google by using a service provider, use Carrier Peering. Carrier Peering is designed for customers who want enterprise-grade connectivity to the Google edge network.

It's often difficult to predict the cost that's associated with egress traffic. To help Internet2 Higher Education members, Google waives internet egress fees that are calculated at list prices up to a maximum of 15% of the total monthly consumption cost. This offer applies to specific Internet egress SKUs.

For more information about networking options, see Choosing a Network Connectivity product.

Get help

This section describes the best practices for getting help from Google.

Choose a support plan that meets your needs

Choose a support plan that meets the needs of your organization and document who has the appropriate permissions to create a support case.

Basic support is free and available to all Google Cloud users. Basic includes billing support but not technical support. To get technical support, you must purchase a technical support plan.

You can only purchase Google Cloud technical support plans at the organization level. The fee for technical support is charged at the project level to all projects in the organization.

For a detailed feature and cost comparison of support plans, see Cloud Customer Care.

At a minimum, we recommend that SLED organizations purchase the Standard Support plan. However, if your organization is running business critical workloads, consider purchasing an Enhanced Support plan. The Enhanced Support plan lets you access Customer Care 24/7, create cases using the Customer Support API, and escalate cases.

For your organization, you might want a Technical Account Manager to assist with guided onboarding, case management, case escalation, and monthly operational health reviews. If you want a Technical Account Manager but don't want a Premium Support plan, we recommend the Technical Account Advisor Service.

You can purchase Standard Support and Enhanced Support using the Google Cloud console. To purchase Premium Support, contact sales.

Create and escalate support cases

To create a case, you can use the Google Cloud console or the Cloud Support API (Enhanced or Premium Support required). When you create a case, keep in mind the appropriate support case priority.

If you have already set the appropriate case priority for your case and are encountering issues with the support process, you can escalate your case. For a list of possible reasons for escalating a case, see Escalate a case.

If you have Premium Support, you can also request an escalation by contacting your Technical Account Manager during local business hours.

What's next