Skip to main content

The GDS Way and its content is intended for internal use by the GDS and CO CDIO communities.

How to store credentials

Depending on how you manage your accounts, you, your team and the service you run may have credentials or other secrets that you need to store securely.

Personal credentials

Examples include login details for:

  • GitHub
  • AWS
  • GOV.UK Signon

Use the password manager built into your browser in the first instance. This is simpler than setting up an extra account with a third party and avoids some of the potential issues below.

If you can’t do this for some reason, then it’s OK to use a third-party password manager. This could be necessary if your browser has an accessibility issue, or if you work with multiple browsers.

Some of the third-party password managers people use at GDS include:

  • LastPass - Approved by Information Assurance and available to install in the GDS Self Service app. However, the free version can only be used on one type of device.
  • 1Password
  • BitWarden - An open source password manager.
  • KeePassXC - An offline password store, which you may want to backup somewhere.
  • QtPass - Another offline store, integrated with Git and GPG / pass.

Note that there is a security trade-off involved in using browser extensions to autofill credentials. On the one hand, autofilling credentials can help protect against phishing (for example your password manager will refuse to autofill credentials if exxample.com attempts to impersonate example.com). On the other hand, it can be difficult to implement this functionality securely in an extension.

Team credentials

Examples include shared login details for:

  • Software repositories e.g. npmjs.org, rubygems.org
  • Admin portals e.g. Fastly, DockerHub

Follow the guidance for managing team credentials in the fist instance.

There’s no established best practice for storing shared credentials at GDS. Some teams have a “credentials” GitHub repository and use pass to store credentials encrypted with GPG. Make sure you configure the repo as internal or ideally private to help prevent accidental disclosure.

Using GPG in this way isn’t ideal because:

  • We can’t revoke access to credentials, unless we change them. Anyone who was given access can still decrypt credentials using their local copy of the repo and its commit history.

  • It creates a high barrier to entry, especially for people less familiar with Unix tooling. We’ve found GPG tools are generally difficult to use and keyservers are unreliable.

Investigate alternatives before adopting GPG-based credential stores for new teams.

Service credentials

Examples include:

  • Functional account credentials e.g. API keys
  • Sensitive configuration (e.g. IP block lists)

Use the secrets management feature of your infrastructure or cloud provider e.g. AWS Secrets Manager, HashiCorp Vault. This should make it easy to control and audit access to the credentials.

Older (pre-cloud) projects in GDS tend to have a “secrets” repository and use GPG to encrypt files, which are then decrypted during the deployment process. However, using GPG isn’t ideal.

This page was last reviewed on 6 August 2021. It needs to be reviewed again on 6 February 2022 by the page owner #gds-way .
This page was set to be reviewed before 6 February 2022 by the page owner #gds-way. This might mean the content is out of date.