Introduction
Why use HashiCorp Validated Designs?
HashiCorp introduced the Validated Designs program to give customers access to a set of guidance based on our experience working with customers to deploy our solutions. Aligning to the provided recommendations gives you a fast track to a production ready service, a standard pattern for our support engineers to best support you, and help you serve your customers including application team developers with optimized workflows.
Note
Audience: This document provides recommendations for implementing Vault as a platform service within your organization. In different organizations, the team responsible for this task is called the Platform Team or the Secrets Team. Whatever your team's name, this document should be helpful to those who are responsible for owning, implementing, and operating Vault.HVDs and HashiCorp Vault adoption maturity stages
HashiCorp Validated Designs provide prescriptive guidance curated from our experience with supporting numerous customer journeys using Vault Enterprise.
Note
Audience: This document provides recommendations for implementing Vault as a platform service within your organization. In different organizations, the team responsible for this task is often called the "Platform Team" or the "Secrets Team". Whatever your team's name, this guide should be helpful to those who are responsible for owning, implementing, and operating Vault.HashiCorp Vault Maturity Stages and Use Cases
Adopt | Standardize | Scale |
---|---|---|
Use Cases - Static Secrets Management - Secrets sync - Access Policy Management - Visibility and Management - Disaster Recovery - Namespaces | Use Cases - Dynamic Secrets - Modernizing Brownfield Applications - Kubernetes Secrets Management - Dynamic Secrets for Terraform - Workflows - Secure Remote Access - Authenticate Access Between applications - Compliance and Governance | Use Cases - Database Secrets - PKI Lifecycle Management - Cloud Key Management - Application Data Encryption - Tokenization - Data at Rest Encryption (KMIP) - Advanced Insights and Management |
Adopt: In the Adopt phase, the emphasis is on customers who are just starting their journey to improve their security posture by reducing secret sprawl and centralizing secrets management. In this phase customers are establishing the foundation of creating a platform based approach to centrally secure and manage secrets for various development and app teams.
Standardize: Customers in the Standardize phase, having successfully completed the Adopt phase, are seeking to expand the availability of the secrets management platform to accommodate a wider and complex range of develop team use cases. They have experienced the benefits of Vault's secure secret management for static secrets and are now ready to leverage more secure credentials such as dynamic credentials. These customers aim to centralize secrets, automate workflows, and enforce access controls. Integration into development pipelines is vital as they strive to eliminate inconsistencies and reduce security risks.
Scale: For customers in the Scale phase, who have progressed through the Adopt and Standardize phases, and gained experience in implementing security practices with Vault, their focus is on maximizing Vault's potential. Deploying across regions and clouds, ensuring high availability, performance optimization, and disaster recovery readiness are paramount. These customers require advanced features like dynamic data masking and improved resilience (performance replication) to meet rigorous security and compliance requirements.
Prerequisites
HashiCorp recommends the following prerequisites before implementing the Vault Operating Guide for Adoption:
- Review Cloud Operating Model
- Attend Vault workshop or Vault academy training
If you are using Vault Enterprise (self-managed/self-hosted Vault), this guide assumes that you have reviewed and/or implemented the following documents:
HashiCorp recommends using Terraform to provision and configure Vault. For guidance on using Terraform, please refer to the Terraform HVD.
Language and definitions
While this guide intentionally uses technology-agnostic language, there are some terms that do not translate seamlessly between providers. This document uses the following terms:
Term | Definition |
---|---|
Namespace | Namespaces provide a way to segment and isolate Vault data into distinct compartments. They enable multi-tenancy, allowing organizations to maintain separate configurations, policies, and secrets for different teams or projects within a single Vault instance. |
Tenant Namespace | Same as Namespaces above, term used to signify isolation for business units and teams. |
Secret Engine | The backend systems or engines where secrets are stored, managed, and organized. Each secret engine represents a different secret storage unit, allowing for the separation and management of distinct secret collections within the Vault. List of Secret Engines available in Vault - Secret Engines. |
Auth (Authentication) Method | The mechanism by which users or systems prove their identity to obtain tokens. Auth Methods encompass a range of options, from username and password to cloud identity systems and more. List of Auth Methods built into Vault - Auth Methods. |
Machine Auth (Authentication) | The automated authentication of machines or applications, allowing them to securely retrieve secrets without manual intervention, leveraging identity-based or role-based access controls. Some types of common machine auth include Kubernetes Auth, AWS Auth, Azure Auth etc. |
Human Auth (Authentication) | Authentication methods used by humans to authenticate into Vault for the purpose of administering Vault, configuring secrets and accessing secrets. List of typical auth methods used by humans include Username/Password, LDAP, Okta, etc. |
Availability zone | A distinct data center within a region that provides redundant and isolated infrastructure to ensure high availability and failover protection. Each region consists of multiple AZs to offer resilience against system failures. |
Region | A geographically distinct area that hosts multiple data centers, providing redundancy and fault tolerance for cloud services. Each Region consists of multiple, isolated locations known as Availability Zones. |
Instance | A physical or virtual server or hardware unit used for computing purposes. |
Load Balancer | A hardware or software device used to distribute incoming network traffic across multiple servers. |
HVD document structure
This document covers the "Adopt" maturity phase of operating Vault includes:
HashiCorp Validated Design adopt stage document structure
Section | Summary |
---|---|
Introduction | This section provides an overview of the overall document. |
People and process | This section outlines the roles, responsibilities, and workflows essential for effectively implementing and managing Vault Enterprise. |
Organizational concepts | This section discusses how to plan the organization of Vault to establish it as a platform. |
Disaster recovery | This section discusses how to plan for and implement disaster recovery replication for Vault Enterprise. |
Initial configuration | This section outlines the essential steps and settings required for configuring Vault Enterprise for its initial usage in your environment. |
Authentication for applications | This section discusses how to configure Vault for authentication by secret consumer applications. |
Static secrets | This section discusses how to onboard static secrets into Vault and how app teams can leverage the secrets in their applications. |
Visibility and management | This section discusses the logs and metrics that need capturing and provides best practices for monitoring the Vault Enterprise platform. |
Standard operational procedures | This section discusses standard operating procedures for managing Vault Enterprise. |
Support readiness | This section discusses how to prepare for and engage with HashiCorp Support. |
Appendix | This section contains supplementary information and resources that provide further context or details on the main content of the document. |
Objectives
Business objectives are high-level goals that organizations strive toward to achieve strategic impact, encompassing areas like customer satisfaction and revenue growth. Functional objectives, in contrast, outline detailed goals related to system features and capabilities, specifying the "what" and "how" aspects of a project. While business objectives inform the overarching direction, functional objectives concentrate on specific tasks necessary to fulfill those broader goals.
The fundamental business and functional objectives listed below are common to organizations seeking a mature solution for secrets management, and all should be realized by implementing the recommendations detailed in this guide.
Business objectives
- Enhance security: Ensure asset, resource, and data security by centralizing and managing access to sensitive information, reducing the risk of breaches and unauthorized access.
- Regulatory compliance: Achieve compliance with industry regulations and standards by implementing robust access controls, encryption, and audit trails for sensitive data.
- ISO/IEC 27001: Part of the ISO/IEC 27000 family of standards, ISO/IEC 27001 provides best practice recommendations on information security management, risk management, and adequate control mechanisms.
- NIST SP 800: This is a guideline from the National Institute of Standards and Technology on Digital Identity Guidelines, which covers identity proofing, authentication, and lifecycle management.
- PCI DSS (Payment Card Industry Data Security Standard): This standard mandates protection for cardholder data, which includes strong access controls and encryption measures.
- FIPS 140-2 (Federal Information Processing Standards): This is a U.S. government standard that defines security requirements for cryptographic modules, including those that manage, process, and store cryptographic keys.
- SOC 2 (Service Organization Control 2): Focuses on management of customer data and requires service providers to follow strict guidelines related to security, availability, processing integrity, confidentiality, and privacy.
- CIS (Center for Internet Security) Critical Security Controls: These controls provide best practices for securing IT systems and data. Some controls specifically relate to account management, access controls, and data protection.
- OWASP (Open Web Application Security Project): While not a compliance standard, OWASP provides a list of top security risks, some of which directly relate to the management and protection of credentials and secrets.
- NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection): These standards are specifically for the reliability of the bulk power system in North America, and they include requirements for access controls and managing credentials.
- FedRAMP (Federal Risk and Authorization Management Program): This U.S. government-wide program standardizes security assessment and authorization for cloud products and services. It includes guidelines on managing and securing credentials and secrets.
- Sarbanes-Oxley Act (SOX): This U.S. legislation has implications for IT and data controls, ensuring that financial data is accurate and protected against fraud. Proper management and security of credentials are an integral part of this.
- Operational efficiency: Streamline the management of secrets, credentials, and encryption keys, reducing administrative overhead and minimizing the potential for human error.
- Risk mitigation: Proactively mitigate security risks associated with managing sensitive information, protecting the organization's reputation and minimizing potential financial losses.
- Data governance: Establish consistent policies and controls for data access, enhancing accountability and ensuring that data is used and accessed appropriately.
Note
HIPAA (Health Insurance Portability and Accountability Act): In the context of the U.S. healthcare sector, HIPAA mandates the protection of personal health information, which includes setting strict controls on credentials and access.GDPR (General Data Protection Regulation): Although a data protection law, GDPR has implications for securing personal data, which includes proper credential management and data encryption.
Functional objectives
- Centralized secrets management: Establish a unified repository for managing secrets, automating/simplifying the process of secret rotation, access, and lifecycle management.
- Identity-based Authentication (AuthN) and Access authorization (AuthZ): Implement identity federation and provide fine-grained access controls tied to user identities and roles, ensuring proper authorization and reducing security risks.
- Encryption as a service: Provide a consistent method for encrypting data at rest and in transit, enhancing data security across the organization.
- Audit trails and logging: Generate comprehensive audit logs to track who accessed which data and when, aiding in compliance, troubleshooting, and security investigations.
- High availability: Design a reliable architecture to minimize downtime and ensure system availability, even during hardware failures or maintenance.
Sample project plan
The table itemizes the outcomes of the HVDs to provide project managers with data they can incorporate into their project plans. You can simultaneously execute many of the activities in the following table. Your HashiCorp account team serves as a valuable resource and consulting partner, possessing the experience necessary to provide guidance. They can help you customize this plan to suit your specific and unique requirements.
HashiCorp Validated Design (HVD) adopt stage deliverables
No. | Deliverable | Brief Description | Time to Complete |
---|---|---|---|
People & Process | |||
1 | Vault operating plan | Create detailed plan for adopting Vault (In collaboration with HashiCorp Account Team and Implementation Partners) | 1 Week |
2 | Training/enablement plan | Create a customized training/enablement plan for the organization (in collaboration with HashiCorp Account Team) | 2 Days |
3 | Identify stakeholders & assign roles | Assign roles to various teams & team members | 1 Week |
4 | Business unit (BU) onboarding schedule | Create a schedule for onboarding the 1st set of Business Units / App teams | 2 Weeks |
Prep for 1st Use | |||
5 | Audit Log | Set up audit logging | 2 Days |
6 | Namespace planning/config | Set up initial namespaces, including policies for human users etc. Create a plan for segmenting namespaces for various BU/applications | 2 Days |
7 | OIDC/LDAP Configuration | Configuration authentication for human users | 1 Week |
8 | System Logs/Telemetry/Audit Logs | Set up integration with in-house Log Management tool | 1 Week |
9 | Env Migration | Set up plan/automation to migrate configuration between environments | 1 Week |
Application Authentication | |||
10 | Application Authentication scenarios | Based on the BU onboarding schedule, determine a list of application authentication requirements to establish Vault Auth Methods that need to be configured. | 1 Week |
11 | Application Auth Methods | Configure automation to set up auth methods & policies that can be used by automation to onboard new apps | 2 Weeks |
Static Secret | |||
12 | App Onboarding | Determine how app teams will onboard new apps and secrets | 1 Week |
13 | Secret Migration | Determine how secrets will be migrated between environments | 1 Week |
Visibility & Management | |||
14 | Telemetry Dashboard | Establish dashboards to monitor the health of Vault Enterprise | 1 Week |
15 | Log Management | Create search queries, alerts for important events | 1 Week |
Tip
HashiCorp offers professional services, and has relationships with experienced implementation partners as well. These services can enable customers to quickly ramp up their onboarding of Vault. For more details, please contact your HashiCorp account team.