a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
65 lines
2.8 KiB
Markdown
65 lines
2.8 KiB
Markdown
---
|
|
layout: "docs"
|
|
page_title: "Token Helpers"
|
|
sidebar_title: "Token Helpers"
|
|
sidebar_current: "docs-commands-token-helper"
|
|
description: |-
|
|
The Vault CLI supports external token helpers that make retrieving, setting and erasing tokens simpler to use.
|
|
---
|
|
|
|
# Token Helpers
|
|
|
|
The Vault CLI provides a built in tool for authenticating to any of the enabled auth backends. By default the Vault CLI will take the generated token after a successful authentication and store it on disk in the `~/.vault-token` file. This functionality can change in Vault via the use of a token helper. A token helper is an external program that Vault calls to save, retrieve or erase a saved token. The token helper could be a very simple script or a more complex program depending on your needs. The interface to the external token helper is extremely simple.
|
|
|
|
## Configuration
|
|
|
|
To configure a token helper, edit (or create) the file `~/.vault` and add a line similar to:
|
|
|
|
```
|
|
token_helper = "/path/to/token/helper.sh"
|
|
```
|
|
|
|
You will need to use the fully qualified path to the token helper script. The script should be executable.
|
|
|
|
## Developing a Token Helper
|
|
|
|
The interface to a token helper is extremely simple: the script is passed with one argument that could be `get`, `store` or `erase`. If the argument is `get`, the script should do whatever work it needs to do to retrieve the stored token and then print the token to `STDOUT`. If the argument is `store`, Vault is asking you to store the token. Finally, if the argument is `erase`, your program should erase the stored token.
|
|
|
|
If your program succeeds, it should exit with status code 0. If it encounters an issue that prevents it from working, it should exit with some other status code. You should write a user-friendly error message to `STDERR`. You should never write anything other than the token to `STDOUT`, as Vault assumes whatever it gets on `STDOUT` is the token.
|
|
|
|
### Example Token Helper
|
|
|
|
This is an example token helper written in Ruby that stores and retrieves tokens in a json file called `~/.vault_tokens`. The key is the environment variable $VAULT_ADDR, this allows the Vault user to easily store and retrieve tokens from a number of different Vault servers.
|
|
|
|
```
|
|
#!/usr/bin/env ruby
|
|
|
|
require 'json'
|
|
|
|
unless ENV['VAULT_ADDR']
|
|
STDERR.puts "No VAULT_ADDR environment variable set. Set it and run me again!"
|
|
exit 100
|
|
end
|
|
|
|
begin
|
|
tokens = JSON.parse(File.read("#{ENV['HOME']}/.vault_tokens"))
|
|
rescue Errno::ENOENT => e
|
|
# file doesn't exist so create a blank hash for it
|
|
tokens = {}
|
|
end
|
|
|
|
case ARGV.first
|
|
when 'get'
|
|
print tokens[ENV['VAULT_ADDR']] if tokens[ENV['VAULT_ADDR']]
|
|
exit 0
|
|
when 'store'
|
|
tokens[ENV['VAULT_ADDR']] = STDIN.read
|
|
when 'erase'
|
|
tokens.delete!(ENV['VAULT_ADDR'])
|
|
end
|
|
|
|
File.open("#{ENV['HOME']}/.vault_tokens", 'w') { |file| file.write(tokens.to_json) }
|
|
```
|
|
|
|
|