Hashicorp Vault Fails to Verify if Approle SecretID Belongs to Role During a Destroy Operation

@@ -0,0 +1,107 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods - Google
+description: OIDC provider configuration for Google
+---
+ 
+## Google
+ 
+Main reference: [Using OAuth 2.0 to Access Google APIs](https://developers.google.com/identity/protocols/OAuth2)
+ 
+1. Visit the [Google API Console](https://console.developers.google.com).
+1. Create or a select a project.
+1. Create a new credential via Credentials > Create Credentials > OAuth Client ID.
+1. Configure the OAuth Consent Screen. Application Name is required. Save.
+1. Select application type: "Web Application".
+1. Configure Authorized Redirect URIs.
+1. Save client ID and secret.
+ 
+### Optional Google-specific Configuration
+ 
+Google-specific configuration is available when using Google as an identity provider from the
+Vault JWT/OIDC auth method. The configuration allows Vault to obtain Google Workspace group membership and
+user information during the JWT/OIDC authentication flow. The group membership obtained from Google Workspace
+may be used for Identity group alias association. The user information obtained from Google Workspace can be
+used to copy claims data into resulting auth token and alias metadata via [claim_mappings](/api-docs/auth/jwt#claim_mappings).
+ 
+#### Setup
+ 
+To set up the Google-specific handling, you'll need:
+ 
+- A Google Workspace account with the [super admin role](https://support.google.com/a/answer/2405986?hl=en)
+  for granting domain-wide delegation API client access.
+- The ability to create a service account in [Google Cloud Platform](https://console.developers.google.com/iam-admin/serviceaccounts).
+- To enable the [Admin SDK API](https://console.developers.google.com/apis/api/admin.googleapis.com/overview).
+- An OAuth 2.0 application with an [external user type](https://support.google.com/cloud/answer/10311615#user-type).
+ 
+The Google-specific handling that's used to fetch Google Workspace groups and user information in Vault uses
+[Google Workspace Domain-Wide Delegation of Authority](https://developers.google.com/admin-sdk/directory/v1/guides/delegation)
+for authentication and authorization. You need to follow **all steps** in the [guide](https://developers.google.com/admin-sdk/directory/v1/guides/delegation)
+to obtain the key file for a Google service account capable of making requests to the Google Workspace
+[User Accounts](https://developers.google.com/admin-sdk/directory/v1/guides/manage-users) and
+[Groups](https://developers.google.com/admin-sdk/directory/v1/guides/manage-groups) APIs.
+ 
+In **step 5** within the section titled
+[Delegate domain-wide authority to your service account](https://developers.google.com/admin-sdk/directory/v1/guides/delegation#delegate_domain-wide_authority_to_your_service_account),
+the only OAuth scopes that should be granted are:
+ 
+- `https://www.googleapis.com/auth/admin.directory.group.readonly`
+- `https://www.googleapis.com/auth/admin.directory.user.readonly`
+ 
+~> This is an **important security step** in order to give the service account the least set of privileges
+that enable the feature.
+ 
+The Google service account key file obtained from the steps in the guide must be made available on the
+host that Vault is running on.
+ 
+#### Configuration
+ 
+- `provider` `(string: <required>)` - Name of the provider. Must be set to "gsuite".
+- `gsuite_service_account` `(string: <required>)` - Either the path to or the contents of a Google service
+  account key file in JSON format. If given as a file path, it must refer to a file that's readable on
+  the host that Vault is running on. If given directly as JSON contents, the JSON must be properly escaped.
+- `gsuite_admin_impersonate` `(string: <required>)` - Email address of a Google Workspace admin to impersonate.
+- `fetch_groups` `(bool: false)` - If set to true, groups will be fetched from Google Workspace.
+- `fetch_user_info` `(bool: false)` - If set to true, user info will be fetched from Google Workspace using the configured [user_custom_schemas](#user_custom_schemas).
+- `groups_recurse_max_depth` `(int: <optional>)` - Group membership recursion max depth. Defaults to 0, which means don't recurse.
+- `user_custom_schemas` `(string: <optional>)` - Comma-separated list of Google Workspace [custom schemas](https://developers.google.com/admin-sdk/directory/v1/guides/manage-schemas).
+  Values set for Google Workspace users using custom schema fields will be fetched and made available as claims that can be used with [claim_mappings](/api-docs/auth/jwt#claim_mappings). Required if [fetch_user_info](#fetch_user_info) is set to true.
+ 
+Example configuration:
+ 
+```
+vault write auth/oidc/config -<<EOF
+{
+    "oidc_discovery_url": "https://accounts.google.com",
+    "oidc_client_id": "your_client_id",
+    "oidc_client_secret": "your_client_secret",
+    "default_role": "your_default_role",
+    "provider_config": {
+        "provider": "gsuite",
+        "gsuite_service_account": "/path/to/service-account.json",
+        "gsuite_admin_impersonate": "admin@gsuitedomain.com",
+        "fetch_groups": true,
+        "fetch_user_info": true,
+        "groups_recurse_max_depth": 5,
+        "user_custom_schemas": "Education,Preferences"
+    }
+}
+EOF
+```
+ 
+#### Role
+ 
+The [user_claim](/api-docs/auth/jwt#user_claim) value of the role must be set to
+one of either `sub` or `email` for the Google Workspace group and user information
+queries to succeed.
+ 
+Example role:
+ 
+```
+vault write auth/oidc/role/your_default_role \
+    allowed_redirect_uris="http://localhost:8200/ui/vault/auth/oidc/oidc/callback,http://localhost:8250/oidc/callback" \
+    user_claim="sub" \
+    groups_claim="groups" \
+    claim_mappings="/Education/graduation_date"="graduation_date" \
+    claim_mappings="/Preferences/shirt_size"="shirt_size"
+```

@@ -0,0 +1,228 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods - Kubernetes
+description: OIDC provider configuration for Kubernetes
+---
+ 
+## Kubernetes
+ 
+Kubernetes can function as an OIDC provider such that Vault can validate its
+service account tokens using JWT/OIDC auth.
+ 
+-> **Note:** The JWT auth engine does **not** use Kubernetes' `TokenReview` API
+during authentication, and instead uses public key cryptography to verify the
+contents of JWTs. This means tokens that have been revoked by Kubernetes will
+still be considered valid by Vault until their expiry time. To mitigate this
+risk, use short TTLs for service account tokens or use
+[Kubernetes auth](/docs/auth/kubernetes) which _does_ use the `TokenReview` API.
+ 
+### Using service account issuer discovery
+ 
+When using service account issuer discovery, you only need to provide the JWT
+auth mount with an OIDC discovery URL, and sometimes a TLS certificate authority
+to trust. This makes it the most straightforward method to configure if your
+Kubernetes cluster meets the requirements.
+ 
+Kubernetes cluster requirements:
+ 
+* [`ServiceAccountIssuerDiscovery`][k8s-sa-issuer-discovery] feature enabled.
+  * Present from 1.18, defaults to enabled from 1.20.
+* kube-apiserver's `--service-account-issuer` flag is set to a URL that is
+  reachable from Vault. Public by default for most managed Kubernetes solutions.
+* Must use short-lived service account tokens when logging in.
+  * Tokens mounted into pods default to short-lived from 1.21.
+ 
+Configuration steps:
+ 
+1. Ensure OIDC discovery URLs do not require authentication, as detailed
+   [here][k8s-sa-issuer-discovery]:
+ 
+   ```bash
+   kubectl create clusterrolebinding oidc-reviewer  \
+      --clusterrole=system:service-account-issuer-discovery \
+      --group=system:unauthenticated
+   ```
+ 
+1. Find the issuer URL of the cluster.
+ 
+   ```bash
+   ISSUER="$(kubectl get --raw /.well-known/openid-configuration | jq -r '.issuer')"
+   ```
+ 
+1. Enable and configure JWT auth in Vault.
+ 
+  1. If Vault is running in Kubernetes:
+ 
+     ```bash
+     kubectl exec vault-0 -- vault auth enable jwt
+     kubectl exec vault-0 -- vault write auth/jwt/config \
+        oidc_discovery_url=https://kubernetes.default.svc.cluster.local \
+        oidc_discovery_ca_pem=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
+     ```
+ 
+  1. Alternatively, if Vault is _not_ running in Kubernetes:
+ 
+     -> **Note:** When Vault is outside the cluster, the `$ISSUER` endpoint below may
+     or may not be reachable. If not, you can configure JWT auth using
+     [`jwt_validation_pubkeys`](#using-jwt-validation-public-keys) instead.
+ 
+     ```bash
+     vault auth enable jwt
+     vault write auth/jwt/config oidc_discovery_url="${ISSUER}"
+     ```
+ 
+1. Configure a role and log in as detailed [below](#creating-a-role-and-logging-in).
+ 
+[k8s-sa-issuer-discovery]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery
+ 
+### Using JWT validation public keys
+ 
+This method can be useful if Kubernetes' API is not reachable from Vault or if
+you would like a single JWT auth mount to service multiple Kubernetes clusters
+by chaining their public signing keys.
+ 
+Kubernetes cluster requirements:
+ 
+* [`ServiceAccountIssuerDiscovery`][k8s-sa-issuer-discovery] feature enabled.
+  * Present from 1.18, defaults to enabled from 1.20.
+  * This requirement can be avoided if you can access the Kubernetes master
+    nodes to read the public signing key directly from disk at
+    `/etc/kubernetes/pki/sa.pub`. In this case, you can skip the steps to
+    retrieve and then convert the key as it will already be in PEM format.
+* Must use short-lived service account tokens when logging in.
+  * Tokens mounted into pods default to short-lived from 1.21.
+ 
+Configuration steps:
+ 
+1. Fetch the service account signing public key from your cluster's JWKS URI.
+ 
+   ```bash
+   # Query the jwks_uri specified in /.well-known/openid-configuration
+   kubectl get --raw "$(kubectl get --raw /.well-known/openid-configuration | jq -r '.jwks_uri' | sed -r 's/.*\.[^/]+(.*)/\1/')"
+   ```
+ 
+1. Convert the keys from JWK format to PEM. You can use a CLI tool or an online
+   converter such as [this one][jwk-to-pem].
+ 
+1. Configure the JWT auth mount with those public keys.
+ 
+   ```bash
+   vault write auth/jwt/config \
+      jwt_validation_pubkeys="-----BEGIN PUBLIC KEY-----
+   MIIBIjANBgkqhkiG9...
+   -----END PUBLIC KEY-----","-----BEGIN PUBLIC KEY-----
+   MIIBIjANBgkqhkiG9...
+   -----END PUBLIC KEY-----"
+   ```
+ 
+1. Configure a role and log in as detailed [below](#creating-a-role-and-logging-in).
+ 
+[jwk-to-pem]: https://8gwifi.org/jwkconvertfunctions.jsp
+ 
+### Creating a role and logging in
+ 
+Once your JWT auth mount is configured, you're ready to configure a role and
+log in. The following assumes you use the projected service account token
+available in all pods by default. See [Specifying TTL and audience](#specifying-ttl-and-audience)
+below if you'd like to control the audience or TTL.
+ 
+1. Choose any value from the array of default audiences. In these examples,
+   there is only one audience in the `aud` array,
+   `https://kubernetes.default.svc.cluster.local`.
+ 
+   To find the default audiences, either create a fresh token (requires
+   `kubectl` v1.24.0+):
+ 
+   ```shell-session
+   $ kubectl create token default | cut -f2 -d. | base64 --decode
+   {"aud":["https://kubernetes.default.svc.cluster.local"], ... "sub":"system:serviceaccount:default:default"}
+   ```
+ 
+   Or read a token from a running pod's filesystem:
+ 
+   ```shell-session
+   $ kubectl exec my-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token | cut -f2 -d. | base64 --decode
+   {"aud":["https://kubernetes.default.svc.cluster.local"], ... "sub":"system:serviceaccount:default:default"}
+   ```
+ 
+1. Create a role for JWT auth that the `default` service account from the
+   `default` namespace can use.
+ 
+   ```bash
+   vault write auth/jwt/role/my-role \
+      role_type="jwt" \
+      bound_audiences="<AUDIENCE-FROM-PREVIOUS-STEP>" \
+      user_claim="sub" \
+      bound_subject="system:serviceaccount:default:default" \
+      policies="default" \
+      ttl="1h"
+   ```
+ 
+1. Pods or other clients with access to a service account JWT can then log in.
+ 
+   ```bash
+   vault write auth/jwt/login \
+      role=my-role \
+      jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token
+   # OR equivalent to:
+   curl \
+      --fail \
+      --request POST \
+      --header "X-Vault-Request: true" \
+      --data '{"jwt":"<JWT-TOKEN-HERE>","role":"my-role"}' \
+      "${VAULT_ADDR}/v1/auth/jwt/login"
+   ```
+ 
+### Specifying TTL and audience
+ 
+If you would like to specify a custom TTL or audience for service account tokens,
+the following pod spec illustrates a volume mount that overrides the default
+admission injected token. This is especially relevant if you are unable to
+disable the [--service-account-extend-token-expiration][k8s-extended-tokens]
+flag for `kube-apiserver` and want to use short TTLs.
+ 
+When using the resulting token, you will need to set `bound_audiences=vault`
+when creating roles in Vault's JWT auth mount.
+ 
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  # automountServiceAccountToken is redundant in this example because the
+  # mountPath used overlaps with the default path. The overlap stops the default
+  # admission injected token from being created. You can use this option to
+  # ensure only a single token is mounted if you choose a different mount path.
+  automountServiceAccountToken: false
+  containers:
+    - name: nginx
+      image: nginx
+      volumeMounts:
+      - name: custom-token
+        mountPath: /var/run/secrets/kubernetes.io/serviceaccount
+  volumes:
+  - name: custom-token
+    projected:
+      defaultMode: 420
+      sources:
+      - serviceAccountToken:
+          path: token
+          expirationSeconds: 600 # 10 minutes is the minimum TTL
+          audience: vault        # Must match your JWT role's `bound_audiences`
+      # The remaining sources are included to mimic the rest of the default
+      # admission injected volume.
+      - configMap:
+          name: kube-root-ca.crt
+          items:
+          - key: ca.crt
+            path: ca.crt
+      - downwardAPI:
+          items:
+          - fieldRef:
+              apiVersion: v1
+              fieldPath: metadata.namespace
+            path: namespace
+```
+ 
+[k8s-extended-tokens]: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/#options

@@ -1033,3 +1033,310 @@ func TestLoadConfigFile_EnforceConsistency(t *testing.T) {
 		t.Fatal(diff)
 	}
 }
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_All(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-all.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"auto-auth", "caching", "templating"},
+		DisableIdleConnsCaching:    true,
+		DisableIdleConnsAutoAuth:   true,
+		DisableIdleConnsTemplating: true,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Auto_Auth(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-auto-auth.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"auto-auth"},
+		DisableIdleConnsCaching:    false,
+		DisableIdleConnsAutoAuth:   true,
+		DisableIdleConnsTemplating: false,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Templating(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-templating.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"templating"},
+		DisableIdleConnsCaching:    false,
+		DisableIdleConnsAutoAuth:   false,
+		DisableIdleConnsTemplating: true,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Caching(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-caching.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"caching"},
+		DisableIdleConnsCaching:    true,
+		DisableIdleConnsAutoAuth:   false,
+		DisableIdleConnsTemplating: false,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Empty(t *testing.T) {
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-empty.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{},
+		DisableIdleConnsCaching:    false,
+		DisableIdleConnsAutoAuth:   false,
+		DisableIdleConnsTemplating: false,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Disable_Idle_Conns_Env(t *testing.T) {
+	err := os.Setenv(DisableIdleConnsEnv, "auto-auth,caching,templating")
+	defer os.Unsetenv(DisableIdleConnsEnv)
+ 
+	if err != nil {
+		t.Fatal(err)
+	}
+	config, err := LoadConfig("./test-fixtures/config-disable-idle-connections-empty.hcl")
+	if err != nil {
+		t.Fatal(err)
+	}
+ 
+	expected := &Config{
+		SharedConfig: &configutil.SharedConfig{
+			PidFile: "./pidfile",
+		},
+		DisableIdleConns:           []string{"auto-auth", "caching", "templating"},
+		DisableIdleConnsCaching:    true,
+		DisableIdleConnsAutoAuth:   true,
+		DisableIdleConnsTemplating: true,
+		AutoAuth: &AutoAuth{
+			Method: &Method{
+				Type:      "aws",
+				MountPath: "auth/aws",
+				Namespace: "my-namespace/",
+				Config: map[string]interface{}{
+					"role": "foobar",
+				},
+			},
+			Sinks: []*Sink{
+				{
+					Type:   "file",
+					DHType: "curve25519",
+					DHPath: "/tmp/file-foo-dhpath",
+					AAD:    "foobar",
+					Config: map[string]interface{}{
+						"path": "/tmp/file-foo",
+					},
+				},
+			},
+		},
+		Vault: &Vault{
+			Address: "http://127.0.0.1:1111",
+			Retry: &Retry{
+				ctconfig.DefaultRetryAttempts,
+			},
+		},
+	}
+ 
+	config.Prune()
+	if diff := deep.Equal(config, expected); diff != nil {
+		t.Fatal(diff)
+	}
+}
+ 
+func TestLoadConfigFile_Bad_Value_Disable_Idle_Conns(t *testing.T) {
+	_, err := LoadConfig("./test-fixtures/bad-config-disable-idle-connections.hcl")
+	if err == nil {
+		t.Fatal("should have error, it didn't")
+	}
+}

@@ -0,0 +1,127 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods - Azure Active Directory
+description: OIDC provider configuration for Azure Active Directory
+---
+ 
+## Azure Active Directory (AAD)
+ 
+~> **Note:** Azure Active Directory Applications that have custom signing keys as a result of using
+the [claims-mapping](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-claims-mapping)
+feature are currently not supported for OIDC authentication.
+ 
+Reference: [Azure Active Directory v2.0 and the OpenID Connect protocol](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc)
+ 
+1. Choose your Azure tenant.
+ 
+1. Go to **Azure Active Directory** and
+   [register an application](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app)
+   for Vault.
+ 
+1. Add Redirect URIs with the "Web" type. You may include two redirect URIs,
+   one for CLI access another one for Vault UI access.
+  - `http://localhost:8250/oidc/callback`
+  - `https://hostname:port_number/ui/vault/auth/oidc/oidc/callback`
+ 
+1. Record the "Application (client) ID" as you will need it as the `oidc_client_id`.
+ 
+1. Under **Endpoints**, copy the OpenID Connect metadata document URL, omitting the `/well-known...` portion.
+  - The endpoint URL (`oidc_discovery_url`) will look like: https://login.microsoftonline.com/tenant-guid-dead-beef-aaaa-aaaa/v2.0
+ 
+1. Under **Certificates & secrets**,
+   [add a client secret](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#add-a-client-secret)
+   Record the secret's value as you will need it as the `oidc_client_secret` for Vault.
+ 
+### Connect AD group with Vault external group
+ 
+Reference: [Azure Active Directory with OIDC Auth Method and External Groups](https://learn.hashicorp.com/tutorials/vault/oidc-auth-azure)
+ 
+To connect the AD group with a [Vault external groups](/docs/secrets/identity#external-vs-internal-groups),
+you will need
+[Azure AD v2.0 endpoints](https://docs.microsoft.com/en-gb/azure/active-directory/develop/azure-ad-endpoint-comparison).
+You should set up a [Vault policy](https://learn.hashicorp.com/tutorials/vault/policies) for the Azure AD group to use.
+ 
+1. Go to **Azure Active Directory** and choose your Vault application.
+ 
+1. Go to **Token configuration** and **Add groups claim**. Select "All" or "SecurityGroup" based on
+   [which groups for a user](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims)
+   you want returned in the claim.
+ 
+1. In Vault, enable the OIDC auth method.
+ 
+1. Configure the OIDC auth method with the `oidc_client_id` (application ID), `oidc_client_secret`
+   (client secret), and `oidc_discovery_url` (endpoint URL) you recorded from Azure.
+   ```shell
+   vault write auth/oidc/config \
+      oidc_client_id="your_client_id" \
+      oidc_client_secret="your_client_secret" \
+      default_role="your_default_role" \
+      oidc_discovery_url="https://login.microsoftonline.com/tenant_id/v2.0"
+   ```
+ 
+1. Configure the [OIDC Role](/api-docs/auth/jwt#create-role) with the following:
+  - `user_claim` should be `"sub"` or `"oid"` following the
+  [recommendation](https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens#using-claims-to-reliably-identify-a-user-subject-and-object-id)
+  from Azure.
+  - `allowed_redirect_uris` should be the two redirect URIs for Vault CLI and UI access.
+  - `groups_claim` should be set to `"groups"`.
+  - `oidc_scopes` should be set to `"https://graph.microsoft.com/.default"`.
+   ```shell
+   vault write auth/oidc/role/your_default_role \
+      user_claim="sub" \
+      allowed_redirect_uris="http://localhost:8250/oidc/callback,https://online_version_hostname:port_number/ui/vault/auth/oidc/oidc/callback"  \
+      groups_claim="groups" \
+      oidc_scopes="https://graph.microsoft.com/.default" \
+      policies=default
+   ```
+ 
+1. In Vault, create the [external group](/api-docs/secret/identity/group).
+   Record the group ID as you will need it for the group alias.
+ 
+1. From Vault, retrieve the [OIDC accessor ID](/api-docs/system/auth#list-auth-methods)
+   from the OIDC auth method as you will need it for the group alias's `mount_accessor`.
+ 
+1. Go to the Azure AD Group you want to attach to Vault's external group. Record the `objectId`
+   as you will need it as the group alias name in Vault.
+ 
+1. In Vault, create a [group alias](/api-docs/secret/identity/group-alias)
+   for the external group and set the `objectId` as the group alias name.
+   ```shell
+   vault write identity/group-alias \
+      name="your_ad_group_object_id" \
+      mount_accessor="vault_oidc_accessor_id" \
+      canonical_id="vault_external_group_id"
+   ```
+ 
+### Optional Azure-specific Configuration
+ 
+If a user is a member of more than 200 groups (directly or indirectly), extra configuration
+is required so that Vault can fetch the groups properly.
+ 
+- In Azure, under the applications **API Permissions**, grant the following permissions:
+  - Microsoft Graph API permission [Directory.Read.All](https://docs.microsoft.com/en-us/graph/permissions-reference#application-permissions-19)
+ 
+- In Vault, set `"provider_config"` to Azure.
+  ```shell
+  vault write auth/oidc/config -<<"EOH"
+  {
+     "oidc_client_id": "your_client_id",
+     "oidc_client_secret": "your_client_secret",
+     "default_role": "your_default_role",
+     "oidc_discovery_url": "https://login.microsoftonline.com/tenant_id/v2.0",
+     "provider_config": {
+        "provider": "azure"
+     }
+  }
+  EOH
+  ```
+ 
+- In Vault, add `"profile"` to `oidc_scopes` so the user's id comes back on the JWT.
+  ```shell
+  vault write auth/oidc/role/your_default_role \
+   user_claim="email" \
+   allowed_redirect_uris="http://localhost:8250/oidc/callback,https://online_version_hostname:port_number/ui/vault/auth/oidc/oidc/callback"  \
+   groups_claim="groups" \
+   oidc_scopes="profile" \
+   policies="default"
+  ```

@@ -9,17 +9,36 @@ description: >-
  
 ## What is Vault?
  
-Vault is an identity-based **secrets** and encryption management system. A secret is anything that you want to tightly control access to, such as API encryption keys, passwords, or certificates. Vault provides encryption services that are gated by authentication and authorization methods. Using Vault’s UI, CLI, or HTTP API, access to secrets and other sensitive data can be securely stored and managed, tightly controlled (restricted), and auditable.
+HashiCorp Vault is an identity-based secrets and encryption management system. A _secret_ is anything that you want to tightly control access to, such as API encryption keys, passwords, and certificates. Vault provides encryption services that are gated by authentication and authorization methods. Using Vault’s UI, CLI, or HTTP API, access to secrets and other sensitive data can be securely stored and managed, tightly controlled (restricted), and auditable.
  
-A modern system requires access to a multitude of secrets: database credentials,
+A modern system requires access to a multitude of secrets, including database credentials,
 API keys for external services, credentials for service-oriented architecture
-communication, etc. Understanding who is accessing what secrets is already very
-difficult and platform-specific. Adding on key rolling, secure storage, and
+communication, etc. It can be difficult to understand who is accessing which secrets, especially since this can be platform-specific. Adding on key rolling, secure storage, and
 detailed audit logs is almost impossible without a custom solution. This is
 where Vault steps in.
  
-Examples work best to showcase Vault. Please see the
-[use cases](/docs/use-cases).
+Vault validates and authorizes clients (users, machines, apps) before providing them access to secrets or stored sensitive data.
+ 
+![How Vault Works](/img/how-vault-works.png)
+ 
+### How does Vault work?
+ 
+Vault works primarily with tokens and a token is associated to the client's policy. Each policy is path-based and policy rules contrains the actions and accessibility to the paths for each client. With Vault, you can create tokens manually and assign them to your clients, or the clients can log in and obtain a token. The illustration below displays Vault's core workflow.
+ 
+![Vault Workflow](/img/vault-workflow-diagram1.png)
+ 
+ The core Vault workflow consists of four stages:
+ 
+* **Authenticate:** Authentication in Vault is the process by which a client supplies information that Vault uses to determine if they are who they say they are. Once the client is authenticated against an auth method, a token is generated and associated to a policy.
+* **Validation:** Vault validates the client against third-party trusted sources, such as Github, LDAP, AppRole, and more.
+* **Authorize**: A client is matched against the Vault security policy.  This policy is a set of rules defining which API endpoints a client has access to with its Vault token. Policies provide a declarative way to grant or forbid access to certain paths and operations in Vault.
+* **Access**: Vault grants access to secrets, keys, and encryption capabilities by issuing a token based on policies associated with the client’s identity. The client can then use their Vault token for future operations.
+ 
+### Why Vault?
+ 
+Most enterprises today have credentials sprawled across their organizations. Passwords, API keys, and credentials are stored in plain text, app source code, config files, and other locations. Because these credentials live everywhere, the sprawl can make it difficult and daunting to really know who has access and authorization to what. Having credentials in plain text also increases the potential for malicious attacks, both by internal and external attackers.
+ 
+Vault was designed with these challenges in mind. Vault takes all of these credentials and centralizes them so that they are defined in one location, which reduces unwanted exposure to credentials. But Vault takes it a few steps further by making sure users, apps, and systems are authenticated and explicitly authorized to access resources, while also providing an audit trail that captures and preserves a history of clients' actions.
  
 The key features of Vault are:
  
@@ -51,16 +70,18 @@ The key features of Vault are:
   Revocation assists in key rolling as well as locking down systems in the
   case of an intrusion.
  
-## What is HCP Vault?
+-> **Tip**: Learn more about Vault [use cases](/docs/use-cases).
+ 
+### What is HCP Vault?
  
-HCP Vault is a hosted version of Vault, which is operated by HashiCorp to allow organizations to get up and running quickly. HCP Vault uses the same binary as self-hosted Vault, which means you will have a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with a self-hosted Vault.
+HashiCorp Cloud Platform (HCP) Vault is a hosted version of Vault, which is operated by HashiCorp to allow organizations to get up and running quickly. HCP Vault uses the same binary as self-hosted Vault, which means you will have a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with a self-hosted Vault. Refer to the [HCP Vault](https://cloud.hashicorp.com/docs/vault) documentation to learn more.
  
-~> **Note**: Currently, HCP Vault clusters are located on AWS running in multiple regions across North America, Asia, and Europe. We will support additional cloud providers in the future.
+> **Hands On:** Try the [Get started](https://learn.hashicorp.com/collections/vault/cloud) tutorial on HashiCorp Learn to set up a managed Vault cluster.
  
-To learn more about HCP Vault, see the [HCP Vault documentation](https://cloud.hashicorp.com/docs/vault). You can also get started with HCP Vault by using the HCP portal to set up your managed Vault cluster. Refer to the [Getting Started with HCP Vault](https://learn.hashicorp.com/collections/vault/cloud) tutorial.
+### Community
  
-## Next Steps
+We welcome questions, suggestions, and contributions from the community.
  
-See the page on [Vault use cases](/docs/use-cases) to learn about the multiple ways
-Vault can be used. Then, continue onwards with the [Getting Started](https://learn.hashicorp.com/collections/vault/getting-started) tutorial to use Vault
-to read, write, and create real secrets and see how it works in practice.
+* Ask questions in [HashiCorp Discuss](https://discuss.hashicorp.com/c/vault/30).
+* Read our [contributing guide](https://github.com/hashicorp/tutorials/blob/main/CONTRIBUTING.md).
+* [Submit an issue](https://github.com/hashicorp/vault/issues/new/choose) for bugs and feature requests.

@@ -0,0 +1,42 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods - ForgeRock
+description: OIDC provider configuration for ForgeRock
+---
+ 
+## ForgeRock
+ 
+1. Navigate to Applications -> OAuth 2.0 -> Clients in ForgeRock Access Management.
+1. Create new client.
+1. Configure Client ID, Client Secret, Scopes and Redirection URIs.
+  - `client ID`
+  - `client secret`
+  - `allowed_redirect_uris` should be the two redirect URIs for Vault CLI and UI access.
+  - `oidc_scopes` should be set to the OIDC scopes.
+1. Save Client ID and Client Secret.
+ 
+### Configuration
+ 
+1. In Vault, enable the OIDC auth method.
+ 
+1. Configure the OIDC auth method with the `oidc_client_id` (client ID), `oidc_client_secret`
+   (client secret), and `oidc_discovery_url` (endpoint URL) from ForgeRock.
+   ```shell
+   vault write auth/oidc/config \
+      oidc_client_id="your_client_id" \
+      oidc_client_secret="your_client_secret" \
+      default_role="your_default_role" \
+      oidc_discovery_url="https://openam.example.com:8443/openam/oauth2"
+   ```
+ 
+1. Configure the [OIDC Role](/api-docs/auth/jwt) with the following:
+  - `user_claim` should be `"sub"`.
+  - `allowed_redirect_uris` should be the two redirect URIs for Vault CLI and UI access.
+  - `oidc_scopes` should be set to the OIDC scopes.
+   ```shell
+   vault write auth/oidc/role/your_default_role \
+      user_claim="sub" \
+      allowed_redirect_uris="http://localhost:8250/oidc/callback,https://online_version_hostname:port_number/ui/vault/auth/oidc/oidc/callback"  \
+      oidc_scopes="your_oidc_scopes" \
+      policies=default
+   ```

@@ -255,18 +255,26 @@ Creates or updates a role.
   `Add Attribute` operation.
 - `operation_create` (`bool: false`) - Grant permission to use the KMIP
   `Create` operation.
+- `operation_decrypt` (`bool: false`) - Grant permission to use the KMIP
+  `Decrypt` operation.
 - `operation_destroy` (`bool: false`) - Grant permission to use the KMIP
   `Destroy` operation.
 - `operation_discover_versions` (`bool: false`) - Grant permission to use the KMIP
-  `Discover Version` operation.
+  `Discover Versions` operation.
+- `operation_encrypt` (`bool: false`) - Grant permission to use the KMIP
+  `Encrypt` operation.
 - `operation_get` (`bool: false`) - Grant permission to use the KMIP
   `Get` operation.
 - `operation_get_attribute_list` (`bool: false`) - Grant permission to use the KMIP
   `Get Attribute List` operation.
 - `operation_get_attributes` (`bool: false`) - Grant permission to use the KMIP
   `Get Attributes` operation.
+- `operation_import` (`bool: false`) - Grant permission to use the KMIP
+  `Import` operation.
 - `operation_locate` (`bool: false`) - Grant permission to use the KMIP
   `Locate` operation.
+- `operation_query` (`bool: false`) - Grant permission to use the KMIP
+  `Query` operation.
 - `operation_register` (`bool: false`) - Grant permission to use the KMIP
   `Register` operation.
 - `operation_rekey` (`bool: false`) - Grant permission to use the KMIP
@@ -281,12 +289,16 @@ Creates or updates a role.
   "operation_activate": true,
   "operation_add_attribute": true,
   "operation_create": true,
+  "operation_decrypt": true,
   "operation_destroy": true,
   "operation_discover_versions": true,
+  "operation_encrypt": true,
   "operation_get": true,
   "operation_get_attribute_list": true,
   "operation_get_attributes": true,
+  "operation_import": true,
   "operation_locate": true,
+  "operation_query": true,
   "operation_register": true,
   "operation_rekey": true,
   "operation_revoke": true
@@ -333,12 +345,16 @@ $ curl \
     "operation_activate": true,
     "operation_add_attribute": true,
     "operation_create": true,
+    "operation_decrypt": true,
     "operation_destroy": true,
     "operation_discover_versions": true,
+    "operation_encrypt": true,
     "operation_get": true,
     "operation_get_attribute_list": true,
     "operation_get_attributes": true,
+    "operation_import": true,
     "operation_locate": true,
+    "operation_query": true,
     "operation_register": true,
     "operation_rekey": true,
     "operation_revoke": true
 causes panic (#16094) (#16116)
 changelog/16094.txt     | 3 +++
 vault/plugin_catalog.go | 5 ++++-
 2 files changed, 7 insertions(+), 1 deletion(-)
 create mode 100644 changelog/16094.txt

@@ -783,22 +783,24 @@ func signCert(b *backend,
 		// We update the value of KeyBits and SignatureBits here (from the
 		// role), using the specified key type. This allows us to convert
 		// the default value (0) for SignatureBits and KeyBits to a
-		// meaningful value. In the event KeyBits takes a zero value, we also
-		// update that to a new value.
+		// meaningful value.
 		//
-		// This is mandatory because on some roles, with KeyType any, we'll
-		// set a default SignatureBits to 0, but this will need to be updated
-		// in order to behave correctly during signing.
-		roleBitsWasZero := data.role.KeyBits == 0
-		if data.role.KeyBits, data.role.SignatureBits, err = certutil.ValidateDefaultOrValueKeyTypeSignatureLength(actualKeyType, data.role.KeyBits, data.role.SignatureBits); err != nil {
+		// We ignore the role's original KeyBits value if the KeyType is any
+		// as legacy (pre-1.10) roles had default values that made sense only
+		// for RSA keys (key_bits=2048) and the older code paths ignored the role value
+		// set for KeyBits when KeyType was set to any. This also enforces the
+		// docs saying when key_type=any, we only enforce our specified minimums
+		// for signing operations
+		if data.role.KeyBits, data.role.SignatureBits, err = certutil.ValidateDefaultOrValueKeyTypeSignatureLength(
+			actualKeyType, 0, data.role.SignatureBits); err != nil {
 			return nil, errutil.InternalError{Err: fmt.Sprintf("unknown internal error updating default values: %v", err)}
 		}
  
-		// We're using the KeyBits field as a minimum value, and P-224 is safe
+		// We're using the KeyBits field as a minimum value below, and P-224 is safe
 		// and a previously allowed value. However, the above call defaults
-		// to P-256 as that's a saner default than P-224 (w.r.t. generation).
-		// So, override our fake Role value if it was previously zero.
-		if actualKeyType == "ec" && roleBitsWasZero {
+		// to P-256 as that's a saner default than P-224 (w.r.t. generation), so
+		// override it here to allow 224 as the smallest size we permit.
+		if actualKeyType == "ec" {
 			data.role.KeyBits = 224
 		}
 	}

@@ -0,0 +1,25 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods
+description: OIDC provider configuration quick starts
+---
+ 
+# OIDC Provider Configuration
+ 
+This page collects high-level setup steps on how to configure an OIDC
+application for various providers. For more general usage and operation
+information, see the [Vault JWT/OIDC method documentation](/docs/auth/jwt).
+ 
+OIDC providers are often highly configurable, and you should become familiar with
+their recommended settings and best practices. The guides listed below are
+largely community-driven and intended to help you get started. Corrections
+and additions may be submitted via the [Vault Github repository](https://github.com/hashicorp/vault).
+ 
+- [Auth0](/docs/auth/jwt/oidc-providers/auth0)
+- [Azure AD](/docs/auth/jwt/oidc-providers/azuread)
+- [ForgeRock](/docs/auth/jwt/oidc-providers/forgerock)
+- [Gitlab](/docs/auth/jwt/oidc-providers/gitlab)
+- [Google](/docs/auth/jwt/oidc-providers/google)
+- [Keycloak](/docs/auth/jwt/oidc-providers/keycloak)
+- [Kubernetes](/docs/auth/jwt/oidc-providers/kubernetes)
+- [Okta](/docs/auth/jwt/oidc-providers/kubernetes)

@@ -288,6 +288,50 @@ func (b *SystemBackend) configPaths() []*framework.Path {
 				},
 			},
 		},
+		{
+			Pattern: "loggers$",
+			Fields: map[string]*framework.FieldSchema{
+				"level": {
+					Type: framework.TypeString,
+					Description: "Log verbosity level. Supported values (in order of detail) are " +
+						"\"trace\", \"debug\", \"info\", \"warn\", and \"error\".",
+				},
+			},
+			Operations: map[logical.Operation]framework.OperationHandler{
+				logical.UpdateOperation: &framework.PathOperation{
+					Callback: b.handleLoggersWrite,
+					Summary:  "Modify the log level for all existing loggers.",
+				},
+				logical.DeleteOperation: &framework.PathOperation{
+					Callback: b.handleLoggersDelete,
+					Summary:  "Revert the all loggers to use log level provided in config.",
+				},
+			},
+		},
+		{
+			Pattern: "loggers/" + framework.MatchAllRegex("name"),
+			Fields: map[string]*framework.FieldSchema{
+				"name": {
+					Type:        framework.TypeString,
+					Description: "The name of the logger to be modified.",
+				},
+				"level": {
+					Type: framework.TypeString,
+					Description: "Log verbosity level. Supported values (in order of detail) are " +
+						"\"trace\", \"debug\", \"info\", \"warn\", and \"error\".",
+				},
+			},
+			Operations: map[logical.Operation]framework.OperationHandler{
+				logical.UpdateOperation: &framework.PathOperation{
+					Callback: b.handleLoggersByNameWrite,
+					Summary:  "Modify the log level of a single logger.",
+				},
+				logical.DeleteOperation: &framework.PathOperation{
+					Callback: b.handleLoggersByNameDelete,
+					Summary:  "Revert a single logger to use log level provided in config.",
+				},
+			},
+		},
 	}
 }
  

@@ -24,14 +24,20 @@ import (
 type Config struct {
 	*configutil.SharedConfig `hcl:"-"`
  
-	AutoAuth       *AutoAuth                  `hcl:"auto_auth"`
-	ExitAfterAuth  bool                       `hcl:"exit_after_auth"`
-	Cache          *Cache                     `hcl:"cache"`
-	Vault          *Vault                     `hcl:"vault"`
-	TemplateConfig *TemplateConfig            `hcl:"template_config"`
-	Templates      []*ctconfig.TemplateConfig `hcl:"templates"`
+	AutoAuth                   *AutoAuth                  `hcl:"auto_auth"`
+	ExitAfterAuth              bool                       `hcl:"exit_after_auth"`
+	Cache                      *Cache                     `hcl:"cache"`
+	Vault                      *Vault                     `hcl:"vault"`
+	TemplateConfig             *TemplateConfig            `hcl:"template_config"`
+	Templates                  []*ctconfig.TemplateConfig `hcl:"templates"`
+	DisableIdleConns           []string                   `hcl:"disable_idle_connections"`
+	DisableIdleConnsCaching    bool                       `hcl:"-"`
+	DisableIdleConnsTemplating bool                       `hcl:"-"`
+	DisableIdleConnsAutoAuth   bool                       `hcl:"-"`
 }
  
+const DisableIdleConnsEnv = "VAULT_AGENT_DISABLE_IDLE_CONNECTIONS"
+ 
 func (c *Config) Prune() {
 	for _, l := range c.Listeners {
 		l.RawConfig = nil
@@ -260,6 +266,28 @@ func LoadConfig(path string) (*Config, error) {
 		result.Vault.Retry.NumRetries = 0
 	}
  
+	if disableIdleConnsEnv := os.Getenv(DisableIdleConnsEnv); disableIdleConnsEnv != "" {
+		result.DisableIdleConns, err = parseutil.ParseCommaStringSlice(strings.ToLower(disableIdleConnsEnv))
+		if err != nil {
+			return nil, fmt.Errorf("error parsing environment variable %s: %v", DisableIdleConnsEnv, err)
+		}
+	}
+ 
+	for _, subsystem := range result.DisableIdleConns {
+		switch subsystem {
+		case "auto-auth":
+			result.DisableIdleConnsAutoAuth = true
+		case "caching":
+			result.DisableIdleConnsCaching = true
+		case "templating":
+			result.DisableIdleConnsTemplating = true
+		case "":
+			continue
+		default:
+			return nil, fmt.Errorf("unknown disable_idle_connections value: %s", subsystem)
+		}
+	}
+ 
 	return result, nil
 }
  

@@ -377,8 +377,8 @@ export default Service.extend({
   },
  
   async authSuccess(options, response) {
-    // persist selectedAuth to sessionStorage to rehydrate auth form on logout
-    sessionStorage.setItem('selectedAuth', options.selectedAuth);
+    // persist selectedAuth to localStorage to rehydrate auth form on logout
+    localStorage.setItem('selectedAuth', options.selectedAuth);
     const authData = await this.persistAuthData(options, response, this.namespaceService.path);
     await this.permissions.getPaths.perform();
     return authData;
@@ -397,8 +397,8 @@ export default Service.extend({
   },
  
   getAuthType() {
-    // check sessionStorage first
-    const selectedAuth = sessionStorage.getItem('selectedAuth');
+    // check localStorage first
+    const selectedAuth = localStorage.getItem('selectedAuth');
     if (selectedAuth) return selectedAuth;
     // fallback to authData which discerns backend type from token
     return this.authData ? this.authData.backend.type : null;

@@ -18,3 +18,23 @@ your issue, you can [enable trace logging](/docs/platform/mssql/configuration#en
  
 Restart SQL Server for the config change to take effect, and you should see more
 detailed logs in the same section of Windows Event Viewer.
+ 
+## Error Codes
+ 
+During installation, the EKM provider registers a manifest of coded event logs to aid debugging. You may see the following error codes during operation.
+ 
+### 2050 License Error
+ 
+The EKM provider was unable to verify that Vault has the correct license features. This
+could be due to:
+ 
+- An incompatible Vault Enterprise license - see the installation [prerequisites](/docs/platform/mssql/installation#prerequisites) for the required license feature.
+- Lack of network connectivity - Check Vault's audit logs to see if any requests are made to
+   authenticate via AppRole or query the `/sys/license/status` API.
+- Misconfigured AppRole auth - Ensure you provided the correct Role ID and Secret ID when
+   configuring the SQL Server `CREDENTIAL`. See the
+   [installation instructions](/docs/platform/mssql/installation) for an end-to-end working example.
+- Incorrect policy permissions - The EKM provider requires the `read` capability
+   on the path `sys/license/status`. See the `tde-policy` created in the
+   [installation instructions](/docs/platform/mssql/installation#configuring-vault)
+   for an example of a working policy.
 <82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
 36f722054de25ae630314742a400310fb66de467 (#16219)
 website/content/docs/plugins/plugin-portal.mdx | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

@@ -12,6 +12,7 @@ For upgrade instructions, see [upgrading](/docs/platform/mssql/upgrading).
 ## Prerequisites
  
 * Vault Enterprise server 1.9+ with a license for the Advanced Data Protection Key Management module
+* Microsoft Windows Server operating system
 * Microsoft SQL Server for Windows (SQL Server for Linux [does not support EKM][linux-ekm])
 * An authenticated Vault client
  
@@ -40,7 +41,7 @@ EKM provider to use it.
  
     ```bash
     vault auth enable approle
-    vault write auth/approle/role/tde-role \
+    vault write auth/approle/role/ekm-encryption-key-role \
         token_ttl=20m \
         max_token_ttl=30m \
         token_policies=tde-policy
@@ -158,6 +159,10 @@ installation.
     PROVIDER_KEY_NAME = 'ekm-encryption-key';
     ```
  
+    -> **Note:** This is the first step at which the EKM provider will communicate with Vault. If
+    Vault is misconfigured, this step is likely to fail. See
+    [troubleshooting](/docs/platform/mssql/troubleshooting) for tips on specific error codes.
+ 
 1. Create another login from the new asymmetric key:
  
     ```sql
@@ -244,4 +249,4 @@ GO
 ALTER DATABASE ENCRYPTION KEY
 ENCRYPTION BY SERVER ASYMMETRIC KEY TransitVaultAsymmetric;
 GO
-```
+```

@@ -0,0 +1,13 @@
+---
+layout: docs
+page_title: OIDC Provider Setup - Auth Methods - Auth0
+description: OIDC provider configuration for Auth0
+---
+ 
+## Auth0
+ 
+1. Select Create Application (Regular Web App).
+1. Configure Allowed Callback URLs.
+1. Copy client ID and secret.
+1. If you see Vault errors involving signature, check the application's Advanced > OAuth settings
+   and verify that signing algorithm is "RS256".

@@ -16,9 +16,11 @@ This program is intended to be largely a self-service process with links and gui
  
 Vault is an Identity-based security solution that leverages trusted sources of identity to keep secrets and application data secured with one centralized, audited workflow for tightly controlling access to secrets across applications, systems, and infrastructure while encrypting data both in flight and at rest. For a full description of the current features please refer to the Vault [website](/).
  
-Vault has a secure [plugin](/docs/plugins) architecture. Vault’s plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. This means the plugin process does not share the same memory space as Vault and therefore can only access the interfaces and arguments given to it.
+There are two main types of integrations with Vault. The first is Runtime Integrations which use Vault as part of a workflow. Many partners have integrations that use existing Vault deployments to retrieve various types of secrets for use in a partner’s application or platform. The use cases can range from Vault storing and providing secrets, issuing or managing PKI certificates or acting as an external key management system. 
  
-Vault plugins can be built-in and bundled with the Vault binary, or be external that has to be manually mounted. Built-in plugins are developed by HashiCorp, while external plugins can be developed by HashiCorp, technology partners, or the community. There is a curated collection of all plugins, both built-in and external, located on the [Plugin Portal](/docs/plugin-portal).
+The second type is where a partner develops a custom plugin. Vault has a secure [plugin](/docs/plugins) architecture. Vault’s plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. 
+ 
+Plugins can be broken into two categories, Secrets Engines and Auth Methods. They can be built-in and bundled with the Vault binary, or be external that has to be manually registered. Built-in plugins are developed by HashiCorp, while external plugins can be developed by HashiCorp, technology partners, or the community. There is a curated collection of all plugins, both built-in and external, located on the [Plugin Portal](/docs/plugins/plugin-portal).
  
 The diagram below depicts the key Vault integration categories and types.
  
@@ -26,21 +28,29 @@ The diagram below depicts the key Vault integration categories and types.
  
 Main Vault categories for partners to integrate with include:
  
-**Authentication Methods**: Authentication (or Auth) methods are plugin components in Vault that perform authentication and are responsible for assigning identity along with a set of policies to a user. Vault supports multiple auth methods/identity models to better support your business use case. You can find more information about Vault Auth Methods [here](/docs/auth/).
+**Authentication Methods**: Authentication (or Auth) methods are plugin components in Vault that perform authentication and are responsible for assigning identity along with a set of policies to a user. Vault supports multiple auth methods/identity models and partners can build a plugin that allows Vault to authenticate against the partners’ platform. You can find more information about Vault Auth Methods [here](/docs/auth/).
  
-**Runtime Integrations**: These types of integrations include integrations developed by partners that work with existing customer deployments of Vault and the partner’s solution.
+**Runtime Integrations**: These types of integrations include integrations developed by partners that work with existing deployments of Vault and the partner’s product as part of the customer's identity/security workflow.
  
-HSM (Hardware Security Module) are specific types of runtime integrations and provide an added level of security and compliance. The HSM communicates with Vault using the PKCS#11 protocol, thereby resulting in the integration to primarily involve verification of the operation of the functionality. You can find more information about Vault's HSM support [here](/docs/enterprise/hsm).
+Oftentimes these integrations involve modifying a partner’s product to become “Vault aware”. There are two main components that need to be considered for this type of integration: 
+1. How is the application going to authenticate itself to Vault?
+1. Support of Namespaces
  
--> **Note:** Integrations related Vault’s [storage](/docs/concepts/storage) backend, [auto auth](/docs/agent/autoauth), and [auto unseal](/docs/concepts/seal#auto-unseal) functionality are not encouraged. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for any questions related to this.
+There are many ways for an application to authenticate itself to Vault (see [Auth Methods](/docs/auth/)), but we recommend partners use one of the following methods: [AppRole](/docs/auth/approle), [JWT / OIDC](/docs/auth/jwt), [TLS Certificates](/docs/auth/cert) or [Username / Password](/docs/auth/userpass). For an integration to be verified as production ready by HashiCorp, there needs to be at least one other Auth method supported besides [Token](/docs/auth/token). Token is not recommended for use in production since it involves creating a manual long lived token (which is against best practice and poses a security risk). Using one of the above mentioned auth methods automatically creates short lived tokens and eliminates the need to manually generate a new token on a regular basis.
+ 
+As the number of customers using Vault Enterprise increases, partners are encouraged to support [Namespaces](https://learn.hashicorp.com/tutorials/vault/namespaces). By supporting Namespaces, there is an additional benefit that an integration should be able to work with HCP Vault.
+ 
+HSM (Hardware Security Module) are specific types of runtime integrations and can be configured to work with new or existing Vault deployments. They provide an added level of security and compliance. The HSM communicates with Vault using the PKCS#11 protocol thereby resulting in the integration to primarily involve verification of the operation of the functionality. You can find more information about Vault’s HSM support [here](/docs/enterprise/hsm). A list of HSMs that have been verified to work with Vault is shown in our [interoperability matrix](/docs/interoperability-matrix).
  
 **Audit/Monitoring & Compliance**: Audit/Monitoring and Compliance are components in Vault that keep a detailed log of all requests and responses to Vault. Because every operation with Vault is an API request/response, the audit log contains every authenticated interaction with Vault, including errors. Vault supports multiple audit devices to support your business use case. You can find more information about Vault Audit Devices [here](/docs/audit/).
  
-**Secrets Engines**: Secrets engines are plugin components which store, generate, or encrypt data. Secrets engines are provided with some set of data that perform actions on that data, and then return a result. Some secrets engines store and read data, like encrypted in-memory data structure, and secrets engines connect to other services. Examples of secrets engines include identity modules of Cloud providers like AWS, Azure IAM models, Cloud (LDAP), database or key management. You can find more information about Vault secrets engines [here](/docs/secrets/).
+**Secrets Engines**: Secrets engines are plugin components which store, generate, or encrypt data. Secrets engines are provided with some set of data, that take some action on that data, and then return a result. Some secrets engines store and read data, like encrypted in-memory data structure, other secrets engines connect to other services. Examples of Secrets Engines include identity modules of Cloud providers like AWS, Azure IAM models, Cloud (LDAP), database or certificate management. You can find more information about Vault Secrets Engines [here](/docs/secrets/).
+ 
+-> **Note:** Integrations related Vault’s [storage](/docs/concepts/storage) backend, [auto auth](/docs/agent/autoauth), and [auto unseal](/docs/concepts/seal#auto-unseal) functionality are not encouraged. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for any questions related to this.
  
 ### HCP Vault
  
-HCP Vault is a managed version of Vault which is operated by HashiCorp to allow customers to quickly get up and running. HCP Vault uses the same binary as self-managed Vault, and offers a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with Vault. Most runtime integrations can be verified with HCP Vault.
+HCP Vault is a managed version of Vault which is operated by HashiCorp to allow customers to quickly get up and running. HCP Vault uses the same binary as self-managed Vault Enterprise, and offers a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with Vault. Most runtime integrations can be verified with HCP Vault.
  
 Sign up for HCP Vault [here](https://portal.cloud.hashicorp.com/) and check out [this](https://learn.hashicorp.com/collections/vault/cloud) learn guide for quickly getting started.
  
@@ -150,9 +160,9 @@ Once the integration has been verified, the partner is requested to sign the Has
  
 At this stage, it is expected that the integration is fully complete, the necessary documentation has been written, and HashiCorp has reviewed the integration.
  
-For Auth or Secret Engine plugins specifically, once the plugin has been validated by HashiCorp, it is recommended the plugin be hosted on Github so it can more easily be downloaded and installed within Vault. We also encourage partners to list their plugin on the [Vault Plugin Portal](/docs/plugin-portal). This is in addition to the listing of the plugin on the technology partners’ dedicated HashiCorp partner page. To have the plugin listed on the portal page, please do a pull request via the “edit in GitHub” link on the bottom of the page and add the plugin in the partner section.
+For Auth or Secret Engine plugins specifically, once the plugin has been verified by HashiCorp, it is recommended the plugin be hosted on Github so it can more easily be downloaded and installed within Vault. We also encourage partners to list their plugin on the [Vault Plugin Portal](/docs/plugins/plugin-portal). This is in addition to the listing of the plugin on the technology partners’ dedicated HashiCorp partner page. To have the plugin listed on the portal page, please do a pull request via the “edit in GitHub” link on the bottom of the page and add the plugin in the partner section.
  
-For HCP Vault validations, the partner will be issued an HCP Vault Verified badge and will have this displayed on their partner page.
+For HCP Vault verifications, the partner will be issued an HCP Vault Verified badge and will have this displayed on their partner page.
  
 ### 6. Support
  
@@ -174,4 +184,4 @@ Below is a checklist of steps that should be followed during the Vault integrati
  
 ## Contact Us
  
-For any questions or feedback, please contact us at: [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com)
+For any questions or feedback, please contact us at: [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com)

@@ -140,15 +140,20 @@ EOF
 ```
  
 - Monitor Vault's log output. Important information about OIDC validation failures will be emitted.
+ 
 - Ensure Redirect URIs are correct in Vault and on the provider. They need to match exactly. Check:
   http/https, 127.0.0.1/localhost, port numbers, whether trailing slashes are present.
+ 
 - Start simple. The only claim configuration a role requires is `user_claim`. After authentication is
   known to work, you can add additional claims bindings and metadata copying.
+ 
 - `bound_audiences` is optional for OIDC roles and typically not required. OIDC providers will use
   the client_id as the audience and OIDC validation expects this.
+ 
 - Check your provider for what scopes are required in order to receive all
   of the information you need. The scopes "profile" and "groups" often need to be
   requested, and can be added by setting `oidc_scopes="profile,groups"` on the role.
+ 
 - If you're seeing claim-related errors in logs, review the provider's docs very carefully to see
   how they're naming and structuring their claims. Depending on the provider, you may be able to
   construct a simple `curl` implicit grant request to obtain a JWT that you can inspect. An example
@@ -161,6 +166,7 @@ EOF
   be helpful when debugging provider setup and verifying that the received claims are what you expect.
   Since claims data is logged verbatim and may contain sensitive information, this option should not be
   used in production.
+ 
 - Azure requires some additional configuration when a user is a member of more
   than 200 groups, described in [Azure-specific handling
   configuration](/docs/auth/jwt/oidc-providers/azuread#optional-azure-specific-configuration)
@@ -231,46 +237,46 @@ Auth methods must be configured in advance before users or machines can
 authenticate. These steps are usually completed by an operator or configuration
 management tool.
  
-1.  Enable the JWT auth method. Either the "jwt" or "oidc" name may be used. The
-    backend will be mounted at the chosen name.
- 
-    ```text
-    $ vault auth enable jwt
-      or
-    $ vault auth enable oidc
-    ```
- 
-1.  Use the `/config` endpoint to configure Vault. To support JWT roles, either local keys, a JWKS URL, or an OIDC
-    Discovery URL must be present. For OIDC roles, OIDC Discovery URL, OIDC Client ID and OIDC Client Secret are required. For the
-    list of available configuration options, please see the [API documentation](/api-docs/auth/jwt).
- 
-    ```text
-    $ vault write auth/jwt/config \
-        oidc_discovery_url="https://myco.auth0.com/" \
-        oidc_client_id="m5i8bj3iofytj" \
-        oidc_client_secret="f4ubv72nfiu23hnsj" \
-        default_role="demo"
-    ```
- 
-1.  Create a named role:
- 
-    ```text
-    vault write auth/jwt/role/demo \
-        allowed_redirect_uris="http://localhost:8250/oidc/callback" \
-        bound_subject="r3qX9DljwFIWhsiqwFiu38209F10atW6@clients" \
-        bound_audiences="https://vault.plugin.auth.jwt.test" \
-        user_claim="https://vault/user" \
-        groups_claim="https://vault/groups" \
-        policies=webapps \
-        ttl=1h
-    ```
- 
-    This role authorizes JWTs with the given subject and audience claims, gives
-    it the `webapps` policy, and uses the given user/groups claims to set up
-    Identity aliases.
- 
-    For the complete list of configuration options, please see the API
-    documentation.
+1. Enable the JWT auth method. Either the "jwt" or "oidc" name may be used. The
+   backend will be mounted at the chosen name.
+ 
+   ```text
+   $ vault auth enable jwt
+     or
+   $ vault auth enable oidc
+   ```
+ 
+1. Use the `/config` endpoint to configure Vault. To support JWT roles, either local keys, a JWKS URL, or an OIDC
+   Discovery URL must be present. For OIDC roles, OIDC Discovery URL, OIDC Client ID and OIDC Client Secret are required. For the
+   list of available configuration options, please see the [API documentation](/api-docs/auth/jwt).
+ 
+   ```text
+   $ vault write auth/jwt/config \
+       oidc_discovery_url="https://myco.auth0.com/" \
+       oidc_client_id="m5i8bj3iofytj" \
+       oidc_client_secret="f4ubv72nfiu23hnsj" \
+       default_role="demo"
+   ```
+ 
+1. Create a named role:
+ 
+   ```text
+   vault write auth/jwt/role/demo \
+       allowed_redirect_uris="http://localhost:8250/oidc/callback" \
+       bound_subject="r3qX9DljwFIWhsiqwFiu38209F10atW6@clients" \
+       bound_audiences="https://vault.plugin.auth.jwt.test" \
+       user_claim="https://vault/user" \
+       groups_claim="https://vault/groups" \
+       policies=webapps \
+       ttl=1h
+   ```
+ 
+   This role authorizes JWTs with the given subject and audience claims, gives
+   it the `webapps` policy, and uses the given user/groups claims to set up
+   Identity aliases.
+ 
+   For the complete list of configuration options, please see the API
+   documentation.
  
 ### Bound Claims
  

@@ -0,0 +1,126 @@
+---
+layout: docs
+page_title: Redis - Database - Secrets Engines
+description: |-
+  Redis is one of the supported plugins for the database secrets engine.
+  This plugin generates database credentials dynamically based on configured
+  roles for the Redis database, and also supports [Static Roles](https://developer.hashicorp.com/vault/docs/secrets/databases#static-roles).
+---
+ 
+# Redis Database Secrets Engine
+ 
+Redis is one of the supported plugins for the database secrets engine. This
+plugin generates database credentials dynamically based on configured roles for
+the Redis database.
+ 
+See the [database secrets engine](/docs/secrets/databases) docs for
+more information about setting up the database secrets engine.
+ 
+## Capabilities
+ 
+| Plugin Name                 | Root Credential Rotation | Dynamic Roles | Static Roles | Username Customization |
+| --------------------------- | ------------------------ | ------------- | ------------ | ---------------------- |
+| `redis-database-plugin`     | Yes                      | Yes           | Yes          | No                     |
+ 
+## Setup
+ 
+1.  Enable the database secrets engine if it is not already enabled:
+ 
+    ```shell-session
+    $ vault secrets enable database
+    Success! Enabled the database secrets engine at: database/
+    ```
+ 
+    By default, the secrets engine will enable at the name of the engine. To
+    enable the secrets engine at a different path, use the `-path` argument.
+ 
+1.  Configure Vault with the proper plugin and connection configuration:
+ 
+    ```shell-session
+    $ vault write database/config/my-redis-database \
+      plugin_name="redis-database-plugin" \
+      host="localhost" \
+      port=6379 \
+      tls=true \
+      ca_cert="$CACERT"
+      username="user" \
+      password="pass" \
+      allowed_roles="my-*-role"
+    ```
+ 
+1.  You should consider rotating the admin password. Note that if you do, the
+    new password will never be made available through Vault, so you should
+    create a Vault-specific database admin user for this.
+ 
+    ```shell-session
+    vault write -force database/rotate-root/my-redis-database
+    ```
+ 
+## Usage
+ 
+After the secrets engine is configured, write dynamic and static roles
+to Vault to enable generating credentials.
+ 
+### Dynamic roles
+ 
+1.  Configure a dynamic role that maps a name in Vault to a JSON string
+    containing the Redis ACL rules, which are either documented [here](https://redis.io/commands/acl-cat) or in the output
+    of the `ACL CAT` Redis command.
+ 
+    ```shell-session
+    $ vault write database/roles/my-dynamic-role \
+        db_name="my-redis-database" \
+        creation_statements='["+@admin"]' \
+        default_ttl="5m" \
+        max_ttl="1h"
+    Success! Data written to: database/roles/my-dynamic-role
+    ```
+ 
+    Note that if a creation_statement is not provided the user account will
+    default to a read only user, `'["~*", "+@read"]'` that can read any key.
+ 
+1.  Generate a new set of credentials by reading from the `/creds` endpoint with the name
+    of the role:
+ 
+    ```shell-session
+    $ vault read database/creds/my-dynamic-role
+    Key                Value
+    ---                -----
+    lease_id           database/creds/my-dynamic-role/OxCTXJcxQ2F4lReWPjbezSnA
+    lease_duration     5m
+    lease_renewable    true
+    password           dACqHsav6-attdv1glGZ
+    username           V_TOKEN_MY-DYNAMIC-ROLE_YASUQUF3GVVD0ZWTEMK4_1608481717
+    ```
+ 
+### Static roles
+ 
+1.  Configure a static role that maps a name in Vault to an existing Redis
+    user.
+ 
+    ```shell-session
+    $ vault write database/static-roles/my-static-role \
+        db_name="my-redis-database" \
+        username="my-existing-redis-user" \
+        rotation_period=5m
+    Success! Data written to: database/static-roles/my-static-role
+    ```
+ 
+1.  Retrieve the credentials from the `/static-creds` endpoint:
+ 
+    ```shell-session
+    $ vault read database/static-creds/my-static-role
+    Key                    Value
+    ---                    -----
+    last_vault_rotation    2020-12-20T10:39:49.647822-06:00
+    password               ylKNgqa3NPVAioBf-0S5
+    rotation_period        5m
+    ttl                    4m39s
+    username               my-existing-redis-user
+    ```
+ 
+## API
+ 
+The full list of configurable options can be seen in the [Redis Database Plugin API](/api-docs/secret/databases/redis) page.
+ 
+For more information on the database secrets engine's HTTP API please see the [Database Secrets Engine API](/api-docs/secret/databases) page.

@@ -0,0 +1,262 @@
+---
+layout: docs
+page_title: KMIP - Profiles Support
+description: |-
+  The KMIP profiles define the use of KMIP objects, attributes, operations, message elements
+  and authentication methods within specific contexts of KMIP server and client interaction.
+  These profiles define a set of normative constraints for employing KMIP within a particular
+  environment or context of use.
+---
+ 
+# KMIP Profiles Version 1.4
+ 
+This document specifies conformance clauses in accordance with the OASIS TC Process ([TC-PROC section 2.18 paragraph 8a][tc-proc-2.18] )
+for the KMIP Specification ([KMIP-SPEC 12.1 and 12.2][kmip-spec]) for a KMIP server or KMIP client through profiles that define the
+use of KMIP objects, attributes, operations, message elements and authentication methods within specific contexts of
+KMIP server and client interaction.
+ 
+Vault implements version 1.4 of the following Key Management Interoperability Protocol Profiles:
+ 
+## [Baseline Server][baseline-server]
+  1. Supports the following objects:
+ 
+    | Object                                                                  | Supported |
+    | ----------------------------------------------------------------------- | :-------: |
+    | Attribute [KMIP-SPEC 2.1.1][kmip-spec-2.1.1]                            | ✅        |
+    | Credential [KMIP-SPEC 2.1.2][kmip-spec-2.1.2]                           | ✅        |
+    | Key Block [KMIP-SPEC 2.1.3][kmip-spec-2.1.3]                            | ✅        |
+    | Key Value [KMIP-SPEC 2.1.4][kmip-spec-2.1.4]                            | ✅        |
+    | Template-Attribute Structure [KMIP-SPEC 2.1.8][kmip-spec-2.1.8]         | ✅        |
+    | Extension Information [KMIP-SPEC 2.1.9][kmip-spec-2.1.9]                | ✅        |
+    | Profile Information [KMIP-SPEC 2.1.19][kmip-spec-2.1.19]                | ✅        |
+    | Validation Information [KMIP-SPEC 2.1.20][kmip-spec-2.1.20]             | ✅        |
+    | Capability Information [KMIP-SPEC 2.1.21][kmip-spec-2.1.21]             | ✅        |
+ 
+  2. Supports the following subsets of attributes:
+ 
+    | Attribute                                                              | Supported | Notes  |
+    | -----------------------------------------------------------------------| :-------: | :----: |
+    | Unique Identifier [KMIP-SPEC 3.1][kmip-spec-3.1]                       | ✅        |        |
+    | Name [KMIP-SPEC 3.2][kmip-spec-3.2]                                    | ✅        |        |
+    | Object Type [KMIP-SPEC 3.3][kmip-spec-3.3]                             | ✅        |        |
+    | Cryptographic Algorithm [KMIP-SPEC 3.4][kmip-spec-3.4]                 | ✅        |        |
+    | Cryptographic Length [KMIP-SPEC 3.5][kmip-spec-3.5]                    | ✅        |        |
+    | Cryptographic Parameters [KMIP-SPEC 3.6][kmip-spec-3.6]                | ✅        |        |
+    | Digest [KMIP-SPEC 3.17][kmip-spec-3.17]                                | ✅        |        |
+    | Cryptographic Usage Mask [KMIP-SPEC 3.19][kmip-spec-3.19]              | ✅        |        |
+    | State [KMIP-SPEC 3.22][kmip-spec-3.22]                                 | ✅        |        |
+    | Initial Date [KMIP-SPEC 3.23][kmip-spec-3.23]                          | ✅        |        |
+    | Process Start Date [KMIP-SPEC 3.25][kmip-spec-3.25]                    | ✅        | Vault 1.11 |
+    | Protect Stop Date [KMIP-SPEC 3.26][kmip-spec-3.26]                     | ✅        | Vault 1.11 |
+    | Activation Date [KMIP-SPEC 3.24][kmip-spec-3.24]                       | ✅        |        |
+    | Deactivation Date [KMIP-SPEC 3.27][kmip-spec-3.27]                     | ✅        |        |
+    | Compromise Occurrence Date [KMIP-SPEC 3.29][kmip-spec-3.29]            | ✅        |        |
+    | Compromise Date [KMIP-SPEC 3.30][kmip-spec-3.30]                       | ✅        |        |
+    | Revocation Reason [KMIP-SPEC 3.31][kmip-spec-3.31]                     | ✅        |        |
+    | Object Group [KMIP-SPEC 3.33][kmip-spec-3.33]                          | ✅        |        |
+    | Fresh [KMIP-SPEC 3.34][kmip-spec-3.34]                                 | ✅        |        |
+    | Link [KMIP-SPEC 3.35][kmip-spec-3.35]                                  | ✅        |        |
+    | Last Change Date [KMIP-SPEC 3.38][kmip-spec-3.38]                      | ✅        |        |
+    | Alternative Name [KMIP-SPEC 3.40][kmip-spec-3.40]                      | ✅        | Vault 1.12 |
+    | Key Value Present [KMIP-SPEC 3.41][kmip-spec-3.41]                     | ✅        | Vault 1.12 |
+    | Key Value Location [KMIP-SPEC 3.42][kmip-spec-3.42]                    | 🔴        |        |
+    | Original Creation Date [KMIP-SPEC 3.43][kmip-spec-3.43]                | ✅        |        |
+    | Random Number Generator [KMIP-SPEC 3.44][kmip-spec-3.44]               | ✅        |        |
+    | Description [KMIP-SPEC 3.46][kmip-spec-3.46]                           | ✅        |        |
+    | Comment [KMIP-SPEC 3.47][kmip-spec-3.47]                               | ✅        |        |
+    | Sensitive [KMIP-SPEC 3.48][kmip-spec-3.48]                             | ✅        |        |
+    | Always Sensitive [KMIP-SPEC 3.49][kmip-spec-3.49]                      | ✅        |        |
+    | Extractable [KMIP-SPEC 3.50][kmip-spec-3.50]                           | ✅        |        |
+    | Never Extractable [KMIP-SPEC 3.51][kmip-spec-3.51]                     | ✅        |        |
+ 
+  3. Supports the following client-to-server operations:
+ 
+    | Operation                                             | Supported | Notes |
+    | ------------------------------------------------------| :--------:|:-----:|
+    | Locate [KMIP-SPEC 4.9][kmip-spec-4.9]                 | ✅        | Vault version 1.11 supports attributes Activation Date, Application Specific Information, Cryptographic Algorithm, Cryptographic Length, Name, Object Type, Original Creation Date, and State. <br/> Vault version 1.12 supports all profile attributes except for Key Value Location.      |
+    | Check [KMIP-SPEC 4.10][kmip-spec-4.10]                | 🔴        |        |
+    | Get [KMIP-SPEC 4.11][kmip-spec-4.11]                  | ✅        |        |
+    | Get Attributes [KMIP-SPEC 4.12][kmip-spec-4.12]       | ✅        |        |
+    | Get Attribute List [KMIP-SPEC 4.13][kmip-spec-4.13]   | ✅        |        |
+    | Add Attribute [KMIP-SPEC 4.14][kmip-spec-4.14]        | ✅        |        |
+    | Modify Attribute [KMIP-SPEC 4.15][kmip-spec-4.15]     | ✅        | Vault 1.12 |
+    | Delete Attribute [KMIP-SPEC 4.16][kmip-spec-4.16]     | ✅        | Vault 1.12 |
+    | Activate [KMIP-SPEC 4.19][kmip-spec-4.19]             | ✅        |        |
+    | Revoke [KMIP-SPEC 4.20][kmip-spec-4.20]               | ✅        |        |
+    | Destroy [KMIP-SPEC 4.21][kmip-spec-4.21]              | ✅        |        |
+    | Query [KMIP-SPEC 4.25][kmip-spec-4.25]                | ✅        | Vault 1.11 |
+    | Discover Versions [KMIP-SPEC 4.26][kmip-spec-4.26]    | ✅        |        |
+ 
+  4.Supports the following message contents:
+ 
+    | Message Content                                                  | Supported |
+    | -----------------------------------------------------------------| :--------:|
+    | Protocol Version [KMIP-SPEC 6.1][kmip-spec-6.1]                  | ✅        |
+    | Operation [KMIP-SPEC 6.2][kmip-spec-6.2]                         | ✅        |
+    | Maximum Response Size [KMIP-SPEC 6.3][kmip-spec-6.3]             | ✅        |
+    | Unique Batch Item ID [KMIP-SPEC 6.4][kmip-spec-6.4]              | ✅        |
+    | Time Stamp [KMIP-SPEC 6.5][kmip-spec-6.5]                        | ✅        |
+    | Asynchronous Indicator [KMIP-SPEC 6.7][kmip-spec-6.7]            | ✅        |
+    | Result Status [KMIP-SPEC 6.9][kmip-spec-6.9]                     | ✅        |
+    | Result Reason [KMIP-SPEC 6.10][kmip-spec-6.10]                   | ✅        |
+    | Batch Order Option [KMIP-SPEC 6.12][kmip-spec-6.12]              | ✅        |
+    | Batch Error Continuation Option [KMIP-SPEC 6.13][kmip-spec-6.13] | ✅        |
+    | Batch Count [KMIP-SPEC 6.14][kmip-spec-6.14]                     | ✅        |
+    | Batch Item [KMIP-SPEC 6.15][kmip-spec-6.15]                      | ✅        |
+    | Attestation Capable Indicator [KMIP-SPEC 6.17][kmip-spec-6.17]   | ✅        |
+    | Client Correlation Value [KMIP-SPEC 6.18][kmip-spec-6.18]        | ✅        |
+    | Server Correlation Value [KMIP-SPEC 6.19][kmip-spec-6.19]        | ✅        |
+    | Message Extension [KMIP-SPEC 6.16][kmip-spec-6.16]               | ✅        |
+ 
+  5. Supports the ID Placeholder [KMIP-SPEC 4][kmip-spec-4]
+  6. Supports Message Format [KMIP-SPEC 7][kmip-spec-7]
+  7. Supports Authentication [KMIP-SPEC 8][kmip-spec-8]
+  8. Supports the TTLV encoding [KMIP-SPEC 9.1][kmip-spec-9.1]
+  9. Supports the transport requirements [KMIP-SPEC 10][kmip-spec-10]
+  10. Supports Error Handling [KMIP-SPEC 11][kmip-spec-11] for any supported object, attribute, or operation
+  11. Optionally supports any clause within [KMIP-SPEC][kmip-spec] that is not listed above
+  12. Optionally supports extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements - We do not have any extensions
+ 
+## [Symmetric Key Lifecycle Server][lifecycle-server]
+ 
+  1. SHALL conform to the [Baseline Server][baseline-server]
+  2. Supports the following objects:
+ 
+    | Object                                                                 | Supported |
+    | -----------------------------------------------------------------------| :----- --:|
+    | Symmetric Key [KMIP-SPEC 2.2.2][kmip-spec-2.2.2]                       | ✅        |
+    | Key Format Type [KMIP-SPEC 9.1.3.2.3][kmip-spec-9.1.3.2.3]             | ✅        |
+ 
+  3. Supports the following subsets of attributes:
+ 
+    | Attribute                                                              | Supported | Notes |
+    | -----------------------------------------------------------------------| :-------: | :---: |
+    | Cryptographic Algorithm [KMIP-SPEC 3.4][kmip-spec-3.4]                 | ✅        |       |
+    | Object Type [KMIP-SPEC 3.3][kmip-spec-3.3]                             | ✅        |       |
+    | Process Start Date [KMIP-SPEC 3.25][kmip-spec-3.25]                    | ✅        | Vault 1.11 |
+    | Protect Stop Date [KMIP-SPEC 3.26][kmip-spec-3.26]                     | ✅        | Vault 1.11 |
+ 
+  4. Supports the following client-to-server operations:
+ 
+    | Operation                                             | Supported |
+    | ------------------------------------------------------| :--------:|
+    | Create [KMIP-SPEC 4.1][kmip-spec-4.1]                 | ✅        |
+ 
+  5. Supports the following message encoding:
+ 
+    | Message Encoding                                                                     | Supported | Notes |
+    | -------------------------------------------------------------------------------------| :--------:|:-----:|
+    | Cryptographic Algorithm [KMIP-SPEC 9.1.3.2.13][kmip-spec-9.1.3.2.13] with values:    |           |       |
+    | i. 3DES                                                                              | ✅        | Vault 1.12 |
+    | ii. AES                                                                              | ✅        |        |
+    | Object Type [KMIP-SPEC 9.1.3.2.12][kmip-spec-9.1.3.2.12] with value:                 |           |        |
+    | i. Symmetric Key                                                                     | ✅        |        |
+    | Key Format Type [KMIP-SPEC 9.1.3.2.3][kmip-spec-9.1.3.2.3] with value:               |           |        |
+    | i. Raw                                                                               | ✅        |        |
+    | ii. Transparent Symmetric Key                                                        | 🔴        |        |
+ 
+  6. MAY support any clause within [KMIP-SPEC][kmip-spec] provided it does not conflict with any other clause within the section [Symmetric Key Lifecycle Server][lifecycle-server]
+  7. MAY support extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements.
+ 
+## [Basic Cryptographic Server][basic-cryptographic-server]
+ 
+  1. SHALL conform to the [Baseline Server][baseline-server]
+  2. Supports the following client-to-server operations:
+ 
+    | Operation                                             | Supported | Notes   |
+    | ------------------------------------------------------| :--------:| --------|
+    | Encrypt [KMIP-SPEC 4.29][kmip-spec-4.29]              | ✅        | Vault 1.11 <br/> Supported for AES, unsupported for 3DES: <br/><br/> Supported Block Cipher Modes: <br/> <ol> <li> GCM </li> <li> CBC </li> <li> CFB </li> <li> CTR </li> <li> ECB </li> <li> OFB </li> </ol> <br/> Stream operations are supported except for GCM block cipher mode. <br/><br/> Supported padding methods: <br/> <ol> <li> None </li> <li> PKCS5 </li> </ol>  |
+    | Decypt [KMIP-SPEC 4.30][kmip-spec-4.30]               | ✅        | Vault 1.11 <br/> Supported for AES, unsupported for 3DES: <br/><br/> Supported Block Cipher Modes: <br/> <ol> <li> GCM </li> <li> CBC </li> <li> CFB </li> <li> CTR </li> <li> ECB </li> <li> OFB </li> </ol> <br/> Stream operations are supported except for GCM block cipher mode. <br/><br/> Supported padding methods: <br/> <ol> <li> None </li> <li> PKCS5 </li> </ol>  |  |
+ 
+  3. MAY support any clause within [KMIP-SPEC][kmip-spec] provided it does not conflict with any other clause within the section [Basic Cryptographic Server][basic-cryptographic-server]
+  4. MAY support extensions outside the scope of this standard (e.g., vendor extensions, conformance clauses) that do not contradict any KMIP requirements.
+ 
+ 
+  [kmip-spec-2.1.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660735
+  [kmip-spec-2.1.2]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660736
+  [kmip-spec-2.1.3]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660737
+  [kmip-spec-2.1.4]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660738
+  [kmip-spec-2.1.8]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660757
+  [kmip-spec-2.1.9]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660758
+  [kmip-spec-2.1.19]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660768
+  [kmip-spec-2.1.20]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660769
+  [kmip-spec-2.1.21]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660770
+  [kmip-spec-3.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660784
+  [kmip-spec-3.2]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660785
+  [kmip-spec-3.3]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660786
+  [kmip-spec-3.4]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660787
+  [kmip-spec-3.5]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660788
+  [kmip-spec-3.6]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660789
+  [kmip-spec-3.17]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660800
+  [kmip-spec-3.19]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660807
+  [kmip-spec-3.22]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660810
+  [kmip-spec-3.23]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660811
+  [kmip-spec-3.25]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660813
+  [kmip-spec-3.26]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660814
+  [kmip-spec-3.24]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660812
+  [kmip-spec-3.27]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660815
+  [kmip-spec-3.29]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660817
+  [kmip-spec-3.30]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660818
+  [kmip-spec-3.31]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660819
+  [kmip-spec-3.33]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660821
+  [kmip-spec-3.34]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660822
+  [kmip-spec-3.35]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660823
+  [kmip-spec-3.38]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660826
+  [kmip-spec-3.40]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660828
+  [kmip-spec-3.41]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660829
+  [kmip-spec-3.42]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660830
+  [kmip-spec-3.43]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660831
+  [kmip-spec-3.44]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660832
+  [kmip-spec-3.46]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660834
+  [kmip-spec-3.47]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660835
+  [kmip-spec-3.48]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660836
+  [kmip-spec-3.49]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660837
+  [kmip-spec-3.50]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660838
+  [kmip-spec-3.51]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660839
+  [kmip-spec-4.9]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660849
+  [kmip-spec-4.10]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660850
+  [kmip-spec-4.11]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660851
+  [kmip-spec-4.12]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660852
+  [kmip-spec-4.13]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660853
+  [kmip-spec-4.14]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660854
+  [kmip-spec-4.15]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660855
+  [kmip-spec-4.16]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660856
+  [kmip-spec-4.19]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660859
+  [kmip-spec-4.20]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660860
+  [kmip-spec-4.21]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660861
+  [kmip-spec-4.25]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660865
+  [kmip-spec-4.26]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660866
+  [kmip-spec-6.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660887
+  [kmip-spec-6.2]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660888
+  [kmip-spec-6.3]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660889
+  [kmip-spec-6.4]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660890
+  [kmip-spec-6.5]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660891
+  [kmip-spec-6.7]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660893
+  [kmip-spec-6.9]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660895
+  [kmip-spec-6.10]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660896
+  [kmip-spec-6.12]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660898
+  [kmip-spec-6.13]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660899
+  [kmip-spec-6.14]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660900
+  [kmip-spec-6.15]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660901
+  [kmip-spec-6.17]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660903
+  [kmip-spec-6.18]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660904
+  [kmip-spec-6.19]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660905
+  [kmip-spec-6.16]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660902
+  [kmip-spec-4]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660840
+  [kmip-spec-7]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660906
+  [kmip-spec-8]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660909
+  [kmip-spec-9.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660911
+  [kmip-spec-10]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660973
+  [kmip-spec-11]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660974
+  [kmip-spec]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html
+  [kmip-spec-2.2.2]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660775
+  [kmip-spec-9.1.3.2.3]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660923
+  [kmip-spec-4.1]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660841
+  [kmip-spec-9.1.3.2.13]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660933
+  [kmip-spec-9.1.3.2.12]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660932
+  [kmip-spec-4.29]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660869
+  [kmip-spec-4.30]: https://docs.oasis-open.org/kmip/spec/v1.4/errata01/os/kmip-spec-v1.4-errata01-os-redlined.html#_Toc490660870
+  [baseline-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431430
+  [lifecycle-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431487
+  [basic-cryptographic-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431527
+  [tc-proc-2.18]: https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26/technical-committee-tc-process-27-july-2011/#specQuality

@@ -60,9 +60,9 @@ there are only three ways to create root tokens:
  
 1. The initial root token generated at `vault operator init` time -- this token has no
    expiration
-2. By using another root token; a root token with an expiration cannot create a
+1. By using another root token; a root token with an expiration cannot create a
    root token that never expires
-3. By using `vault operator generate-root` ([example](/guides/operations/generate-root))
+1. By using `vault operator generate-root` ([example](https://learn.hashicorp.com/tutorials/vault/generate-root))
    with the permission of a quorum of unseal key holders
  
 Root tokens are useful in development but should be extremely carefully guarded
@@ -91,10 +91,10 @@ Often this behavior is not desired, so users with appropriate access can create
 token tree. These orphan tokens can be created:
  
 1. Via `write` access to the `auth/token/create-orphan` endpoint
-2. By having `sudo` or `root` access to the `auth/token/create`
+1. By having `sudo` or `root` access to the `auth/token/create`
    and setting the `no_parent` parameter to `true`
-3. Via token store roles
-4. By logging in with any other (non-`token`) auth method
+1. Via token store roles
+1. By logging in with any other (non-`token`) auth method
  
 Users with appropriate permissions can also use the `auth/token/revoke-orphan`
 endpoint, which revokes the given token but rather than revoke the rest of the
@@ -108,9 +108,9 @@ accessor is a value that acts as a reference to a token and can only be used to
 perform limited actions:
  
 1. Look up a token's properties (not including the actual token ID)
-2. Look up a token's capabilities on a path
-3. Renew the token
-4. Revoke the token
+1. Look up a token's capabilities on a path
+1. Renew the token
+1. Revoke the token
  
 The token _making the call_, _not_ the token associated with the accessor, must
 have appropriate permissions for these functions.
@@ -159,11 +159,11 @@ token's information is looked up. It is based on a combination of factors:
  
 1. The system max TTL, which is 32 days but can be changed in Vault's
    configuration file.
-2. The max TTL set on a mount using [mount
+1. The max TTL set on a mount using [mount
    tuning](/api-docs/system/mounts). This value
    is allowed to override the system max TTL -- it can be longer or shorter,
    and if set this value will be respected.
-3. A value suggested by the auth method that issued the token. This
+1. A value suggested by the auth method that issued the token. This
    might be configured on a per-role, per-group, or per-user basis. This value
    is allowed to be less than the mount max TTL (or, if not set, the system max
    TTL), but it is not allowed to be longer.
@@ -194,8 +194,8 @@ can be created in a few ways:
  
 1. By having `sudo` capability or a `root` token with the `auth/token/create`
    endpoint
-2. By using token store roles
-3. By using an auth method that supports issuing these, such as
+1. By using token store roles
+1. By using an auth method that supports issuing these, such as
    AppRole
  
 At issue time, the TTL of a periodic token will be equal to the configured

@@ -0,0 +1,76 @@
+---
+layout: api
+page_title: Redis - Database - Secrets Engines - HTTP API
+description: >-
+  The Redis plugin for Vault's database secrets engine generates [ACL credentials](https://redis.io/docs/manual/security/acl/)
+  to access Redis servers.
+---
+ 
+# Redis Database Plugin HTTP API
+ 
+The Redis database plugin is one of the supported plugins for the database
+secrets engine. This plugin generates database credentials dynamically based on
+configured roles for the Redis database.
+ 
+## Configure Connection
+ 
+In addition to the parameters defined by the [Database
+Secrets Engine](/api-docs/secret/databases#configure-connection), this plugin
+has a number of parameters to further configure a connection.
+ 
+| Method | Path                     |
+| :----- | :----------------------- |
+| `POST` | `/database/config/:name` |
+ 
+### Parameters
+ 
+- `host` `(string: <required>)` – Specifies the host to connect to.
+ 
+- `port` `(int: <required>)` – Specifies the port number of the connection.
+ 
+- `username` `(string: <required>)` – Specifies the username for Vault to use.
+ 
+- `password` `(string: <required>)` – Specifies the password corresponding to the given username.
+ 
+- `tls` `(bool: false)` – Specifies whether to use TLS when connecting to Redis.
+ 
+- `insecure_tls` `(bool: false)` – Specifies whether to skip verification of the
+server certificate when using TLS.
+ 
+### Sample Payload
+ 
+```json
+{
+  "plugin_name": "redis-database-plugin",
+  "host": "localhost://127.0.0.1",
+  "username": "user",
+  "password": "pass",
+  "allowed-roles": "my-*-role"
+}
+```
+ 
+### Sample Request
+ 
+```shell-session
+$ curl \
+    --header "X-Vault-Token: ..." \
+    --request POST \
+    --data @payload.json \
+    http://127.0.0.1:8200/v1/database/config/redis
+```
+ 
+## Statements
+ 
+Statements are configured during role creation and are used by the plugin to
+determine what is sent to the database on user creation, renewing, and
+revocation. For more information on configuring roles see the [Role
+API](/api/secret/databases#create-role) in the database secrets engine docs.
+ 
+### Parameters
+ 
+The following are the statements used by this plugin. If not mentioned in this
+list the plugin does not support that statement type.
+ 
+- `creation_statements` `(list: [])` – Specifies a JSON string containing
+[Redis ACL rules](https://redis.io/commands/acl-cat) to assign to created users. If not provided, defaults to
+a read-only user that can read any key.

@@ -89,7 +89,7 @@ Although client counts have been available via the usage metrics UI since Vault
   - Changed the non-entity token computation logic to deduplicate non-entity tokens, reducing the overall client count. Moving forward, non-entity tokens, where there is no entity to map tokens, Vault will use the contents of the token to generate a unique client identifier based on the namespace ID and associated policies. The clientID will prevent duplicating the same token in the overall client count when the token is used again during the billing period.
   - Changed the tracking of non-entity tokens to complete on access instead of creation.
   - Changed the computation logic to not include root tokens in the client count aggregate.
-  - Changed the local auth mount computation logic such that local auth mounts count towards clients but not as non-entity tokens. Prior to Vault 1.9, local auth mounts counted towards non-entity tokens. Refer to the [What is a Client?](docs/concepts/client-count) documentation to learn more.
+  - Changed the local auth mount computation logic such that local auth mounts count towards clients but not as non-entity tokens. Prior to Vault 1.9, local auth mounts counted towards non-entity tokens. Refer to the [What is a Client?](/docs/concepts/client-count) documentation to learn more.
   - Added ability to display clients per namespace (top 10, descending order) in the UI and export data for all namespaces. Prior to Vault 1.9, you could not view view the split of clients per namespace on the UI, nor could you export this data via the UI.
   - Added ability to display clients earlier than a month (within ten minutes of enabling the feature) in the UI. Prior to Vault 1.9, after enabling the counting of clients, you had to wait for a month to view the client aggregates in the UI.
   - Changed functionality to disallow creating two aliases from the same auth mount under a single entity. For more information, refer to the question [Starting in Vault 1.9, Vault does not allow creating two aliases from the same auth mount under a single entity. What changed and how does this impact client counting?](#q-starting-in-vault-1-9-vault-does-not-allow-creating-two-aliases-from-the-same-auth-mount-under-a-single-entity-what-changed-and-how-does-this-impact-client-counting)
@@ -257,7 +257,7 @@ However, creating a new token across a parent/child namespace boundary could res
  
 ### Q: How does the Nomad Vault integration affect client counts?
  
-The [Nomad Vault integration](https://www.nomadproject.io/docs/integrations/vault-integration#token-role-based-integration) uses [token roles](https://www.nomadproject.io/docs/integrations/vault-integration#vault-token-role-configuration). A single token role creates tokens for many Nomad jobs. If no [explicit identity aliases](/api-docs/auth/token#entity_alias) are provided (which is not currently supported in the integration), this would create a non-entity token for every running instance of a Nomad job.
+The [Nomad Vault integration](https://www.nomadproject.io/docs/integrations/vault-integration#token-role-based-integration) uses [token roles](https://www.nomadproject.io/docs/integrations/vault-integration#vault-token-role-configuration#vault-token-role-configuration). A single token role creates tokens for many Nomad jobs. If no [explicit identity aliases](/api-docs/auth/token#entity_alias) are provided (which is not currently supported in the integration), this would create a non-entity token for every running instance of a Nomad job.
 Prior to Vault 1.9, the Nomad Vault integration caused duplicate clients, resulting in an elevated client count. Post Vault 1.9, with the introduction of the deduplication logic, the number of clients created by the integration is reduced. For more information on improvements made to client count in Vault 1.9, refer to the question [Which version of Vault reflects the most accurate count of clients with Vault?](#q-which-vault-version-reflects-the-most-accurate-client-counts).
  
 ### Q: Starting in Vault 1.7, Vault does not allow creating two aliases from the same auth mount under a single entity. What changed and how does this impact client counting?

@@ -6,58 +6,76 @@ description: These are general upgrade instructions for Vault plugins.
  
 # Upgrading Vault Plugins
  
-## External Plugin Upgrade Procedure
+## Plugin Upgrade Procedure
  
-The following procedure details steps for upgrading an external plugin that has
-been registered to the catalog on a running server. This procedure is
-applicable to secret engines, auth methods, and database plugins.
+The following procedures detail steps for upgrading a plugin that has been mounted
+at a path on a running server. The steps are the same whether the plugin being
+upgraded is built-in or external.
  
-Vault executes plugin binaries when they are configured and roles are established
-around them. The binary cannot be modified or replaced while running, so
-upgrades cannot be performed by simply swapping the binary and updating the hash
-in the plugin catalog.
+~> Plugin versioning was introduced with Vault 1.12.0, so if your Vault server is
+  on 1.11.x or earlier, see the [1.11.x version of this page](/docs/v1.11.x/upgrading/plugins)
+  for plugin upgrade instructions.
  
-Instead, you can restart or reload a plugin with the
-`sys/plugins/reload/backend` [API][plugin_reload_api]. Follow these steps to
-replace or upgrade a Vault plugin binary:
+### Upgrading auth and secrets plugins
  
-1. [Register][plugin_registration] version 1 of `my-db-plugin` to the catalog.
-   Skip this step if your plugin is already registered.
+The process is nearly identical for auth and secret plugins. If you are upgrading
+an auth plugin, just replace all usages of `secrets` or `secret` with `auth`.
+ 
+1. [Register][plugin_registration] the first version of your plugin to the catalog.
+   Skip this step if your initial plugin is built-in or already registered.
  
     ```shell-session
-    $ vault plugin register -sha256=<SHA256 Hex value of the plugin binary> \
-        database \                  # type
-        my-db-plugin
+    $ vault plugin register
+        -sha256=<SHA256 Hex value of the plugin binary> \
+        secret \
+        my-secret-plugin
     ```
  
-2. [Mount][plugin_management] the plugin backend. Skip this step if the backend
+1. [Mount][plugin_management] the plugin. Skip this step if your initial plugin
    is already mounted.
  
     ```shell-session
-    $ vault secrets enable database
+    $ vault secrets enable my-secret-plugin
     ```
  
-3. Register version 2 of `my-db-plugin` to the catalog under the same plugin
-   name, but with updated command to run version 2 of `my-db-plugin` and updated
-   sha256 of the new binary
+1. Register a second version of your plugin. You **must** use the same plugin
+   type and name (the last two arguments) as the plugin being upgraded. This is
+   true regardless of whether the plugin being upgraded is built-in or external.
  
     ```shell-session
-    $ vault plugin register -sha256=<SHA256 Hex value of the plugin binary> \
-        database \                  # type
-        my-db-plugin
+    $ vault plugin register \
+        -sha256=<SHA256 Hex value of the plugin binary> \
+        -command=my-secret-plugin-1.0.1 \
+        -version=v1.0.1 \
+        secret \
+        my-secret-plugin
     ```
  
-4. Trigger a [plugin reload](/docs/commands/plugin/reload) to reload all
+1. Tune the existing mount to configure it to use the newly registered version.
+ 
+   ```shell-session
+   $ vault secrets tune -plugin-version=v1.0.1 my-secret-plugin
+   ```
+ 
+1. If you wish, you can check the updated configuration. Notice the "Version" is
+   now different from the "Running Version".
+ 
+   ```shell-session
+   $ vault secrets list -detailed
+   ```
+ 
+1. Finally, trigger a [plugin reload](/docs/commands/plugin/reload) to reload all
    mounted backends using that plugin or a subset of the mounts using that plugin
-   with either the `plugin` or `mounts` parameter respectively.
+   with either the `plugin` or `mounts` flag respectively.
  
     ```shell-session
-    $ vault plugin reload -plugin my-db-plugin
+    $ vault plugin reload -plugin my-secret-plugin
     ```
  
-Until step 4, the mount will still use version 1 of `my-db-plugin`, and when
-the reload is triggered, Vault will kill `my-db-plugin`’s process and start the
-new plugin process for `my-db-plugin` version 2.
+Until the last step, the mount will still run the first version of `my-secret-plugin`. When
+the reload is triggered, Vault will kill `my-secret-plugin`’s process and start the
+new plugin process for `my-secret-plugin` version 1.0.1. The "Running Version" should also
+now match the "Version" when you run `vault secrets list -detailed`.
  
 -> **Important:** Plugin reload of a new plugin binary must be
 performed on each Vault instance. Performing a plugin upgrade on a single
@@ -65,147 +83,101 @@ instance or through a load balancer can result in mismatched
 plugin binaries within a cluster. On a replicated cluster this may be accomplished
 by setting the 'scope' parameter of the reload to 'global'.
  
-## Overriding Built-in Plugins
- 
-### Background
- 
-Vault's auth methods and secrets engines are structured as plugins, but this
-design is not obvious since many of them are built into Vault.
- 
-You can see them with the Vault plugin list command, for example, the list of
-Secrets engines:
- 
-```shell-session
-$ vault plugin list secret
-Plugins
-ad
-alicloud
-aws
-azure
-cassandra
-consul
-gcp
-gcpkms
-kv
-ldap
-mongodb
-mongodbatlas
-mssql
-mysql
-nomad
-openldap
-pki
-postgresql
-rabbitmq
-ssh
-terraform
-totp
-transit
-```
- 
-This will list all Secrets engines, internal (built-in) or external. To find
-out if a plugin is built-in, we can query its info:
- 
-```shell-session
-$ vault plugin info secret azure
-Key        Value
-args       []
-builtin    true
-command    n/a
-name       azure
-sha256     n/a
-```
- 
-Because these built-in engines are plugins, they can be overridden. This can be
-a useful way to leverage features or bug fixes in plugins that are newer than
-the version of Vault you're using, without updating or even restarting Vault,
-and while retaining the data for your existing mount.
- 
-Assume you have a new version of Azure Secrets and the binary is called
-"azure_new". The binary needs to be in the [plugin directory](/docs/plugins/plugin-architecture#plugin-directory)
-and can then be registered as either a distinct plugin, or overriding the
-current one.
- 
-~> **Important:** do not disable (`vault secrets disable ...`) any mount that has
-data you're interested in; that would erase storage. For the in-place update,
-register a new plugin atop the built-in one and leave any mounts alone.
- 
-### Procedure for Overriding Built-in Plugins
- 
-The syntax is the same as an external plugin, with the difference being you
-name it the same as a built-in:
+### Upgrading database plugins
  
-```shell-session
-$ vault plugin register \
-  -sha256=<SHA256 Hex value of the plugin binary> \
-  -command=azure_new \
-  secret \
-  azure
-```
+1. [Register][plugin_registration] the first version of your plugin to the catalog.
+   Skip this step if your initial plugin is built-in or already registered.
  
-"-command=azure_new" is the name of the binary, "secret" is the plugin type,
-and "azure" is the name of the built-in plugin that we're overriding. We can
-verify that the override is in place:
- 
-```shell-session
-$ vault plugin info secret azure
-Key        Value
-args       []
-builtin    false
-command    azure_new
-name       azure
-sha256     f6f6ec45d37484c257aa9ff80444b9f244aaef1c650edf8a42a2a1d3f00db2c5
-```
+    ```shell-session
+    $ vault plugin register
+        -sha256=<SHA256 Hex value of the plugin binary> \
+        database \
+        my-db-plugin
+    ```
  
-At this point we've overridden the built-in, but it is not yet actively
-handling requests. For that we run:
+1. [Mount][plugin_management] the plugin. Skip this step if your initial plugin
+   is already mounted.
  
-```shell-session
-$ vault plugin reload -plugin=azure
-```
+    ```shell-session
+    $ vault secrets enable database
+    $ vault write database/config/my-db \
+        plugin_name=my-db-plugin \
+        # ...
+    ```
  
-### Procedure for Reverting After Overriding A Built-in Plugin
+1. Register a second version of your plugin. You **must** use the same plugin
+   type and name (the last two arguments) as the plugin being upgraded. This is
+   true regardless of whether the plugin being upgraded is built-in or external.
  
-To revert the override, first deregister the plugin:
+    ```shell-session
+    $ vault plugin register \
+        -sha256=<SHA256 Hex value of the plugin binary> \
+        -command=my-db-plugin-1.0.1 \
+        -version=v1.0.1 \
+        database \
+        my-db-plugin
+    ```
  
-```shell-session
-$ vault plugin deregister secret azure
-```
+1. Update the database config with the new version. The database secrets
+   engine will immediately reload the plugin, using the new version. Any omitted
+   config parameters will not be updated.
+    
+    ```shell-session
+    $ vault write database/config/my-db \
+        plugin_version=v1.0.1
+    ```
  
-Next, verify the override has been reverted and we are now using the built-in
-plugin:
+Until the last step, the mount will still run the first version of `my-db-plugin`. When
+the reload is triggered, Vault will kill `my-db-plugin`’s process and start the
+new plugin process for `my-db-plugin` version 1.0.1.
  
-```shell-session
-$ vault plugin info secret azure
-Key        Value
-args       []
-builtin    true
-command    n/a
-name       azure
-sha256     n/a
-```
+### Downgrading Plugins
  
-Finally, reload the plugin:
+Plugin downgrades follow the same procedure as upgrades. You can use the Vault
+plugin list command to check what plugin versions are available to downgrade to:
  
 ```shell-session
-$ vault plugin reload -plugin=azure
+$ vault plugin list secret
+Name                Version
+----                -------
+ad                  v0.14.0+builtin
+alicloud            v0.13.0+builtin
+aws                 v1.12.0+builtin.vault
+azure               v0.14.0+builtin
+cassandra           v1.12.0+builtin.vault
+consul              v1.12.0+builtin.vault
+gcp                 v0.14.0+builtin
+gcpkms              v0.13.0+builtin
+kv                  v0.13.3+builtin
+ldap                v1.12.0+builtin.vault
+mongodb             v1.12.0+builtin.vault
+mongodbatlas        v0.8.0+builtin
+mssql               v1.12.0+builtin.vault
+mysql               v1.12.0+builtin.vault
+nomad               v1.12.0+builtin.vault
+openldap            v0.9.0+builtin
+pki                 v1.12.0+builtin.vault
+postgresql          v1.12.0+builtin.vault
+rabbitmq            v1.12.0+builtin.vault
+ssh                 v1.12.0+builtin.vault
+terraform           v0.6.0+builtin
+totp                v1.12.0+builtin.vault
+transit             v1.12.0+builtin.vault
 ```
  
-### Caveats to Overriding Built-in Plugins
+### Additional Upgrade Notes
  
 * As mentioned earlier, disabling existing mounts will wipe the existing data.
-* This type of upgrade affects all uses of the plugin. So if you have 5
-  different Azure Secrets mounts, they'll all change after the replacement. If
-  you don't want that, you'll need to register the plugin under a different name
-  and start with a fresh mount.
-* In most cases, data upgrade and downgrade is not an issue. If the "new" version
-  introduces new data and you downgrade, the "old" version will ignore the
-  extraneous data. In some cases upgrading changes existing data in non-backwards
-  compatible ways, so it is good to check whether this is an issue.
+* Overwriting an existing version in the catalog will affect all uses of that
+  plugin version. So if you have 5 different Azure Secrets mounts using v1.0.0,
+  they'll all start using the new binary if you overwrite it. We recommend
+  treating plugin versions in the catalog as immutable, much like version control
+  tags.
+* Each plugin has its own data within Vault storage. While it is rare for HashiCorp
+  maintained plugins to update their storage schema, it is up to plugin authors
+  to manage schema upgrades and downgrades. Check the plugin release notes for
+  any unsupported upgrade or downgrade transitions, especially before moving to
+  a new major version or downgrading.
  
 [plugin_reload_api]: /api-docs/system/plugins-reload-backend
 [plugin_registration]: /docs/plugins/plugin-architecture#plugin-registration
 <82990506+hc-github-team-secure-vault-core@users.noreply.github.com>
 6cb818993eaf8537f65816daf7123645adc7d926 (#17505)
 builtin/logical/pki/path_tidy.go | 11 -----------
 changelog/17497.txt              |  3 +++
 2 files changed, 3 insertions(+), 11 deletions(-)
 create mode 100644 changelog/17497.txt

@@ -30,18 +30,52 @@ $ curl \
  
 ```json
 {
-  "github/": {
-    "type": "github",
-    "description": "GitHub auth"
-  },
-  "token/": {
-    "config": {
-      "default_lease_ttl": 0,
-      "max_lease_ttl": 0
+  "request_id": "9bc0fab8-d65c-3961-afe6-d05f50c5fd22",
+  "lease_id": "",
+  "lease_duration": 0,
+  "renewable": false,
+  "data": {
+    "github/": {
+      "accessor": "auth_github_badd7fd0",
+      "config": {
+        "default_lease_ttl": 0,
+        "force_no_cache": false,
+        "max_lease_ttl": 0,
+        "token_type": "default-service"
+      },
+      "deprecation_status": "supported",
+      "description": "",
+      "external_entropy_access": false,
+      "local": false,
+      "options": null,
+      "plugin_version": "",
+      "running_plugin_version": "v1.12.0+builtin.vault",
+      "running_sha256": "",
+      "seal_wrap": false,
+      "type": "github",
+      "uuid": "4b42d1a4-0a0d-3c88-ae90-997e0c8b41be"
     },
-    "description": "token based credentials",
-    "type": "token"
-  }
+    "token/": {
+      "accessor": "auth_token_bd90f507",
+      "config": {
+        "default_lease_ttl": 0,
+        "force_no_cache": false,
+        "max_lease_ttl": 0,
+        "token_type": "default-service"
+      },
+      "description": "token based credentials",
+      "external_entropy_access": false,
+      "local": false,
+      "options": null,
+      "plugin_version": "",
+      "running_plugin_version": "v1.12.0+builtin.vault",
+      "running_sha256": "",
+      "seal_wrap": false,
+      "type": "token",
+      "uuid": "e162baec-721b-7657-7913-c960df402f8a"
+    }
+  },
+  "warnings": null
 }
 ```
  
@@ -99,6 +133,11 @@ For example, enable the "foo" auth method will make it accessible at
   - `allowed_response_headers` `(array: [])` - List of headers to whitelist,
     allowing a plugin to include them in the response.
  
+  - `plugin_version` `(string: "")` – Specifies the semantic version of the plugin
+    to use, e.g. "v1.0.0". If unspecified, the server will select any matching
+    unversioned plugin that may have been registered, the latest versioned plugin
+    registered, or a built-in plugin in that order of precendence.
+ 
 Additionally, the following options are allowed in Vault open-source, but
 relevant functionality is only supported in Vault Enterprise:
  
@@ -145,9 +184,9 @@ $ curl \
  
 This endpoints returns the configuration of the auth method at the given path.
  
-| Method | Path             |
-| :----- | :--------------- |
-| `GET`  | `/sys/auth/path` |
+| Method | Path              |
+| :----- | :---------------- |
+| `GET`  | `/sys/auth/:path` |
  
 ### Sample Request
  
@@ -161,24 +200,10 @@ $ curl \
  
 ```json
 {
-  "uuid": "4b42d1a4-0a0d-3c88-ae90-997e0c8b41be",
-  "type": "github",
-  "accessor": "auth_github_badd7fd0",
-  "local": false,
-  "seal_wrap": false,
-  "external_entropy_access": false,
-  "options": null,
-  "config": {
-    "default_lease_ttl": 0,
-    "force_no_cache": false,
-    "max_lease_ttl": 0,
-    "token_type": "default-service"
-  },
-  "description": "",
   "request_id": "8d2a1e33-4c00-46a5-f50d-4dc5f5d96f12",
   "lease_id": "",
-  "renewable": false,
   "lease_duration": 0,
+  "renewable": false,
   "data": {
     "accessor": "auth_github_badd7fd0",
     "config": {
@@ -187,17 +212,19 @@ $ curl \
       "max_lease_ttl": 0,
       "token_type": "default-service"
     },
+    "deprecation_status": "supported",
     "description": "",
     "external_entropy_access": false,
     "local": false,
     "options": null,
+    "plugin_version": "",
+    "running_plugin_version": "v1.12.0+builtin.vault",
+    "running_sha256": "",
     "seal_wrap": false,
     "type": "github",
     "uuid": "4b42d1a4-0a0d-3c88-ae90-997e0c8b41be"
   },
-  "wrap_info": null,
-  "warnings": null,
-  "auth": null
+  "warnings": null
 }
 ```
  
@@ -316,6 +343,9 @@ can be achieved without `sudo` via `sys/mounts/auth/[auth-path]/tune`._
   - `batch`: Override any auth method preference and always issue batch tokens
     from this mount
  
+- `plugin_version` `(string: "")` – Specifies the semantic version of the plugin
+  to use, e.g. "v1.0.0". Changes will not take effect until the mount is reloaded.
+ 
 ### Sample Payload
  
 ```json

@@ -7,21 +7,24 @@ description: Learn about Vault's plugin system.
  
 # Plugin System
  
-All Vault auth methods and secrets engines are considered plugins. This concept
-allows both built-in and external plugins to be treated like building blocks.
-Any plugin can exist at multiple different mount paths. Different versions of a
-plugin may be at each location, with each version differing from Vault's
-version.
+Vault supports 3 types of plugins; auth methods, secret engines, and database
+plugins. This concept allows both built-in and external plugins to be treated
+like building blocks. Any plugin can exist at multiple different mount paths.
+Different versions of a plugin may be at each location, with each version differing
+from Vault's version.
  
-## Built-In Plugins
+A plugin is uniquely identified by its type (one of `secret`, `auth`, or
+`database`), name (e.g. `aws`), and version (e.g `v1.0.0`). An empty version
+implies either the built-in plugin or the single unversioned plugin that can
+be registered.
+ 
+See [Plugin Upgrade Procedure](/docs/upgrading/plugins#plugin-upgrade-procedure)
+for details on how to upgrade a built-in plugin in-place.
  
-Built-in plugins are shipped with Vault, often for commonly used implementations,
-and require no additional operator intervention to run. Built-in plugins are
-just like any other backend code inside Vault.
+## Built-In Plugins
  
-To use a different or edited version of a built-in plugin, the plugin must be
-run as an external plugin. See [Overriding Built-in Plugins](/docs/upgrading/plugins#overriding-built-in-plugins)
-for details on how to override a built-in plugin in-place.
+Built-in plugins are shipped with Vault, often for commonly used integrations,
+and can be used without any prerequisite steps.
  
 ## External Plugins
  
@@ -33,8 +36,48 @@ binaries can be obtained from [releases.hashicorp.com](https://releases.hashicor
 or they can be [built from source](/docs/plugins/plugin-development#building-a-plugin-from-source).
  
 Vault's external plugins are completely separate, standalone applications that
-Vault executes and communicates with over RPC. Each time a Vault secret engine
-or auth method is mounted, a new process is spawned. However, plugins can be
-made to implement [plugin multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing)
+Vault executes and communicates with over RPC. Each time a Vault secret engine,
+auth method, or database plugin is mounted, a new process is spawned. However,
+plugins can be made to implement [plugin multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing)
 to improve performance. Plugin multiplexing allows plugin processes to be
 reused across all mounts of a given type.
+ 
+## Plugin Versioning
+ 
+Vault supports managing, running and upgrading plugins using semantic version
+information.
+ 
+The plugin catalog optionally supports specifying a semantic version when
+registering an external plugin. Multiple versions of a plugin can be registered
+in the catalog simultaneously, and a version can be selected when mounting a
+plugin or tuning an existing mount in-place.
+ 
+If no version is specified when creating a new mount, the following precedence is used
+for any available plugins whose type and name match:
+ 
+* The plugin registered with no version
+* The plugin with the most recent semantic version among any registered versions
+* The plugin built into Vault
+ 
+### Built-In Versions
+ 
+Vault will report a version for built-in plugins to indicate what version of the
+plugin code got built into Vault as a dependency. For example:
+ 
+```shell-session
+$ vault plugin list secret
+Name                Version
+----                -------
+ad                  v0.14.0+builtin
+alicloud            v0.13.0+builtin
+aws                 v1.12.0+builtin.vault
+# ...
+```
+ 
+Here, Vault has a dependency on `v0.14.0` of the [hashicorp/vault-plugin-secrets-ad](https://github.com/hashicorp/vault-plugin-secrets-ad)
+repo, and the `vault` metadata identifier for `aws` indicates that plugin's code was
+within the Vault repo. For plugins within the Vault repo, Vault's own major, minor,
+and patch versions are used to form the plugin version.
+ 
+The `builtin` metadata identifier is reserved and cannot be used when registering
+external plugins.