hashicorp · taoism4504 · Apr 4, 2022 · Apr 3, 2022
@@ -209,7 +209,7 @@ page.
   or `"never"`.
 
 - `when_inconsistent` `(string: optional)` - Set to one of `"fail"`, `"retry"`,
-   or `"forward"`.
+  or `"forward"`.
 
 -> **Note:** When the `cache` block is defined, at least one
 [template][agent-template] or [listener][agent-listener] must also be defined
@@ -339,8 +339,8 @@ vault {
 }
 ```
 
-## Learn
+## Tutorial
 
 Refer to the [Vault Agent
 Caching](https://learn.hashicorp.com/vault/identity-access-management/agent-caching)
-guide for a step-by-step tutorial.
+tutorial to learn how to use the Vault Agent to increase the availability of tokens and secrets to clients using its Caching function.
@@ -231,11 +231,11 @@ not require a credential, but still enforce constraints for login. For
 example, `secret_id_bound_cidrs` will only allow logins coming from IP addresses
 belonging to configured CIDR blocks on the AppRole.
 
-## Learn
+## Tutorial
 
 Refer to the [AppRole Pull
 Authentication](https://learn.hashicorp.com/vault/identity-access-management/iam-authentication)
-guide for a step-by-step tutorial.
+tutorial to learn how to use the AppRole method to generate tokens for machines or apps.
 
 ## API
 
@@ -341,12 +341,12 @@ using VaultSharp.V1.AuthMethods.AppRole;
 using VaultSharp.V1.AuthMethods.Token;
 using VaultSharp.V1.Commons;
 
-namespace Examples 
+namespace Examples
 {
     public class ApproleAuthExample
     {
         const string DefaultTokenPath = "../../../path/to/wrapping-token";
-        
+
         /// <summary>
         /// Fetches a key-value secret (kv-v2) after authenticating to Vault via AppRole authentication
         /// </summary>
@@ -356,7 +356,7 @@ namespace Examples
 	        // The Secret ID is a value that needs to be protected, so instead of the app having knowledge of the secret ID directly,
 	        // we have a trusted orchestrator (https://learn.hashicorp.com/tutorials/vault/secure-introduction?in=vault/app-integration#trusted-orchestrator)
 	        // give the app access to a short-lived response-wrapping token (https://www.vaultproject.io/docs/concepts/response-wrapping).
-	        // Read more at: https://learn.hashicorp.com/tutorials/vault/approle-best-practices?in=vault/auth-methods#secretid-delivery-best-practices             
+	        // Read more at: https://learn.hashicorp.com/tutorials/vault/approle-best-practices?in=vault/auth-methods#secretid-delivery-best-practices
             var vaultAddr = Environment.GetEnvironmentVariable("VAULT_ADDR");
             if(String.IsNullOrEmpty(vaultAddr))
             {
@@ -382,9 +382,9 @@ namespace Examples
             // We pass null here instead of the wrapping token to avoid depleting its single usage
             // given that we already initialized our client with the wrapping token
             Secret<Dictionary<string, object>> secretIdData =  vaultClientForUnwrapping.V1.System
-                .UnwrapWrappedResponseDataAsync<Dictionary<string, object>>(null).Result; 
+                .UnwrapWrappedResponseDataAsync<Dictionary<string, object>>(null).Result;
 
-            var secretId = secretIdData.Data["secret_id"]; // Grab the secret_id 
+            var secretId = secretIdData.Data["secret_id"]; // Grab the secret_id
 
             // We create a second VaultClient and initialize it with the AppRole auth method and our new credentials.
             IAuthMethodInfo authMethod = new AppRoleAuthMethodInfo(roleId, secretId.ToString());
@@ -395,9 +395,9 @@ namespace Examples
             // We can retrieve the secret from VaultClient
             Secret<SecretData> kv2Secret = null;
             kv2Secret = vaultClient.V1.Secrets.KeyValue.V2.ReadSecretAsync(path: "/creds").Result;
-            
+
             var password = kv2Secret.Data.Data["password"];
-            
+
             return password.ToString();
         }
     }

@@ -267,7 +267,7 @@ or deleted and are used to decrypt older data.
 rotation is desired for data that was seal wrapped prior to this version must also set
 `default_key_label` and `hmac_default_key_label` to allow for decryption of older values.
 
-## Learn
+## Tutorial
 
 Refer to the [HSM Integration - Seal Wrap](https://learn.hashicorp.com/vault/operations/ops-seal-wrap)
-guide for a step-by-step tutorial.
+tutorial to learn how to enable the Seal Wrap feature to protect your data.
@@ -92,5 +92,5 @@ migrate to Integrated Storage, read the following tutorials:
 ## Learn
 
 Refer to the [Integrated
-Storage](https://learn.hashicorp.com/collections/vault/raft) tutorial collection
+Storage](https://learn.hashicorp.com/collections/vault/raft) tutorials
 to learn more about Integrated Storage.
@@ -197,10 +197,9 @@ storage "raft" {
 }
 ```
 
-## Learn
+## Tutorial
 
 Refer to [Integrated
-Storage](https://learn.hashicorp.com/collections/vault/raft) for a collection of
-tutorials on Integrated Storage.
+Storage](https://learn.hashicorp.com/collections/vault/raft) for a tutorials on Integrated Storage.
 
 [raft]: https://raft.github.io/ 'The Raft Consensus Algorithm'
@@ -13,13 +13,13 @@ The following documentation describes installing, running, and using
 Vault and **Vault Agent Injector** on OpenShift.
 
 ~> **Note:** We recommend using the Vault agent injector on Openshift
-   instead of the Secrets Store CSI driver. OpenShift
-   [does not recommend](https://docs.openshift.com/container-platform/4.9/storage/persistent_storage/persistent-storage-hostpath.html)
-   using `hostPath` mounting in production or
-   [certify Helm charts](https://github.com/redhat-certification/chart-verifier/blob/dbf89bff2d09142e4709d689a9f4037a739c2244/docs/helm-chart-checks.md#table-2-helm-chart-default-checks)
-   using CSI objects because pods must run as privileged. If you would like to run the Secrets Store
-   CSI driver on a development or testing cluster, refer to
-   [installation instructions for the Vault CSI provider](/docs/platform/k8s/csi/installation).
+instead of the Secrets Store CSI driver. OpenShift
+[does not recommend](https://docs.openshift.com/container-platform/4.9/storage/persistent_storage/persistent-storage-hostpath.html)
+using `hostPath` mounting in production or
+[certify Helm charts](https://github.com/redhat-certification/chart-verifier/blob/dbf89bff2d09142e4709d689a9f4037a739c2244/docs/helm-chart-checks.md#table-2-helm-chart-default-checks)
+using CSI objects because pods must run as privileged. If you would like to run the Secrets Store
+CSI driver on a development or testing cluster, refer to
+[installation instructions for the Vault CSI provider](/docs/platform/k8s/csi/installation).
 
 ## Requirements
 
@@ -199,6 +199,8 @@ $ helm install vault hashicorp/vault \
     --set "injector.externalVaultAddr=http://external-vault:8200"
 ```
 
--> **Step-by-step instructions:** The [Integrate a Kubernetes Cluster with an
+## Tutorial
+
+Refer to the [Integrate a Kubernetes Cluster with an
 External Vault](https://learn.hashicorp.com/vault/getting-started-k8s/external-vault)
-guide demonstrates using an external Vault within a Kubernetes cluster.
+tutorial to learn how to use an external Vault within a Kubernetes cluster.
@@ -347,10 +347,9 @@ handle this is to simply wait and retry using the new password.
 
 Active Directory will only support password changes over a secure connection. Ensure that your configuration block is not using an unsecured LDAP connection.
 
-## Learn
+## Tutorial
 
-Refer to the [Active Directory Service Account Check-out](https://learn.hashicorp.com/vault/secrets-management/ad-secrets) guide
-for a step-by-step tutorial.
+Refer to the [Active Directory Service Account Check-out](https://learn.hashicorp.com/vault/secrets-management/ad-secrets) tutorial to learn how to enable a team to share a select set of service accounts.
 
 ## API
 

@@ -39,8 +39,8 @@ Vault as an OIDC provider.
    Success! Enabled userpass auth method at: userpass/
    ```
 
-  Any Vault auth method may be used within the OIDC flow. For simplicity, enable the
-  `userpass` auth method.
+Any Vault auth method may be used within the OIDC flow. For simplicity, enable the
+`userpass` auth method.
 
 2. Create a user:
 
@@ -70,7 +70,7 @@ Vault as an OIDC provider.
    To allow all Vault entities to authenticate, the built-in [allow_all](/docs/concepts/oidc-provider#assignments)
    assignment is provided.
 
-5. Read client credentials:
+4. Read client credentials:
 
    ```text
    $ vault read identity/oidc/client/my-webapp
@@ -90,47 +90,47 @@ Vault as an OIDC provider.
    The `client_id` and `client_secret` are the client application's credentials. These
    values are typically required when configuring an OIDC relying party.
 
-6. Read OIDC discovery configuration:
-
-    ```text
-    $ curl -s http://127.0.0.1:8200/v1/identity/oidc/provider/default/.well-known/openid-configuration
-    {
-      "issuer": "http://127.0.0.1:8200/v1/identity/oidc/provider/default",
-      "jwks_uri": "http://127.0.0.1:8200/v1/identity/oidc/provider/default/.well-known/keys",
-      "authorization_endpoint": "http://127.0.0.1:8200/ui/vault/identity/oidc/provider/default/authorize",
-      "token_endpoint": "http://127.0.0.1:8200/v1/identity/oidc/provider/default/token",
-      "userinfo_endpoint": "http://127.0.0.1:8200/v1/identity/oidc/provider/default/userinfo",
-      "request_uri_parameter_supported": false,
-      "id_token_signing_alg_values_supported": [
-        "RS256",
-        "RS384",
-        "RS512",
-        "ES256",
-        "ES384",
-        "ES512",
-        "EdDSA"
-      ],
-      "response_types_supported": [
-        "code"
-      ],
-      "scopes_supported": [
-        "openid"
-      ],
-      "subject_types_supported": [
-        "public"
-      ],
-      "grant_types_supported": [
-        "authorization_code"
-      ],
-      "token_endpoint_auth_methods_supported": [
-        "none",
-        "client_secret_basic"
-      ]
-    }
-    ```
-
-    Each Vault OIDC provider publishes [discovery metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).
-    The `issuer` value is typically required when configuring an OIDC relying party.
+5. Read OIDC discovery configuration:
+
+   ```text
+   $ curl -s http://127.0.0.1:8200/v1/identity/oidc/provider/default/.well-known/openid-configuration
+   {
+     "issuer": "http://127.0.0.1:8200/v1/identity/oidc/provider/default",
+     "jwks_uri": "http://127.0.0.1:8200/v1/identity/oidc/provider/default/.well-known/keys",
+     "authorization_endpoint": "http://127.0.0.1:8200/ui/vault/identity/oidc/provider/default/authorize",
+     "token_endpoint": "http://127.0.0.1:8200/v1/identity/oidc/provider/default/token",
+     "userinfo_endpoint": "http://127.0.0.1:8200/v1/identity/oidc/provider/default/userinfo",
+     "request_uri_parameter_supported": false,
+     "id_token_signing_alg_values_supported": [
+       "RS256",
+       "RS384",
+       "RS512",
+       "ES256",
+       "ES384",
+       "ES512",
+       "EdDSA"
+     ],
+     "response_types_supported": [
+       "code"
+     ],
+     "scopes_supported": [
+       "openid"
+     ],
+     "subject_types_supported": [
+       "public"
+     ],
+     "grant_types_supported": [
+       "authorization_code"
+     ],
+     "token_endpoint_auth_methods_supported": [
+       "none",
+       "client_secret_basic"
+     ]
+   }
+   ```
+
+   Each Vault OIDC provider publishes [discovery metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata).
+   The `issuer` value is typically required when configuring an OIDC relying party.
 
 ## Usage
 
@@ -157,10 +157,10 @@ The Vault OIDC provider feature currently supports the following authentication
 
 - [Authorization Code Flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth).
 
-## Learn
+## Tutorial
 
 Refer to the [Vault as an OIDC Identity Provider](https://learn.hashicorp.com/tutorials/vault/oidc-identity-provider)
-guide for an advanced tutorial on configuring HashiCorp [Boundary](https://www.boundaryproject.io/)
+tutorial to learn how to configure a HashiCorp [Boundary](https://www.boundaryproject.io/)
 to leverage Vault as a source of identity using the OIDC protocol.
 
 ## API

@@ -267,18 +267,19 @@ allows for writing keys with arbitrary values.
 
    Perform a patch using the `patch` method:
 
-      ```shell-session
-      $ vault kv patch -method=patch -cas=2 secret/my-secret bar=bbb
-      Key              Value
-      ---              -----
-      created_time     2019-06-19T17:23:49.199802Z
-      custom_metadata  <nil>
-      deletion_time    n/a
-      destroyed        false
-      version          3
-      ```
+   ```shell-session
+   $ vault kv patch -method=patch -cas=2 secret/my-secret bar=bbb
+   Key              Value
+   ---              -----
+   created_time     2019-06-19T17:23:49.199802Z
+   custom_metadata  <nil>
+   deletion_time    n/a
+   destroyed        false
+   version          3
+   ```
 
    Perform a patch using the read-then-write method:
+
    ```shell-session
    $ vault kv patch -method=rw secret/my-secret bar=bbb
    Key              Value
@@ -479,9 +480,9 @@ See the commands below for more information:
    A secret's key metadata can contain custom metadata used to describe the secret.
    The data will be stored as string-to-string key-value pairs.
    The `-custom-metadata` flag can be repeated to add multiple key-value pairs.
- 
-   The `vault kv metadata put` command can be used to fully overwrite the value of  `custom_metadata`:
- 
+
+   The `vault kv metadata put` command can be used to fully overwrite the value of `custom_metadata`:
+
    ```shell-session
    $ vault kv metadata put -custom-metadata=foo=abc -custom-metadata=bar=123 secret/ my-secret
    Success! Data written to: secret/metadata/my-secret
@@ -495,17 +496,17 @@ See the commands below for more information:
    deletion_time    n/a
    destroyed        false
    version          2
- 
+
    ====== Data ======
    Key         Value
    ---         -----
    foo         aa
    bar         bb
    ```
- 
-   The `vault kv metadata patch` command can be used to partially overwrite the  valueof `custom_metadata`.
+
+   The `vault kv metadata patch` command can be used to partially overwrite the valueof `custom_metadata`.
    The following invocation will update `custom_metadata` sub-field `foo` but leave `bar` untouched:
- 
+
    ```shell-session
    $ vault kv metadata patch -custom-metadata=foo=def secret/my-secret
    Success! Data written to: secret/metadata/my-secret
@@ -519,7 +520,7 @@ See the commands below for more information:
    deletion_time    n/a
    destroyed        false
    version          2
- 
+
    ====== Data ======
    Key         Value
    ---         -----
@@ -534,11 +535,11 @@ See the commands below for more information:
    Success! Data deleted (if it existed) at: secret/metadata/my-secret
    ```
 
-## Learn
+## Tutorial
 
 Refer to the [Versioned Key/Value Secrets
 Engine](https://learn.hashicorp.com/vault/secrets-management/sm-versioned-kv)
-guide for a step-by-step tutorial.
+tutorial to learn how to use KV secrets engine v2 to version or roll back secrets.
 
 ## API
 

@@ -339,9 +339,9 @@ transformations:
 
 - builtin/internal
 
-## Learn
+## Tutorial
 
-Refer to the [Transform Secrets Engine](https://learn.hashicorp.com/vault/adp/transform) guide for a step-by-step tutorial.
+Refer to the [Transform Secrets Engine](https://learn.hashicorp.com/vault/adp/transform) tutorial to learn how to use the Transform secrets engine to handle secure data transmission and tokenization against provided secrets.
 
 ## API