fix linting/whitespace in configure-gmsa.md

content/en/docs/tasks/configure-pod-container/configure-gmsa.md

@@ -12,18 +12,17 @@ This page shows how to configure [Group Managed Service Accounts](https://docs.m
 
 In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as Custom Resources. Windows Pods, as well as individual containers within a Pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, the Docker runtime supports GMSA for Windows workloads.
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
 You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster:
 
 ### Install the GMSACredentialSpec CRD
+
 A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml.
 Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`
 
 ### Install webhooks to validate GMSA users
+
 Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the Pod or container level:
 
 1. A mutating webhook that expands references to GMSAs (by name from a Pod specification) into the full credential spec in JSON form within the Pod spec.
@@ -44,14 +43,14 @@ A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission
 
 The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters)
 
-
-
 <!-- steps -->
 
 ## Configure GMSAs and Windows nodes in Active Directory
+
 Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described in the [Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet)
 
 ## Create GMSA credential spec resources
+
 With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1).
 
 Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it:
@@ -92,6 +91,7 @@ credspec:
 The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml` and applied to the cluster using: `kubectl apply -f gmsa-Webapp1-credspec.yml`
 
 ## Configure cluster role to enable RBAC on specific GMSA credential specs
+
 A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml`
 
 ```yaml
@@ -108,6 +108,7 @@ rules:
 ```
 
 ## Assign role to service accounts to use specific GMSA credspecs
+
 A service account (that Pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to use the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above.
 
 ```yaml
@@ -127,6 +128,7 @@ roleRef:
 ```
 
 ## Configure GMSA credential spec reference in Pod spec
+
 The Pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` is used to specify references to desired GMSA credential spec custom resources in Pod specs. This configures all containers in the Pod spec to use the specified GMSA. A sample Pod spec with the annotation populated to refer to `gmsa-WebApp1`:
 
 ```yaml
@@ -206,9 +208,10 @@ There is also a known issue with containerd that occurs when trying to connect t
 ```PowerShell
 ping adserver.ad.local
 ```
+
 and correctly resolves the hostname to an IPv4 address. The output is similar to:
 
-```
+```PowerShell
 Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data:
 Reply from 192.168.111.18: bytes=32 time=6ms TTL=124
 Reply from 192.168.111.18: bytes=32 time=5ms TTL=124
@@ -224,7 +227,7 @@ cd \\adserver.ad.local\test
 
 you see an error that implies the target share doesn't exist:
 
-```
+```PowerShell
 cd : Cannot find path '\\adserver.ad.local\test' because it does not exist.
 At line:1 char:1
 + cd \\adserver.ad.local\test
@@ -241,7 +244,7 @@ cd \\192.168.111.18\test
 
 After you change into a directory within the share, you see a prompt similar to:
 
-```
+```PowerShell
 Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test>
 ```
 
@@ -258,8 +261,10 @@ In the example below the Pod did not get the credspec correctly:
 ```PowerShell
 kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
 ```
+
 `nltest.exe /parentdomain` results in the following error:
-```
+
+```PowerShell
 Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
 ```
 
@@ -278,7 +283,8 @@ nltest.exe /query
 ```
 
 Results in the following output:
-```
+
+```PowerShell
 I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
 ```
 
@@ -289,7 +295,8 @@ nltest /sc_reset:domain.example
 ```
 
 If the command is successful you will see and output similar to this:
-```
+
+```PowerShell
 Flags: 30 HAS_IP  HAS_TIMESERV
 Trusted DC Name \\dc10.domain.example
 Trusted DC Connection Status Status = 0 0x0 NERR_Success