All your secrets belong to you!
HashiCorp Vault is a highly sophisticated tool for secrets management and encryption.
The main features include but are not limited to:
- Encryption and centralized storage of secrets (passwords, keys, tokens, etc.) at rest,
- Role-based access management to said secrets, dynamic access allocation (i.e. for client applications, temporary user accounts etc.),
- Detailed auditing of access to secrets
- Capable of Replication and Redundancy (Disaster Recovery)
- High availability setup ensures data integrity
- Using Identity providers allow easy access via established routines and workflows
- Vault stores secrets in a backend (different possibilities available, some with high availability options and support from HashiCorp, others on ones own terms).
- Access to secrets via API or UI, due to API access easily available for integration into existing workflows.
- Capable of Integration into OpenShift or Kubernetes Clusters.
- Multilayered security features (secrets encrypted at rest, role-based access, time restricted leases, i.e. tokens provided to application and revoked after set timeframe)
- Even a captured token or a token accidentally not omitted from a log only poses a small breach risk that way as the time it can be used with malicious intent is limited.
- The Enterprise Edition offers additional features (automated replication to secondary site, automated disaster recovery) but even Open-Source version provides numerous benefits and options
- Thanks to identity providers (can be self-hosted one like Keycloak or based on existing workflows via AWS, Azure, etc.) access to secrets can easily be mapped to appropriate roles.
- Even if encrypted, it is stored off site.
- As encrypted files are not easily readable by git, changes in those files often cause merge conflicts.
- Developers can have access to production secrets.
- Storing the secrets in vault removes these obstacles, with secret injection or external secrets setup vault can be used even by vault-agnostic applications, all they need is an appropriate role setup and secrets can be injected when required.
- No secrets in the repository means no merge conflicts in those files.
- Developers only need their applications to call the correct secrets when in a production environment, only the client application with the right permissions will have access to the secret itself.
Christian Hubinger
Your fast-track to Cloud Native Infrastructure expertise
In a free first consult with our Head of Cloud-Native Christian, we can talk about your consulting and/or service needs.
This link will take you to savvycal, a fantastic tool to book a meeting with Christian in one click. Also feel free to check out their privacy policy here.