Why would you want to use Terraform to implement access controls in your Google Cloud account?

• Speed. Terraform provides a level of automation. Being able to describe your access controls in a code based format allows you to programmatically interact with your Google Cloud account using API calls being made by Terraform to your Google cloud account. This can speed up development/implementation time.
• Integration. Being that we are using APIs on the backend, we can now integrate building certain access controls into new or existing pipelines.
• Version control. Because we are using Terraform .tf configuration files, we can upload our code to a source code repository. I can use git to keep track of all the changes and/or different versions of our code.
• Collaboration. Because we can store our code in a source code repository this enables our access controls to be shared across the team. Making use of pull requests allows your team to increase knowledge sharing.
• Consistency. Because we have our access controls defined in code we can enforce best practices using modules in Terraform. Modules allow you to reuse code in various configurations which further ensures consistency and speeds up development time.

IAM basics

Let’s briefly look at some basic components of IAM, which make up the foundation of any IAM strategy.

Roles

A role is a collection of individual permissions. Permissions can be looked at as “things I can do with a service”. For example with the Cloud Run Invoker role I can run.jobs.run and run.routes.invoke.

Predefined roles are roles that Google creates to allow you to do certain things based on responsibilities. Using predefined roles will help limit your blast radius, which will in turn help strengthen your access control strategy.

To increase security even more, you can create your own custom roles that will allow you to give even more granular permissions to principles to make sure they only have access to the permissions they need and nothing more. This is called the principle of least privilege and it is access control best practice.

Role Binding

Principals

A principal can be thought of as an entity that would need access to resources. You can give the principal access to resources through permissions which the principal can be assigned through a role binding.

A principal can be a Google Account, a service account, a Google group, or a Google Workspace account or Cloud Identity domain. Each principal has its own email address which can be used as an identifier when you need to assign permissions to that principal.

Hierarchical structure

• Provide a hierarchy of ownership
• Provide attach points and inheritance

What does this mean? It means that resources can be associated with a parent. For example, I can have a folder that represents the Devops team. Under that folder I can have a project that will then have resources attached to it. You can see from this progression that the project’s direct ancestor is the Devops folder (which represents the Devops department). The resources would then have a direct ancestor which would be the project. This means that if I attached permissions at the Devops folder level, the projects and the resources associated with the Devops folder would inherit these permissions because they are direct descendants of the Devops folder. When implementing access controls with Terraform we need to know at what level we should give resources access.

Organizational policies

Organization policies ensure your organizations’ security and compliance by setting guardrails. Organizational policies allow you to enforce constraints which specify what resource configurations are allowed within an organization. Let’s see how constraints work.

Building with Terraform

Now let’s take a look at how we could build a policy with code:

Service Accounts

A service account can be looked at as both a principal and a resource. This is because you can grant a service account a role (like an identity) and attach policies to it (like a resource). Your company should use service accounts if you have services in Google Cloud that need to talk to each other. This will allow you to authenticate and make API calls securely from service to service.

Use Case

Now we have the basics down, let’s take a look at a practical use case.

Wiring things up

Local development

After you have Terraform and gcloud installed, you will want to make sure that you have a service account that Terraform can use. Make sure that service account has all the proper permissions needed. Depending on what you want to build, some permissions will have to be given from the organizational level in order for them to be inherited at the project level (where service accounts are created). Next, let’s make sure you are using the proper authentication method. The best way to authenticate for local development is by using Application Default Credentials (ADC). With a simple setup, Terraform will be able to authenticate automatically using the credentials from your gcloud configuration.

Automated development

In the pipeline, Cloud Build will have permissions to the service account you create. This will allow Cloud Build to assume the permissions of that service account and in turn authenticate your Terraform configuration.

Pipeline

Now that we have the service account and all the proper tools in place, let’s build a pipeline. As you can see below, I am using a yaml file in order to automatically build a pipeline in Cloud Build. Each step in the pipeline is introduced through a Docker container. My pipeline does some standard things with Terraform.

• Terraform init
• Terraform fmt
• Terraform plan
• Terraform apply

Conclusion

Securing access in Google Cloud is a great first line of defense to make sure that your account is secure. Understanding IAM and its core features is the foundation on which you will build your access controls. Automating access controls can save your company time, money, and give your organization the agility it needs to make changes in a structured way when the need arises. You can create a free account at cloud.google.com. Don’t know where to get started with IAM? We’ve got you covered. Try this IAM tutorial to hit the ground running.