consul Installation CPU Profiles pprof A Profile is a collection of stack traces showing the call sequences that led to instances of a particular event such as allocation It does not track time spent sleeping or waiting for I O Every 10ms the CPU profiler interrupts a thread in the program and records the stack traces of running goroutines

Answer:
# pprof

> A Profile is a collection of stack traces showing the call sequences that led to instances of a particular event, such as allocation.

## Installation
`go install github.com/google/pprof@latest`

### CPU Profiles
* Every 10ms the CPU profiler interrupts a thread in the program and records the stack traces of **running** goroutines.
	* It does **not** track time spent sleeping or waiting for I/O.
* The duration of a sample is assumed to be 10ms, so the seconds spent in a function is calculated as: `(num_samples * 10ms)/1000`

### Heap Profiles
*  Aims to record the stack trace for every 512KB allocated, at the point of the allocation.
	* Tracks allocations and when profiled allocations are freed. With both of these data points pprof can calculate allocations and memory in use.
* `alloc_objects` and `alloc_space` refer to allocations since the start of the profiling period.
	* Helpful for tracking functions that produce a lot of allocations.
* `inuse_objects` and `inuse_space` refers to allocations that have not been freed.
	* `inuse_objects = allocations - frees`
	* Helpful for tracking sources of high memory usage.
	* May not line up with OS reported memory usage! The profiler only tracks heap memory usage, and there are also cases where the Go GC will not release free heap memory to the OS.
* When allocations are made, the heap sampler makes a decision about whether to sample the allocation or not. If it decides to sample it, it records the stack trace, counts the allocation, and counts the number of bytes allocated.
	* When an object's memory is freed, the heap profiler checks whether that allocation was sampled, and if it was, it counts the bytes freed.

### Goroutine Profiles
* Shows the number of times each stack trace was seen across goroutines.

## Common commands
* Open a profile in the terminal:
`go tool pprof profile.prof`
`go tool pprof heap.prof`
`go tool pprof goroutine.prof`

* Open a profile in a web browser:
`go tool pprof -http=:8080 profile.prof`

* If the correct source isn't detected automatically, specify the location of the source associated with the profile:
`go tool pprof -http=:9090 -source_path=/Users/freddy/go/src/github.com/hashicorp/consul-enterprise profile.prof`

Useful in annotated `Source` view which shows time on a line-by-line basis.

**Important:** Ensure that the source code matches the version of the binary! The source view relies on line numbers for its annotations.

* Compare two profiles:
`go tool pprof -http=:8080 -base before/profile.prof after/profile.prof`
This comparison will subtract the `-base` profile from the given profile. In this case, "before" is subtracted from "after".

* Useful commands when profile is opened in terminal:
	* `top` lists the top 10 nodes by value
	* `list <function regex>` lists the top matches to the pattern

## Graph view
* **Node Values:**
	* Package
	* Function
	* Flat value: the value in the function itself.
	* Cumulative value: the sum of the flat value and all its descendants.
	* Percentage of flat and cumulative values relative to total samples. Total sample time is visible with `top` command in terminal view.

Example:
```
func foo(){
    a()                                 // step 1 takes 1s
    do something directly.              // step 2 takes 3s
    b()                                 // step 3 takes 1s
}
```

`flat` is the time spent on step 2 (3s),  while `cum` is time spent on steps 1 to 3.

* **Path Value**
	* The cumulative value of the following node.

* **Node Color**:
  * large positive cumulative values are red.
  * cumulative values close to zero are grey.
  * large negative cumulative values are green; negative values are most likely to appear during profile comparison.

* **Node Font Size**:
  * larger font size means larger absolute flat values.
  * smaller font size means smaller absolute flat values.

* **Edge Weight**:
  * thicker edges indicate more resources were used along that path.
  * thinner edges indicate fewer resources were used along that path.

* **Edge Color**:
  * large positive values are red.
  * large negative values are green.
  * values close to zero are grey.

* **Dashed Edges**: some locations between the two connected locations were removed.

* **Solid Edges**: one location directly calls the other.

* **"(inline)" Edge Marker**: the call has been inlined into the caller. More on inlining: [Inlining optimisations in Go | Dave Cheney](https://dave.cheney.net/2020/04/25/inlining-optimisations-in-go)

Example graph:
![Nodes](./pprof_cpu_nodes.png)

* 20.11s is spent doing direct work in `(*Store).Services()`
* 186.88s is spent in this function **and** its descendants
* `(*Store).Services()` has both large `flat` and `cumulative` values, so the font is large and the box is red.
* The edges to `mapassign_faststr` and `(radixIterator).Next()` are solid and red because these are direct calls with large positive values.

## Flame graph view
A collection of stack traces, where each stack is a column of boxes, and each box represents a function.

Functions at the top of the flame graph are parents of functions below.

The width of each box is proportional to the number of times it was observed during sampling.

Mouse-over boxes shows `cum` value and percentage, while clicking on boxes lets you zoom into their stack traces.

### Note
* The background color is **not** significant.
* Sibling boxes are not necessarily in chronological order.

## References:
* [Diagnostics - The Go Programming Language](https://go.dev/doc/diagnostics)
* [Profiling Go programs with pprof](https://jvns.ca/blog/2017/09/24/profiling-go-with-pprof/)
* [pprof/README.md](https://github.com/google/pprof/blob/master/doc/README.md)
* [GitHub - DataDog/go-profiler-notes: felixge's notes on the various go profiling methods that are available.](https://github.com/DataDog/go-profiler-notes)
* [The Flame Graph - ACM Queue](https://queue.acm.org/detail.cfm?id=2927301)
* [High Performance Go Workshop](https://dave.cheney.net/high-performance-go-workshop/dotgo-paris.html#pprof)
* [Pprof and golang - how to interpret a results?](https://stackoverflow.com/a/56882137

pprof    A Profile is a collection of stack traces showing the call sequences that led to instances of a particular event  such as allocation      Installation  go install github com google pprof latest       CPU Profiles   Every 10ms the CPU profiler interrupts a thread in the program and records the stack traces of   running   goroutines      It does   not   track time spent sleeping or waiting for I O    The duration of a sample is assumed to be 10ms  so the seconds spent in a function is calculated as    num samples   10ms  1000       Heap Profiles    Aims to record the stack trace for every 512KB allocated  at the point of the allocation     Tracks allocations and when profiled allocations are freed  With both of these data points pprof can calculate allocations and memory in use     alloc objects  and  alloc space  refer to allocations since the start of the profiling period     Helpful for tracking functions that produce a lot of allocations     inuse objects  and  inuse space  refers to allocations that have not been freed      inuse objects   allocations   frees     Helpful for tracking sources of high memory usage     May not line up with OS reported memory usage  The profiler only tracks heap memory usage  and there are also cases where the Go GC will not release free heap memory to the OS     When allocations are made  the heap sampler makes a decision about whether to sample the allocation or not  If it decides to sample it  it records the stack trace  counts the allocation  and counts the number of bytes allocated     When an object s memory is freed  the heap profiler checks whether that allocation was sampled  and if it was  it counts the bytes freed        Goroutine Profiles   Shows the number of times each stack trace was seen across goroutines      Common commands   Open a profile in the terminal   go tool pprof profile prof   go tool pprof heap prof   go tool pprof goroutine prof     Open a profile in a web browser   go tool pprof  http  8080 profile prof     If the correct source isn t detected automatically  specify the location of the source associated with the profile   go tool pprof  http  9090  source path  Users freddy go src github com hashicorp consul enterprise profile prof   Useful in annotated  Source  view which shows time on a line by line basis     Important    Ensure that the source code matches the version of the binary  The source view relies on line numbers for its annotations     Compare two profiles   go tool pprof  http  8080  base before profile prof after profile prof  This comparison will subtract the   base  profile from the given profile  In this case   before  is subtracted from  after       Useful commands when profile is opened in terminal      top  lists the top 10 nodes by value     list  function regex   lists the top matches to the pattern     Graph view     Node Values       Package    Function    Flat value  the value in the function itself     Cumulative value  the sum of the flat value and all its descendants     Percentage of flat and cumulative values relative to total samples  Total sample time is visible with  top  command in terminal view   Example      func foo        a                                      step 1 takes 1s     do something directly                  step 2 takes 3s     b                                      step 3 takes 1s         flat  is the time spent on step 2  3s    while  cum  is time spent on steps 1 to 3        Path Value      The cumulative value of the following node       Node Color        large positive cumulative values are red      cumulative values close to zero are grey      large negative cumulative values are green  negative values are most likely to appear during profile comparison       Node Font Size        larger font size means larger absolute flat values      smaller font size means smaller absolute flat values        Edge Weight        thicker edges indicate more resources were used along that path      thinner edges indicate fewer resources were used along that path       Edge Color        large positive values are red      large negative values are green      values close to zero are grey       Dashed Edges    some locations between the two connected locations were removed         Solid Edges    one location directly calls the other         inline   Edge Marker    the call has been inlined into the caller  More on inlining   Inlining optimisations in Go   Dave Cheney  https   dave cheney net 2020 04 25 inlining optimisations in go   Example graph    Nodes    pprof cpu nodes png     20 11s is spent doing direct work in    Store  Services      186 88s is spent in this function   and   its descendants      Store  Services    has both large  flat  and  cumulative  values  so the font is large and the box is red    The edges to  mapassign faststr  and   radixIterator  Next    are solid and red because these are direct calls with large positive values        Flame graph view A collection of stack traces  where each stack is a column of boxes  and each box represents a function   Functions at the top of the flame graph are parents of functions below   The width of each box is proportional to the number of times it was observed during sampling    Mouse over boxes shows  cum  value and percentage  while clicking on boxes lets you zoom into their stack traces       Note   The background color is   not   significant    Sibling boxes are not necessarily in chronological order       References     Diagnostics   The Go Programming Language  https   go dev doc diagnostics     Profiling Go programs with pprof  https   jvns ca blog 2017 09 24 profiling go with pprof      pprof README md  https   github com google pprof blob master doc README md      GitHub   DataDog go profiler notes  felixge s notes on the various go profiling methods that are available   https   github com DataDog go profiler notes     The Flame Graph   ACM Queue  https   queue acm org detail cfm id 2927301     High Performance Go Workshop  https   dave cheney net high performance go workshop dotgo paris html pprof     Pprof and golang   how to interpret a results   https   stackoverflow com a 56882137


vault Instead of starting your Vault server manually from the command line you can Run Vault as a service layout docs page title Run Vault as a service Configure and deploy Vault as a service for Linux or Windows

Answer:
---
layout: docs
page_title: Run Vault as a service
description: >-
  Configure and deploy Vault as a service for Linux or Windows.
---

# Run Vault as a service

Instead of starting your Vault server manually from the command line, you can
configure a service to start Vault automatically.

## Before you start

- **You must install Vault**. You can [use a package manager](/vault/install)
  or [install a binary manually](/vault/docs/install/install-binary).

## Step 1: Create a new service

<Tabs>

<Tab heading="Linux shell" group="nix">

<Highlight title="Example tested on Ubuntu 22.04">

   The following service definition is a simpler version of the `vault.service`
   example in the Vault GitHub repo: [vault/.release/linux/package/usr/lib/systemd/system/vault.service](https://github.com/hashicorp/vault/blob/main/.release/linux/package/usr/lib/systemd/system/vault.service)

</Highlight>

1. Set the `VAULT_CONFIG` environment variable to your Vault configuration
   directory. The default configuration directory is `/etc/vault.d`:

   ```shell-session
   $ VAULT_CONFIG=/etc/vault.d
   ```

1. Confirm the path to your Vault binary:
   ```
   $ VAULT_BINARY=$(which vault)
   ```

1. Create a `systemd` service called `vault.service` that uses the Vault
   binary:

   ```shell-session
   $ sudo tee /lib/systemd/system/vault.service <<EOF
   [Unit]
   Description="HashiCorp Vault"
   Documentation="https://developer.hashicorp.com/vault/docs"
   ConditionFileNotEmpty="${VAULT_CONFIG}/vault.hcl"

   [Service]
   User=vault
   Group=vault
   SecureBits=keep-caps
   AmbientCapabilities=CAP_IPC_LOCK
   CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
   NoNewPrivileges=yes
   ExecStart=${VAULT_BINARY} server -config=${VAULT_CONFIG}/vault.hcl
   ExecReload=/bin/kill --signal HUP
   KillMode=process
   KillSignal=SIGINT

   [Install]
   WantedBy=multi-user.target
   EOF
   ```

1. Change the permissions on `/lib/systemd/system/vault.service` to `644`:

   ```shell-session
   $ sudo chmod 644 /lib/systemd/system/vault.service
   ```

</Tab>

<Tab heading="Powershell" group="ps">

The Windows binary for Vault does not support the Windows Service Application
API. To run Vault as a service, you must use a Windows service wrapper. You can
use whatever wrapper is appropriate for your environment, but the easiest we
have found is `nssm`.

1. Download and install [`nssm`](https://nssm.cc/) manually or install the
   package with [Chocolatey](https://chocolatey.org/):

   ```powershell
   choco install nssm
   ```

1. Set a `VAULT_HOME` environment variable to your preferred Vault home
   directory. For example, `c:\Program Files\Vault`:

   ```powershell
   $env:VAULT_HOME = "${env:ProgramFiles}\Vault"
   ```

1. Use `nssm` to create a new Windows service:
   ```powershell
   nssm install MS_VAULT "${env:VAULT_HOME}\vault.exe"
   ```

1. Set the working directory for your Vault installation:
   ```powershell
   nssm set MS_VAULT AppDirectory "${env:VAULT_HOME}" ; `
   nssm set MS_VAULT AppParameters "server -config Config\vault.hcl"
   ```

1. Define the runtime parameters for Vault, including the
   `-config` flag with the relative path to your Vault configuration file, for
   example `Config\vault.hcl`:
   ```powershell
   nssm set MS_VAULT AppDirectory "${env:VAULT_HOME}" ; `
   nssm set MS_VAULT AppParameters "server -config Config\vault.hcl"
   ```

1. Set the display name and description for the "Services"
   management console:
   ```powershell
   nssm set MS_VAULT DisplayName "Vault Service" ; `
   nssm set MS_VAULT Description "Vault server running as a service"
   ```

1. Set the startup type for your service. We recommend setting startup to
   "Manual" until you confirm the service is working as expected:
   ```powershell
   nssm set MS_VAULT Start SERVICE_DEMAND_START
   ```

1. Configure the service to pipe information from `stdout` and `stderr` to files
   under your logging directory, for example `${env:VAULT_HOME}\Logs`:
   ```powershell
   nssm set MS_VAULT AppStdout "${env:VAULT_HOME}\Logs\vault-stdout.log" ; `
   nssm set MS_VAULT AppStderr "${env:VAULT_HOME}\Logs\vault-error.log"
   ```

1. Optionally, you can use the `AppEnvironmentExtra` parameter to set relevant
   variables for the service environment. For example, to set the `VAULT_ADDR`
   environment variable:

   ```powershell
   nssm set MS_VAULT AppEnvironmentExtra `$env:VAULT_ADDR=https://localhost:8200
   ```

1. Confirm your Vault service settings with `nssm`:

   ```powershell
   nssm dump MS_VAULT | Foreach {$_ -replace '.+nssm\.exe ',''}
   ```

</Tab>

</Tabs>

## Step 2: Start the new service

<Tabs>

<Tab heading="Linux shell" group="nix">

1. Reload the `systemd` configuration:

   ```shell-session
   $ sudo systemctl daemon-reload
   ```

1. Start the Vault service:

   ```shell-session
   $ sudo systemctl start vault.service
   ```

1. Verify the service status:

   ```shell-session
      $ systemctl status vault.service

      vault.service - "HashiCorp Vault"
         Loaded: loaded (/lib/systemd/system/vault.service; disabled; vendor preset: enabled)
         Active: active (running) since Thu 2024-09-05 13:58:45 UTC; 4s ago
            Docs: https://developer.hashicorp.com/vault/docs
         Main PID: 3145 (vault)
            Tasks: 8 (limit: 2241)
         Memory: 23.6M
            CPU: 200ms
         CGroup: /system.slice/vault.service
                  └─3145 /usr/bin/vault server -config=/etc/vault.d/vault.hcl
   ```

</Tab>

<Tab heading="Powershell" group="ps">

<Highlight title="Use Powershell commands or wrapper commands to manage your service">

   Once you create the service, you can control it using standard `*-Service`
   cmdlets **or** the relevant commands for the associated wrapper. For example,
   to control the service with `nssm` use `nssm start MS_VAULT`.

</Highlight>

1. Start the Vault service::
   ```powershell
   Start-Service -Name MS_VAULT
   ```

1. Confirm service status:

   ```powershell
   Get-Service -Name MS_VAULT

   Status   Name               DisplayName
   ------   ----               -----------
   Running  MS_VAULT           Vault Service
   ```

</Tab>

</Tabs>

## Step 3: Verify the service is running

To confirm the service is running and your Vault service is available, open the
Vault GUI in a browser at the default address:
[http://localhost:8200](http://localhost:8200)

## Related tutorials

The following tutorials provide additional guidance for installing Vault and
production cluster deployment:

- [Day One Preparation](/vault/tutorials/day-one-raft)
- [Recommended Patterns](/vault/tutorials/recommended-patterns)

layout  docs page title  Run Vault as a service description       Configure and deploy Vault as a service for Linux or Windows         Run Vault as a service  Instead of starting your Vault server manually from the command line  you can configure a service to start Vault automatically      Before you start       You must install Vault    You can  use a package manager   vault install    or  install a binary manually   vault docs install install binary        Step 1  Create a new service   Tabs    Tab heading  Linux shell  group  nix     Highlight title  Example tested on Ubuntu 22 04       The following service definition is a simpler version of the  vault service     example in the Vault GitHub repo   vault  release linux package usr lib systemd system vault service  https   github com hashicorp vault blob main  release linux package usr lib systemd system vault service        Highlight   1  Set the  VAULT CONFIG  environment variable to your Vault configuration    directory  The default configuration directory is   etc vault d          shell session      VAULT CONFIG  etc vault d         1  Confirm the path to your Vault binary              VAULT BINARY   which vault             1  Create a  systemd  service called  vault service  that uses the Vault    binary         shell session      sudo tee  lib systemd system vault service   EOF     Unit     Description  HashiCorp Vault     Documentation  https   developer hashicorp com vault docs     ConditionFileNotEmpty    VAULT CONFIG  vault hcl       Service     User vault    Group vault    SecureBits keep caps    AmbientCapabilities CAP IPC LOCK    CapabilityBoundingSet CAP SYSLOG CAP IPC LOCK    NoNewPrivileges yes    ExecStart   VAULT BINARY  server  config   VAULT CONFIG  vault hcl    ExecReload  bin kill   signal HUP    KillMode process    KillSignal SIGINT      Install     WantedBy multi user target    EOF         1  Change the permissions on   lib systemd system vault service  to  644          shell session      sudo chmod 644  lib systemd system vault service           Tab    Tab heading  Powershell  group  ps    The Windows binary for Vault does not support the Windows Service Application API  To run Vault as a service  you must use a Windows service wrapper  You can use whatever wrapper is appropriate for your environment  but the easiest we have found is  nssm    1  Download and install   nssm   https   nssm cc   manually or install the    package with  Chocolatey  https   chocolatey org           powershell    choco install nssm         1  Set a  VAULT HOME  environment variable to your preferred Vault home    directory  For example   c  Program Files Vault          powershell     env VAULT HOME      env ProgramFiles  Vault          1  Use  nssm  to create a new Windows service        powershell    nssm install MS VAULT    env VAULT HOME  vault exe          1  Set the working directory for your Vault installation        powershell    nssm set MS VAULT AppDirectory    env VAULT HOME          nssm set MS VAULT AppParameters  server  config Config vault hcl          1  Define the runtime parameters for Vault  including the      config  flag with the relative path to your Vault configuration file  for    example  Config vault hcl         powershell    nssm set MS VAULT AppDirectory    env VAULT HOME          nssm set MS VAULT AppParameters  server  config Config vault hcl          1  Set the display name and description for the  Services     management console        powershell    nssm set MS VAULT DisplayName  Vault Service         nssm set MS VAULT Description  Vault server running as a service          1  Set the startup type for your service  We recommend setting startup to     Manual  until you confirm the service is working as expected        powershell    nssm set MS VAULT Start SERVICE DEMAND START         1  Configure the service to pipe information from  stdout  and  stderr  to files    under your logging directory  for example    env VAULT HOME  Logs         powershell    nssm set MS VAULT AppStdout    env VAULT HOME  Logs vault stdout log         nssm set MS VAULT AppStderr    env VAULT HOME  Logs vault error log          1  Optionally  you can use the  AppEnvironmentExtra  parameter to set relevant    variables for the service environment  For example  to set the  VAULT ADDR     environment variable         powershell    nssm set MS VAULT AppEnvironmentExtra   env VAULT ADDR https   localhost 8200         1  Confirm your Vault service settings with  nssm          powershell    nssm dump MS VAULT   Foreach      replace    nssm  exe                 Tab     Tabs      Step 2  Start the new service   Tabs    Tab heading  Linux shell  group  nix    1  Reload the  systemd  configuration         shell session      sudo systemctl daemon reload         1  Start the Vault service         shell session      sudo systemctl start vault service         1  Verify the service status         shell session         systemctl status vault service        vault service    HashiCorp Vault           Loaded  loaded   lib systemd system vault service  disabled  vendor preset  enabled           Active  active  running  since Thu 2024 09 05 13 58 45 UTC  4s ago             Docs  https   developer hashicorp com vault docs          Main PID  3145  vault              Tasks  8  limit  2241           Memory  23 6M             CPU  200ms          CGroup   system slice vault service                     3145  usr bin vault server  config  etc vault d vault hcl           Tab    Tab heading  Powershell  group  ps     Highlight title  Use Powershell commands or wrapper commands to manage your service       Once you create the service  you can control it using standard    Service     cmdlets   or   the relevant commands for the associated wrapper  For example     to control the service with  nssm  use  nssm start MS VAULT      Highlight   1  Start the Vault service         powershell    Start Service  Name MS VAULT         1  Confirm service status         powershell    Get Service  Name MS VAULT     Status   Name               DisplayName                                               Running  MS VAULT           Vault Service           Tab     Tabs      Step 3  Verify the service is running  To confirm the service is running and your Vault service is available  open the Vault GUI in a browser at the default address   http   localhost 8200  http   localhost 8200      Related tutorials  The following tutorials provide additional guidance for installing Vault and production cluster deployment      Day One Preparation   vault tutorials day one raft     Recommended Patterns   vault tutorials recommended patterns


vault Guide to partnership integrations and creating plugins for Vault Vault integration program page title Vault Integration Program layout docs 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

Answer:
---
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](/).

There are two main types of integrations with Vault. The first is Runtime Integrations which use Vault as part of a workflow. Many partners have integrations that use existing Vault deployments to retrieve various types of secrets for use in a partner’s application or platform. The use cases can range from Vault storing and providing secrets, issuing or managing PKI certificates or acting as an external key management system.

The second type is where a partner develops a custom plugin. Vault has a secure [plugin](/vault/docs/plugins) architecture. Vault’s plugins are completely separate, standalone applications that Vault executes and communicates with over RPC.

Plugins can be broken into two categories, Secrets Engines and Auth Methods. They can be built-in and bundled with the Vault binary, or be external that has to be manually registered. 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 [Vault Integrations](/vault/integrations) page.

The diagram below depicts the key Vault integration categories and types.

![Integration Categories](/img/integration-program-vaulteco.png)

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 and partners can build a plugin that allows Vault to authenticate against the partners’ platform. You can find more information about Vault Auth Methods [here](/vault/docs/auth/).

**Runtime Integrations**: These types of integrations include integrations developed by partners that work with existing deployments of Vault and the partner’s product as part of the customer's identity/security workflow.

Oftentimes these integrations involve modifying a partner’s product to become “Vault aware”. There are two main components that need to be considered for this type of integration:
1. How is the application going to authenticate itself to Vault?
1. Support of Namespaces

There are many ways for an application to authenticate itself to Vault (see [Auth Methods](/vault/docs/auth/)), but we recommend partners use one of the following methods: [AppRole](/vault/docs/auth/approle), [JWT / OIDC](/vault/docs/auth/jwt), [TLS Certificates](/vault/docs/auth/cert) or [Username / Password](/vault/docs/auth/userpass). For an integration to be verified as production ready by HashiCorp, there needs to be at least one other Auth method supported besides [Token](/vault/docs/auth/token). Token is not recommended for use in production since it involves creating a manual long lived token (which is against best practice and poses a security risk). Using one of the above mentioned auth methods automatically creates short lived tokens and eliminates the need to manually generate a new token on a regular basis.

As the number of customers using Vault Enterprise increases, partners are encouraged to support [Namespaces](/vault/tutorials/enterprise/namespaces). By supporting Namespaces, there is an additional benefit that an integration should be able to work with HCP Vault Dedicated.

HSM (Hardware Security Module) are specific types of runtime integrations and can be configured to work with new or existing Vault deployments. They 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](/vault/docs/enterprise/hsm). A list of HSMs that have been verified to work with Vault is shown in our [interoperability matrix](/vault/docs/interoperability-matrix).

**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](/vault/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 take some action on that data, and then return a result. Some secrets engines store and read data, like encrypted in-memory data structure, other 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 certificate management. You can find more information about Vault Secrets Engines [here](/vault/docs/secrets/).

-> **Note:** Integrations related Vault’s [storage](/vault/docs/concepts/storage) backend, [auto auth](/vault/docs/agent-and-proxy/autoauth), and [auto unseal](/vault/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.

### HCP Vault Dedicated

HCP Vault Dedicated is a managed version of Vault which is operated by HashiCorp to allow customers to quickly get up and running. HCP Vault Dedicated uses the same binary as self-managed Vault Enterprise, and offers a consistent user experience. You can use the same Vault clients to communicate with HCP Vault Dedicated as you use to communicate with Vault. Most runtime integrations can be verified with HCP Vault Dedicated.

Sign up for HCP Vault Dedicated [here](https://portal.cloud.hashicorp.com/) and check out [this](/vault/tutorials/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 Dedicated badge once their integration has been verified to work with HCP Vault Dedicated. 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=>
<ImageConfig inline height={200} width={200}>

![Vault Enterprise Badge](/img/VaultEnterprise_badge.png)

</ImageConfig>
<ImageConfig inline height={200} width={200}>

![HCP Vault Dedicated](/img/HCPV_badge.png)

</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.

![Development Process](/img/integration-program-devprocess.png)

1. Engage: Initial contact between vendor and HashiCorp
1. Enable: Information and articles to aid with the development of the integration
1. Develop and Test: Integration development and testing process
1. Review: HashiCorp verification of integration (iterative process)
1. Release: Verified integration made available and listed on the HashiCorp website once the HashiCorp technology partnership agreement has been executed
1. 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](/vault/tutorials)
- 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](/vault/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](/vault/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](/vault/tutorials)
- [Auth Methods documentation](/vault/docs/auth)
- [HSM documentation](/vault/docs/enterprise/hsm)
- [HSM Configuration information](/vault/docs/configuration/seal/pkcs11)

**Audit, Monitoring & Compliance Integration**

- [Audit devices documentation](/vault/docs/audit)

**Secrets Engine Integration**

- [Secret engine documentation](/vault/docs/secrets)
- [Custom Secrets Engines | Vault - HashiCorp Learn](/vault/tutorials/custom-secrets-engine)

**HCP Vault Dedicated**

The process to spin up a testing instance of HCP Vault Dedicated is very [straightforward](/vault/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/products/vault/pricing) 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 Dedicated.

- Since HCP Vault Dedicated is running Vault Enterprise, the integration will need to be aware of [Namespaces](/vault/tutorials/enterprise/namespaces). This is important as the main namespace in HCP Vault Dedicated 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 Dedicated 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 Dedicated is able to communicate with the application using a [private peered](/hcp/docs/hcp/network/hvn-aws/hvn-peering) connection via a [HashiCorp Virtual Network](/hcp/docs/hcp/network).

Additional resources:

- [HCP Sign up](/hcp/docs/hcp/network)
- [Namespaces - Vault Enterprise](/vault/docs/enterprise/namespaces)
- [Create a Vault Cluster on HCP | HashiCorp Learn](/vault/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 Dedicated. 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 verified 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 Integrations](/vault/integrations) page. 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 Dedicated verifications, 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)

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       There are two main types of integrations with Vault  The first is Runtime Integrations which use Vault as part of a workflow  Many partners have integrations that use existing Vault deployments to retrieve various types of secrets for use in a partner s application or platform  The use cases can range from Vault storing and providing secrets  issuing or managing PKI certificates or acting as an external key management system   The second type is where a partner develops a custom plugin  Vault has a secure  plugin   vault docs plugins  architecture  Vault s plugins are completely separate  standalone applications that Vault executes and communicates with over RPC   Plugins can be broken into two categories  Secrets Engines and Auth Methods  They can be built in and bundled with the Vault binary  or be external that has to be manually registered  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  Vault Integrations   vault integrations  page   The diagram below depicts the key Vault integration categories and types     Integration Categories   img integration program vaulteco png   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 and partners can build a plugin that allows Vault to authenticate against the partners  platform  You can find more information about Vault Auth Methods  here   vault docs auth       Runtime Integrations    These types of integrations include integrations developed by partners that work with existing deployments of Vault and the partner s product as part of the customer s identity security workflow   Oftentimes these integrations involve modifying a partner s product to become  Vault aware   There are two main components that need to be considered for this type of integration  1  How is the application going to authenticate itself to Vault  1  Support of Namespaces  There are many ways for an application to authenticate itself to Vault  see  Auth Methods   vault docs auth     but we recommend partners use one of the following methods   AppRole   vault docs auth approle    JWT   OIDC   vault docs auth jwt    TLS Certificates   vault docs auth cert  or  Username   Password   vault docs auth userpass   For an integration to be verified as production ready by HashiCorp  there needs to be at least one other Auth method supported besides  Token   vault docs auth token   Token is not recommended for use in production since it involves creating a manual long lived token  which is against best practice and poses a security risk   Using one of the above mentioned auth methods automatically creates short lived tokens and eliminates the need to manually generate a new token on a regular basis   As the number of customers using Vault Enterprise increases  partners are encouraged to support  Namespaces   vault tutorials enterprise namespaces   By supporting Namespaces  there is an additional benefit that an integration should be able to work with HCP Vault Dedicated   HSM  Hardware Security Module  are specific types of runtime integrations and can be configured to work with new or existing Vault deployments  They 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   vault docs enterprise hsm   A list of HSMs that have been verified to work with Vault is shown in our  interoperability matrix   vault docs interoperability matrix      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   vault 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 take some action on that data  and then return a result  Some secrets engines store and read data  like encrypted in memory data structure  other 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 certificate management  You can find more information about Vault Secrets Engines  here   vault docs secrets          Note    Integrations related Vault s  storage   vault docs concepts storage  backend   auto auth   vault docs agent and proxy autoauth   and  auto unseal   vault 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       HCP Vault Dedicated  HCP Vault Dedicated is a managed version of Vault which is operated by HashiCorp to allow customers to quickly get up and running  HCP Vault Dedicated uses the same binary as self managed Vault Enterprise  and offers a consistent user experience  You can use the same Vault clients to communicate with HCP Vault Dedicated as you use to communicate with Vault  Most runtime integrations can be verified with HCP Vault Dedicated   Sign up for HCP Vault Dedicated  here  https   portal cloud hashicorp com   and check out  this   vault tutorials 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 Dedicated badge once their integration has been verified to work with HCP Vault Dedicated  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    ImageConfig inline height  200  width  200      Vault Enterprise Badge   img VaultEnterprise badge png     ImageConfig   ImageConfig inline height  200  width  200      HCP Vault Dedicated   img HCPV badge png     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     Development Process   img integration program devprocess png   1  Engage  Initial contact between vendor and HashiCorp 1  Enable  Information and articles to aid with the development of the integration 1  Develop and Test  Integration development and testing process 1  Review  HashiCorp verification of integration  iterative process  1  Release  Verified integration made available and listed on the HashiCorp website once the HashiCorp technology partnership agreement has been executed 1  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   vault tutorials    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   vault 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   vault 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   vault tutorials     Auth Methods documentation   vault docs auth     HSM documentation   vault docs enterprise hsm     HSM Configuration information   vault docs configuration seal pkcs11     Audit  Monitoring   Compliance Integration       Audit devices documentation   vault docs audit     Secrets Engine Integration       Secret engine documentation   vault docs secrets     Custom Secrets Engines   Vault   HashiCorp Learn   vault tutorials custom secrets engine     HCP Vault Dedicated    The process to spin up a testing instance of HCP Vault Dedicated is very  straightforward   vault 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 products vault pricing  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 Dedicated     Since HCP Vault Dedicated is running Vault Enterprise  the integration will need to be aware of  Namespaces   vault tutorials enterprise namespaces   This is important as the main namespace in HCP Vault Dedicated 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 Dedicated 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 Dedicated is able to communicate with the application using a  private peered   hcp docs hcp network hvn aws hvn peering  connection via a  HashiCorp Virtual Network   hcp docs hcp network    Additional resources      HCP Sign up   hcp docs hcp network     Namespaces   Vault Enterprise   vault docs enterprise namespaces     Create a Vault Cluster on HCP   HashiCorp Learn   vault 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 Dedicated  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 verified 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 Integrations   vault integrations  page  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 Dedicated verifications  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


vault page title Glossary of Terms Glossary Vault Glossary sidebar title Glossary layout docs

Answer:
---
layout: docs
page_title: Glossary of Terms
sidebar_title: Glossary
description: |-
  Vault Glossary.
---

# Glossary

This page collects brief definitions of some of the technical terms used in the
documentation for Vault.

- [Audit Device](#audit-device)
- [Auth Method](#auth-method)
- [Barrier](#barrier)
- [Client Token](#client-token)
- [Plugin](#plugin)
- [Request](#request)
- [Secret](#secret)
- [Secrets Engine](#secrets-engine)
- [Server](#server)
- [Storage Backend](#storage-backend)

### Audit device

An audit device is responsible for managing audit logs.
Every request to Vault and response from Vault goes through the configured
audit devices. This provides a simple way to integrate Vault with multiple
audit logging destinations of different types.

### Auth method

An auth method is used to authenticate users or applications
which are connecting to Vault. Once authenticated, the auth method returns the
list of applicable policies which should be applied. Vault takes an
authenticated user and returns a client token that can be used for future
requests. As an example, the `userpass` auth method uses a username and
password to authenticate the user. Alternatively, the `github` auth method
allows users to authenticate via GitHub.

### Barrier

Almost everything Vault writes to storage is encrypted using the keyring, which is protected by the seal. We refer to this practice as "the barrier". There are a few exceptions to the rule, for example, the seal configuration is stored in an unencrypted file since it's needed to unseal the barrier, and the keyring is encrypted using the root key, while the root key is encrypted using the seal.

### Client token

A client token (aka "Vault Token") is conceptually
similar to a session cookie on a web site. Once a user authenticates, Vault
returns a client token which is used for future requests. The token is used by
Vault to verify the identity of the client and to enforce the applicable ACL
policies. This token is passed via HTTP headers.

### Plugin

Plugins are a feature of Vault that can be enabled, disabled, and customized to
some degree. All Vault [auth methods](/vault/docs/auth) and [secrets engines](/vault/docs/secrets)
are considered plugins.

#### Built-in plugin

Built-in plugins are shipped with Vault, often for commonly used
implementations, and require no additional operator intervention to run.
Built-in plugins are just like any other backend code inside Vault.

#### External plugin

External plugins are not shipped with Vault and require additional operator
intervention to run. Vault's external plugins are completely separate,
standalone applications that Vault executes and communicates with over RPC.
Each time a Vault secret engine or auth method is mounted, a new process is
spawned.

#### External multiplexed plugin

An external plugin may make use of [plugin multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing).
A multiplexed plugin allows a single plugin process to be used for multiple
mounts of the same type.

### Request

A request being made to Vault contains all relevant parameters and context in order
for Vault to be able to act accordingly. Vault represents this request internally
in a way that understands:

* Mount Point - Used to generate relative paths.
* Mount Type - The type of mount the request is interacting with.
* Namespace - The [namespace](/vault/docs/enterprise/namespaces) the request is taking place within.
* Operation - See [the operation description](#operation) below for the supported operations.
* Path - The full path of the request.

<Note title="Request's Namespace">
  The Namespace a request is targeting may be specified either as part of the path
  or the Vault Namespace header.
</Note>

Please see our Enterprise documentation for further information on how
[Namespaces can be specified](/vault/docs/enterprise/namespaces#vault-api-and-namespaces)
as part of a request.

#### Operation

The request's operation can be one of the following: `alias-lookahead`, `create`, `delete`,
`header`, `help`, `list`, `patch`, `read`, `renew`, `resolve-role`, `revoke`, `rollback`
`update`.

### Secret

A secret is the term for anything returned by Vault which
contains confidential or cryptographic material. Not everything returned by
Vault is a secret, for example system configuration, status information, or
policies are not considered secrets. Dynamic secrets always have an associated lease, and static secrets do not.
This means clients cannot assume that the dynamic secret contents can be used
indefinitely. Vault will revoke a dynamic secret at the end of the lease, and an
operator may intervene to revoke the Dynamic Secret before the lease is over. This
contract between Vault and its clients is critical, as it allows for changes
in keys and policies without manual intervention.

### Secrets engine

A secrets engine is responsible for managing secrets.
Simple secrets engines, such as the "kv" secrets engine, return the same
secret when queried. Some secrets engines support using policies to
dynamically generate a secret each time they are queried. This allows for
unique secrets to be used which allows Vault to do fine-grained revocation and
policy updates. As an example, a MySQL secrets engine could be configured with
a "web" policy. When the "web" secret is read, a new MySQL user/password pair
will be generated with a limited set of privileges for the web server.

### Server

Vault depends on a long-running instance which operates as a
server. The Vault server provides an API which clients interact with and
manages the interaction between all the secrets engines, ACL enforcement, and
secret lease revocation. Having a server based architecture decouples clients
from the security keys and policies, enables centralized audit logging, and
simplifies administration for operators.

### Storage backend

A storage backend is responsible for durable storage of
_encrypted_ data. Backends are not trusted by Vault and are only expected to
provide durability. The storage backend is configured when starting the Vault
server.

layout  docs page title  Glossary of Terms sidebar title  Glossary description       Vault Glossary         Glossary  This page collects brief definitions of some of the technical terms used in the documentation for Vault      Audit Device   audit device     Auth Method   auth method     Barrier   barrier     Client Token   client token     Plugin   plugin     Request   request     Secret   secret     Secrets Engine   secrets engine     Server   server     Storage Backend   storage backend       Audit device  An audit device is responsible for managing audit logs  Every request to Vault and response from Vault goes through the configured audit devices  This provides a simple way to integrate Vault with multiple audit logging destinations of different types       Auth method  An auth method is used to authenticate users or applications which are connecting to Vault  Once authenticated  the auth method returns the list of applicable policies which should be applied  Vault takes an authenticated user and returns a client token that can be used for future requests  As an example  the  userpass  auth method uses a username and password to authenticate the user  Alternatively  the  github  auth method allows users to authenticate via GitHub       Barrier  Almost everything Vault writes to storage is encrypted using the keyring  which is protected by the seal  We refer to this practice as  the barrier   There are a few exceptions to the rule  for example  the seal configuration is stored in an unencrypted file since it s needed to unseal the barrier  and the keyring is encrypted using the root key  while the root key is encrypted using the seal       Client token  A client token  aka  Vault Token   is conceptually similar to a session cookie on a web site  Once a user authenticates  Vault returns a client token which is used for future requests  The token is used by Vault to verify the identity of the client and to enforce the applicable ACL policies  This token is passed via HTTP headers       Plugin  Plugins are a feature of Vault that can be enabled  disabled  and customized to some degree  All Vault  auth methods   vault docs auth  and  secrets engines   vault docs secrets  are considered plugins        Built in plugin  Built in plugins are shipped with Vault  often for commonly used implementations  and require no additional operator intervention to run  Built in plugins are just like any other backend code inside Vault        External plugin  External plugins are not shipped with Vault and require additional operator intervention to run  Vault s external plugins are completely separate  standalone applications that Vault executes and communicates with over RPC  Each time a Vault secret engine or auth method is mounted  a new process is spawned        External multiplexed plugin  An external plugin may make use of  plugin multiplexing   vault docs plugins plugin architecture plugin multiplexing   A multiplexed plugin allows a single plugin process to be used for multiple mounts of the same type       Request  A request being made to Vault contains all relevant parameters and context in order for Vault to be able to act accordingly  Vault represents this request internally in a way that understands     Mount Point   Used to generate relative paths    Mount Type   The type of mount the request is interacting with    Namespace   The  namespace   vault docs enterprise namespaces  the request is taking place within    Operation   See  the operation description   operation  below for the supported operations    Path   The full path of the request    Note title  Request s Namespace     The Namespace a request is targeting may be specified either as part of the path   or the Vault Namespace header    Note   Please see our Enterprise documentation for further information on how  Namespaces can be specified   vault docs enterprise namespaces vault api and namespaces  as part of a request        Operation  The request s operation can be one of the following   alias lookahead    create    delete    header    help    list    patch    read    renew    resolve role    revoke    rollback   update        Secret  A secret is the term for anything returned by Vault which contains confidential or cryptographic material  Not everything returned by Vault is a secret  for example system configuration  status information  or policies are not considered secrets  Dynamic secrets always have an associated lease  and static secrets do not  This means clients cannot assume that the dynamic secret contents can be used indefinitely  Vault will revoke a dynamic secret at the end of the lease  and an operator may intervene to revoke the Dynamic Secret before the lease is over  This contract between Vault and its clients is critical  as it allows for changes in keys and policies without manual intervention       Secrets engine  A secrets engine is responsible for managing secrets  Simple secrets engines  such as the  kv  secrets engine  return the same secret when queried  Some secrets engines support using policies to dynamically generate a secret each time they are queried  This allows for unique secrets to be used which allows Vault to do fine grained revocation and policy updates  As an example  a MySQL secrets engine could be configured with a  web  policy  When the  web  secret is read  a new MySQL user password pair will be generated with a limited set of privileges for the web server       Server  Vault depends on a long running instance which operates as a server  The Vault server provides an API which clients interact with and manages the interaction between all the secrets engines  ACL enforcement  and secret lease revocation  Having a server based architecture decouples clients from the security keys and policies  enables centralized audit logging  and simplifies administration for operators       Storage backend  A storage backend is responsible for durable storage of  encrypted  data  Backends are not trusted by Vault and are only expected to provide durability  The storage backend is configured when starting the Vault server


vault compares to existing software and contains a quick start for using Vault with Vault We cover what Vault is what problems it can solve how it page title Introduction What is Vault layout docs Welcome to the intro guide to Vault This guide is the best place to start

Answer:
---
layout: docs
page_title: Introduction
description: >-
  Welcome to the intro guide to Vault! This guide is the best place to start
  with Vault. We cover what Vault is, what problems it can solve, how it
  compares to existing software, and contains a quick start for using Vault.
---

# What is Vault?

HashiCorp Vault is an identity-based secrets and encryption management system.
It provides encryption services that are gated by authentication and authorization
methods to ensure secure, auditable and restricted access to _secrets_.

A secret is anything that you want to tightly control access to, such as tokens,
API keys, passwords, encryption keys or certificates. Vault provides a unified
interface to any secret, while providing tight access control and recording a
detailed audit log.

API keys for external services, credentials for service-oriented architecture
communication, etc. It can be difficult to understand who is accessing which
secrets, especially since this can be platform-specific. Adding on key rolling,
secure storage, and detailed audit logs is almost impossible without a custom
solution. This is where Vault steps in.

Vault validates and authorizes clients (users, machines, apps) before providing
them access to secrets or stored sensitive data.

![How Vault Works](/img/how-vault-works.png)

## How does Vault work?

Vault works primarily with tokens and a token is associated to the client's policy. Each policy is path-based and policy rules constrains the actions and accessibility to the paths for each client. With Vault, you can create tokens manually and assign them to your clients, or the clients can log in and obtain a token. The illustration below displays Vault's core workflow.

![Vault Workflow](/img/vault-workflow-diagram1.png)

 The core Vault workflow consists of four stages:

- **Authenticate:** Authentication in Vault is the process by which a client supplies information that Vault uses to determine if they are who they say they are. Once the client is authenticated against an auth method, a token is generated and associated to a policy.
- **Validation:** Vault validates the client against third-party trusted sources, such as Github, LDAP, AppRole, and more.
- **Authorize**: A client is matched against the Vault security policy.  This policy is a set of rules defining which API endpoints a client has access to with its Vault token. Policies provide a declarative way to grant or forbid access to certain paths and operations in Vault.
- **Access**: Vault grants access to secrets, keys, and encryption capabilities by issuing a token based on policies associated with the client’s identity. The client can then use their Vault token for future operations.

## Why Vault?

Most enterprises today have credentials sprawled across their organizations. Passwords, API keys, and credentials are stored in plain text, app source code, config files, and other locations. Because these credentials live everywhere, the sprawl can make it difficult and daunting to really know who has access and authorization to what. Having credentials in plain text also increases the potential for malicious attacks, both by internal and external attackers.

Vault was designed with these challenges in mind. Vault takes all of these credentials and centralizes them so that they are defined in one location, which reduces unwanted exposure to credentials. But Vault takes it a few steps further by making sure users, apps, and systems are authenticated and explicitly authorized to access resources, while also providing an audit trail that captures and preserves a history of clients' actions.

The key features of Vault are:

- **Secure Secret Storage**: Arbitrary key/value secrets can be stored
  in Vault. Vault encrypts these secrets prior to writing them to persistent
  storage, so gaining access to the raw storage isn't enough to access
  your secrets. Vault can write to disk, [Consul](https://www.consul.io/),
  and more.

- **Dynamic Secrets**: Vault can generate secrets on-demand for some
  systems, such as AWS or SQL databases. For example, when an application
  needs to access an S3 bucket, it asks Vault for credentials, and Vault
  will generate an AWS keypair with valid permissions on demand. After
  creating these dynamic secrets, Vault will also automatically revoke them
  after the lease is up.

- **Data Encryption**: Vault can encrypt and decrypt data without storing
  it. This allows security teams to define encryption parameters and
  developers to store encrypted data in a location such as a SQL database
  without having to design their own encryption methods.

- **Leasing and Renewal**: All secrets in Vault have a _lease_ associated
  with them. At the end of the lease, Vault will automatically revoke that
  secret. Clients are able to renew leases via built-in renew APIs.

- **Revocation**: Vault has built-in support for secret revocation. Vault
  can revoke not only single secrets, but a tree of secrets, for example
  all secrets read by a specific user, or all secrets of a particular type.
  Revocation assists in key rolling as well as locking down systems in the
  case of an intrusion.

<Tip title="Vault use cases">

Learn more about Vault [use cases](/vault/docs/use-cases).

</Tip>

## What is HCP Vault Dedicated?

HashiCorp Cloud Platform (HCP) Vault Dedicated is a hosted version of Vault, which is operated by HashiCorp to allow organizations to get up and running quickly. HCP Vault Dedicated uses the same binary as self-hosted Vault, which means you will have a consistent user experience. You can use the same Vault clients to communicate with HCP Vault Dedicated as you use to communicate with a self-hosted Vault. Refer to the [HCP Vault Dedicated](/hcp/docs/vault) documentation to learn more.

<Tip title="Hands-on">

Try the [Get started](/vault/tutorials/cloud) tutorials to set up a managed
Vault cluster.

</Tip>

## Community

We welcome questions, suggestions, and contributions from the community.

- Ask questions in [HashiCorp Discuss](https://discuss.hashicorp.com/c/vault/30).
- Read our [contributing guide](https://github.com/hashicorp/vault/blob/main/CONTRIBUTING.md).
- [Submit an issue](https://github.com/hashicorp/vault/issues/new/choose) for bugs and feature requests.

layout  docs page title  Introduction description       Welcome to the intro guide to Vault  This guide is the best place to start   with Vault  We cover what Vault is  what problems it can solve  how it   compares to existing software  and contains a quick start for using Vault         What is Vault   HashiCorp Vault is an identity based secrets and encryption management system  It provides encryption services that are gated by authentication and authorization  methods to ensure secure  auditable and restricted access to  secrets     A secret is anything that you want to tightly control access to  such as tokens  API keys  passwords  encryption keys or certificates  Vault provides a unified interface to any secret  while providing tight access control and recording a detailed audit log   API keys for external services  credentials for service oriented architecture communication  etc  It can be difficult to understand who is accessing which secrets  especially since this can be platform specific  Adding on key rolling  secure storage  and detailed audit logs is almost impossible without a custom solution  This is where Vault steps in   Vault validates and authorizes clients  users  machines  apps  before providing them access to secrets or stored sensitive data     How Vault Works   img how vault works png       How does Vault work   Vault works primarily with tokens and a token is associated to the client s policy  Each policy is path based and policy rules constrains the actions and accessibility to the paths for each client  With Vault  you can create tokens manually and assign them to your clients  or the clients can log in and obtain a token  The illustration below displays Vault s core workflow     Vault Workflow   img vault workflow diagram1 png    The core Vault workflow consists of four stages       Authenticate    Authentication in Vault is the process by which a client supplies information that Vault uses to determine if they are who they say they are  Once the client is authenticated against an auth method  a token is generated and associated to a policy      Validation    Vault validates the client against third party trusted sources  such as Github  LDAP  AppRole  and more      Authorize    A client is matched against the Vault security policy   This policy is a set of rules defining which API endpoints a client has access to with its Vault token  Policies provide a declarative way to grant or forbid access to certain paths and operations in Vault      Access    Vault grants access to secrets  keys  and encryption capabilities by issuing a token based on policies associated with the client s identity  The client can then use their Vault token for future operations      Why Vault   Most enterprises today have credentials sprawled across their organizations  Passwords  API keys  and credentials are stored in plain text  app source code  config files  and other locations  Because these credentials live everywhere  the sprawl can make it difficult and daunting to really know who has access and authorization to what  Having credentials in plain text also increases the potential for malicious attacks  both by internal and external attackers   Vault was designed with these challenges in mind  Vault takes all of these credentials and centralizes them so that they are defined in one location  which reduces unwanted exposure to credentials  But Vault takes it a few steps further by making sure users  apps  and systems are authenticated and explicitly authorized to access resources  while also providing an audit trail that captures and preserves a history of clients  actions   The key features of Vault are       Secure Secret Storage    Arbitrary key value secrets can be stored   in Vault  Vault encrypts these secrets prior to writing them to persistent   storage  so gaining access to the raw storage isn t enough to access   your secrets  Vault can write to disk   Consul  https   www consul io      and more       Dynamic Secrets    Vault can generate secrets on demand for some   systems  such as AWS or SQL databases  For example  when an application   needs to access an S3 bucket  it asks Vault for credentials  and Vault   will generate an AWS keypair with valid permissions on demand  After   creating these dynamic secrets  Vault will also automatically revoke them   after the lease is up       Data Encryption    Vault can encrypt and decrypt data without storing   it  This allows security teams to define encryption parameters and   developers to store encrypted data in a location such as a SQL database   without having to design their own encryption methods       Leasing and Renewal    All secrets in Vault have a  lease  associated   with them  At the end of the lease  Vault will automatically revoke that   secret  Clients are able to renew leases via built in renew APIs       Revocation    Vault has built in support for secret revocation  Vault   can revoke not only single secrets  but a tree of secrets  for example   all secrets read by a specific user  or all secrets of a particular type    Revocation assists in key rolling as well as locking down systems in the   case of an intrusion    Tip title  Vault use cases    Learn more about Vault  use cases   vault docs use cases      Tip      What is HCP Vault Dedicated   HashiCorp Cloud Platform  HCP  Vault Dedicated is a hosted version of Vault  which is operated by HashiCorp to allow organizations to get up and running quickly  HCP Vault Dedicated uses the same binary as self hosted Vault  which means you will have a consistent user experience  You can use the same Vault clients to communicate with HCP Vault Dedicated as you use to communicate with a self hosted Vault  Refer to the  HCP Vault Dedicated   hcp docs vault  documentation to learn more    Tip title  Hands on    Try the  Get started   vault tutorials cloud  tutorials to set up a managed Vault cluster     Tip      Community  We welcome questions  suggestions  and contributions from the community     Ask questions in  HashiCorp Discuss  https   discuss hashicorp com c vault 30     Read our  contributing guide  https   github com hashicorp vault blob main CONTRIBUTING md      Submit an issue  https   github com hashicorp vault issues new choose  for bugs and feature requests