[Terragrunt GitOps - Part 4] Onboarding a customer

Introduction

In this article, we'll deal with onboarding customers to our solution. Onboarding here is semi-automated.

Manual actions:

customer creating Service Accounts for SP (Service Provider)
granting appropriate roles to the Service accounts

GitOps actions:

creating sets of Cloud Build triggers

The sequence of actions will be:

First, we'll add the appropriate code to the terragrunt-example-envs repository and push it to Github. That will create sets of CB triggers.
Then we'll simulate customer-side actions and create relevant SAs and IAM bindings.
Finally, we'll grant those SAs appropriate roles in SP projects, so they can be impersonated by "Cloud Build-attached SA".

Add code to the terragrunt-example-envs repository

As mentioned above, we start with terragrunt-example-envs repository. In the first article of the series, I explained its structure and mentioned the onboard directory.

Before you have any customers, it's of course empty. You have to fill in the appropriate values in onabord.hcl file, and then create a directory per customer and, inside that directory, another directory (per environment). Create a test branch (not named main ) and push to terragrunt-example-envs to run terragrunt run-all plan .

The contents of the branch will be akin to this commit's code.

Note. You have to already have a file called customer.hcl inside your customer folder.

The result should be a successful plan job:

Then you can open a Pull Request in Github to the main branch and merge it. It will trigger an apply job:

You can examine the customer 1-dedicated project to confirm that the triggers have been created:

If done correctly, all the setup relevant to Customer 1 should be there, for example:

Customer-side set-up

Let's now tackle customer-side set-up: stuff that the customer has to do for us, and then the IAM bindings we do once the Service Accounts exist.

Each customer has to create a Service Account so that we (== Service Provider) can impersonate it.

For the purposes of this article, I'll create (while wearing a nice cap with a "customer 1" inscription on the cap I'm wearing) a service account:

gcloud iam service-accounts create customer1-solution-sa --display-name "Solution SA" --project prj-customer1-outside-org

The customer now has to grant the SP SA Admin role. In this case, I'm the only one in my "SP team", in real life that would be a Cloud Identity group most probably:

gcloud iam service-accounts add-iam-policy-binding customer1-solution-sa@prj-customer1-outside-org.iam.gserviceaccount.com --member="user:piotr@techdive.click" --role="roles/iam.serviceAccountAdmin" --project prj-customer1-outside-org

OK, but those SAs still can't do anything in the customer perimeter. Since in this article, the resources we deploy are GCS buckets (meh), let's grant this SA appropriate roles:

gcloud projects add-iam-policy-binding prj-customer1-outside-org --member="serviceAccount:customer1-solution-sa@prj-customer1-outside-org.iam.gserviceaccount.com" --role="roles/storage.admin"

IAM bindings in customer-dedicated projects

Since we'll impersonate customers' SAs in our Terragrunt jobs, those accounts will need permission to create buckets in the customer-dedicated projects. Why buckets? Because those buckets will store the Terraform state file of the modules invoked.

(Too many buckets, buckets everywhere, maybe I should have chosen something else for the "solution"...)

gcloud projects add-iam-policy-binding prj-customer1-dedicated --member="serviceAccount:customer1-solution-sa@prj-customer1-outside-org.iam.gserviceaccount.com" --role="roles/storage.admin"

And, finally, we need to grant the SA attached to the customer-dedicated CB triggers the ability to impersonate them (remember, in one of the previous steps we granted SP members the SA Admin role, necessary to execute the commands below).

gcloud iam service-accounts add-iam-policy-binding customer1-solution-sa@prj-customer1-outside-org.iam.gserviceaccount.com --member="serviceAccount:customer-1-cb-exec-check@prj-customer1-dedicated.iam.gserviceaccount.com" --role="roles/iam.serviceAccountTokenCreator" --project prj-customer1-outside-org

Note. Here we grant a role to the check account: customer-1-cb-exec-check@prj-customer1-dedicated.iam.gserviceaccount.com . As you may remember from the first article, check environment means "don't deploy on customer's perimeter". Consequently, the Token Creator role for this SA is not needed. I'm including it for demonstration purposes because I want to show the onboarding phase in full. It will become necessary for dev, prod etc environments.

Conclusion

In this article, I went through all of the steps necessary to "onboard" a customer to the solution, i.e. create all the resources needed to start operations and the management of the infrastructure.