From 7bb9f977337955074675ef35326e4e38d1de0553 Mon Sep 17 00:00:00 2001 From: Austin Gebauer <34121980+austingebauer@users.noreply.github.com> Date: Wed, 23 Mar 2022 06:12:52 -0700 Subject: [PATCH] docs/ssct: service side to server side (#14654) --- website/content/docs/configuration/replication.mdx | 2 +- website/content/docs/enterprise/consistency.mdx | 2 +- website/content/docs/faq/ssct.mdx | 2 +- website/content/docs/release-notes/1.10.mdx | 4 ++-- website/content/docs/upgrading/upgrade-to-1.10.x.mdx | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/website/content/docs/configuration/replication.mdx b/website/content/docs/configuration/replication.mdx index 82b6c81f78..41c78ce03b 100644 --- a/website/content/docs/configuration/replication.mdx +++ b/website/content/docs/configuration/replication.mdx @@ -45,4 +45,4 @@ replication { - `allow_forwarding_via_token` `(string: "")` - When set to `new_token`, requests sent to non-active nodes are forwarded if the node does not yet have the token information in storage. -Support for Service Side Consistent Tokens is now available. Refer to the [Service Side Consistent Token FAQ](/docs/faq/ssct) for details. +Support for Server Side Consistent Tokens is now available. Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details. diff --git a/website/content/docs/enterprise/consistency.mdx b/website/content/docs/enterprise/consistency.mdx index 159c6e6a71..11cb65fb95 100644 --- a/website/content/docs/enterprise/consistency.mdx +++ b/website/content/docs/enterprise/consistency.mdx @@ -206,7 +206,7 @@ The replication option [allow_forwarding_via_token](/docs/configuration/replicat can be used to enforce requests that would have returned 412s in the aforementioned way will be forwarded instead to the active node. -Refer to the [Service Side Consistent Token FAQ](/docs/faq/ssct) for details. +Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details. ## Client API helpers diff --git a/website/content/docs/faq/ssct.mdx b/website/content/docs/faq/ssct.mdx index 6c5a74b321..e26c3470d1 100644 --- a/website/content/docs/faq/ssct.mdx +++ b/website/content/docs/faq/ssct.mdx @@ -1,7 +1,7 @@ --- layout: docs page_title: Server Side Consistent Token FAQ -description: An list of frequently asked questions about service side consistent token +description: An list of frequently asked questions about server side consistent tokens --- # Server Side Consistent Token FAQ diff --git a/website/content/docs/release-notes/1.10.mdx b/website/content/docs/release-notes/1.10.mdx index 5470a70b99..14c23716bf 100644 --- a/website/content/docs/release-notes/1.10.mdx +++ b/website/content/docs/release-notes/1.10.mdx @@ -68,11 +68,11 @@ To address security and compliance needs, customers may require that keys be eit The work done above to support HSM-backed PKI operations inspired us to consider what other key possession paradigms we could support. This led us to extend the implementation to support Cloud Key Management Systems in addition to HSMs. In Vault 1.10, users may generate new PKI pairs and perform sign/verify certificate workflows, all with those keys never leaving the cloud KMS itself. Vault 1.10 provides support for AWS Key Management Service and Azure Key Vault Key Management Service. -### Server Side Consisten Tokens +### Server Side Consistent Tokens Vault’s [eventual consistency](/docs/enterprise/consistency) model precludes read-after-write guarantees when clients interact with performance standbys or performance replication clusters. The [Client Controlled Consistency](/docs/enterprise/consistency#vault-1-7-mitigations) mitigations supported with Vault 1.7 provide ways to achieve consistency through client modifications or by using the agent for proxied requests, which is not possible in all cases. The Server Side Consistent Tokens feature provides an implicit way to achieve consistency by embedding the minimum Write-Ahead-Log state information in the Service tokens returned from logins or token-create requests. This feature introduces changes in the token format and the new tokesn will be the default tokens starting in Vault 1.10. Vault 1.10 is backwards compatible with old tokens. -See [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), [Upgrade to 1.10](/docs/upgrading/upgrade-to-1.10.x) and [Service Side Consistent Token FAQ](/docs/faq/ssct) to understand the various consistency options available with Vault 1.10 and the considerations to be aware of prior to selecting an option for your use case. +See [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), [Upgrade to 1.10](/docs/upgrading/upgrade-to-1.10.x) and [Server Side Consistent Token FAQ](/docs/faq/ssct) to understand the various consistency options available with Vault 1.10 and the considerations to be aware of prior to selecting an option for your use case. ## Vault Agent Features diff --git a/website/content/docs/upgrading/upgrade-to-1.10.x.mdx b/website/content/docs/upgrading/upgrade-to-1.10.x.mdx index 8c4f531154..760f7e68c6 100644 --- a/website/content/docs/upgrading/upgrade-to-1.10.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.10.x.mdx @@ -51,4 +51,4 @@ Additionally, non-root service tokens are now longer than before. Previously, se were 26 characters; they now have a minimum of 95 characters. However, existing tokens will still work. -Refer to the [Service Side Consistent Token FAQ](/docs/faq/ssct) for details. +Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details.