Setting Up Your GCP Foundations Through Terraform — Chapter 2 — Access to GCP, Setting Up Billing & Preparing Github
Preamble:
In this chapter, we will continue preparing the ground for access to GCP and building out our Github repo for both our infrastructure and application code. Unfortunately for me, the guy who decided to name the series “Setting up your GCP foundations through Terraform”, the first 4 steps of setting up your GCP foundations are easier done through the Admin Console & GCP Console GUI.
In the next chapter, we will start working with the GCP Terraform modules to build out the first critical piece — our bootstrap project, this is the link to the first module we will use.
If you have time, I would also highly recommend reading the book Terraform Up & Running by Yevgeniy Brikman — this is a great way to build your foundational Terraform knowledge for the work ahead.
If you haven’t used GitHub before I would recommend reading up on it or going through training on Youtube, ACloudGuru, and other learning platforms you might have access to.
Let’s get to work:
Users:
To keep things simple, I’m just going to start by showing how to add one user:
- Login to admin.google.com with your super user account
- Under the Users section click “Add a user”
3. Fill in the “First name”, “Last name” and “Primary email” -> click “Add new user”
4. Click “PREVIEW AND SEND” — to send the new user their login credentials.
5. Click “DONE”
I recommend creating two separate users, one for org-admin and a second for everything else the user will be doing in the environment. Following the same principle as the super admin role in cloud identity, we want to limit, monitor and audit the use of org admin roles and permissions, hence the separation.
For smaller companies of 1–10 team members, or if we want to set up a pilot/POC environment adding users 1 by 1 is a great option. But this is not an option that is maintainable while scaling or for existing medium-large size companies. In the “Additional Resources” Part of chapter 2, there are instructions on adding multiple users and groups at once or setting up an identity federation with Active Directory, Okta, and other 3rd party identity providers. If this is a relevant scenario for you and you would like to see a walk-through of this process leave a comment at the bottom of the article.
Before we set up the groups I wanted to share a short explanation of why we need to set up groups and what the GCP best practice is around this.
- Create/import/federate your existing users
- If you have existing groups import/federate them and if not — create new groups accordingly.
- Add users to relevant groups.
- Add a group to the Org/Folder/Project/Resource which they need permissions on.
- Assign relevant roles to that group.
This will allow you to easily provide and revoke access for users by simply adding or removing them from groups. Even if there are only a handful of people in the company it is always recommended to assign permissions to a group and not to individual users. If instead of assigning roles to groups you assign roles to individual users it becomes very difficult at scale to understand who has access to what, and what they can do on those resources. — for a deeper dive on this topic read — resource hierarchy access control.
Groups & Admin Access:
- From the GCP Setup Checklist click on “Set up Google Cloud in the Google Cloud Console”
2. The first time you login to the console, if you don’t have an organizational node already it might take a few minutes to set it up, wait for an e-mail from GCP saying the organization has been setup before moving forward.
3. Click “CONTINUE TO USERS & GROUPS”
4. Click “CONTINUE USERS & GROUPS”
5. Select the groups you would like to create, personally I recommend clicking on “CREATE ALL GROUPS” -> “CONTINUE”. You will be prompted to customize your group names. A good naming convention is as follows: company_name-cloud_environment-distintive_function-permissions_level
Where:
- company_name — is the name of the company, if you only have one company under your umbrella this is straightforward, but if you have multiple companies under your umbrella this will be a useful differentiator.
- cloud_environment — is the name of the cloud environment e.g. GCP/AWS/Azure
- distintive_function — is the function of the users in the group e.g. org-admins, billing, security
- permissions_level — is the general level of permissions granted to the group e.g. admin, editor, viewer, etc.
6. Let’s go ahead and update the names of the groups and then click “SAVE & CREATE” -> “CONTINUE”
7. You will be prompted to return to the admin console and set up your administrative users. Since we have already done this in a previous step, you can go ahead and click “CONTINUE”
From this screen, we can add the users we created to the relevant groups. Let's add our first org-admins to our gcp-organization-admins group.
8. Next to the group we want to manage click “ADD MEMBERS”.
9. Type in the user's email address -> select their level of permission on the group (Member/Manager/Owner) -> click “SAVE”
** As we move along we will either add additional users to the other groups via terraform or through the cloud GUI, trying to do as much as possible through Terraform.
10. Once you have finished adding members to your groups click on “CONFIRM USERS AND GROUPS”
11. You will be notified that you have completed the users & groups task. Click “CONTINUE TO ADMINISTRATIVE ACCESS”`
Granting permissions to our groups:
When starting on your GCP journey it is important to understand the difference between the IAM roles you have available to you. I highly recommend reading the GCP IAM page on Understanding Roles.
The tl;dr: There are three types of roles: Basic, Predefined, and Custom. When you start your journey with GCP you should start by using predefined roles. Basic roles have a very broad scope and are a massive security risk. Custom roles are can be very granular and fine-tuned, but like the saying says “with great power comes great responsibility” — if you create custom roles, you are responsible for maintaining them which could become very complex very quickly.
If you are in a highly regulated industry where you have to have very fine-grained controls I would start with a predefined role, let the team begin working, and then based on their needs turn it into a custom role and start stripping away permissions. You could also use the role recommendations service which can help recommend what permissions to remove based on the user's actions and usage. It will always recommend removing permissions and never recommend adding them.
- Follow the instructions on the “Administrative access” page to provide access to the org admin and the billing admin groups — This will be the last step we perform while logged in as the super admin. Following this, we will log out and log in again, this time as the org admin.
**Important tip — Chrome sometimes has issues disconnecting and shifting context between users — my recommendation is to either switch between chrome profiles or to work in an Incognito mode (separate window, not separate tab) when changing between users.
Github:
You must be saying to yourself “Wait! Why aren’t we setting up billing now?”. The simple answer is — If you are a new GCP user you might be entitled to a 90-day 300$ free trial program. So I want to postpone activating this offering for as long as possible. Let's set up our Github environment for development and then, once we are ready to start building we will turn on Billing.
Design decisions regarding the repo:
- “There are so many tools out there, why are we using Github?”. The simple answer is it is free, has got great foundational tools to support CI/CD, and integrates with GCP’s tooling very well. Like I said there are other great tools out there, like Gitlab, BitBucket, and others that you might already own. For the point of this series, I’m not getting into the differences between them, right now ;-). The principles I will lay out are the same, how you implement them and what tool you use is up to you.
- For this project I am going to be setting this up as a mono-repo, with short-lived feature branches, having both infrastructure and application code in the same repo. Like many things in the Dev/Git Ops world, this can become a bit of a religious discussion, see this article on Monorepo vs Multirepo. The main benefit I saw behind the decision to build out a monorepo is to reduce my operational overhead. Setting up code testing, security and other repo operational measures can become cumbersome when managing 10s-1000s of repos, depending on the size of the company. I prefer to set it up once and maintain the configuration across my entire environment.
Checklist:
- Sign-up for Github
- Create your repository. Here you can choose between public and private, as this is for your cloud environment I would set it up as a private repository.
- Setup Visual Studio Code or which ever IDE you prefer to use.
- Install Terraform.
- In VS code clone your repo.
- Create your README.md file, for more info on what should go into your README.md see this link.
- Setup a codeowners file — This will help with controlling who can do what when it comes to your cloud infrastructure. Like with most permissions the best practice is to create a group/team of owners and assign the group as a code owner.
- Setup protected branches as required.
- Work through setting up your project for healthy contributions — even if this is an internal project and not an open-source project, defining healthy work contribution procedures in writing will help I would start with Issue and pull request templates. For Issue templates: I would start with creating templates for Bugs, Enhancements (AKA Feature Requests), and Chores
- Create a Pull request template.
- Perform your first PR
Setting up billing:
Now that users are assigned to their relevant groups and Github is ready let’s set up our Billing admin permissions.
- Follow the steps in Chapter 4 of the GCP setup checklist.
- You will need to decide if you want to set up self-served or invoiced billing and define your account accordingly. If you are already a customer of DoiT International you can reach out to your DoiT contact and ask them for your billing ID.
- Define budgets to generate alerts when spending reaches certain thresholds. In this section it will also recommend setting up billing exports to BQ, we will perform this through Terraform later on in the series. — no need to do this now.
- I highly recommend reading through the best practices for billing and management, and/or assigning this task to the relevant people in your org.
Summary:
Today we have completed laying the foundations for developing our GCP landing zone through Terraform. We have created users and groups, assigned those users to the groups, and granted those groups permissions at the organization level. We have also prepared our Github environment for development and set up billing for our project.
That’s it for this chapter, if you have read this far and are enjoying the series, leave a clap at the bottom of the article and/or give me a follow on Medium, Linkedin, or Twitter where I will be sharing additional updates and resources!
Coming Next Week:
- Deploying our bootstrap project & CI/CD pipeline through Terraform
