Browse Source

Add Vault 1.10 updates

James Bayer 4 years ago
parent
commit
c12d19f263
1 changed files with 18 additions and 11 deletions
  1. 18 11
      docs/provider-hashicorp-vault.md

+ 18 - 11
docs/provider-hashicorp-vault.md

@@ -318,18 +318,25 @@ and pick the best fit for your environment and Vault configuration.
 
 
 #### Read Your Writes
 #### Read Your Writes
 
 
-The simplest method is simply utilizing the `X-Vault-Index` header returned on
-all write requests (including logins). Passing this header back on subsequent
-requests instructs the Vault client to retry the request until the server has an
-index greater than or equal to that returned with the last write.
-
-Obviously though, this has a performance hit because the read is blocked until
-the follower's local state has caught up.
+Vault 1.10.0 and later encodes information in the token to detect the case 
+when a server is behind. If a Vault server does not have information about 
+the provided token, [Vault returns a 412 error](https://www.vaultproject.io/docs/faq/ssct#q-is-there-anything-else-i-need-to-consider-to-achieve-consistency-besides-upgrading-to-vault-1-10) 
+so clients know to retry.
+
+A method supported in versions Vault 1.7 and later is to utilize the 
+`X-Vault-Index` header returned on all write requests (including logins). 
+Passing this header back on subsequent requests instructs the Vault client 
+to retry the request until the server has an index greater than or equal 
+to that returned with the last write. Obviously though, this has a performance
+hit because the read is blocked until the follower's local state has caught up.
 
 
 #### Forward Inconsistent
 #### Forward Inconsistent
 
 
-In addition to the aforementioned `X-Vault-Index` header, Vault also supports
-proxying inconsistent requests to the current cluster leader for immediate
-read-after-write consistency. This is achieved by setting the `X-Vault-Inconsistent`
+Vault also supports proxying inconsistent requests to the current cluster leader 
+for immediate read-after-write consistency.
+ 
+Vault 1.10.0 and later [support a replication configuration](https://www.vaultproject.io/docs/faq/ssct#q-is-there-a-new-configuration-that-this-feature-introduces) that detects when forwarding should occur and does it transparently to the client.
+
+In Vault 1.7 forwarding can be achieved by setting the `X-Vault-Inconsistent`
 header to `forward-active-node`. By default, this behavior is disabled and must
 header to `forward-active-node`. By default, this behavior is disabled and must
-be explicitly enabled in the server's [replication configuration](https://www.vaultproject.io/docs/configuration/replication#allow_forwarding_via_header).
+be explicitly enabled in the server's [replication configuration](https://www.vaultproject.io/docs/configuration/replication#allow_forwarding_via_header).