Skip to content

Secrets Management

Jump to bottom
BN Developer edited this page Jan 5, 2022 · 24 revisions

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.bndigital.dev
├── 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>
        └── ...

Overview

In the vault, there are the next root directories:

  • accounts folder stores all credentials to log into somewhere. If you need to have login/pass to an external or internal system, you would mostly find credentials right here.
  • projects folder stores all project-specific credentials. They should be applicable to this and only this project.
  • personal folder stores all secure data of you as a BN Digital Engineer.
  • templates folder doesn't store actual credentials but provide a straightforward structure that you are encouraged to copy.

Accounts structure

In the accounts folder, you will find all unique resource identifiers folders. Search for figma if you want to log into Figma account. Inside the folder, you would find the account ID and key-value pairs inside.

Example ``` accounts ├── figma │ └── design@bndigital.co │ └── login > design@bndigital.co │ └── password > ******** ├── mailgun │ └── info@bndigital.co │ └── login > info@bndigital.co │ └── token > **************** │ └── password > ******** └── ... ```

Projects structure

In the projects folder, you will find all project identifiers folders. Their names should correspond to github repository and PM tool name. Inside the folder, you could find the next structure:

<project 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]
  • global folder stores all credentials that are common to the whole project. For instance, it could be BN Digital Strapi credentials, or Google API key. The folder should not contain anything infrastructure-related.
  • infra-stage is a mandatory folder that stores all secrets regarding the staging environment and is exclusive to it. Databases, login/password pairs should go there if they are not common throughout the whole project.
  • infra-prod is a folder to keep if we took the responsibility to go production.
  • If we need to have another environment, a separate folder could be created with the name "infra-" and an identifier. It could be infra-qa, infra-stage2, etc.
  • All other secrets that for any reason don't match with the pattern go to the *extras folder.

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
  1. 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.

Clone this wiki locally