LGTM Devlog 13: GitHub Branch Protection and Security
Tags: devjournal, github, git, python
Published: 2021-01-01 22:28:21

Let's talk about security a sec. On Google Cloud, every account - both users, and service accounts, have a certain set of permissions that allow them to use google services. These permissions are important. For example the default user account that you get when you create a GCP project, has `owner` permissions, which grants access to EVERYTHING. This is convenient and also dangerous.  Similarly the default service account that Firebase creates has `editor` permissions, which similarly has broad-ranging permissions.

The danger of this is if there were unauthorized access to these accounts, the person could do anything, ranging from starting up a whole bunch of VMs to mine bitcoin or send spam, to deleting all your data.

To avoid this, we want to lock down things to a reasonably degree. 

# Locking down GitHub Actions
Since we are deploying functions directly from GitHub Actions, those actions need enough permissions to do that, as well as authenticate with the GitHub API. To accomplish this, we create a service account just for GitHub Actions as well.

![Creating a Service Account](https://dev-to-uploads.s3.amazonaws.com/i/7f8ogda594clb7zu9fgc.png)

In step 2, we grant this function the "Cloud Functions Developer" role, which it needs to be able to deploy cloud functions.

Then, once created, we also go and create a private key. This is needed by GitHub Actions to authenticate as this service account.

![Downloading the deploy key](https://dev-to-uploads.s3.amazonaws.com/i/jgs1p1lrtgsjzqij12em.png)

# Locking down Google Cloud Functions
Then, we need to create a new service account so that the Google Cloud Function we set up previously doesn't have any extra privileges that it doesn't need. Right now it doesn't need any since we haven't added any real functionality yet, so we just create the account.

![Create service account](https://dev-to-uploads.s3.amazonaws.com/i/f4uw33n6lwwtasfriqub.png)

Once this account is created, we need to give the GitHub Actions service account created previously access to using this account (something that it needs when deploying the cloud function). In the Permissions pane of the service account, it's possible to specify which users or service accounts can use this one. I add the GitHub Actions one in there.

After creating this service account, nothing else needs to be done other than to copy its account ID (which is formatted like an email address), and specifying it when we deploy functions so it will use this account. (I actually add the service account to a environment secret on GitHub so it can be used during the CI)

That's all for locking down the GCloud account for now.

# GitHub Branch Protection
Over on GitHub, a very dangerous thing for git is allowing force-pushes, which have the potential for wreaking (irreparable) havoc on the repo. So we use Branch Protection, which prevents force-pushes. It also lets us set up some rules to only allow merging into `main` branch via PR, and at the same time requiring that tests pass (a useful move, avoids untested and bad merges).

![Branch protection rule](https://dev-to-uploads.s3.amazonaws.com/i/o4z4aid7av4zp4jsbwnl.png)

___
Between these measures, security is improved a little bit