Over the past few weeks I’ve been working with the team to set up the Mantel Group GCP account.  I’ve used GCP at previous employers and for my own personal projects in the past, however I’ve never set up a new account for an organisation before.  There’s surprisingly little information out there on how others have set up their own organisations, so I decided to share our learnings.  This post provides some details of our setup in the hope that it’s useful to others.

Below were some of our requirements and objectives:

  • Support multiple organisation units – We have two companies within the Mantel Group being DigIO and Eliiza.  We want to be able to cleanly separate resources belonging to each unit.
  • Support development/experimentation and production – We expect to run different types of workloads that will have widely varying requirements around information sharing and security.
  • Maximise transparency – We want to provide as much visibility into the setup and configuration of the organisation as possible.  We can’t give everybody write access to everything, but read-only access by default allows people to discover what is there, improve information sharing, reduce the need for redundant documentation, and well … promotes good behaviour by everyone involved.
  • Maximise empowerment and minimise bottlenecks – The last thing we want to create is a highly centralised structure that requires all work to run through a central group of people.  We want to encourage people to experiment, learn, and create.
  • Clear ownership – The last thing we want to create is a tragedy of the commons where a mess is created and nobody cleans up after themselves.  Every resource should have a clear owner who is accountable for its long-term care and maintenance.

The following sections describe the configuration and security policies we applied.

Authentication

Authentication for GCP leverages our existing G Suite integration which is currently integrated with Okta for single sign on.  This is a well trodden path.

Organisation Level Permissions

As an existing G Suite user with the Super Admin role, I was able to create our GCP organisation, and this resulted in me initially being the only person with the GCP Organisation → Administrator role.  This role doesn’t allow you to directly create or manage resources in GCP, instead it allows you to assign roles to users (including yourself) and/or groups.  As such, users with this role define the security policies of the organisation.  The only change made here was to add this role to another colleague to avoid me being a bottleneck or single point of failure.

By default, GCP provides everybody in the organisation with Project → Creator and Billing → Billing Account Creator privileges.  These have been removed to prevent people accidentally creating projects at the root level.  Alternatives are provisioned further down in the folder/project hierarchy.

I have added the following roles to myself and my fellow admin:

  • Billing → Billing Account Administrator – This allows us to see and manage all billing accounts.  Responsibility for this role may be separated over time.
  • Resource Manager → Folder Admin – This allows us to create the top-level folder structures for the organisation.  Over time we may add this role at lower levels of the folder hierarchy (e.g. see Sandbox Permissions below) to allow others to self-manage their own structures.

The following roles have been added for everybody in the organisation:

  • Project → Browser – By default, GCP doesn’t allow folder or projects to be browsed which goes against our desire for transparency and allowing people to see how our organisation is structured.  This role allows people to browse the organisation, folders and projects.  This will allow people to request access to projects from their owners if required, but won’t let them access (read or write) any project resources.
  • IAM → Security Reviewer – By default, project owners (or browsers) cannot inherited IAM permissions on a project, only those set on the project itself.  This role allows people to see the full set of permissions on a project including those inherited from parent folders or the organisation.

Folder Structures

Folders and projects are a significant point of difference for GCP, so we had to spend some time understanding how to best use them.  Projects are containers for all cloud resources (e.g. buckets, VMs) provisioned in GCP.  Projects can be grouped into folder structures, and permissions can be applied at any level in the hierarchy and inherited by sub-folders and projects further down the hierarchy.  It’s flexible and powerful allowing some aspects of security such as authentication to be handled centrally, but others such as per-project access control to be delegated to organisational units.  After dealing with large numbers of AWS accounts in the past, and having to duplicate all aspects of security across these accounts this is pleasant to use.  Perhaps the new AWS Organizations provide similar benefits.

We defined the following folder structure.  We expect this to grow and be extended over time, but we hope it provides a good starting point that will allow us to scale our activities effectively.

  • mantelgroup.com.au – Root organisation.
    • DigIO – Folder containing all DigIO folders and projects.
      • Sandbox – Folder containing experimental projects.  See “Sandbox Permissions” below for details of permissions.
      • Production – Folder containing production projects.  See “Production Permissions” below for details of permissions.
    • Eliiza – Folder containing all Eliiza folders and projects.
      • As per DigIO above …

Sandbox Permissions

Sandbox folders are setup for each org unit, and provide a space where anybody can experiment with GCP itself or GCP hosted technology.  The following roles have been granted to everybody:

  • Project → Viewer – Allows people to see but not modify the resources (e.g. buckets and VMs) within a project.  This is useful for sandbox projects where information sharing should be preferable to information hiding.  People don’t have to be added to projects in order to view their contents.
  • Resource Manager → Project Creator – Allows people to create their own projects.  After creation, the creating person will automatically become an owner of the project.  The project browser role declared at the org level allows anybody to discover the owner of the project if they want to join it.

Production Permissions

We haven’t currently defined any permissions on the Production folders.  Permissions vary per production project, so permissions can be defined at the project level.  Unlike sandbox projects where we can get away with read-only access for everybody and allow owners to self-manage their projects we need to create more specific policies.  Over time we will potentially leverage G Suite groups to control access.

Billing Accounts

Billing accounts exist within the organisation, but aren’t nested in the same folder structures as projects.  Multiple projects may be assigned to a single billing account.  Conversely, a project may be assigned to zero or one billing accounts.

We expect our approach to billing to evolve over time.  For now we have used the following approach:

  • We have created a DigIO Sandbox Billing account for all DigIO sandbox projects, and an Eliiza Sandbox Billing account for all Eliiza sandbox projects.
  • We will manage production billing accounts on a case by case basis.
  • I and a colleague manage all billing accounts via our organisation-wide Billing → Billing Account Administrator role.
  • If anybody wishes to create a new project, we either configure their project billing for them, or have a brief discussion about billing responsibilities and grant them the Billing → Billing Account User role on an individual billing account so that they can manage it themselves.

While it’s possible to add billing notifications, I’d like to see GCP introduce better support for quotas.  Hard limits aren’t desirable for production workloads, but for sandbox environments we’d like to avoid costly mistakes without having to constantly monitor consumption.

Closing Thoughts

I’m pleasantly surprised by the GCP security model.  It’s allowed us to setup a structure that achieves our goals with very few compromises.  With AWS in particular we’ve struggled to define the right granularity for accounts, but it feels like this struggle falls away with GCP’s organisation/folder/project model and independent billing accounts.

We still have some work to do to figure out the right approach to billing, but we’ll continue to experiment in that space.  I’ve used BigQuery billing exports in the past, so knowing we have that in our back pocket to deal with more complex scenarios is comforting.

Only time will tell whether our configuration provides a good foundation to build on, or if it requires rework.  If we encounter any major issues or make any significant improvements we’ll continue to share them.

I’ve mentioned many GCP roles in this post. For more details of GCP roles, refer to Google’s understanding roles documentation.

I hope you found this useful.