[DOCS] Add GUI for Azure/AWS/GCP Secret Engines configuration (#29647)

* wip

* finish azure docs

* some fixes

* get role heading to where it was

* Apply suggestions from code review

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

* Update website/content/docs/secrets/azure.mdx

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

* pr comments

* add aws

* gcp configuration

* fix formatting

* remove indents for parser

* formatting fixed?

* Update website/content/docs/secrets/gcp.mdx

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

* Apply suggestions from code review

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

* try again

* might be the end of me

* tried running npm run format and got some promising results

* missed

* this should work

* numbering fixes

* Apply suggestions from code review

add group="gui"

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

* Update azure.mdx

change heading to match

---------

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

website/content/docs/secrets/aws.mdx

@@ -53,26 +53,81 @@ Most secrets engines must be configured in advance before they can perform their
 functions. These steps are usually completed by an operator or configuration
 management tool.
 
-1.  Enable the AWS secrets engine:
+Enable the AWS secrets engine:
 
-    ```text
+<Tabs>
-    $ vault secrets enable aws
+
-    Success! Enabled the aws secrets engine at: aws/
+<Tab heading="CLI"  group="cli">
+
+```shell-session
+$ vault secrets enable gcp
+Success! Enabled the gcp secrets engine at: gcp/
 ```
 
 By default, the secrets engine will mount at the name of the engine. To
 enable the secrets engine at a different path, use the `-path` argument.
 
-1.  Configure the credentials that Vault uses to communicate with AWS to generate
+</Tab>
-    the IAM credentials:
 
-    ```text
+<Tab heading="GUI"  group="gui">
+
+![Partial screenshot of the Vault GUI showing the "Identity token key" search select input](/img/gui/aws/identityTokenKey.png)
+
+You must have `list` permission on the `identity/oidc/key` endpoint to view
+existing workload identity federation (WIF) identity token keys during setup.
+
+1. Open the web UI for your Vault instance.
+1. Login under the target namespace or choose the target namespace from the
+   selector at the bottom of the left-hand menu and re-authenticate.
+1. Select **Secrets Engines** from the left-hand menu.
+1. Click **Enable new engine +** on the **Secrets Engines** page.
+1. Select **AWS**.
+1. Click **Next**.
+1. Set the mount path for the AWS plugin. For example, `aws`.
+1. If you use WIF, add the identity token key:
+   - Click **Method Options**.
+   - Click **Identity Token Key**.
+   - Enter your new key name or select one from the token key list.
+1. Click **Enable engine**.
+1. Click **Save** to enable the plugin.
+
+</Tab>
+
+</Tabs>
+
+Configure the credentials that Vault uses to communicate with AWS to generate the IAM credentials:
+
+<Tabs>
+
+<Tab heading="CLI"  group="cli">
+
+```shell-session
 $ vault write aws/config/root \
     access_key=AKIAJWVN5Z4FOFT7NLNA \
     secret_key=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 \
     region=us-east-1
 ```
 
+</Tab>
+
+<Tab heading="GUI"  group="gui">
+
+![Partial screenshot of the Vault GUI showing the Configuration form](/img/gui/aws/configure.png)
+
+1. Open the web UI for your Vault instance.
+1. Login under the target namespace or choose the target namespace from the
+   selector at the bottom of the left-hand menu and re-authenticate.
+1. Select **Secrets Engines** from the left-hand menu.
+1. Select your `aws` plugin you want to update.
+1. Click **Configure**.
+1. Enter your configuration information.
+1. Set the access type <EnterpriseAlert inline="true" />
+1. Save your changes.
+
+</Tab>
+
+</Tabs>
+
 Internally, Vault will connect to AWS using these credentials. As such,
 these credentials must be a superset of any policies which might be granted
 on IAM credentials. Since Vault uses the official AWS SDK, it will use the
@@ -94,14 +149,34 @@ management tool.
 your AWS root account credentials. Instead, generate a dedicated user or
 role.
 
-1.  Alternatively, configure the audience claim value and the role ARN to assume for plugin workload identity federation:
+Alternatively, configure the audience claim value and the role ARN to assume for plugin workload identity federation:
 
-    ```text
+<Tabs>
+
+<Tab heading="CLI"  group="cli">
+
+```shell-session
 $ vault write aws/config/root \
     identity_token_audience="<TOKEN AUDIENCE>" \
     role_arn="<AWS ROLE ARN>"
 ```
 
+</Tab>
+
+<Tab heading="GUI"  group="gui">
+
+Select **Workload Identity Federation** for Access Type and enter the following information:
+![Partial screenshot of the Vault GUI showing the Configuration form with WIF access type selected](/img/gui/aws/configure-wif.png)
+
+- **Issuer URL**: The fully qualified and network-reachable issuer URL for the Vault plugin identity token issuer. For example, `https://vault.example.com/v1/identity/oidc/plugins`.
+- **Role ARN**: The ARN of the AWS IAM role to assume.
+- **Identity token audience**: The audience claim value for the plugin identity tokens. This value must match the allowed audiences configured for the target Federated Identity Credential.
+
+</Tab>
+
+</Tabs>
+
+## Role setup
 Vault's identity token provider will internally sign the plugin identity token JWT.
 Given a trust relationship is configured between Vault and AWS via
 Web Identity Federation, the secrets engine can exchange this identity token to obtain

website/content/docs/secrets/azure.mdx

@@ -35,9 +35,13 @@ Most secrets engines must be configured in advance before they can perform their
 functions. These steps are usually completed by an operator or configuration
 management tool.
 
-1. Enable the Azure secrets engine:
+Enable the Azure secrets engine:
 
-   ```shell
+<Tabs>
+
+<Tab heading="CLI"  group="cli">
+
+```shell-session
 $ vault secrets enable azure
 Success! Enabled the azure secrets engine at: azure/
 ```
@@ -45,9 +49,41 @@ management tool.
 By default, the secrets engine will mount at the name of the engine. To
 enable the secrets engine at a different path, use the `-path` argument.
 
-1. Configure the secrets engine with account credentials:
+</Tab>
 
-   ```shell
+<Tab heading="GUI"  group="gui">
+
+![Partial screenshot of the Vault GUI showing the "Identity token key" search select input](/img/gui/azure/identityTokenKey.png)
+
+You must have `list` permission on the `identity/oidc/key` endpoint to view
+existing workload identity federation (WIF) identity token keys during setup.
+
+1. Open the web UI for your Vault instance.
+1. Login under the target namespace or choose the target namespace from the
+   selector at the bottom of the left-hand menu and re-authenticate.
+1. Select **Secrets Engines** from the left-hand menu.
+1. Click **Enable new engine +** on the **Secrets Engines** page.
+1. Select **Azure**.
+1. Click **Next**.
+1. Set the mount path for the Azure plugin. For example, `azure`.
+1. If you use WIF, add the identity token key:
+   - Click **Method Options**.
+   - Click **Identity Token Key**.
+   - Enter your new key name or select one from the token key list.
+1. Click **Enable engine**.
+1. Click **Save** to enable the plugin.
+
+</Tab>
+
+</Tabs>
+
+Configure the secrets engine with account credentials:
+
+<Tabs>
+
+<Tab heading="CLI"  group="cli">
+
+```shell-session
 $ vault write azure/config \
     subscription_id=$AZURE_SUBSCRIPTION_ID \
     tenant_id=$AZURE_TENANT_ID \
@@ -57,20 +93,41 @@ management tool.
 Success! Data written to: azure/config
 ```
 
-   If you are running Vault inside an Azure VM with MSI enabled, `client_id` and
+</Tab>
-   `client_secret` may be omitted. For more information on authentication, see the [authentication](#authentication) section below.
 
-   In some cases, you cannot set sensitive account credentials in your
+<Tab heading="GUI"  group="gui">
-   Vault configuration. For example, your organization may require that all
+
-   security credentials are short-lived or explicitly tied to a machine identity.
+![Partial screenshot of the Vault GUI showing the Configuration form](/img/gui/azure/configure.png)
+
+1. Open the web UI for your Vault instance.
+1. Login under the target namespace or choose the target namespace from the
+   selector at the bottom of the left-hand menu and re-authenticate.
+1. Select **Secrets Engines** from the left-hand menu.
+1. Select your `azure` plugin you want to update.
+1. Click **Configure**.
+1. Enter your configuration information.
+1. Set the access type <EnterpriseAlert inline="true" />
+1. Save your changes.
+
+</Tab>
+
+</Tabs>
+
+If you are running Vault inside an Azure VM with MSI enabled, `client_id` and `client_secret` may be omitted. For more information on authentication, see the [authentication](#authentication) section below.
+
+In some cases, you cannot set sensitive account credentials in your Vault configuration. For example, your organization may require that all security credentials are short-lived or explicitly tied to a machine identity.
 
 To provide managed identity security credentials to Vault, we recommend using Vault
 [plugin workload identity federation](#plugin-workload-identity-federation-wif)
 (WIF) as shown below.
 
-1.  Alternatively, configure the audience claim value and the Client, Tenant and Subscription IDs for plugin workload identity federation:
+Alternatively, configure the audience claim value and the Client, Tenant and Subscription IDs for plugin workload identity federation:
 
-   ```text
+<Tabs>
+
+<Tab heading="CLI"  group="cli">
+
+```shell-session
 $ vault write azure/config \
     subscription_id=$AZURE_SUBSCRIPTION_ID \
     tenant_id=$AZURE_TENANT_ID \
@@ -78,6 +135,22 @@ management tool.
     identity_token_audience=$TOKEN_AUDIENCE
 ```
 
+</Tab>
+
+<Tab heading="GUI"  group="gui">
+
+For WIF configuration, select **Workload Identity Federation** for Access Type and enter the following information:
+  ![Partial screenshot of the Vault GUI showing the Configuration form with WIF access type selected](/img/gui/azure/configure-wif.png)
+  - **Subscription ID**: The ID of the Azure subscription.
+  - **Tenant ID**: The ID of the Azure Active Directory tenant.
+  - **Client ID**: The OAuth2 client id to connect to Azure.
+  - **Issuer URL**: The fully qualified and network-reachable issuer URL for the Vault plugin identity token issuer. For example, `https://vault.example.com/v1/identity/oidc/plugins`.
+  - **Identity token audience**: The audience claim value for the plugin identity tokens. This value must match the allowed audiences configured for the target Federated Identity Credential. Mutually exclusive with `client_secret`.
+
+</Tab>
+
+</Tabs>
+
 The Vault identity token provider signs the plugin identity token JWT internally.
 If a trust relationship exists between Vault and Azure through WIF, the secrets
 engine can exchange the Vault identity token for a federated access token.
@@ -97,8 +170,12 @@ management tool.
 [public keys](/vault/api-docs/secret/identity/tokens#read-active-public-keys)
 and verify the plugin identity token signature.
 
-1. Configure a role. A role may be set up with either an existing service principal, or
+Configure a role. A role may be set up with either an existing service principal, or a set of Azure roles that will be assigned to a dynamically created service principal.
-   a set of Azure roles that will be assigned to a dynamically created service principal.
+
+<Note>
+  The Vault UI only supports Azure Secret engine configuration. You must use the
+  CLI/API for role configuration and credential rotation.
+</Note>
 
 To configure a role called "my-role" with an existing service principal:
 

website/content/docs/secrets/gcp.mdx

@@ -38,7 +38,11 @@ Most secrets engines must be configured in advance before they can perform their
 functions. These steps are usually completed by an operator or configuration
 management tool.
 
-1.  Enable the Google Cloud secrets engine:
+Enable the Google Cloud secrets engine:
+
+<Tabs>
+
+<Tab heading="CLI"  group="cli">
 
 ```shell-session
 $ vault secrets enable gcp
@@ -48,14 +52,65 @@ management tool.
 By default, the secrets engine will mount at the name of the engine. To
 enable the secrets engine at a different path, use the `-path` argument.
 
-1.  Configure the secrets engine with account credentials, or leave blank or unwritten
+</Tab>
-    to use Application Default Credentials.
+
+<Tab heading="GUI"  group="gui">
+
+![Partial screenshot of the Vault GUI showing the "Identity token key" search select input](/img/gui/gcp/identityTokenKey.png)
+
+You must have `list` permission on the `identity/oidc/key` endpoint to view
+existing workload identity federation (WIF) identity token keys during setup.
+
+1. Open the web UI for your Vault instance.
+1. Login under the target namespace or choose the target namespace from the
+   selector at the bottom of the left-hand menu and re-authenticate.
+1. Select **Secrets Engines** from the left-hand menu.
+1. Click **Enable new engine +** on the **Secrets Engines** page.
+1. Select **Google Cloud**.
+1. Click **Next**.
+1. Set the mount path for the GCP plugin. For example, `gcp`.
+1. If you use WIF, add the identity token key:
+   - Click **Method Options**.
+   - Click **Identity Token Key**.
+   - Enter your new key name or select one from the token key list.
+1. Click **Enable engine**.
+1. Click **Save** to enable the plugin.
+
+</Tab>
+
+</Tabs>
+
+Configure the secrets engine with account credentials, or leave blank or unwritten to use Application Default Credentials:
+
+<Tabs>
+
+<Tab heading="CLI"  group="cli">
 
 ```shell-session
 $ vault write gcp/config credentials=@my-credentials.json
 Success! Data written to: gcp/config
 ```
 
+</Tab>
+
+<Tab heading="GUI"  group="gui">
+
+![Partial screenshot of the Vault GUI showing the Configuration form](/img/gui/gcp/configure.png)
+
+1. Open the web UI for your Vault instance.
+1. Login under the target namespace or choose the target namespace from the
+   selector at the bottom of the left-hand menu and re-authenticate.
+1. Select **Secrets Engines** from the left-hand menu.
+1. Select your `gcp` plugin you want to update.
+1. Click **Configure**.
+1. Enter your configuration information.
+1. Set the access type <EnterpriseAlert inline="true" />
+1. Save your changes.
+
+</Tab>
+
+</Tabs>
+
 If you are running Vault from inside [Google Compute Engine][gce] or [Google
 Kubernetes Engine][gke], the instance or pod service account can be used in
 place of specifying the credentials JSON file.
@@ -69,15 +124,33 @@ management tool.
 [plugin workload identity federation](#plugin-workload-identity-federation-wif)
 (WIF) as shown below.
 
+Alternatively, configure the audience claim value and the service account email to assume for plugin workload identity federation:
 
-1.  Alternatively, configure the audience claim value and the service account email to assume for plugin workload identity federation:
+<Tabs>
 
-    ```text
+<Tab heading="CLI"  group="cli">
+
+```shell-session
 $ vault write gcp/config \
-        identity_token_audience="<TOKEN AUDIENCE>" \
+    identity_token_audience=<TOKEN_AUDIENCE> \
-        service_account_email="<SERVICE ACCOUNT EMAIL>"
+    service_account_email=<SERVICE_ACCOUNT_EMAIL>
 ```
 
+</Tab>
+
+<Tab heading="GUI"  group="gui">
+
+Select **Workload Identity Federation** for Access Type and enter the following information:
+![Partial screenshot of the Vault GUI showing the Configuration form with WIF access type selected](/img/gui/gcp/configure-wif.png)
+
+- **Issuer URL**: The fully qualified and network-reachable issuer URL for the Vault plugin identity token issuer. For example, `https://vault.example.com/v1/identity/oidc/plugins`.
+- **Identity token audience**: The audience claim value for the plugin identity tokens. This value must match the allowed audiences configured for the target Federated Identity Credential.
+- **Service account email**: Email ID for the Service Account to impersonate for Workload Identity Federation.
+
+</Tab>
+
+</Tabs>
+
 Vault's identity token provider signs the plugin identity token JWT internally.
 If a trust relationship exists between Vault and GCP through WIF, the secrets
 engine can exchange the Vault identity token for a
@@ -97,7 +170,10 @@ management tool.
 [public keys](/vault/api-docs/secret/identity/tokens#read-active-public-keys)
 and verify the plugin identity token signature.
 
-1. Configure rolesets or static accounts. See the relevant sections below.
+<Note>
+  The Vault UI only supports GCP Secret engine configuration. You must use the
+  CLI/API for additional operations.
+</Note>
 
 ## Rolesets