Guide/Identity: use consistent id/accessor example to fix #5340 (#5432)

This commit is contained in:
Brian Shumate 2018-09-28 17:43:15 -04:00 committed by Chris Hoffman
parent 8ff89b972c
commit d62d482033

View file

@ -67,7 +67,7 @@ Vault generates a token. This token has policies granting you permission to perf
the appropriate operations.
How can a Jenkins server programmatically request a token so that it can read
secrets from Vault?
secrets from Vault?
## Solution
@ -75,7 +75,7 @@ secrets from Vault?
Enable **AppRole** auth method so that the Jenkins server can obtain a Vault
token with appropriate policies attached. Since each AppRole has attached
policies, you can write fine-grained policies limiting which app can access
which path.
which path.
## Prerequisites
@ -497,8 +497,8 @@ $ curl --request POST --data @payload.json http://127.0.0.1:8200/v1/auth/approle
"wrap_info": null,
"warnings": null,
"auth": {
"client_token": "3e7dd0ac-8b3e-8f88-bb37-a2890455ca6e",
"accessor": "375c077e-bf02-a09b-c864-63d7f967e86b",
"client_token": "eeaf890e-4b0f-a687-4190-c75b1d6d70bc",
"accessor": "fcee5d4e-7281-8bb0-2901-e743c52e0502",
"policies": [
"default",
"jenkins"
@ -537,9 +537,9 @@ No value found at secret/mysql/webapp
Alternatively, you can first authenticate with Vault using the `client_token`.
```shell
$ vault login 3e7dd0ac-8b3e-8f88-bb37-a2890455ca6e
$ vault login eeaf890e-4b0f-a687-4190-c75b1d6d70bc
Successfully authenticated! You are now logged in.
token: 3e7dd0ac-8b3e-8f88-bb37-a2890455ca6e
token: eeaf890e-4b0f-a687-4190-c75b1d6d70bc
token_duration: 2762013
token_policies: [default jenkins]
@ -577,7 +577,7 @@ You can now pass the `client_token` returned in [Step 4](#step4) in the
**Example:**
```plaintext
$ curl --header "X-Vault-Token: 3e7dd0ac-8b3e-8f88-bb37-a2890455ca6e" \
$ curl --header "X-Vault-Token: eeaf890e-4b0f-a687-4190-c75b1d6d70bc" \
--request GET \
http://127.0.0.1:8200/v1/secret/data/mysql/webapp | jq
{
@ -615,7 +615,7 @@ becomes how to deliver those values to the expected client.
A common solution involves **three personas** instead of two: `admin`, `app`, and
`trusted entity`. The `trusted entity` delivers the Role ID and Secret ID to the
client by separate means.
client by separate means.
For example, Terraform as a trusted entity can deliver the Role ID onto the
virtual machine. When the app runs on the virtual machine, the Role ID already