luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

docs allow_forwarding_via_token syntax update (#18956) 

* allow_forwarding_via_token syntax update

the example syntax used for `allow_forwarding_via_token` marks the option as an array when it does not need to be, this updates the format on the page to be a code block and removes the square braces

* another update to `allow_forwarding_via_token` syntax
This commit is contained in:
Rowan Smith 2023-02-04 05:58:19 +11:00 committed by GitHub
parent 8edfb21521
commit 6c53845db9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
website/content/docs/faq/ssct.mdx
View File

@ -64,7 +64,12 @@ With the exception of the prefix changes detailed above that apply to all token
There is a new configuration in the replication section as follows:
`replication { allow_forwarding_via_token = ["new_token"] } `
```
replication {
allow_forwarding_via_token = "new_token"
}
```
This configuration allows Vault clusters to be configured so that requests made to performance standbys that don’t yet have the most up-to-date WAL index are forwarded to the active node. Please note that there will be extra load on the active node with this type of configuration.
### Q: Is there anything else I need to consider to achieve consistency, besides upgrading to Vault 1.10?
@ -75,7 +80,13 @@ Yes, there are several considerations to keep in mind, and possibly things that
- Ensure that your clients can retry for the best experience.
- Starting with Go api version [1.1.0](https://pkg.go.dev/github.com/hashicorp/vault/api@v1.1.0), the Go client library enables automatic retries for 412 errors. By default, retries=2, or use client method [SetMaxRetries](https://pkg.go.dev/github.com/hashicorp/vault/api#Client.SetMaxRetries). Or, you can use the Vault environment variable [VAULT_MAX_RETRIES](/vault/docs/commands#vault_max_retries) to achieve the same result.
- If you use a client library other than Go, you may still need to ensure that your client can handle 412 retries in order to achieve consistency.
- If your client cannot retry, you can use the Vault server replication configuration `allow_forwarding_via_token = ["new_token"]` to allow for consistency. As stated earlier, this will incur extra load on the server due to forwarding of requests that don't have the up-to-date WAL-state to the server.
- If your client cannot retry, you can use the Vault server replication configuration `allow_forwarding_via_token` to allow for consistency. As stated earlier, this will incur extra load on the server due to forwarding of requests that don't have the up-to-date WAL-state to the server:
```
replication {
allow_forwarding_via_token = "new_token"
}
```
~> **Note:** If you are generating root tokens or recovery tokens without using the Vault CLI, you will need to modify the OTP length used. refer [here](/vault/docs/upgrading/upgrade-to-1.10.x) for details.