Policy design for startup customers

This article shows you how to design a set of policies that enable your company, a hypothetical startup customer named StartupExampleOrganization, to use Google Cloud.

Startups begin with minimal infrastructure: only network connectivity and laptops, with no investment in on-premises servers. Startup teams are small, autonomous, and run fast. They are trusted to make their own decisions on what services and tools to use. Startups are sensitive to the risk of their IP being inadvertently made public early.

Given this environment, you as the startup's administrator initially want to implement a light-touch set of rules that cover billing and violation of security controls.

The policies enable your company to use Google Cloud in a way that meets the following requirements:

  • Use Google Workspace to manage identities and provide office productivity tools.
  • Optimize for team autonomy and velocity.
  • Permit developers to choose their own tools, create their own resources and environments, experiment, and so on.
  • Use private repositories and registries.
  • Implement guard rails to protect security, compliance, and so on.
  • Alert for expenditures above a soft limit.
  • Assume good intention, but have some high-level controls and alert for any violation of nascent security controls.
  • Give developers access to a shared set of resources.
  • Design the Google Cloud environment to grow with minimal pain points.

Governance and visibility

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

Identity management

StartupExampleOrganization requirement addressed:

  • Use Google Workspace to manage identities and provide office productivity tools.

Identity and Access Management (IAM) enables you to grant access to Google Cloud resources by granting access to members. Members can be one of the following types:

  • Google Account
  • Service account
  • Google group
  • Google Workspace domain (If you have a Google Workspace account, this implies that a Google Workspace domain exists. For more information, see this help topic.)

A Google Workspace account has an intrinsic relationship with the Google Cloud resource hierarchy, as the following diagram shows:

resource hierarchy

To use Google Cloud, you aren't required to have an Organization resource; however, it's prudent for any company, no matter the size, to start setting up their Google Cloud resources under the Organization resource. As an organization admin, you have full visibility and control of your company's assets.

As an StartupExampleOrganization admin, you are already a Google Workspace customer, so the prerequisite to start using the Organization resource is already in place. You can grant permissions to Google Workspace accounts to access Google Cloud resources.

Organizational setup

StartupExampleOrganization requirements addressed:

  • Permit developers to choose their own tools, create their own resources and environments, experiment, and so on.
  • Give developers access to a shared set of resources.
  • Design the Google Cloud environment to grow with minimal pain points.

With an organization resource in place, you can map your organization to the resource hierarchy. As part of this hierarchical organization, you can use Cloud Folders as containers for projects and other folders. Cloud Folders allow users to group projects under folders, enabling management at scale of resources and policies. This structure parallels the teams and the apps (mapped to projects) they work on grouped under them. The following diagram shows an overview.

organizational setup

Using Cloud Folders enables you to administer access management policies at the folder level. All projects under a particular folder inherit that folder's policy.

StartupExampleOrganization wants their developers to be able to do their jobs quickly. They also want you to implement a framework that allows them to grow and satisfy basic security and compliance requirements that their business needs—for example, protecting personally identifiable information (PII). By using the organization resource, you can ensure that they have central oversight yet allow each team to own their folders and projects. For example, each team can decide independently how to deploy apps and how to implement monitoring.

To share resources across projects, create a Shared resource project that is also a service project to a Shared Virtual Private Cloud (VPC) host project. For more information, see Network configuration and security controls.

You can use the resource project to host service accounts that are used in automation processes such as a continuous integration and deployment pipelines (CI/CD). Shared assets, such as configuration scripts, and shared datasets can also be located in this project. You can then restrict who can manage the resource project.

You can implement guard rails through organizational policies, where you forbid configuration options that don't comply with the company's standard. For example, you can prevent external IPs from using any virtual machine (VM), no matter who created it. You can override per project as necessary. By implementing service accounts whose permissions are granted at the organizational level of the hierarchy, you can run jobs from a dedicated project to monitor or alert on risks or aggregate inventory and metrics.

System operations

StartupExampleOrganization requirements addressed:

  • Optimize for team autonomy and velocity.
  • Permit developers to choose their own tools, create their own resources and environments, experiment, and so on.
  • Use private repositories and registries.
  • Give developers access to a shared set of resources.

The founders of StartupExampleOrganization know they need to protect their IP. Implementing private repositories and container registries can help. Google Cloud provides fully hosted private Git repositories where you can restrict access through IAM. Container Registry is a private registry using Cloud Storage for your Docker images. You can use Container Registry and grant appropriate permissions to ensure that your containers are restricted to members of your organization.

Service accounts help facilitate automation processes. Automation is always important, but especially so when agility is key. The more you automate, the more resources you can focus on app development.

Adopting the concept of infrastructure as code to automate cloud environments lets you set up your projects and associated controls programmatically and repeatedly. In addition, you can version-control the scripts and templates you use so that you treat configuring your Google Cloud environment as you do code, with all the benefits that version control provides.

Using Cloud Deployment Manager, you can automatically create projects with the appropriate resources and IAM policies. You can use the templates as part of a self-service system.

As your organization grows, these repeatable processes allow new teams to ramp up quickly and produce quickly.

Organizational security controls

StartupExampleOrganization requirement addressed:

  • Implement guard rails to protect security, compliance, and so on.
  • Assume good intention, but have some high-level controls and alert for any violation of the nascent security controls.

The Organization Policy service provides central, programmatic control over StartupExampleOrganization'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:

  • Centralized control to configure restrictions on how your organization’s resources can be used.
  • Policies can be set 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. This means that individual users and project owners cannot override organizational policies.

Resource control

You can implement organization policies to enforce what resources are available in a Google Cloud trust boundary (folder, project, or other organizational level).

  • IAM enables you to manage access control by defining who (identity) has what access (role) to which resource. You can grant roles to users by creating an IAM policy, which is a collection of statements defining who has what type of access. You attach a policy to a resource, so whenever that resource is accessed, the policy enforces access control.
  • Resource Manager provides attach points and inheritance for access control and organization policies. Using the Resource Manager API enables you to interact with the organization, folders, and projects.
  • In all cases, think carefully about what access controls to put in place, who must be granted access, and where to apply least privileges.

Initially, set up a framework that allows the tightening of controls as they grow. Set up restricted permissions to the shared resource project, and limit access to the organizational admin role, network role, and security role.

Functional roles

You need to map StartupExampleOrganization's functional roles to appropriate IAM roles.

By using groups to manage your users, you can modify who can carry out a function. Instead of updating the policy, you can edit group membership. You can name the groups to reflect the functional roles using StartupExampleOrganization's terminology. As the organization grows, you can reduce members of that group as you build a dedicated team of network and security administrators.

The following example of an IAM policy can help StartupExampleOrganization meet their requirements:

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

Roles to grant: Network Admin, Shared VPC, Security Admin

Members to be bound: Security & Network admin team
A central team manages both networking and security controls. All projects share a single VPC network.

The Network Admin role together with the Shared VPC Admin role allows central administration of network resources.

The Security Admin role provides the permissions needed to manage firewall rules and SSL certificates.

Naming conventions and labeling

OurStartupOrg requirements addressed:

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

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

Tracking and understanding spending

StartupExampleOrganization requirements addressed:

  • Alert for expenditures above a soft limit.

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

  • Projects to organize resources. Cost is shown per project. Project IDs are included in the billing export.
  • Annotation of projects with labels that represent additional grouping information—for example, environment=test. Labels are included in the billing export to allow you to break down costs into more detail. Although labels are subject to change, they can still be useful.
  • Encoding a cost center into Project Name or ID to make it easier to track costs back to the cost center.
  • Cloud Billing Reports to view usage costs at a glance and analyze trends.
  • Export 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

StartupExampleOrganization has a single person responsible for paying bills. With this policy in place, your developers can use your billing account but cannot set up additional billing accounts. Using Billing IAM roles enables the developers to set up the appropriate permissions for this scenario.

Billing exports provide a way to analyze costs and at first, might not be a high-priority requirement for StartupExampleOrganization. Future growth might require cost analysis, however, so implementing some basic configuration rules now, makes it easier to implement later.

To alert on billing metrics, you can set budgets and alerts at the billing account or for individual projects. You can set budgets at a specific amount or match them to the previous month's spending. You can also create alerts to notify billing administrators when spending exceeds a percentage of your budget. For startup customers, budgets are soft, so exceeding the budget doesn't affect usage.

You can apply a budget to each project. This per-project budget gives you the flexibility to allocate more funds to some projects as required, and you can set alerts against each project. For example, a project using BigQuery might need a higher budget than projects that are just using instances.

Organizational and identity management policy proposal

The following diagram shows the proposed StartupExampleOrganization organizational policies.

organizational policy

In the preceding diagram, there are six key characteristics:

  1. Organization policy to set "guard rails."

  2. Service accounts running organization-wide collecting and monitoring.

  3. Folder for departments with resources.

  4. Projects for teams, apps, environments, and test cases.

  5. Use IAM for identity management.

  6. Shared infrastructure resources managed by central. admin teams and shared with other departments with minimal privilege.

Network configuration and security controls

StartupExampleOrganization requirements addressed:

  • Give developers access to a shared set of resources.

  • Design the Google Cloud environment to grow with minimal pain points.

At first, StartupExampleOrganization doesn't have a permanent office. When they do find an office location, if their workloads require lower latency than they can get by routing over the internet, they might use Cloud Interconnect to connect to Google Cloud.

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 administer the central network.

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

By implementing Shared VPC, you can centrally manage the VPC network, but keep things simple by setting up a VPN from the StartupExampleOrganization offices to the Shared VPC host. The VPN provides easy access to service projects on the Shared VPC host.

Setting up a flexible framework from the outset enables you to share network resources and administer the central network as the company grows.

IAM network roles

Functionality Description of IAM policies required
A restricted number of users manages 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 Shared VPC enables you to map centralized teams to manage network configuration.
  • Assign the Network Admin role together with the Shared VPC Admin (XPNAdmin) 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 represents a networking model that meets StartupExampleOrganization's requirements.

Networking model that gives developers access to a shared set of resources.

In the preceding diagram, there are two key characteristics:

  1. Central admins and service accounts making all templatized resource changes.

  2. Shared resources in a separate subnet.

Firewall rules

Firewall rules manage traffic between source and target subnets and/or instances that are tagged or using specific service accounts. These rules provide the controls needed to ensure sufficient gates are in place between the development, testing, and production environments.

References

Requirement References
Identity management
Organizational setup
Systems operations
Billing
Networking and security controls

What's next