Table of contents

The GDS Way and its content is intended for internal use by the GDS community.

How to manage access to your third-party service accounts

Your GDS team is likely to use third-party tools to develop a service, such as GitHub and logit. Follow this guidance to manage access to any associated accounts.

When managing third-party service accounts, you must ensure:

  • only the correct people in your team have access
  • team members have account access revoked when they leave
  • you identify who in your team is doing what and when (this is more important for some tools, like Amazon CloudTrail, than others like BrowserStack).

To securely manage account credentials

You’re likely to need a set of credentials to gain access to your third-party user account, for example passwords or secret access keys.

When managing these credentials, you must:

  • keep the number of secrets you have to a minimum - this reduces the number of credentials to revoke when someone leaves GDS (passwords are particularly problematic secrets, other secrets such as secret access keys or OAuth tokens are more easily rotated)
  • never use credentials associated with another individual
  • encourage the rest of your team to avoid sharing credentials unnecessarily (technical limitations may mean this is sometimes unavoidable)

For accounts with organisation-level access

Often third-party services natively support organisation or team level access, for example the use of alphagov on GitHub. In these cases you should ensure only the appropriate individuals on your team have access.

With team or organisation-level accounts, where possible you should:

  • create separate accounts for each individual rather than share credentials
  • use a single-sign-on provider rather than create an account with a separate username and password - preferably use G Suite as it’s a core part of the GDS leaver process, which means that access to linked third-party services will be revoked automatically when someone leaves
  • ensure that you have a documented process for removing individuals’’s access when they leave GDS

For accounts with individual-level access

When services don’t support organisation-level access, you may have to share individuals’ sign-on credentials.

Sharing individuals’ sign-on credentials can create risks as:

  • you don’t always know who can access a service (particularly if users only access a service rarely because you can forget who has access)
  • the last person with account credentials may leave GDS, making it impossible for others to access a service in future

To reduce these risks, you should:

  • create an account using a Google Group email address rather than an individual’s email address
  • set posting permissions to ‘public’ so your group can receive emails from outside GDS
  • set viewing topic permissions to ‘all members of the group’ so only users with access to a service are able to view posts
  • store passwords in your team’s shared credential store
  • use two-factor authentication
  • ensure you have a documented process for removing an individual’s access to the Google Group, credential store and for rotating credentials including any API keys

For GitHub accounts

You can use your existing personal GitHub account when you join GDS. Each GDS team should have someone (usually a technical lead) who is an owner and can grant/revoke access to their repositories.

For Logit accounts

Use Google Apps Marketplace when you sign into Logit (this is the only available option).

This page was last reviewed on 4 June 2018. It needs to be reviewed again on 4 December 2018 by the page owner #gds-way .
This page was set to be reviewed before 4 December 2018 by the page owner #gds-way. This might mean the content is out of date.