Secrets Management

We are seeking the best recommendation and practice offered by HC vault for the below

  1. Allow users to securely store and manage different types of secrets (passwords, API keys, certificates).
  2. Support secret rotation and automated updates to mitigate security risks.
  3. Provide secure storage for secrets, ensuring encryption and protection against unauthorized access.

Hi @jaganbabu15 ,

This one is a bit heavy to answer, as a lot of the practices that will be best for your organization will depend on local/industry requirements, teams, culture etc.

There are many ways to address the 3 requirements you have.

For item 1, you can use the Vault K/V secret engine to store all types of secrets as you have listed. For things like certificates or other complex things you may want to base64 encode the values before writing to Vault (or any secrets tool really) as the format is likely to be flattened, or you would have to do something like add manual line breaks to maintain the formatting.

You can either use a single K/V engine and write policies for different teams that only permit access to different paths, you could enable the K/V secrets engine at different paths for different teams, or you could look at Vault Enterprise or HCP Vault Dedciated and use namespaces.

For item two, it depends on what you mean by rotate, and depends on the system. For database workloads, you can use the database dynamic secrets engine. Vault will take a user/role that permits it to manage accounts on the RDBMS, rotate the password so only Vault has it, and generate just in time credentials when someone needs to access it. This limits credentials from being exposed/leaked since they are temporary and revoked after the TTL is reached.

For 3, storage encryption is part of Vault security regardless of whether you use integrated storage (recommended) or Consul. Unauthorized access, like most systems, is a shared responsibility. Vault certainly provides you the ability to limit access using things like MFA or SSO. But even then, much of this will still rely on how your systems work, what type of auth methods you use and how you configure them, and how you write policies. If you opt to use SSO, but have weak authentication, don’t enable MFA, or attach an overly permissive policy (e.g. using root like policies) then people/systems will have access to things you may not intend for them to access.

Hi Jonathan,

Really appreciate your support on your inputs and it’s great valued information.

Thank you

1 Like