Markdown linting and formatting

docs/understanding_bigbang/kube-apiserver_webhooks_diagram.md

@@ -6,10 +6,10 @@
 * Kubernetes Security Best Practice (per [kube-bench](https://github.com/aquasecurity/kube-bench)) for requests to the kube-apiserver is that requests should go through the following flow of controls:
   1. mTLS Authentication via x509 certs:
      * This is baked into Kubernetes
-  2. RBAC Authorization of users and Node Authentication for worker nodes
+  1. RBAC Authorization of users and Node Authentication for worker nodes
      * `--authorization-mode=Node,RBAC` flag on kube-apiserver ensures this is set.
      * Deployed applications contain YAML manifests with rbac rules to minimize the rights of the application's service account.
-  3. Admission Controllers: These take effect after Authn and Authz have occurred and allow the functionality of the api-server to be extended to enable additional security controls and advanced features.
+  1. Admission Controllers: These take effect after Authn and Authz have occurred and allow the functionality of the api-server to be extended to enable additional security controls and advanced features.
      * There are apiserver plugins baked into Kubernetes that just need to be turned on like `--enable-admission-plugins=NodeRestriction` per kube-bench.
      * There's also webhooks that allow extending the apiserver with custom logic, this will be overviewed in the diagram below.
 
@@ -27,7 +27,7 @@
 
 #### 2. Mutating Admission Controllers
 
-* This improves user experience for developers. If a namespace is labeled `istio-injection=enabled`, then a developer can submit a YAML manifest where the pod only needs to reference 1 container image/the application. After the request is authenticated and authorized against the kube-apiserver, it's admission controller will see a mutating admission webhook exists and the manifest will be sent to the istiod pod in the istio-system namespace to mutate the manifest and inject an istio init container and istio envoy proxy sidecar container into the YAML manifest. This allows the developer's pod to be integrated into the service mesh with minimal configuration / effort on their part/no adjustments to their YAMLs were needed.
+* This improves user experience for developers. If a namespace is labeled `istio-injection=enabled`, then a developer can submit a YAML manifest where the pod only needs to reference 1 container image/the application. After the request is authenticated and authorized against the kube-apiserver, it's admission controller will see a mutating admission webhook exists and the manifest will be sent to the `istiod` pod in the `istio-system` namespace to mutate the manifest and inject an Istio init container and Istio envoy proxy sidecar container into the YAML manifest. This allows the developer's pod to be integrated into the service mesh with minimal configuration / effort on their part/no adjustments to their YAMLs were needed.
 * Note: It's possible to use Istio CNI Plugin to eliminate the need for Istio Init Containers.
 
 #### 3. Validating Admission Controllers