Secret Management using Vault

Secret Management using Vault

Scenario:

        An application depends upon many resources in order to function properly, such as databases, third party API’s, storage, monitoring tools etc. It uses secrets to access/authenticate itself with these tools. These secrets are confidential tokens that have to be secured and passed on to the application. But how do we do that?

Traditional Approach:

        The most common way to store secrets is in config/.env files. These files are attached to the application’s codebase. We maintain separate config/.env file for every application environment, i.e. Dev, QA, Prod etc…

Flaws in this approach:

• What if someone has access to the codebase? They will get access to applications secret data such as database password, credentials to tools etc…
• Secret Sprawl: Every secret file is spread out in every application instance, source code, CI/CD tools etc.
• Encryption: Secrets are not encrypted. Anyone who can access the application environment can access the secrets.
• Break Glass procedure: In events of compromise, the procedure involved in securing the secrets is poorly configured

This is where VAULT comes in ...

Vault:

        Vault is a tool designed to store and access application’s sensitive data securely. It helps us to build a centralised secret management service. Vault can generate the secrets, encrypt the data, limit the access to the stored data and also it can help in revoking the access. It also solves the problem of tracking who accessed/modified a secret via audit logs.

Use Cases:

It is built to mainly focus on the :

• Secret Sprawl : To have a centralised storage system
• Security : To encrypt/decrypt the creds in transit
• Identity Access Management : To authenticate or authorize the operator

Key Features of Vault:

• Secure secret storage:

• Everything stored is encrypted
• Uses 256 bit AES advanced encryption mechanism
• NO Hardware required

• Dynamic secrets:

• Mechanism for generating secrets on the fly
• Generates on demand credentials that have limited access, to get going with the functionalities

• Leasing, renewal of tokens:

• Every secret has a lease
• Revoked at the end of lease unless renewed
• Can be manually revoked by operators in the events of Break Glass procedure

• Auditing:

• Visibility on who has access/modified the secrets

• ACL:

• Give limited access to particular user such that the job functionality is satisfied

Vault Architecture:

• Operator send the keys to be stored in vault via its api
• These env variables are encrypted before api transmits them (encryption as a service)
• Encrypted secrets are stored within preferred storage.
• In similar way, Operator requests vault an env file.
• Vault verifies the user if it has the right permissions
• Vault retrieves the secrets from its storage.
• Decrypts them and send back to the user.

References:

• https://www.youtube.com/watch?v=3q9_gxqkZA8
• https://www.vaultproject.io/docs/internals/

---