[BACKPORT] Manual cherry-pick of failed release/1.13.x backport PRs (#26798)

* Fix "auto unseal" case inconsistency (#25119)

There was inconsistency in the capitalization of auto unseal in this doc.  The initial heading had it right. It shouldn't be capitalized according to the documentation style guidance for feature capitalization. Also, high availability doesn't need to be capitalized.

Change warning to tag syntax so it's clear what should be part of the aside

---------

Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>

* added documentation for mongodb atlas database secrets engine eventua… (#24152)

* added documentation for mongodb atlas database secrets engine eventual consistency

* Update events.mdx (#25835)

Added missing ' to the command at the end

* Add missing beta partial

* Add another missing partial

---------

Co-authored-by: Mitch Pronschinske <mpronschinske@hashicorp.com>
Co-authored-by: kevin-loehfelm <37027455+kevin-loehfelm@users.noreply.github.com>
Co-authored-by: preetibhat6 <139800125+preetibhat6@users.noreply.github.com>

Author: 4 people

changelog/24152.txt

@@ -0,0 +1,3 @@
+```release-note:improvement
+website/docs: Add note about eventual consietency with the MongoDB Atlas database secrets engine
+```

website/content/docs/concepts/events.mdx

@@ -132,8 +132,8 @@ By default, the events are delivered in protobuf binary format.
 The endpoint can also format the data as JSON if the `json` query parameter is set to `true`:
 
 ```shell-session
-$ wscat -H "X-Vault-Token: $(vault print token)" --connect 'ws://127.0.0.1:8200/v1/sys/events/subscribe/kv-v2/data-write?json=true
-{"id":"901f2388-aabb-a385-7bc0-0b09d5fa060b","source":"https://vaultproject.io/","specversion":"1.0","type":"*","data":{"event":{"id":"901f2388-aabb-a385-7bc0-0b09d5fa060b","metadata":{"current_version":"1","oldest_version":"0","path":"data/foo"}},"event_type":"kv-v2/data-write","plugin_info":{"mount_class":"secret","mount_accessor":"kv_a6081d01","mount_path":"secret/","plugin":"kv"}},"datacontentype":"application/cloudevents","time":"2023-02-17T13:11:39.227341-08:00"}
+$ wscat -H "X-Vault-Token: $(vault print token)" --connect 'ws://127.0.0.1:8200/v1/sys/events/subscribe/kv-v2/data-write?json=true'
+{"id":"a3be9fb1-b514-519f-5b25-b6f144a8c1ce","source":"vault://mycluster","specversion":"1.0","type":"*","data":{"event":{"id":"a3be9fb1-b514-519f-5b25-b6f144a8c1ce","metadata":{"current_version":"1","data_path":"secret/data/foo","modified":"true","oldest_version":"0","operation":"data-write","path":"secret/data/foo"}},"event_type":"kv-v2/data-write","plugin_info":{"mount_class":"secret","mount_accessor":"kv_5dc4d18e","mount_path":"secret/","plugin":"kv"}},"datacontentype":"application/cloudevents","time":"2023-09-12T15:19:49.394915-07:00"}
 ...
 ```
 

website/content/docs/concepts/seal.mdx

@@ -85,7 +85,7 @@ access to the root key shares.
 
 ## Auto unseal
 
-Auto Unseal was developed to aid in reducing the operational complexity of
+Auto unseal was developed to aid in reducing the operational complexity of
 keeping the unseal key secure. This feature delegates the responsibility of
 securing the unseal key from users to a trusted device or service. At startup
 Vault will connect to the device or service implementing the seal and ask it
@@ -110,10 +110,13 @@ that would be provided with Shamir. The process remains the same.
 For a list of examples and supported providers, please see the
 [seal documentation](/vault/docs/configuration/seal).
 
--> **Warning:** Recovery keys cannot decrypt the root key, and thus are not
-sufficient to unseal Vault if the Auto Unseal mechanism isn't working. They
-are purely an authorization mechanism.  Using Auto Unseal 
-creates a strict Vault lifecycle dependency on the underlying seal mechanism. 
+When DR replication is enabled in Vault Enterprise, [Performance Standby](/vault/docs/enterprise/performance-standby) nodes on the DR cluster will seal themselves, so they must be restarted to be unsealed.
+
+<Warning title="Recovery keys cannot decrypt the root key">
+
+Recovery keys cannot decrypt the root key and thus are not sufficient to unseal
+Vault if the auto unseal mechanism isn't working. They are purely an authorization mechanism.
+Using auto unseal creates a strict Vault lifecycle dependency on the underlying seal mechanism. 
 This means that if the seal mechanism (such as the Cloud KMS key) becomes unavailable, 
 or deleted before the seal is migrated, then there is no ability to recover 
 access to the Vault cluster until the mechanism is available again. **If the seal 
@@ -128,6 +131,7 @@ seal configured independently of the primary, and when properly configured guard
 against *some* of this risk.  Unreplicated items such as local mounts could still 
 be lost.
 
+</Warning>
 
 ## Recovery key
 
@@ -188,7 +192,7 @@ API prefix for this operation is at `/sys/rekey-recovery-key` rather than
 
 ## Seal migration
 
-The Seal migration process cannot be performed without downtime, and due to the
+The seal migration process cannot be performed without downtime, and due to the
 technical underpinnings of the seal implementations, the process requires that
 you briefly take the whole cluster down. While experiencing some downtime may
 be unavoidable, we believe that switching seals is a rare event and that the
@@ -198,15 +202,15 @@ inconvenience of the downtime is an acceptable trade-off.
 something goes wrong.
 
 ~> **NOTE**: Seal migration operation will require both old and new seals to be
-available during the migration. For example, migration from Auto Unseal to Shamir
-seal will require that the service backing the Auto Unseal is accessible during
+available during the migration. For example, migration from auto unseal to Shamir
+seal will require that the service backing the auto unseal is accessible during
 the migration.
 
-~> **NOTE**: Seal migration from Auto Unseal to Auto Unseal of the same type is
+~> **NOTE**: Seal migration from auto unseal to auto unseal of the same type is
 supported since Vault 1.6.0. However, there is a current limitation that
 prevents migrating from AWSKMS to AWSKMS; all other seal migrations of the same
-type are supported. Seal migration from One Auto Unseal type (AWS KMS) to
-different Auto Unseal type (HSM, Azure KMS, etc.) is also supported on older
+type are supported. Seal migration from one auto unseal type (AWS KMS) to
+different auto unseal type (HSM, Azure KMS, etc.) is also supported on older
 versions as well.
 
 ### Migration post Vault 1.5.1
@@ -253,7 +257,7 @@ any storage backend.
 1. Seal migration is now completed. Take down the old active node, update its
    configuration to use the new seal blocks (completely unaware of the old seal type)
    ,and bring it back up. It will be auto-unsealed if the new seal is one of the
-   Auto seals, or will require unseal keys if the new seal is Shamir.
+   auto seals, or will require unseal keys if the new seal is Shamir.
 
 1. At this point, configuration files of all the nodes can be updated to only have the
    new seal information. Standby nodes can be restarted right away and the active
@@ -277,7 +281,7 @@ keys.
 
 #### Migration from auto unseal to shamir
 
-To migrate from Auto Unseal to Shamir keys, take your server cluster offline
+To migrate from auto unseal to Shamir keys, take your server cluster offline
 and update the [seal configuration](/vault/docs/configuration/seal) and add `disabled
 = "true"` to the seal block. This allows the migration to use this information
 to decrypt the key but will not unseal Vault. When you bring your server back
@@ -290,9 +294,9 @@ will be migrated to be used as unseal keys.
 
 ~> **NOTE**: Migration between same Auto Unseal types is supported in Vault
 1.6.0 and higher. For these pre-1.5.1 steps, it is only possible to migrate from
-one type of Auto Unseal to a different type (ie Transit -> AWSKMS).
+one type of auto unseal to a different type (ie Transit -> AWSKMS).
 
-To migrate from Auto Unseal to a different Auto Unseal configuration, take your
+To migrate from auto unseal to a different auto unseal configuration, take your
 server cluster offline and update the existing [seal
 configuration](/vault/docs/configuration/seal) and add `disabled = "true"` to the seal
 block. Then add another seal block to describe the new seal.
@@ -315,3 +319,74 @@ When the quorum of nodes are back up, Raft will elect a leader and the leader
 node that will perform the migration. The migrated information will be replicated to
 all other cluster peers and when the peers eventually become the leader,
 migration will not happen again on the peer nodes.
+
+## Seal high availability <EnterpriseAlert inline="true" />
+
+@include 'alerts/beta.mdx'
+
+Seal high availability (Seal HA) allows the configuration of more than one auto 
+seal mechanism such that Vault can tolerate the temporary loss of a seal service 
+
+or device for a time.  With Seal HA configured with at least two and no more than
+three auto seals, Vault can also start up and unseal if one of the
+configured seals is still available (though Vault will remain in a degraded mode in
+this case). While seals are unavailable, seal wrapping and entropy augmentation can
+still occur using the remaining seals, and values produced while a seal is down will
+be re-wrapped with all the seals when all seals become healthy again.
+
+An operator should choose two seals that are unlikely to become unavailable at the
+same time.  For example, they may choose KMS keys in two cloud regions, from
+two different providers; or a mix of HSM, KMS, or Transit seals.
+
+When an operator configures an additional seal or removes a seal (one at a time)
+and restarts Vault, Vault will automatically detect that it needs to re-wrap
+CSPs and seal wrapped values, and will start the process.  Seal re-wrapping can
+be monitored via the logs or via the `sys/seal-status` endpoint.  While a 
+re-wrap is in progress (or could not complete successfully), changes to the
+seal configuration are not allowed.
+
+In additional to high availability, seal HA can be used to migrate between two 
+auto seals in a simplified manner.  To migrate in this way:
+
+In additional to high availability, Seal HA can be used to migrate between two
+auto seals in a [simplified manner.](#migration-post-vault-1-16-0-via-seal-ha-for-auto-seals-enterprise)
+
+Note that Shamir seals are not auto seals and cannot be included in a Seal
+HA setup.  This is because auto seals support seal wrap while Shamir seals
+do not, so the loss of the auto seal does not necessarily leave Vault in a
+fully available state. 
+
+### Use and Configuration
+
+Refer to the [configuration](/vault/docs/configuration/seal/seal-ha) section
+for details on configuring Seal HA.
+
+### Seal Re-Wrapping
+
+Whenever seal configuration changes, Vault must re-wrap all CSPs and seal
+wrapped values, to ensure each value has an entry encrypted by all configured
+seals.  Vault detects these configuration changes automatically, and triggers
+a re-wrap.  Re-wraps can take some time, depending on the number of
+seal wrapped values.  While re-wrapping is in progress, no configuration changes
+to the seals can be made.
+
+Progress of the re-wrap can be monitored using
+the [`sys/sealwrap/rewrap`](/vault/api-docs/system/sealwrap-rewrap) endpoint.
+
+### Limitations and Known Issues
+
+In order to limit complexity and increase safety, there are some limitations
+to the use and configuration of Seal HA:
+
+* Vault must be configured for a single seal at the time of initialization.
+Extra seals can then be added.
+* Seals must be added or removed one at a time.
+* Only auto seals can be used in HA configurations.  Shamir and auto cannot
+be mixed.
+* A maximum of three seals can be configured.
+* As seal wrapped values must be wrapped by all configured seals, it is possible
+that large values may fail to persist as the size of the entry is multiplied by
+the number of seals causing it to exceed the storage entry size limit.   An example
+would be storing a large document in KVv2 with seal wrapping enabled.
+* It is not possible to rotate the data encryption key nor the recovery keys while
+unless all seals are healthy.

website/content/docs/secrets/databases/mongodbatlas.mdx

@@ -73,7 +73,69 @@ the proper permissions, it can generate credentials.
         lease_duration     1h
         lease_renewable    true
         password           FBYwnnh-fwc0quxtKf11
-        username           v-my-role-DKbQEg6uRn
+        username           v-my-password-role-DKbQEg6uRn
+    ```
+
+    Each invocation of the command generates a new credential.
+
+    MongoDB Atlas database credentials eventually become consistent when the
+    [MongoDB Atlas Admin API](https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/)
+    coordinates with hosted clusters in your Atlas project. You cannot use the
+    credentials successfully until the consistency process completes.
+
+    If you plan to use MongoDB Atlas credentials in a pipeline, you may need to add
+    a time delay or secondary process to account for the time required to establish consistency.
+
+#### Client certificate credentials
+
+1.  Configure a role that maps a name in Vault to a MongoDB Atlas command that executes and
+    creates the X509 type database user credential:
+
+    ```shell-session
+    $ vault write database/roles/my-dynamic-certificate-role \
+      db_name=my-mongodbatlas-database \
+      creation_statements='{"database_name": "$external", "x509Type": "CUSTOMER", "roles": [{"databaseName":"<db_name>","roleName":"readWrite"}]}' \
+      default_ttl="1h" \
+      max_ttl="24h" \
+      credential_type="client_certificate" \
+      credential_config=ca_cert="$(cat path/to/ca_cert.pem)" \
+      credential_config=ca_private_key="$(cat path/to/private_key.pem)" \
+      credential_config=key_type="rsa" \
+      credential_config=key_bits=2048 \
+      credential_config=signature_bits=256 \
+      credential_config=common_name_template="{{.DisplayName}}_{{.RoleName}}_{{unix_time}}"
+    Success! Data written to: database/roles/my-dynamic-certificate-role
+    ```
+
+1.  Generate a new credential by reading from the `/creds` endpoint with the name
+of the role:
+
+    ```shell-session
+    $ vault read database/creds/my-dynamic-certificate-role
+      Key                 Value
+      ---                 -----
+      request_id          b6556b2d-c379-5a92-465d-6597c506c821
+      lease_id            database/creds/my-dynamic-certificate-role/AZ5tao6NjLJctx7fm1bujKEL
+      lease_duration      1h
+      lease_renewable     true
+      client_certificate  -----BEGIN CERTIFICATE-----
+                          ...
+                          -----END CERTIFICATE-----
+      private_key         -----BEGIN PRIVATE KEY-----
+                          ...
+                          -----END PRIVATE KEY-----
+      private_key_type    rsa
+      username            CN=token_my-dynamic-certificate-role_1677262121
+    ```
+
+## Client certificate authentication
+
+MongoDB Atlas supports [X.509 client certificate based authentication](https://www.mongodb.com/docs/manual/tutorial/configure-x509-client-authentication/)
+for enhanced authentication security as an alternative to username and password authentication.
+The MongoDB Atlas database plugin can be used to manage client certificate credentials for
+MongoDB Atlas users by using `client_certificate` [credential_type](/vault/api-docs/secret/databases#credential_type).
+
+See the [usage](/vault/docs/secrets/databases/mongodbatlas#usage) section for examples using dynamic roles.
 
 ## API
 

website/content/partials/alerts/beta.mdx

@@ -0,0 +1,6 @@
+<Note title="Beta feature">
+
+  Beta functionality is stable but possibly incomplete and subject to change.
+  **We strongly discourage using beta features in production deployments of Vault**
+
+</Note>

website/content/partials/alerts/enterprise-only.mdx

@@ -0,0 +1,4 @@
+<EnterpriseAlert product="vault">
+  <a href="https://www.hashicorp.com/products/vault/pricing">Vault Enterprise</a>
+  &nbsp; license required
+</EnterpriseAlert>