Fix formatting for webhook-certs Consul tutorial

website/content/docs/k8s/deployment-configurations/vault/data-integration/webhook-certs.mdx

@@ -14,9 +14,9 @@ In a Consul Helm chart configuration that does not use Vault, webhook-cert-manag
 
 When Vault is configured as the controller and connect inject Webhook Certificate Provider on Kubernetes: 
   - `webhook-cert-manager` is no longer deployed to the cluster.
-  - controller and connect inject each get their webhook certificates from its own Vault PKI mount via the injected Vault Agent.
-  - controller and connect inject each need to be configured with its own Vault Role that has necessary permissions to receive certificates from its respective PKI mount.
-  - controller and connect inject each locally update its own `mutatingwebhookconfiguration` so that Kubernetes can relay events.
+  - Controller and connect inject each get their webhook certificates from its own Vault PKI mount via the injected Vault Agent.
+  - Controller and connect inject each need to be configured with its own Vault Role that has necessary permissions to receive certificates from its respective PKI mount.
+  - Controller and connect inject each locally update its own `mutatingwebhookconfiguration` so that Kubernetes can relay events.
   - Vault manages certificate rotation and rotates certificates to each webhook.
 
 To use Vault as the controller and connect inject Webhook Certificate Provider, we will need to modify the steps outlined in the [Data Integration](/docs/k8s/deployment-configurations/vault/data-integration) section:
@@ -31,8 +31,8 @@ These following steps will be repeated for each datacenter:
 Complete the following prerequisites prior to implementing the integration described in this topic: 
 1. Verify that you have completed the steps described in [Systems Integration](/docs/k8s/deployment-configurations/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/deployment-configurations/vault).
 1. You should be familiar with the [Data Integration Overview](/docs/k8s/deployment-configurations/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/deployment-configurations/vault).
-1. Configure [Vault as the Server TLS Certificate Provider on Kubernetes](/docs/k8s/deployment-configurations/vault/data-integration/server-tls) 
-1. Configure [Vault as the Service Mesh Certificate Provider on Kubernetes](/docs/k8s/deployment-configurations/vault/data-integration/connect-ca)
+1. Configure [Vault as the Server TLS Certificate Provider on Kubernetes](/docs/k8s/deployment-configurations/vault/data-integration/server-tls).
+1. Configure [Vault as the Service Mesh Certificate Provider on Kubernetes](/docs/k8s/deployment-configurations/vault/data-integration/connect-ca).
 
 ## Bootstrapping the PKI Engines
 Issue the following commands to enable and configure the PKI Secrets Engine to serve TLS certificates for the controller and connect inject webhooks:
@@ -71,8 +71,7 @@ Issue the following commands to enable and configure the PKI Secrets Engine to s
           ttl=87600h
   ```
 ## Create Vault Policies
-1. Create a policy that allows `["create", "update"]` access to the
-[certificate issuing URL](https://www.vaultproject.io/api-docs/secret/pki) so Consul controller and connect inject can fetch a new certificate/key pair and provide it to the Kubernetes `mutatingwebhookconfiguration`.
+1. Create a policy that allows `["create", "update"]` access to the [certificate issuing URL](https://www.vaultproject.io/api-docs/secret/pki) so Consul controller and connect inject can fetch a new certificate/key pair and provide it to the Kubernetes `mutatingwebhookconfiguration`.
 
     The path to the secret referenced in the `path` resource is the same value that you will configure in the  `global.secretsBackend.vault.controller.tlsCert.secretName` and `global.secretsBackend.vault.connectInject.tlsCert.secretName` Helm configuration (refer to [Update Consul on Kubernetes Helm chart](#update-consul-on-kubernetes-helm-chart)).
 
@@ -92,8 +91,7 @@ Issue the following commands to enable and configure the PKI Secrets Engine to s
     EOF
     ```
 
-1. Create a policy that allows `["read"]` access to the [CA URL](https://www.vaultproject.io/api-docs/secret/pki#read-certificate),
-this is required for the Consul components to communicate with the Consul servers in order to fetch their auto-encryption certificates.
+1. Create a policy that allows `["read"]` access to the [CA URL](https://www.vaultproject.io/api-docs/secret/pki#read-certificate), this is required for the Consul components to communicate with the Consul servers in order to fetch their auto-encryption certificates.
 
     The path to the secret referenced in the `path` resource is the same values that you will configure in the  `global.secretsBackend.vault.controller.caCert.secretName` and `global.secretsBackend.vault.connectInject.caCert.secretName` Helm configuration (refer to [Update Consul on Kubernetes Helm chart](#update-consul-on-kubernetes-helm-chart)).
 
@@ -112,6 +110,7 @@ this is required for the Consul components to communicate with the Consul server
     }
     EOF
     ```
+
 1. Configure allowed domains for PKI certificates.
 
     ```shell-session
@@ -153,10 +152,10 @@ this is required for the Consul components to communicate with the Consul server
 
 1. Finally, Kubernetes auth roles need to be created for controller and connect inject webhooks.
 
-
     The path to the secret referenced in the `path` resource is the same values that you will configure in the  `global.secretsBackend.vault.controllerRole` and `global.secretsBackend.vault.connectInjectRole` Helm configuration (refer to [Update Consul on Kubernetes Helm chart](#update-consul-on-kubernetes-helm-chart)).
 
     Role for Consul controller webhooks:
+
     ```shell-session
     $ vault write auth/kubernetes/role/controller-role \
         bound_service_account_names=<Consul controller service account> \