Terry Beavis | Wednesday, August 5th, 2020
Problem
- Many applications need to use secrets (username, passwords, tokens, …) to connect with other services like databases or protected services.
- The classical way to provide secrets to an application is using environment variables, configuration files, JVM parameters or command line parameters, meaning if an attacker can get into the machine they will be able to access all of these un-encrypted values.
Requirement
- Reduce the amount of information an attacker can get when penetrating the system.
Solution
A new naming convention and best practices were created as well as a new module to enforce them. This was embedded inside each service to access Vault’s secrets at runtime.
This module centralizes all access to secrets to talk with the Hashicorp vault with caching capabilities to avoid performance degradation.
The solution expands the capacity to consume secrets from multiple Vault servers allowing each system to share their secrets in their own Vault.
Challenge
- Analyze how to embed the new architectural component in all parts where access to secrets were required.
- Cross security boundaries between infrastructure layers.
Result
- No more username/passwords/token presents as environment variables, parameters or inside plain text files.
- All secrets were managed in a central management server (Hashicorp Vault)
- All applications access a central secrets management server to get secrets, where each secret handles its own TTL caching policies.
Changes in secrets (renewal) are done in a central place and information is scattered to all clients.
Filed under: