[Guide] Tokens & Leases guide **Correction** (#5375)

* Added Azure Key Vault

* Corrected the info about orphan token creation

website/source/guides/identity/lease.html.md

@@ -467,7 +467,7 @@ the attempt to read the secret from the cubbyhole failed.
 
 Set the `num_uses` property in the request payload.
 
-```shell
+```plaintext
 $ curl --header "X-Vault-Token: ..." --request POST  \
        --data '{ "policies": ["default"], "num_uses":2 }' \
        http://127.0.0.1:8200/v1/auth/token/create | jq
@@ -590,17 +590,20 @@ token renewal period. This value can be an integer value in seconds (e.g.
 **Example:**
 
 ```shell
-$ curl --header "X-Vault-Token: ..." --request POST \
-       --data @payload.json \
-       http://127.0.0.1:8200/v1/auth/token/roles/zabbix
-
-$ cat payload.json
+# API request payload
+$ tee payload.json <<EOF
 {
 	"allowed_policies": [
 		"default"
 	],
 	"period": "24h"
 }
+EOF
+
+# Create a token role called 'zabbix'
+$ curl --header "X-Vault-Token: ..." --request POST \
+       --data @payload.json \
+       http://127.0.0.1:8200/v1/auth/token/roles/zabbix
 ```
 
 This creates a token role named `zabbix` with `default` policies attached.
@@ -651,45 +654,62 @@ $ vault write auth/approle/role/jenkins policies="jenkins" period="72h"
 
 Or
 
-```plaintext
-$ curl --header "X-Vault-Token:..." --request POST \
-       --data @payload.json \
-       http://127.0.0.1:8200/v1/auth/approle/role/jenkins
-
-$ cat payload.json
+```shell
+# Sample request payload
+$ tee payload.json <<EOF
 {
   "allowed_policies": [
 		"jenkins"
 	],
   "period": "72h"  
 }
+EOF
+
+# Create a role named 'jenkins'
+$ curl --header "X-Vault-Token:..." --request POST \
+       --data @payload.json \
+       http://127.0.0.1:8200/v1/auth/approle/role/jenkins
 ```
 
 
 
 ### <a name="step5"></a>Step 5: Orphan tokens
 
-**Root** or **sudo users** have the ability to generate **orphan** tokens. Orphan tokens
-are **not** children of their parent; therefore, orphan tokens do not expire when their
-parent does.
-
+Orphan tokens are **not** children of their parent; therefore, orphan tokens do
+not expire when their parent does.
 
 **NOTE:** Orphan tokens still expire when their own max TTL is reached.
 
 #### CLI command
 
+The following CLI command requires **root** token or **sudo** capability on the
+`auth/token/create` path.
+
 ```shell
 $ vault token create -orphan
 ```
 
 #### API call using cURL
 
+To create an orphan token, use the **`auth/token/create-orphan`** endpoint:
+
 ```shell
 $ curl --header "X-Vault-Token:..." --request POST \
-       --data '{ "no_parent": true }' \
        http://127.0.0.1:8200/v1/auth/token/create-orphan | jq
 ```
 
+Also, you can create an orphan token using the **`auth/token/create`** endpoint with
+`no-parent` parameter set to true.
+
+```shell
+$ curl --header "X-Vault-Token:..." --request POST \
+       --data '{ "no_parent": true }' \
+       http://127.0.0.1:8200/v1/auth/token/create | jq
+```
+
+!> **NOTE:** The **`auth/token/create`** endpoint requires **root** token or
+**sudo** capability to create an orphan token while
+**`auth/token/create-orphan`** endpoint does not.
 
 ### <a name="step6"></a>Step 6: Revoke tokens and leases
 
@@ -747,10 +767,9 @@ $ curl --header "X-Vault-Token:..." --request POST \
        http://127.0.0.1:8200/v1/sys/leases/revoke-prefix/auth/token/create
 
 # Revoke all tokens by accessor
-$ curl \
-    --header "X-Vault-Token: ..." --request POST \
-    --data '{ "accessor": "2b2b5b83-7f22-fecd-03f0-4e25bf64da11" }' \
-    http://127.0.0.1:8200/v1/auth/token/revoke-accessor
+$ curl --header "X-Vault-Token: ..." --request POST \
+       --data '{ "accessor": "2b2b5b83-7f22-fecd-03f0-4e25bf64da11" }' \
+       http://127.0.0.1:8200/v1/auth/token/revoke-accessor
 ```
 
 

website/source/guides/operations/autounseal-aws-kms.html.md

@@ -50,18 +50,19 @@ many different key holders with many different keys.
 
 ## Solution
 
-Vault Enterprise supports opt-in automatic unsealing via cloud technologies such
-Amazon KMS or Google Cloud KMS. This feature enables operators to delegate the
-unsealing process to trusted cloud providers to ease operations in the event of
-partial failure and to aid in the creation of new or ephemeral clusters.
+Vault Enterprise supports opt-in automatic unsealing via cloud technologies:
+Amazon KMS, Azure Key Vault or GCP Cloud KMS. This feature enables operators to
+delegate the unsealing process to trusted cloud providers to ease operations in
+the event of partial failure and to aid in the creation of new or ephemeral
+clusters.
 
 ![Unseal with AWS KMS](/assets/images/vault-autounseal-2.png)
 
 ## Prerequisites
 
 This guide assumes the following:   
 
-- Access to **Vault Enterprise 0.9.0 or later** which supports AWS KMS as an unseal mechanism
+- Access to **Vault Enterprise 0.9.0 or later** 
 - A URL to download Vault Enterprise from (an Amazon S3 bucket will suffice)
 - AWS account for provisioning cloud resources
 - [Terraform installed](https://www.terraform.io/intro/getting-started/install.html)
@@ -124,7 +125,7 @@ $ export AWS_SECRET_ACCESS_KEY = "<YOUR_AWS_SECRET_ACCESS_KEY>"
 ```
 
 Create a file named **`terraform.tfvars`** and specify your Vault Enterprise
-binary download URL. 
+binary download URL.
 
 **Example:**