How Abbey securely manages access to Google Groups

At Abbey, we see that many customers rely on Google groups to manage who has access to what so we wanted to take a spin at showing how we can simplify managing those groups through our concept of grant kits.

Most organizations will bucket their employees into various groups depending on their role, such as marketing, product, engineering, emergency, security, etc. These groups will initially map 1:1 with Google groups, resulting in

• marketing@abbey.io
• product@abbey.io
• engineering@abbey.io
• emergency@abbey.io
• ...

This seems easy enough at first - when a new employee joins the company, log onto the console, put them in the right group depending on their role, and voila. But wait, what happens when they switch roles? What if the product team is split into multiple groups? Multiply these events by the number of employees and this problem sounds much worse.

We haven’t even talked yet about who’s responsible for this approving these group changes. Is the product team the only owner of their group, or should the security team be responsible of overseeing these changes? This leads to tension across different orgs because there isn’t a clear ownership or alignment. Do you ever remember being surprised an approval request came to your Slack DMs or email? Or had to review access lists you shouldn’t have been a part of?

Enter Abbey Grant Kits

Luckily, we have a solution to tie together Infrastructure as Code with Access Management in the form of Abbey Grant Kits (AGKs), which gives you the ability to define who should be able to approve any permission updates and what those permissions look like.

With AGKs, permissions and policies are defined directly in Terraform alongside your existing code, so you get all the benefits of easily auditable and peer-reviewable changes! This also means you get the benefit of code reusability - easily share and update policies and reviewer lists across multiple groups at once.

If your groups are already defined in Terraform then that’s great! If not, don’t worry - we can easily pull the data in.

Google Groups & Grant Kits

We can use grant kits to directly add/remove people from Google Groups, and configure permission policies such as time-based revocation.

As an example, we set the approval list for our emergency@ google group to include our security team and have a 24 hour automatic expiry. When an access request is initiated through the Abbey UI, it will request an approval from our security team. If approved, it will create a new membership to the emergency@ group for the requester. Abbey will automatically revoke the membership in 24 hours based on the policy set in the grant kit.

Re-using Grant Kits

This allows you to define your reviewer lists and permission policies in code alongside your resources, and share those configs across multiple groups. Let’s imagine the product team has split into 5 different groups - product-research@, product-marketing@, product-features@, product-planning@, product-testing@.

In the old world, this would become 5 new groups requiring manual membership management. With Abbey, we can re-use our grant kit config from our product@ group and keep them the same or narrow the reviewer lists down based on the new managers of the team. We would likely keep the permission policies the same so no changes needed there. After that, memberships for the new groups will be self-managed.

Running it live

Here’s an example you can use live on with Google Cloud Platform or Google Workspace, where you can configure Abbey to add and automatically revoke members to your Google groups. Feel free to use either depending on your infrastructure setup.

We’re also working on an in-depth video walkthrough or if you’d like to see similar examples for other Google resources, let us know at hello@abbey.io or join the slack community!