Automating Employee Onboarding to GitHub

Onboarding new engineering hires is hard. You want to get them productive on day 1 and a big part of this is getting them access to relevant codebases. You generally have two options: Birthright access or Just-in-Time (JIT) access.

Birthright access is when you give access based on the new hire's job function. Just make sure you don't end up giving them access to every repo in your organization. It's unlikely they'll need access to everything, especially on their first day. You also want to limit the blast radius for code to be exfiltrated if their account is compromised.

Just-in-Time (JIT) access, at its extreme, is when you give no one access to any repo by default. New hires would then request access to what they need, when they need it. This breaks down even at relatively small scale.

Because of this you might be tempted to add a Slack-based request workflow so you can review requests in Slack. Well this just sounds like a ticketing system with extra steps.

Maybe make service owners responsible for reviewing access to their own repos? Well now you're just spreading the pain.

So how do you get that sweet Just-in-Time access and least privilege without the toil? Sprinkle in some automation to this workflow.

The Abbey Way

The Abbey way is to leverage Infrastructure as Code (IaC) to configure this workflow once and have it automated forever.

You can do this with Abbey in 3 simple steps:

1. Configure a Grant Kit in Terraform for new hires to request access to GitHub teams.
2. Use Policy-as-Code, backed by Open Policy Agent (OPA), to automate approvals or denials to your GitHub teams based on your Okta groups.
3. Get back to work and focus your attention on other things.

Configure a Grant Kit for employees to request access to GitHub Teams

Let's say you have many GitHub Teams configured in Terraform which you iterated over a list of local.eng_teams.

You can configure Grant Kits to expose each of these groups for your new hires to request access to:

The code above has two key parts. First, we add policies to automatically approve or deny requests based on the requester's Okta groups. That way, you don't have to get pinged for every request.

Automate using Policy-as-Code

Let's say a new hire belongs to the Engineering group in Okta and we want to automatically allow them access. In all other cases, automatically deny access. This logic can be represented below in the OPA Rego code:

Notice the data.system.abbey.identities.okta.groups variable. Abbey enriches this for you automatically. You just have to set up Okta to sync attributes via SCIM. You can use this data directly in your OPA policies to write richer access logic.

Generate Terraform-native output automatically

The second key part of the code above is the output block. This generates Terraform-native output for each GitHub Team. This output is generated when a new hire requests for access to a GitHub team. Abbey will interpolate the username data from their GitHub identity and add it to the output.

Tell new hires to request access when they need repo access

That's it! You only need to configure this once. Now all future new hires can request access to GitHub teams whenever they need it.

You no longer need to manually review requests!

Even better, your workload of 500 hours of requests has now been reduced to mere minutes of work!

Expand your automation

If you need more control over how employees get access, you can add in single- or multi-step workflows to define a series of approval steps that might be required, such as by service owner, manager, and security, depending on the repo's sensitivity.

You can also skip individual workflow steps, for example, if the requester isn't a new hire based on some amount of tenure in your company. More on these in a future blog post.

Wrap Up

In this blog post, we showed you how onboarding new engineering hires so they're productive on day 1, while seemingly simple, can get out of hand at scale if you're trying to balance between birthright and JIT access. On one hand, you want to improve security while on the other, you want to avoid toil. If you use your existing IaC tools such as Terraform, and are able to extend it using Policy-as-Code, you can automate the toil away while maintaining security.