Secrets Management

Introduction

We all have secrets, and we keep them, you know, in secret. But when it comes to our clients' secrets, we need to keep them twice more thoroughly. That's why we use Vault by HashiCorp, an enterprise-grade secrets repository. It allows to securely store all passwords, tokens, certificates, and smoothly integrate them into the codebase.

Access

You can access a web-based interface here: BN Vault

For authentication, generate Github Token as discussed

Structure

vault
├── accounts
│   └── <service uri>
│       └── <account identifier>
│           └── [key-value]
├── projects
│   └── <project name> - same as repository name
│       ├── global
│       │   └── <account identifier>
│       │       └── [key-value]
│       ├── infra-stage
│       │   └── <account identifier>
│       │       └── [key-value]
│       ├── infra-prod
│       │   └── <account identifier>
│       │       └── [key-value]
│       ├── infra-xxx
│       │   └── <account identifier>
│       │       └── [key-value]
│       └── extras
│           └── 
│               └── <account identifier>
│                   └── [key-value]
├── personal
│   ├── [certificate 1]
│   ├── [certificate 2]
│   └── [certificate x]
└── templates
    ├── project
    │   └── ...
    └── <service>
        └── ...

Path pattern

/secrets/projects/:project

Project	Description
Project	Name of current project - used as only one root for all dependent configurations and credentials

Materialized path pattern

:provider/:service/:environment

Parameter	Description
Provider	Represents third party which provides configuration
Service	Optionally, application name in case of multiple
Environment	Optionally, environment name (could be one of: development

Key pattern

kebab-case

Consistent naming desired, as well as environment naming convention. Also, credentials are grouped by application, avoiding extra prefixing

Usage

Examples

APP_GOOGLE_CLIENT_SECRET environment variable projects/app/google/client-secret secret path

Local provisioning

To populate, perform next steps:

1. Add @bn-digital/vault in package.json devDependencies
2. Create .env.dist if your package require dynamic configuration
3. Populate .env.dist with required keys and complete paths to your secret as value see sample
4. Create .env with following content (it will not be replaced after pulling values from Vault):

VAULT_ENDPOINT=${{ vault-url }} # something like https://vault.acme.com
GITHUB_TOKEN=${{ github-token }} # something like ghp_50005b28B37VAlq8aaAQm19a

5. Prepend that command in start script for your convenience:

{
  "scripts": {
    "start": "vault-env && webpack serve --mode=development"
  }
}

Q&A

Why can't we store all secrets in a repository? — Cause it is insecure, especially for the front-end part. You can't store any secret on the front-end side, as it could be simply reverse-engineered and stolen. Why can't we store secrets on local machines? – Cause it is both insecure and not scalable. Remember, we work as a team, and sharing passwords securely is important. You can't just send a password in an email or a slack channel, even a client does that. Why it is so important? – Cause it is a security issue, and security is treated as one of the most important human needs. That is our obligation as a team and as an organisation to keep clients' secrets as secure as possible.