Creating and Using Service Accounts in PAD

Within Google’s infrastructure, you have a number of ways to authenticate for access to services. Some services require - or highly benefit from - an authentication method called service accounts. PAD administrators and engineer roles in projects can create and modify service accounts to perform work in their projects. Previously this required assistance from CTA staff, but we have now made it self-service for PAD users!

What are service accounts?

Service accounts are non-human users. They are a special type of account, intended for situations where an application or a workflow needs to access resources or perform actions without the user’s involvement. A service account is different from a normal user account in a handful of ways. For one, service accounts don’t have a traditional username/password structure and can’t be used for browser-based sign-on. Additionally, they are created and managed as a resource that belongs to a specific Google Cloud project. In contrast, user accounts in PAD are managed by CTA and can be used to sign in on a browser.

Service accounts can also be granted to resources, such as a Cloud Storage bucket, and they can be accessed and impersonated by other users or groups. You can also create a key for a service account; this is similar for security purposes to a password, and is required for use with some services. 

What are examples of when I would use a service account?

A number of Google services, like Google Workflows or scheduled queries, will require you to use a service account in order to schedule runs. Many non-Google services, such as Hex, also require a service account to make a connection to your PAD Google Cloud project. You can also use a service account when you need to connect scripts or other programmatic processes to your PAD Google Cloud project and don’t want to run them manually with your user account.

How do I create a service account and generate keys?

To create a service account, navigate to the IAM and Admin/Service accounts page in your project. Please note that only users with administrator and engineer PAD roles can create or modify service accounts and keys. If you don’t have access to create a service account or key, please speak to your PAD project’s administrator. 

Once you’re on the service accounts page, click ‘Create a service account’. From there, you can give your service account a display name and actual name, as well as add a description. Use clear, human-readable names that describe the service account’s purpose at a glance.

After you finish there, you can assign roles to your service account. Roles indicate the permissions a service account has, and you can read more about recommended roles here for different use cases. Google also has comprehensive documentation of available roles here. To assign roles, select the one you want in the menu. You can and often will add multiple roles. Aim to follow the principle of least privilege - only give your service account the permissions it absolutely needs to complete its tasks. Often, you may have to revisit the permissions after you get your script or service up and running with your service account, but Google’s error messages will tell you explicitly which permissions are missing. Note that any roles you assign here will be PAD project-wide.

After you select your roles, you’ll have the option to grant principals on your service account. Principals indicate other Google services or users that have access to the service account. This is typically not needed unless your use case specifically calls for it. 

From there, click Done and your service account is created! You’ll see it show up on both the service accounts page and the main IAM and Admin page with its unique email address - this is how you’ll identify the service account. You can also go back to the service account page at any time and edit its permissions or principals by selecting the three dots next to its entry and clicking on ‘Manage permissions’, or delete it if needed. Additionally, the main IAM page will display all the permissions it currently has.

If you want to make a key, you’ll also navigate to the three-dot menu and select ‘Manage keys’. From there, you should see a button for ‘Add key'.

Click add key and then select create new key. Typically, you want to use the JSON file version of the key; make sure you download it upon creation to store it somewhere secure. You can also deactivate keys from this page.

Please note that if Google’s monitoring service detects your service account key on the public internet (for example, if it’s accidentally uploaded to a code repository), it will be automatically deactivated. We recommend rotating keys on a regular basis as a best practice.

I already see service accounts in my project - why can’t I just use those?

There are a number of service accounts in your project that are created by CTA or by Google. You can read more about them here. Generally, we recommend creating your own service account for any work you want to do.

We also recommend limiting a service account to only one use - so one process, or one service, etc. This is for security purposes - if a service account is compromised and has wide-ranging permissions and applications for multiple services, it can do more harm and is also harder to track and rotate.