Projects in GCP – 3 tier applications on Google Cloud

Also visit GoogleCloudArchitect.us for in-depth GCP posts. Also Read – A Reusable Hub Spoke Network Design on GCP   and Service Projects – VPCs or not

As a Google Cloud Architect, your understanding of GCP Projects and Service Accounts to access resources within that project, is key to gaining operational competency.

This post discusses how GCP projects can serve as an IAM boundary, a billing boundary as well as an application boundary (app tier boundary). There is nothing analogous on either AWS or Azure.

The Project Boundary is PRIMARILY an IAM Boundary

Say your infrastructure consists of a large number of cloud resources, that need to be shared in specific ways across your organization.

• Development teams only need development network resources (VPN tunnels for example) whereas
• Production teams don’t care about your VPN. They have their own direct connect that they use to get onto their jump boxes to get to their production hosted assets.

How do you isolate these networking resources between different IAM groups (prod users and dev users)?

In both AWS and Azure, you would start isolating these at the network level — i.e. you may define a development VPC (or a dev-VNET in Azure) for development resources and a production VPC (for production resources).

In other words, you have to lean on the cloud network itself to provide you with the isolation levels of the resources you need.

There should be an easier way to target certain IAM groups for certain resources and others for other resources.

Enter the GCP Project

Now, enter GCP and the Project Level Construct. The same problem can be solved using the trust boundary provided by Projects.

In GCP, you would solve this problem by having two separate projects (a DEV project, a PROD project etc.). Each project comes with it’s own Default VPC (and you can add as many custom VPCs as you like).

Projects are holders of resources, akin to Accounts in AWS.

   While AWS accounts are certainly more than simple resource containers, this is still the best way to visualize the correspondence between AWS accounts and GCP projects. They are also both the highest level ‘billing containers’.

Projects are both ‘billing containers’ and also trust boundaries for resources

Projects are both, Billing boundaries (every resource in a project is billed to the same ‘project’) as well as a ‘resource trust’ policy.

The trust boundary within a GCP Project is implicit — resources within a project automatically have access to each other. And they are denied access to resources in other projects.

Hence, a storage bucket and a compute instance, within the same project, don’t need any special ‘cross project access role’ (see section below).  At the same time, it is important to understand that project boundaries are largely ‘invisible’

The Project Boundary is ‘Mostly Invisible’

If you have TWO VPCs within the same project, and you need access to some resource in VPC 1  from VPC 2, you STILL have to peer the two VPCs.  It may seem that because they two VPCs are in the same project, that you do not have to do this. This is what I mean by a ‘mostly invisible’ boundary  – as far as resource access is concerned, the boundary is invisible. A project serves only as an IAM boundary and a convenient BILLING bounday.

This concept bears a bit of repetition. If you have two resources in the SAME project, you still have to grant access to the appropriate service account to access resource B from resource A.

How many projects? One or multiple- GCP Projects as Application Tier Boundaries

Since the project boundary is mainly invisible (and only provides advantages), GCP’s recommendation is to have as MANY projects — with each project containing only a limited number of resources.

Take the example of a built in service account that is used to access compute engine resources. This SA (service account)  actually has Project Editor (which means, it can do just about everything to EVERY resource in the project, except DELETE the project itself).

This is not the ‘least privilege’ approach.

Hence, what you need it to split up your SINGLE large project, into smaller projects. That way, access control is simplified.

Another example is that of splitting up your app into tiered project. A three tier app would exist on GCP as three projects – a middle tier project, a web tier project and a data tier project.

A natural question then arises — Now that we have multiple projects holding resources belonging to a SINGLE app, how do we access resources ACROSS projects?

Cross project access to resources?

  First of all, you should ALMOST NEVER need to cross a project boundary. A project should contain all the resources it needs. Should you need a resource from another project, there is a specific construct in GCP (called a Shared Project), that enables you to do just that.

Still, if the need arises (say you have a centralized logging bucket in a separate ‘logging project’), you can access that resource from another project.

If you think AWS accounts, how does a resource in Account A, access a resource in Account B? The answer is cross account roles.

In a similar vein, in GCP as well, a role is needed to provide cross project access. A service account in project A is granted access (access being a compute viewer) to a compute resource in project B, by assigning the appropriate role (see gcloud example below).

gcloud projects add-iam-policy-binding $GCP_PROJECT_ID_B \
--member=serviceAccount:${GCP_PROJECT_ID_A}@myaccount.gserviceaccount.com \
--role=roles/compute.viewer \ 

I thought a ‘VPC’ was the container of resources? Where does a VPC fit into this picture?

A VPC, in GCP does contain resources, same as in AWS. However, to enable multiple projects to share resources, there is a construct called a Shared VPC. 

In this construct, a single project serves as a ‘host project’ and other projects (service projects) can access resources within the host project (i.e. inside the project’s VPC).

However, not all GCP resources can be shared via the shared VPC construct.

Mainly network resources and redis memory store can be shared. For a full list, see the appendix below.

The primary purpose of the Shared VPC is to provide sharing as well as easier network administration for common network elements (e.g. NAT instances, Firewall Rules, Routes)

What do you do if you need to share a non networking resource? Like a secrets manager secret or a KMS key?

You are back to the first option above — cross project IAM roles.

Another way you can share resources across VPCs is to use VPC Peering. More on that in a separate post.

Granting and Denying Access to Project Resources

Granting access to A project resource is the same as what you would do to grant access to the resource from another project. Essentially, the SERVICE ACCOUNT that operates that resource (e.g. Compute Engine Service Account) needs access to the project resource.

This is true whether both the resources involved are in the SAME project or DIFFERENT projects.

For RESTRICTING access to specific resources within a project, you would typically do a TWO STEP configuration:

1. The first is the GRANT at the IAM level (grant viewer access to the user, for example)
2. GRANT / DENY at the resource level (this resource is ALLOWED to be accessed by this user, all other resources are IMPLICITLY denied).

Granular access is at the heart of the principle of least privilege, and this post shows how to use the Google Cloud Project Boundary to accomplish granular access. With a firm understanding of GCP Projects, and the other reoccurring theme GCP Service Accounts (upcoming post), you can get rolling on GCP development.

Summary

A GCP project is like an AWS account, in that it is the holder of resources as well as a top level billable entity. It is primarily an IAM  boundary and not anything more. For purposes of granting or denying access to resources , the project boundary is somewhat invisible. You still need to grant service accounts access to the individual resource, regardless of project boundaries.

Understanding projects in GCP, alongside understanding service accounts in GCP, are the two crucial components to becoming a hands-on GCP architect.

Set up a 1 on 1 appointment with Anuj to assist with your cloud journey.