Policy design for education and training customers

This article shows you how to design a set of policies that enable your company, a hypothetical training organization named TrainingExampleOrganization, to use Google Cloud.

Education and training organizations present a specific use case because the training provider typically:

  • Owns all the resources and billing.
  • Pays for the infrastructure usage for the course or lab.
  • Ensures isolation between users and between users and the training provider.
  • Ensures that the provisioning process for each session is fully automated and fast.

TrainingExampleOrganization is a training organization that provides a set of online courses that students can subscribe to. The lab exercises for each module in a course use cloud resources that can be spun up as needed. How long the course environment is available depends on the lab or exercises required. TrainingExampleOrganization needs to manage costs and suspend usage of courses and their lab modules as required.

The policies described in this article enable TrainingExampleOrganization to use Google Cloud and meet the following requirements:

  • Retain ownership of cloud resources.
  • Create and manage temporary accounts and sessions.
  • Implement isolation between students.
  • Scale to many with automated provisioning.
  • Manage billing and policies through a central team.
  • Monitor and send alerts on activity occurring in labs and student environments.
  • Restrict what resources can be used.
  • Protect against abuse.

Governance and visibility

The following sections walk through various Google Cloud approaches TrainingExampleOrganization can use to meet the list of requirements.

Identity management

TrainingExampleOrganization requirement addressed:

  • Create and manage temporary accounts and sessions.

You can configure Cloud Identity, so that you can store user accounts. You can also use the Directory API to automatically create, enable, and disable users as required. You use this API to create accounts that won't be granted access to any other applications. The classroom or lab owner is responsible for provisioning students.

Organizational setup

TrainingExampleOrganization requirement addressed:

  • Retain ownership of cloud resources.

When you implement Google Directory, it implies a G Suite domain exists. An intrinsic relationship exists between a G Suite account and the Google Cloud resource hierarchy. With an Organization resource in place, you get centralized visibility and control over all the Google Cloud resources that are used as part of providing the training environments. You can use Cloud Folders as containers for projects and other folders. Cloud Folders let users group projects under folders, enabling management at scale of resources and policies.

The following diagram shows an overview of this structure.

Architecture of TrainingExampleOrganization that retains ownership of cloud resources.

This structure parallels a lab, where each project within a lab (folder) maps to an environment for each student. You can also use the folders to identify all the projects and assets associated with a particular lab or classroom.

System operations

TrainingExampleOrganization requirements addressed:

  • Scale to many with automated provisioning.

You can provision users automatically by using the Directory API. And you can use Cloud Deployment Manager to automatically create and configure projects with the appropriate resources and Identity and Access Management policies.

Organizational security controls

TrainingExampleOrganization requirements addressed:

  • Implement isolation between students.
  • Monitor and send alerts on activity occurring in labs and student environments.
  • Restrict what resources can be used.
  • Protect against abuse.

Treating projects as the trust boundary, you can, by adopting a least privilege approach, assign only the permissions the student needs to participate in the lab classroom.

If you assign common permissions at the folder level, the projects created for each student will inherit those permissions. You can then assign student level permissions at a project level.

The Organization Policy service provides central, programmatic control over TrainingExampleOrganization's cloud resources. The service provides a simple mechanism for enforcing allowed configurations across your Cloud Resource hierarchy. In this context, policies refer to Organization policies, which allow you to control the organization-level configuration of cloud resources.

Organization policies provide the following benefits:

  • You can set policies per project, per folder, or per organization.
  • Policies are inherited down the resource hierarchy, and the policy administrator can override them at any level on which an organizational policy can be set.
  • The organization policy administrator, not the resource owner, manages policies. Individual users and project owners can't override organizational policies.

Using organization policies, you can restrict what API calls can be made for all projects under the organization resource. You can restrict each project to make calls to APIs required for the classroom or lab environment.

The following example IAM policy can help TrainingExampleOrganization meet their requirements:

Description of IAM policy Functionality
The resource level at which to grant the policy: Organization

Role to grant: Billing User

Member to be bound: The Service account that is used for automating project and object creation.
The Billing User role gives the service account the permissions to:
  • Create a project.
  • Enable billing (associate projects with the organization's billing account for all projects in the organization) and APIs.
  • Create resources under the project.

To protect resources from being abused, you can set per-project quota limits to restrict the number of resources that can be started in a project.

You can use Cloud Audit Logs to look at recent audit logs. Logging records Admin Activity logs and Data Access logs generated by Google Cloud services to help you determine who did what, where, and when in your Google Cloud projects.

You can retain individual audit log entries for a specified length of time in Cloud Logging, which offers a dashboard view of recent project activity. The Cloud Logging quota policy explains how long log entries are retained, although you can't otherwise delete or modify the audit logs or their entries. For longer retention, you can export audit log entries to a Cloud Storage bucket, a BigQuery dataset, a Pub/Sub topic, or any combination of the three.

Using logs-based metrics, you can monitor and trigger alerting policies so TrainingExampleOrganization is notified in a timely manner of any potential abuse.

You can use Firewall Rules Logging to audit, verify, and analyze the effects of your firewall rules. For example, you can determine whether a firewall rule designed to deny traffic is functioning as intended.

Naming conventions and labeling

TrainingExampleOrganization requirements addressed:

  • Distribute cross-charging across teams and the products they develop.
  • Monitor activity occurring in OurTrainingOrg's GCP account

Labels are key-value pairs that are supported by a number of Google Cloud resources TrainingExampleOrganization can use labels to track spending in exported billing data across teams and the products they develop. By using labels to filter and group, TrainingExampleOrganization can then use Cloud Monitoring resource groups to monitor activity per team or per application

Tracking and understanding spending

TrainingExampleOrganization requirements addressed:

  • Protect against abuse.
  • Manage billing and policies through a central team.

A single billing account implemented in conjunction with Resource Manager and billing features can meet TrainingExampleOrganization's requirements. The billing features include:

  • Annotation of projects with labels that represent additional grouping information—for example, environment=Lab1. Labels are included in billing exports to allow TrainingExampleOrganization to break down costs into more detail. Although labels are subject to change, they can still be useful.
  • Encoding the Class ID into the Project Name or ID.
  • Cloud Billing Reports to view usage costs at a glance and analyze trends.
  • Exporting billing data directly to BigQuery to enable detailed analytics.

The following diagram illustrates a single billing account implemented in conjunction with Resource Manager.

billing structure

To centrally manage billing, you must grant the billing admin role to the billing account and bind this IAM role to whomever manages billing.

Because projects are created automatically, create a shared resources project. In this project, create a service account that you grant the Billing User role to. Then use this service account to create the projects needed for each lab environment.

By setting up per-project billing alerts, you can be alerted when a project is hitting a limit that is unexpected for the lab. This monitoring offers another way to help prevent abuse.

Organizational and identity management policy proposal

The following diagram shows the proposed TrainingExampleOrganization organizational policies.

Organizational policies for TrainingExampleOrganization.

In the preceding diagram, there are four key characteristics:

  1. Organization policy to restrict which APIs can be enabled to ensure that only resources required by each lab can be used in a project.

  2. Shared resources project contains service account used to provision a new project for every student/lab session.

  3. Per-project quota prevents students from spinning up a large amount of resources and guards against abuse.

  4. Domain admins are the only admins who can create, disable, or delete users and have ultimate control of student access and guard against abuse.

Network configuration and security controls

TrainingExampleOrganization requirement addressed:

  • Implement isolation between students.

In a pre-provisioned lab environment, students don't typically make network changes. So centrally administering networks and security is the preferred approach, which you can do project by project or preferably by implementing a shared VPC model.

Shared VPC

Shared VPC enables you to manage common network resources, such as VPC networks and subnets, from a central host project. Other projects can also access these resources. This setup and its IAM controls make it easier to implement and administer the central network.

Shared VPC also enables you to have a VPC network, such as a common private RFC 1918 IP space, spanning multiple projects. You can add instances from any project to this VPC network or its subnets.

You can attach a VPN to that single VPC network, which can be used by all or a subset of the projects.

Shared VPC offers the following features:

  • Allows for a set of centralized network admins separate from your project admins.

  • Enables you to designate a group of admins to manage the shared VPC using IAM controls.

  • Makes it easy for you to create separate sets of admins. The admins for each Google Cloud project can create and use instances on the VPC network.

  • Allows for the network admin to be part of a centralized team, while users across different departments in the organization can share the VPC network or subnet.

  • Provides a way to centrally manage networking resources—for example, IP addresses, subnets, and so on.

  • Enables you to apply consistent policies and enforce them across the organization.

  • The network admin can define a set of common firewall rules, gateways, security policies, and NAT, once and apply them to all subnets. These policies don't need to be defined and maintained N times for each project.

The projects spun up as part of the lab use the centralized VPC network and can use only that VPC network—for example, launching an instance in that VPC network.

IAM network roles

Functionality Description of IAM policies required
A restricted number of users manage both networking and security controls. All projects share a single VPC network.
  • Following best practices, set up a group that contains the identities of the users who centrally manage networking and security. Use this group in the IAM policies needed to meet this requirement.
  • Using a Shared VPC enables you to map centralized teams to manage network configuration.
  • Assign the Network Admin role together with the Shared VPC Admin role to the group at the organization level of the cloud resource hierarchy. In addition, granting the Security Admin role at the organization level to this admin group provides the permissions needed to manage firewall rules and SSL certificates.

The following diagram shows the simplest model that meets TrainingExampleOrganization's central control requirements.

Architecture that meets TrainingExampleOrganization's central control requirements.

In the preceding diagram, there are four key characteristics:

  1. Central admins and service accounts making all templatized resource changes at the organization level.

  2. Central admin of network and security controls in a shared VPC host project.

  3. A single lab admin in a subnet can administer all labs.

  4. Shared resources are in a separate subnet.

Firewall rules

Firewall rules manage traffic between source and target subnets and/or instances that are tagged or using service accounts. These rules provides the controls needed to ensure sufficient gates are in place between the student environments.

References

Requirement References
Identity management
Organizational setup
Billing
Networking and security controls

What's next