Secrets Management

This document defines how to support management of secrets and keys within a cloud-based solution.

We currently rely on three different resources for keys and secrets.

  1. GitHub repo

  2. Terraform

  3. Azure Key Vault

  4. ~~Application files.~~ Do not do this. Secrets should not be stored in source files.

Usage Guidance

The resource to use to store your secrets can be determined by these usage scenarios:

Resource

Secret Usage

Examples

GitHub

Connectivity to Terraform and Organization Tools

TF_ ids; LeanIX Scan; Snyk

Terraform

Deployment and Configuration of Cloud Resources

environment, location

Key Vault

Application Secrets and Keys

client id and secret, api keys

To choose the right resource, determine the purpose of your secret. For example, if you need to connect to Azure from your GitHub deployment action, you’ll need a GitHub secret. If you need to vary the SKU of a resource per environment, store the value in your Terraform remote workspace variables.

GitHub Secrets

GitHub supports three types of secrets for your GitHub Actions:

Secret Type

Usage

Ownership

Configured

Environment

Terraform subscription, clientid and client secret

CloudOps

During repo creation

Repository

Custom secrets for the solution such as a Teams webhook for notifications

Solution team

As needed

Organization

Clouds Ops use such as LeanIX scan and Snyk token

CloudOps

As needed

Terraform Secrets

Terraform secrets are not always secrets in the pure sense of the word. Often they are simply configuration settings for Terraforming your cloud resources. If you find yourself needing to check the Sensitive checkbox for a variable in your remote workspace, consider that it may be more appropriate as a Key Vault secret.

Tying secrets to the cloud provider where we have additional security in place is preferred over tying them to a third-party tool.

IT required tags should already be configured from creation of the repo by the association of a variable set each of your environment-specific Terraform workspaces. For older repos, you’ll need to request a variable set be added. It’s your responsibility to use these tags in your Terraform. Eventually, the concept of default tags will be supported for Azure resources, like they are for AWS today, and those can be set once in your Terraform instead of per-resource.

Key Vault Secrets

Secure storage for your secrets in the cloud. Provision a Key Vault instance and store secrets using the azurerm_key_vault and azure_key_vault_secret Terraform resources.

App Configuration

A consideration for Azure-based solutions is to leverage the AppConfiguration service.

Advantages include:

  • Support for Key Vault secret and key access

  • Support for non-secret settings for your solution (e.g. app settings)

  • Support for feature flags

  • Single interface to read all of the above; only need to manage one connection string

Glossary

  • Secret - any data you want to secure such as API credentials or passwords.

  • Key - a cryptographic key. The clear text value cannot be seen or retrieved by the owner.