Add manual fixes for md linter

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>

Author: antgamdia

site/README.md

@@ -10,7 +10,7 @@ This site uses [Hugo](https://github.com/gohugoio/hugo) for rendering. It is rec
 
 ### Local Hugo Rendering
 
-Hugo is available for many platforms. It can be installed using:
+Hugo is available on many platforms. It can be installed using:
 
 - Linux: Most native package managers
 - macOS: `brew install hugo`
@@ -25,14 +25,14 @@ hugo server --disableFastRender
 
 Access the site at [http://localhost:1313](http://localhost:1313). Press `Ctrl-C` when done viewing.
 
-The [site/content/docs/latest](./content/docs/latest) directory holds the project documentation whereas [site/themes/template/static../img/docs](./themes/template/static../img/docs) contains the images used in the documentation. Note they have to be under that folder to be properly served.
+The [site/content/docs/latest](./content/docs/latest) directory holds the project documentation whereas the [site/themes/template/static../img/docs](./themes/template/static../img/docs) directory contains the images used in the documentation. Note they have to be under that folder to be properly served.
 
 #### Run Hugo with Docker
 
 To ease the local development and prevent you from polluting your local environment with tools that rarely use,
 it is possible to run the `Hugo` server via `Docker` through a `Make` target.
 
-```
+```bash
 make site-server
 ```
 
@@ -60,9 +60,9 @@ hugo
 npx check-html-links ./public/
 ```
 
-## Check formatting
+## Check format
 
-Also, another tool for checking the markdown syntax are [markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli) and [prettier](https://github.com/prettier/prettier). To use them, run:
+Also, another tool for checking the markdown syntax is [markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli) and [prettier](https://github.com/prettier/prettier). To use them, run:
 
 ```bash
 cd site

site/content/docs/latest/howto/OIDC/OAuth2OIDC-keycloak.md

@@ -5,9 +5,9 @@ It covers the installation and documentation for Kubeapps interacting with two K
 
 The installation used the [bitnami chart for Keycloak](https://github.com/bitnami/charts/tree/main/bitnami/keycloak) (version 12.0.4/2.4.8) and [bitnami chart for Kubeapps](https://github.com/bitnami/charts/tree/main/bitnami/kubeapps) (version 7.0.0/2.3.2)
 
-# Keycloak Installation
+## Keycloak Installation
 
-## SSL
+### SSL
 
 In order to support OIDC or OAuth, most servers and proxies require HTTPS. By default, the certificate created by the helm chart / Keycloak server is both invalid (error with `notBefore` attribute) and also based on a deprecated certificate version making it incompatible to use (i.e. is it based on Common Name instead of SAN and is rejected).
 
@@ -82,7 +82,7 @@ Note that the names of the keystore and truststore matters and must be exactly a
 kubectl create secret generic keycloak-tls --from-file=./keycloak-0.keystore.jks  --from-file=./keycloak.truststore.jks
 ```
 
-## Helm Install
+### Keycloak Helm Install
 
 To provide a default install, not many values must be provided in the values file - the values are mostly default passwords and the name of the secret created in Step 3 above.
 
@@ -131,13 +131,13 @@ Then just deploy Keycloak either using Kubeapps UI or helm cli as follows:
 helm install keycloak bitnami/keycloak --values my-values.yaml
 ```
 
-# Keycloak Configuration
+## Keycloak Configuration
 
 Follow the [Keycloak documentation](https://www.keycloak.org/documentation) to create and configure a new Realm to work with.
 
 This section will focus on a few aspects to configure for the SSO scenario to work.
 
-## Groups Claim
+### Groups Claim
 
 By default, there is no "groups" scope/claim. We will create a global client scope for groups.
 
@@ -161,7 +161,7 @@ Once the client scope is created, you should be redirected to a page with severa
 
 Note: if you navigate to "Client Scopes" and then select the tab "Default Client Scopes" you should be able to see the newly created "groups" scope in the "available client scopes" lists.
 
-## Clients
+### Clients
 
 In probably a very simplified view, Clients represent the application to be protected and accessed via SSO and OIDC. Here, the environment consisted of the Kubeapps web app and two Kubernetes clusters. So we need to create three clients.
 
@@ -201,7 +201,7 @@ Once created, configure the authentication as follows:
 - Configure the "Access Type" to be "confidential". This will add a new "Credentials" tab from which you can get the client secret
 - Ensure "Standard Flow Enabled" is enabled, this is required for the login screen.
 - "Direct Access Grants Enabled" can be disabled.
-- In the "Valid Redirect URIs" field, enter "http://localhost:8000/\*" as a placeholder. We will need to revisit this field once we know the public hostname of kubeapps
+- In the "Valid Redirect URIs" field, enter `http://localhost:8000/\*` as a placeholder. We will need to revisit this field once we know the public hostname of kubeapps
 - Save
 
 As for the cluster clients, we need to configure the client scopes:
@@ -252,17 +252,17 @@ In this option, the claim is statically defined via a mapper similar to the one
 
 The two client ids will be injected in the audience claim automatically.
 
-## Users
+### Users in Keycloak
 
 Users are intuitive to create. But they must be configured with a "verified" email address.
 
 The oauth proxy used in kubeapps requires email as the username. Furthermore, if the email is not marked as verified, JWT validation will fail and authentication will fail.
 
 In order to test multiple users with different levels of authorization, it is useful to create them with multiple dummy email addresses. This can be done by ensuring that when the user is created, the field "email verified" is ON (skipping an actual email verification workflow).
 
-# Kubeapps Installation
+## Kubeapps Installation
 
-## Helm Install
+### Kubeapps Helm Install
 
 Few changes are required to values.yaml for the helm installation:
 
@@ -314,13 +314,13 @@ authProxy:
     - --oidc-issuer-url=https://<xxx>.us-east-2.elb.amazonaws.com/auth/realms/AWS
 ```
 
-## Configuration
+### Configuration
 
 Once Kubeapps is installed and the load balancer is ready, we need to go back to Keycloak to configure the callback URL:
 
 - Navigate to the `kubeapps` Client
 - In the "Valid Redirect URIs" enter the callback URL for Kubeapps. It will be of the form "http://`<hostname>`/oauth2/callback" (where `<hostname>` is the load balancer hostname)
 
-## Users
+### Users
 
 Users created in Keycloak will be authenticated but they will not have access to the cluster resources by default. Make sure to create role bindings to users and/or groups in both clusters.

site/content/docs/latest/howto/OIDC/OAuth2OIDC-oauth2-proxy.md

@@ -13,7 +13,7 @@ Kubeapps chart allows you to automatically deploy the proxy for you as a sidecar
  --set authProxy.extraFlags="{<other flags>,--proxy-prefix=/subpath/oauth2}"\
 ```
 
-**Example 1: Using the OIDC provider**
+### Example 1: Using the OIDC provider
 
 This example uses `oauth2-proxy`'s generic OIDC provider with Google, but is applicable to any OIDC provider such as Keycloak, Dex, Okta or Azure Active Directory etc. Note that the issuer url is passed as an additional flag here, together with an option to enable the cookie being set over an insecure connection for local development only:
 
@@ -28,7 +28,7 @@ helm install kubeapps bitnami/kubeapps \
   --set authProxy.extraFlags="{--cookie-secure=false,--oidc-issuer-url=https://accounts.google.com}" \
 ```
 
-**Example 2: Using a custom oauth2-proxy provider**
+### Example 2: Using a custom oauth2-proxy provider
 
 Some of the specific providers that come with `oauth2-proxy` are using OpenIDConnect to obtain the required IDToken and can be used instead of the generic oidc provider. Currently this includes only the GitLab, Google and LoginGov providers (see [OAuth2_Proxy's provider configuration](https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/overview) for the full list of OAuth2 providers). The user authentication flow is the same as above, with some small UI differences, such as the default login button is customized to the provider (rather than "Login with OpenID Connect"), or improved presentation when accepting the requested scopes (as is the case with Google, but only visible if you request extra scopes).
 
@@ -45,7 +45,7 @@ helm install kubeapps bitnami/kubeapps \
   --set authProxy.extraFlags="{--cookie-secure=false}"
 ```
 
-**Example 3: Authentication for Kubeapps on a GKE cluster**
+### Example 3: Authentication for Kubeapps on a GKE cluster
 
 Google Kubernetes Engine does not allow an OIDC IDToken to be used to authenticate requests to the managed API server, instead requiring the standard OAuth2 access token.
 For this reason, when deploying Kubeapps on GKE we need to ensure that

site/content/docs/latest/howto/OIDC/using-an-OIDC-provider-with-pinniped.md

@@ -88,7 +88,7 @@ But, what if this `kube-controller-manager` is not a normal pod on a schedulable
 
 In managed clusters, such as AKS, Pinniped cannot read the cluster's certificate and key. In this case, Pinniped will have a fallback mechanism: the [impersonation proxy](https://pinniped.dev/docs/background/architecture/). It simply creates a LoadBalancer service that proxies the actual Kubernetes API. For this reason, when using Kubeapps in managed clusters using Pinniped, you'll need to use the Impersonation Proxy URL (and CA certificate) instead of the usual k8s API server URL.
 
-Assuming you have successfully [installed Pinniped](#installing-pinniped) and configured the [JWTAuthenticator](#configure-pinniped-to-trust-your-oidc-identity-provider), you have to retrieve the Impersonation Proxy URL and CA by inspecting the `CredentialIssuer` object. To do so, you can run the following commands:
+Assuming you have successfully [installed Pinniped](#installing-pinniped-concierge) and configured the [JWTAuthenticator](#configure-pinniped-concierge-to-trust-your-oidc-identity-provider), you have to retrieve the Impersonation Proxy URL and CA by inspecting the `CredentialIssuer` object. To do so, you can run the following commands:
 
 Retrieving the Impersonation Proxy URL:
 

site/content/docs/latest/howto/private-app-repository.md

@@ -40,9 +40,9 @@ To install a Harbor registry in the cluster:
 
 2. Update the following parameter in the deployment values:
 
-- `service.tls.enabled`: Set to `false` to deactivate the TLS settings. Alternatively, you can provide a valid TSL certificate (check [Bitnami Harbor Helm chart documentation](https://github.com/bitnami/charts/tree/main/bitnami/harbor#parameters) for more information).
+   - `service.tls.enabled`: Set to `false` to deactivate the TLS settings. Alternatively, you can provide a valid TSL certificate (check [Bitnami Harbor Helm chart documentation](https://github.com/bitnami/charts/tree/main/bitnami/harbor#parameters) for more information).
 
-  ![Harbor Deploy Form](../img/harbor-deploy-form.png)
+   ![Harbor Deploy Form](../img/harbor-deploy-form.png)
 
 3. Deploy the chart and wait for it to be ready.
 
@@ -56,40 +56,40 @@ To install a Harbor registry in the cluster:
 
 1. First, create a Helm chart package:
 
-```console
-$ helm package /path/to/my/chart
-Successfully packaged chart and saved it to: /path/to/my/chart/my-chart-1.0.0.tgz
-```
+   ```console
+   $ helm package /path/to/my/chart
+   Successfully packaged chart and saved it to: /path/to/my/chart/my-chart-1.0.0.tgz
+   ```
 
 2. Second, login into Harbor admin portal following the instructions in the chart notes:
 
-```console
-1. Get the Harbor URL:
+   ```console
+   1. Get the Harbor URL:
 
-  echo "Harbor URL: https://127.0.0.1:8080/"
-  kubectl port-forward --namespace default svc/my-harbor 8080:80 &
+     echo "Harbor URL: https://127.0.0.1:8080/"
+     kubectl port-forward --namespace default svc/my-harbor 8080:80 &
 
-2. Login with the following credentials to see your Harbor application
+   2. Login with the following credentials to see your Harbor application
 
-  echo Username: "admin"
-  echo Password: $(kubectl get secret --namespace default my-harbor-core-envvars -o jsonpath="{.data.HARBOR_ADMIN_PASSWORD}" | base64 --decode)
-```
+     echo Username: "admin"
+     echo Password: $(kubectl get secret --namespace default my-harbor-core-envvars -o jsonpath="{.data.HARBOR_ADMIN_PASSWORD}" | base64 --decode)
+   ```
 
 3. Create a new Project named **my-helm-repo**. Each project will serve as a Package repository (in this example, a Helm chart repository).
 
-![Harbor new project](../img/harbor-new-project.png)
+   ![Harbor new project](../img/harbor-new-project.png)
 
-- It is possible to configure Harbor to use HTTP basic authentication if you set the `Access Level` of the project to `non public`. This enforces authentication to access the packages in the repository from an external client (Helm CLI, Kubeapps or any other).
+   - It is possible to configure Harbor to use HTTP basic authentication if you set the `Access Level` of the project to `non public`. This enforces authentication to access the packages in the repository from an external client (Helm CLI, Kubeapps or any other).
 
 4. Click the project name to view the project details page, then click **Helm Charts** tab to list all helm charts.
 
-![Harbor list charts](../img/harbor-list-charts.png)
+   ![Harbor list charts](../img/harbor-list-charts.png)
 
 5. Click **Upload** button to upload the Helm chart you previously created. You can also use the `helm` command to upload the chart too.
 
-![Harbor upload chart](../img/harbor-upload-chart.png)
+   ![Harbor upload chart](../img/harbor-upload-chart.png)
 
-> Please refer to ['Manage Helm Charts in Harbor'](https://goharbor.io/docs/2.6.0/working-with-projects/working-with-images/managing-helm-charts) for more details.
+   > Please refer to ['Manage Helm Charts in Harbor'](https://goharbor.io/docs/2.6.0/working-with-projects/working-with-images/managing-helm-charts) for more details.
 
 ### Harbor: Configure the repository in Kubeapps
 
@@ -156,16 +156,16 @@ To use ChartMuseum with Kubeapps:
 
 1. First configure a public repo in Kubeapps to deploy its Helm chart from the `stable` repository:
 
-![ChartMuseum chart](../img/chartmuseum-chart.png)
+   ![ChartMuseum chart](../img/chartmuseum-chart.png)
 
 2. Deploy last version by using Kubeapps. Update the following parameters in the deployment values:
 
-- `env.open.DISABLE_API`: Set to `false` to use the ChartMuseum API to push new charts.
-- `persistence.enabled`: Set to `true` to enable persistence for the stored charts.
+   - `env.open.DISABLE_API`: Set to `false` to use the ChartMuseum API to push new charts.
+   - `persistence.enabled`: Set to `true` to enable persistence for the stored charts.
 
-  > Note that this will create a [Kubernetes Persistent Volume Claim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#lifecycle-of-a-volume-and-claim) so depending on your Kubernetes provider you may need to manually allocate the required Persistent Volume to satisfy the claim. Some Kubernetes providers will automatically create PVs for you so setting this value to `true` will be enough.
+   > Note that this will create a [Kubernetes Persistent Volume Claim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#lifecycle-of-a-volume-and-claim) so depending on your Kubernetes provider you may need to manually allocate the required Persistent Volume to satisfy the claim. Some Kubernetes providers will automatically create PVs for you so setting this value to `true` will be enough.
 
-![ChartMuseum Deploy Form](../img/chartmuseum-deploy-form.png)
+   ![ChartMuseum Deploy Form](../img/chartmuseum-deploy-form.png)
 
 ### ChartMuseum: Upload a chart
 
@@ -175,21 +175,21 @@ Once ChartMuseum is deployed you will be able to upload a chart.
 
 1. In one terminal open a port-forward tunnel to the application:
 
-```console
-$ export POD_NAME=$(kubectl get pods --namespace default -l "app=chartmuseum" -l "release=my-chartrepo" -o jsonpath="{.items[0].metadata.name}")
-$ kubectl port-forward $POD_NAME 8080:8080 --namespace default
-Forwarding from 127.0.0.1:8080 -> 8080
-Forwarding from [::1]:8080 -> 8080
-```
+   ```console
+   $ export POD_NAME=$(kubectl get pods --namespace default -l "app=chartmuseum" -l "release=my-chartrepo" -o jsonpath="{.items[0].metadata.name}")
+   $ kubectl port-forward $POD_NAME 8080:8080 --namespace default
+   Forwarding from 127.0.0.1:8080 -> 8080
+   Forwarding from [::1]:8080 -> 8080
+   ```
 
 2. In a different terminal you can push your chart:
 
-```console
-$ helm package /path/to/my/chart
-Successfully packaged chart and saved it to: /path/to/my/chart/my-chart-1.0.0.tgz
-curl --data-binary "@my-chart-1.0.0.tgz" http://localhost:8080/api/charts
-{"saved":true}
-```
+   ```console
+   $ helm package /path/to/my/chart
+   Successfully packaged chart and saved it to: /path/to/my/chart/my-chart-1.0.0.tgz
+   curl --data-binary "@my-chart-1.0.0.tgz" http://localhost:8080/api/charts
+   {"saved":true}
+   ```
 
 ### ChartMuseum: Authentication/Authorization
 

site/content/docs/latest/reference/developer/README.md

@@ -1,18 +1,18 @@
 # The Kubeapps Components
 
-### Kubeapps dashboard
+## Kubeapps dashboard
 
 The dashboard is the main UI component of the Kubeapps project. Written in JavaScript, the dashboard uses the React JavaScript library for the frontend.
 
 Please refer to the [Kubeapps Dashboard Developer Guide](./dashboard.md) for the developer setup.
 
-### Kubeapps APIs service
+## Kubeapps APIs service
 
 The Kubeapps APIs service is the main backend component of the Kubeapps project. Written in Go, the APIs service provides a pluggable gRPC service that is used to support different Kubernetes packaging formats.
 
 See the [Kubeapps APIs Service Developer Guide](kubeapps-apis.md) for more information.
 
-### asset-syncer
+## asset-syncer
 
 The `asset-syncer` component is a tool that scans a Helm chart repository and populates chart metadata in the database. This metadata is then served by the `kubeapps-apis` component.
 

site/content/docs/latest/reference/developer/apprepository-controller.md

@@ -29,8 +29,7 @@ Based off the [Kubernetes Sample Controller](https://github.com/kubernetes/sampl
 - [Kubernetes cluster (v1.8+)](https://kubernetes.io/docs/setup/)
 - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
 - [Telepresence](https://telepresence.io)
-
-_Telepresence is not a hard requirement, but is recommended for a better developer experience_
+  - _Telepresence is not a hard requirement, but is recommended for a better developer experience_
 
 ## Download the kubeapps source code
 

site/content/docs/latest/reference/developer/asset-syncer.md

@@ -11,6 +11,7 @@ The `asset-syncer` component is a tool that scans a Helm chart repository and po
 - [Kubernetes cluster (v1.8+)](https://kubernetes.io/docs/setup/). [Minikube](https://github.com/kubernetes/minikube) is recommended.
 - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
 - [Telepresence](https://telepresence.io)
+  - _Telepresence is not a hard requirement, but is recommended for a better developer experience_
 
 ## Download the Kubeapps source code
 

site/content/docs/latest/reference/developer/dashboard.md

@@ -11,8 +11,7 @@ The dashboard is the main UI component of the Kubeapps project. Written in JavaS
 - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
 - [Docker CE](https://www.docker.com/community-edition)
 - [Telepresence](https://telepresence.io)
-
-_Telepresence is not a hard requirement, but is recommended for a better developer experience_
+  - _Telepresence is not a hard requirement, but is recommended for a better developer experience_
 
 ## Download the kubeapps source code