Vault Documentation: Added Glossary (#12324)

* added glossary

* Update website/content/docs/glossary.mdx

Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>

* Update website/content/docs/glossary.mdx

Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>

* modified secrets and barrier content based on feedback

Co-authored-by: trujillo-adam <47586768+trujillo-adam@users.noreply.github.com>

website/content/docs/glossary.mdx

@@ -0,0 +1,89 @@
+---
+layout: docs
+page_title: Glossary of Terms
+sidebar_title: Glossary
+description: |-
+  Vault Glossary.
+---
+
+# Glossary
+
+This page collects brief definitions of some of the technical terms used in the
+documentation for Vault.
+
+- [Audit Device](#audit-device)
+- [Auth Method](#auth-method)
+- [Barrier](#barrier)
+- [Client Token](#client-token)
+- [Secret](#secret)
+- [Secrets Engine](#secrets-engine)
+- [Server](#server)
+- [Storage Backend](#storage-backend)
+
+### Audit Device
+
+An audit device is responsible for managing audit logs.
+Every request to Vault and response from Vault goes through the configured
+audit devices. This provides a simple way to integrate Vault with multiple
+audit logging destinations of different types.
+
+### Auth Method
+
+An auth method is used to authenticate users or applications
+which are connecting to Vault. Once authenticated, the auth method returns the
+list of applicable policies which should be applied. Vault takes an
+authenticated user and returns a client token that can be used for future
+requests. As an example, the `userpass` auth method uses a username and
+password to authenticate the user. Alternatively, the `github` auth method
+allows users to authenticate via GitHub.
+
+### Barrier
+
+Almost everything Vault writes to storage is encrypted using the keyring, which is protected by the seal. We refer to this practice as "the barrier". There are a few exceptions to the rule, for example, the seal configuration is stored in an unencrypted file since it's needed to unseal the barrier, and the keyring is encrypted using the master key, while the master key is encrypted using the seal.
+
+### Client Token
+
+A client token (aka "Vault Token") is conceptually
+similar to a session cookie on a web site. Once a user authenticates, Vault
+returns a client token which is used for future requests. The token is used by
+Vault to verify the identity of the client and to enforce the applicable ACL
+policies. This token is passed via HTTP headers.
+
+### Secret
+
+A secret is the term for anything returned by Vault which
+contains confidential or cryptographic material. Not everything returned by
+Vault is a secret, for example system configuration, status information, or
+policies are not considered secrets. Dynamic secrets always have an associated lease, and static secrets do not.
+This means clients cannot assume that the dynamic secret contents can be used
+indefinitely. Vault will revoke a dynamic secret at the end of the lease, and an
+operator may intervene to revoke the Dynamic Secret before the lease is over. This
+contract between Vault and its clients is critical, as it allows for changes
+in keys and policies without manual intervention.
+
+### Secrets Engine
+
+A secrets engine is responsible for managing secrets.
+Simple secrets engines, such as the "kv" secrets engine, return the same
+secret when queried. Some secrets engines support using policies to
+dynamically generate a secret each time they are queried. This allows for
+unique secrets to be used which allows Vault to do fine-grained revocation and
+policy updates. As an example, a MySQL secrets engine could be configured with
+a "web" policy. When the "web" secret is read, a new MySQL user/password pair
+will be generated with a limited set of privileges for the web server.
+
+### Server
+
+Vault depends on a long-running instance which operates as a
+server. The Vault server provides an API which clients interact with and
+manages the interaction between all the secrets engines, ACL enforcement, and
+secret lease revocation. Having a server based architecture decouples clients
+from the security keys and policies, enables centralized audit logging, and
+simplifies administration for operators.
+
+### Storage Backend
+
+A storage backend is responsible for durable storage of
+_encrypted_ data. Backends are not trusted by Vault and are only expected to
+provide durability. The storage backend is configured when starting the Vault
+server.

website/content/docs/internals/architecture.mdx

@@ -17,67 +17,6 @@ spelunking through the source code. However, if you're an operator of Vault, we
 recommend learning about the architecture due to the importance of Vault in an
 environment.
 
-# Glossary
-
-Before describing the architecture, we provide a glossary of terms to help
-clarify what is being discussed:
-
-- **Storage Backend** - A storage backend is responsible for durable storage of
-  _encrypted_ data. Backends are not trusted by Vault and are only expected to
-  provide durability. The storage backend is configured when starting the Vault
-  server.
-
-- **Barrier** - The barrier is cryptographic steel and concrete around the
-  Vault. All data that flows between Vault and the storage backend passes
-  through the barrier. The barrier ensures that only encrypted data is written
-  out, and that data is verified and decrypted on the way in. Much like a bank
-  vault, the barrier must be "unsealed" before anything inside can be accessed.
-
-- **Secrets Engine** - A secrets engine is responsible for managing secrets.
-  Simple secrets engines like the "kv" secrets engine simply return the same
-  secret when queried. Some secrets engines support using policies to
-  dynamically generate a secret each time they are queried. This allows for
-  unique secrets to be used which allows Vault to do fine-grained revocation and
-  policy updates. As an example, a MySQL secrets engine could be configured with
-  a "web" policy. When the "web" secret is read, a new MySQL user/password pair
-  will be generated with a limited set of privileges for the web server.
-
-- **Audit Device** - An audit device is responsible for managing audit logs.
-  Every request to Vault and response from Vault goes through the configured
-  audit devices. This provides a simple way to integrate Vault with multiple
-  audit logging destinations of different types.
-
-- **Auth Method** - An auth method is used to authenticate users or applications
-  which are connecting to Vault. Once authenticated, the auth method returns the
-  list of applicable policies which should be applied. Vault takes an
-  authenticated user and returns a client token that can be used for future
-  requests. As an example, the `userpass` auth method uses a username and
-  password to authenticate the user. Alternatively, the `github` auth method
-  allows users to authenticate via GitHub.
-
-- **Client Token** - A client token (aka "Vault Token") is conceptually
-  similar to a session cookie on a web site. Once a user authenticates, Vault
-  returns a client token which is used for future requests. The token is used by
-  Vault to verify the identity of the client and to enforce the applicable ACL
-  policies. This token is passed via HTTP headers.
-
-- **Secret** - A secret is the term for anything returned by Vault which
-  contains confidential or cryptographic material. Not everything returned by
-  Vault is a secret, for example system configuration, status information, or
-  policies are not considered secrets. Secrets always have an associated lease.
-  This means clients cannot assume that the secret contents can be used
-  indefinitely. Vault will revoke a secret at the end of the lease, and an
-  operator may intervene to revoke the secret before the lease is over. This
-  contract between Vault and its clients is critical, as it allows for changes
-  in keys and policies without manual intervention.
-
-- **Server** - Vault depends on a long-running instance which operates as a
-  server. The Vault server provides an API which clients interact with and
-  manages the interaction between all the secrets engines, ACL enforcement, and
-  secret lease revocation. Having a server based architecture decouples clients
-  from the security keys and policies, enables centralized audit logging and
-  simplifies administration for operators.
-
 # High-Level Overview
 
 A very high level overview of Vault looks like this:

website/data/docs-nav-data.json

@@ -1666,6 +1666,14 @@
   {
     "divider": true
   },
+
+  {
+    "title": "Glossary",
+    "path": "glossary"
+  },
+  {
+    "divider": true
+  },
   {
     "title": "Vault Enterprise",
     "routes": [