HashiCorp Vault

Vault is a key/value secret storage. A secret is anything that you want to tightly control access, such as API keys, passwords, certificates, and other sensitive information. Vault provides a unified interface to any secret while providing tight access control and recording a detailed audit log.

Vault allows to centralise the Identity management solution across different platform (replacing IAM, Azure AD, Cloud IAM, etc.). This implies that each application need to directly access Vault.

Vault Act as a Root or Intermediate Certificate Authority and Provide Encryption as a Service (you provide the clear text password and vault encrypt.

What Problems does Vault solve:

1. Centralize secret across the organisation

2. Increase security posture by elimination long-lived credential

Vault architecture

Architecture | Vault by HashiCorpVault by HashiCorp

between the HTTP/S API layer (used application and user to interact with Vault and the storage backend where all the secrets are persisted we have security barriers that provide a cryptographic seal around the core components and require vault be be unsealed and the request to be authenticate to

How to Authenticate

To authenticate to Vault we require a Role ID and a Secret ID. These are used to generate and Vault authentication token. In a subsequent request to Vault the authentication token is used to retrieve secrets from Vault from a secret path. Normally the authentication token last a day while the Secret ID requires to be rotated every year.

What Problems Does Vault Solve?

• Centralize secrets across the organization

• eliminate log-lived credentials

• Provide encryption as a Service to the organization

• Automate the generation of certificates for authentication

Data Protection and Vault Initialisation

Vault create and encryption keys that are stored alongside the data that is protecting

A Master key is used to protect the Encryption Key. The Master Key is stored in memory.

During the Vault Initialisation:

• The Master Key is created and stored in-memory. Options to define thresholds, key shares, recovery keys, and encryption keys.

• the Root Token is generated and provided. The Root Token is used for the initial authentication into Vault as will set u addition authentication methods and revoke this root token. This is done using the vault operator init This provides a set of unsealed keys part of the key shard that can now be used to decrypt and read the data.

• Vault seal means that vault "throws away" the master key and requires another unseal to perform any further operations

• we need to seals and unseal Vault for example if the key shard has been exposes

Options for Usealing Vault are:

• Key sharding: taking the master key (that protect the encryption key) and breaking it up in multiple key shards distributed among multiple people in an organisation. You can request the individual shards to be encrypted with different PGP keys. This utilise the "Shamir's Secret Sharing Algorithm

• Cloud Auto Unseal uses a KMS solution (e.g. AWS KMS, Azure Key Vault, Google Cloud KMS, AliClud KMS) to encrypt the master key and store it in a storage Back end. Auto Unseal uses a cloud or on-premises HSM (or other Vault cluster) to unencrypt the Master key and unseal Vault

• Transit Unseal. instead of using a KMS solution or on-premise HSM solution is uses a separate "Core Vault Cluster" to encrypt and de-crypt the Vault Master key

Secret Engines

• Vault components which store, generate, or encrypt data

• Secret engines are enabled and isolated at a "path"

Authentication Methods

Authentication Methods are responsible for assigning identity and policies to a user

Multiple authentication methods are available.

Once authenticated Vault will issue a client token used to make subsequent Vault requests (read/write)

Vault Paths

Everything is Vault is path--based

The path prefix tells Vault which Vault component a request should be routed

Secretes engine and authentication methods are "mounted" as a specified path

Paths available are dependent on the features enabled in Vault, such as Authentication Methods and Secrets Engine.

Permissions, or policies, are granted based upon the path

Some secret engines and authentication methods have some predefined paths beneath the mount point. For example, the database secret has:

• database/config/config name= connection information

• database/roles/role name= defines statement to execute to create the database credential

• database/creds/rolename = credential generation

Vault Path example

Storage Backend

Vault server Configuration examples

Seal Stanza - AWS Example

• secret_key: the IAM secret key with permission to use the KMS key

• access_key is the IAM access key with permission to use the KMS key. If Vault is deployed in AWS, use IAM service role instead access_key and the secret_key.

Vault Policies

Vault allows to set up ACL Policies. A policy is set up against a path and has a set of capabilities (e.g. "create", "read", "delete")

• Starting Vault

docker run -d -p 8200:8200 --name vault -e 'VAULT_DEV_ROOT_TOKEN_ID=myroot' -e 'VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200' vault

Enter in the Vault container and authenticate to Vault

docker exec -i -t vault sh
export VAULT_ADDR='http://localhost:8200'
vault loging myroot

White a secret in Vault:

vault kv put secret/configclient client.pseudo.property="Property value loaded from Vault"

Now you can browserhttp://localhost:8200 and enter the application with your root token.