178 lines
15 KiB
Plaintext
178 lines
15 KiB
Plaintext
---
|
||
layout: docs
|
||
page_title: Vault Integration Program
|
||
description: Guide to partnership integrations and creating plugins for Vault.
|
||
---
|
||
|
||
# Vault Integration Program
|
||
|
||
The HashiCorp Vault Integration Program allows for partners to integrate their products to work with HashiCorp Vault (Open Source or Enterprise versions) or [HashiCorp Cloud Platform](https://cloud.hashicorp.com) (HCP) Vault. Vault covers a relatively large surface area and thereby a large set of possible integrations, some of which require the partner to build a Vault plugin or an integration that results in the partner’s solution working tightly with Vault.
|
||
|
||
Partners integrating their solutions via the Vault Integration Process provide their customers a verified and seamless user experience.
|
||
|
||
This program is intended to be largely a self-service process with links and guidance to information sources, clearly defined steps, and checkpoints.
|
||
|
||
## Types of Vault Integrations
|
||
|
||
Vault is an Identity-based security solution that leverages trusted sources of identity to keep secrets and application data secured with one centralized, audited workflow for tightly controlling access to secrets across applications, systems, and infrastructure while encrypting data both in flight and at rest. For a full description of the current features please refer to the Vault [website](/).
|
||
|
||
Vault has a secure [plugin](/docs/plugins) architecture. Vault’s plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. This means the plugin process does not share the same memory space as Vault and therefore can only access the interfaces and arguments given to it.
|
||
|
||
Vault plugins can be built-in and bundled with the Vault binary, or be external that has to be manually mounted. Built-in plugins are developed by HashiCorp, while external plugins can be developed by HashiCorp, technology partners, or the community. There is a curated collection of all plugins, both built-in and external, located on the [Plugin Portal](/docs/plugin-portal).
|
||
|
||
The diagram below depicts the key Vault integration categories and types.
|
||
|
||
|
||
|
||
Main Vault categories for partners to integrate with include:
|
||
|
||
**Authentication Methods**: Authentication (or Auth) methods are plugin components in Vault that perform authentication and are responsible for assigning identity along with a set of policies to a user. Vault supports multiple auth methods/identity models to better support your business use case. You can find more information about Vault Auth Methods [here](/docs/auth/).
|
||
|
||
**Runtime Integrations**: These types of integrations include integrations developed by partners that work with existing customer deployments of Vault and the partner’s solution.
|
||
|
||
HSM (Hardware Security Module) are specific types of runtime integrations and provide an added level of security and compliance. The HSM communicates with Vault using the PKCS#11 protocol, thereby resulting in the integration to primarily involve verification of the operation of the functionality. You can find more information about Vault's HSM support [here](/docs/enterprise/hsm).
|
||
|
||
-> **Note:** Integrations related Vault’s [storage](/docs/concepts/storage) backend, [auto auth](/docs/agent/autoauth), and [auto unseal](/docs/concepts/seal#auto-unseal) functionality are not encouraged. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for any questions related to this.
|
||
|
||
**Audit/Monitoring & Compliance**: Audit/Monitoring and Compliance are components in Vault that keep a detailed log of all requests and responses to Vault. Because every operation with Vault is an API request/response, the audit log contains every authenticated interaction with Vault, including errors. Vault supports multiple audit devices to support your business use case. You can find more information about Vault Audit Devices [here](/docs/audit/).
|
||
|
||
**Secrets Engines**: Secrets engines are plugin components which store, generate, or encrypt data. Secrets engines are provided with some set of data that perform actions on that data, and then return a result. Some secrets engines store and read data, like encrypted in-memory data structure, and secrets engines connect to other services. Examples of secrets engines include identity modules of Cloud providers like AWS, Azure IAM models, Cloud (LDAP), database or key management. You can find more information about Vault secrets engines [here](/docs/secrets/).
|
||
|
||
### HCP Vault
|
||
|
||
HCP Vault is a managed version of Vault which is operated by HashiCorp to allow customers to quickly get up and running. HCP Vault uses the same binary as self-managed Vault, and offers a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with Vault. Most runtime integrations can be verified with HCP Vault.
|
||
|
||
Sign up for HCP Vault [here](https://portal.cloud.hashicorp.com/) and check out [this](https://learn.hashicorp.com/collections/vault/cloud) learn guide for quickly getting started.
|
||
|
||
### Vault Integration Badges
|
||
|
||
There are two types of badges that partners could receive: Vault Enterprise Verified and HCP Vault Verified badges. Partners will be issued the Vault Enterprise badge for integrations that work with Vault Enterprise features such as namespaces, HSM support, or key management. Partners will be issued the HCP Vault badge once their integration has been verified to work with HCP Vault. The badge(s) would be displayed on their partner page (example: [MongoDB](https://www.hashicorp.com/partners/tech/mongodb#vault) and can also be used on their own website to help provide better visibility and differentiation to customers. The process for verification of these integrations is detailed below.
|
||
|
||
<span style={{display:'block', textAlign:'center'}}>
|
||
<ImageConfig inline height={200} width={200}>
|
||
|
||
|
||
|
||
</ImageConfig>
|
||
<ImageConfig inline height={200} width={200}>
|
||
|
||
|
||
|
||
</ImageConfig>
|
||
</span>
|
||
|
||
## Development Process
|
||
|
||
The Vault integration development process is divided into six steps. By following these steps, Vault integrations can be developed alongside HashiCorp to ensure that the integrations are able to be verified and supported in Vault as quickly as possible. A visual representation of the self-guided steps is depicted below.
|
||
|
||
|
||
|
||
1. Engage: Initial contact between vendor and HashiCorp
|
||
2. Enable: Information and articles to aid with the development of the integration
|
||
3. Develop and Test: Integration development and testing process
|
||
4. Review: HashiCorp verification of integration (iterative process)
|
||
5. Release: Verified integration made available and listed on the HashiCorp website once the HashiCorp technology partnership agreement has been executed
|
||
6. Support: Ongoing maintenance and support of the integration by the partner.
|
||
|
||
### 1. Engage
|
||
|
||
Please begin by providing some basic information about the integration that is being built via a simple [webform](https://docs.google.com/forms/d/e/1FAIpQLSfQL1uj-mL59bd2EyCPI31LT9uvVT-xKyoHAb5FKIwWwwJ1qQ/viewform).
|
||
|
||
This information is recorded and used by HashiCorp to track the integration through various stages. The information is also used to notify the integration developer of any overlapping work, perhaps coming from the community so you may better focus resources.
|
||
|
||
Vault has a large and active community and ecosystem of partners that may have already started working on a similar integration. We'll do our best to connect similar parties to avoid duplicate work.
|
||
|
||
### 2. Enable
|
||
|
||
While not mandatory, HashiCorp encourages partners to sign an MNDA (Mutual Non-Disclosure Agreement) to allow for open dialog and sharing of ideas during the integration process.
|
||
|
||
In an effort to support our self-serve model, we’ve included links to resources, documentation, examples and best practices to guide you through the Vault integration development and testing process.
|
||
|
||
- [Vault Tutorial and Learn Site](https://learn.hashicorp.com/vault)
|
||
- Sample development implemented by a [partner](https://www.hashicorp.com/integrations/venafi/vault/)
|
||
- Example runtime integrations for reference: [F5](https://www.hashicorp.com/integrations/f5/vault), [ServiceNow](https://www.hashicorp.com/integrations/servicenow/vault)
|
||
- [Vault Community Forum](https://discuss.hashicorp.com/c/vault)
|
||
|
||
We encourage partners to closely follow the above guidance. Adopting the same structure and coding patterns helps expedite the review and release cycles.
|
||
|
||
### 3. Develop and Test
|
||
|
||
For our partners who are building runtime integrations with Vault, we encourage them to support multiple [authentication](/docs/auth) methods (e.g. Approle, JWT, K8s) besides tokens. Additionally we encourage them to add as much flexibility when specifying paths for secrets engines. For our partners who want to build a plugin, the only knowledge necessary to write a plugin is basic command-line skills and knowledge of the Go programming language. When writing in Go-Language, HashiCorp has found the integration development process to be straightforward and simple when partners pay close attention and follow the resources by adopting the same structure and coding patterns to help expedite the review and release cycles.
|
||
|
||
Please remember that all integrations should have the appropriate documentation to assist Vault users in configuring the integrations.
|
||
|
||
**Auth Methods**
|
||
|
||
- [Auth Methods documentation](/docs/auth)
|
||
- [Example of how to build, install, and maintain auth method plugins plugin](https://www.hashicorp.com/blog/building-a-vault-secure-plugin)
|
||
- [Sample plugin code](https://github.com/hashicorp/vault-auth-plugin-example)
|
||
|
||
**Runtime Integration**
|
||
|
||
- [Vault Tutorial and Learn Site](https://learn.hashicorp.com/vault)
|
||
- [Auth Methods documentation](/docs/auth)
|
||
- [HSM documentation](/docs/enterprise/hsm)
|
||
- [HSM Configuration information](/docs/configuration/seal/pkcs11)
|
||
|
||
**Audit, Monitoring & Compliance Integration**
|
||
|
||
- [Audit devices documentation](/docs/audit)
|
||
|
||
**Secrets Engine Integration**
|
||
|
||
- [Secret engine documentation](/docs/secrets)
|
||
- [Custom Secrets Engines | Vault - HashiCorp Learn](https://learn.hashicorp.com/collections/vault/custom-secrets-engine)
|
||
|
||
**HCP Vault**
|
||
|
||
The process to spin up a testing instance of HCP Vault is very [straightforward](https://learn.hashicorp.com/tutorials/cloud/get-started-vault). HCP has been designed as a turn-key managed service so configuration is minimal. Furthermore, HashiCorp provides all new users an initial credit which lasts for a couple of months when using the [development](https://cloud.hashicorp.com/pricing/vault) cluster. Used in conjunction with AWS free tier resources, there should be no cost beyond the time spent by the designated tester.
|
||
|
||
There are a couple of items to consider when determining if the integration will work with HCP Vault.
|
||
|
||
- Since HCP Vault is running Vault Enterprise, the integration will need to be aware of [Namespaces](https://learn.hashicorp.com/tutorials/vault/namespaces). This is important as the main namespace in HCP Vault is called 'admin' which is different from the standard ‘root’ namespace in a self managed Vault instance. If the integration currently doesn't support namespaces, then an additional benefit of adding Namespace support iis that this will also enable it to work with all self managed Vault Enterprise installations.
|
||
- HCP Vault is currently only deployed on AWS and so the partner’s application should be able to be deployed or run in AWS. This is vital so that HCP Vault is able to communicate with the application using a [private peered](https://learn.hashicorp.com/tutorials/cloud/amazon-peering-hcp) connection via a [HashiCorp Virtual Network](https://cloud.hashicorp.com/docs/hcp/network).
|
||
|
||
Additional resources:
|
||
|
||
- [HCP Sign up](https://cloud.hashicorp.com/docs/hcp/network)
|
||
- [Namespaces - Vault Enterprise](/docs/enterprise/namespaces)
|
||
- [Create a Vault Cluster on HCP | HashiCorp Learn](https://learn.hashicorp.com/tutorials/cloud/get-started-vault)
|
||
|
||
### 4. Review
|
||
|
||
During the review process, HashiCorp will provide feedback on the newly developed integration for both Vault and HCP Vault. This is an important step to allow HashiCorp to review and verify your Vault integration. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for verification.
|
||
|
||
The review process can take some time to complete and may require some iterations through the code to address any problems identified by the HashiCorp team.
|
||
|
||
Once the integration has been verified, the partner is requested to sign the HashiCorp Technology Partner Agreement to have their integration listed on the HashiCorp website upon release.
|
||
|
||
### 5. Release
|
||
|
||
At this stage, it is expected that the integration is fully complete, the necessary documentation has been written, and HashiCorp has reviewed the integration.
|
||
|
||
For Auth or Secret Engine plugins specifically, once the plugin has been validated by HashiCorp, it is recommended the plugin be hosted on Github so it can more easily be downloaded and installed within Vault. We also encourage partners to list their plugin on the [Vault Plugin Portal](/docs/plugin-portal). This is in addition to the listing of the plugin on the technology partners’ dedicated HashiCorp partner page. To have the plugin listed on the portal page, please do a pull request via the “edit in GitHub” link on the bottom of the page and add the plugin in the partner section.
|
||
|
||
For HCP Vault validations, the partner will be issued an HCP Vault Verified badge and will have this displayed on their partner page.
|
||
|
||
### 6. Support
|
||
|
||
At HashiCorp, we view the release step as the beginning of the journey. Getting the integration built is just the first step in enabling users to leverage it against their infrastructure. Once development is completed, on-going effort is required to support the developed integration and address any issues in a timely manner.
|
||
|
||
The expectation from the partner is to create a mechanism to track and resolve all critical issues within 48 hours, and all other issues within 5 business days. This is a requirement given the critical nature of Vault to customers’ operations. Partners who choose to not support their integration will not be considered a verified integration and cannot be listed on the website.
|
||
|
||
## Checklist
|
||
|
||
Below is a checklist of steps that should be followed during the Vault integration development process. This reiterates the steps described above.
|
||
|
||
- Fill out the [Vault Integration webform](https://docs.google.com/forms/d/e/1FAIpQLSfQL1uj-mL59bd2EyCPI31LT9uvVT-xKyoHAb5FKIwWwwJ1qQ/viewform).
|
||
- Develop and test Vault integration along with the documentation, send to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com), to schedule an initial review.
|
||
- Address review feedback and finalize the development process.
|
||
- Provide HashiCorp with credentials for underlying infrastructure for test purposes.
|
||
- Demo the integration.
|
||
- Execute HashiCorp Partner Agreement Documents, review logo guidelines, partner listing and more.
|
||
- Plan to continue supporting the integration with additional functionality and responding to customer issues
|
||
|
||
## Contact Us
|
||
|
||
For any questions or feedback, please contact us at: [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com)
|