make tabs for different mechanisms

Author: Sohamdg081992

articles/azure-monitor/containers/prometheus-metrics-scrape-configuration.md

@@ -505,17 +505,38 @@ Scraping targets using basic auth is currently not supported using pod/service m
 If you have a Prometheus instance served with TLS and you want to scrape metrics from it, you need to set scheme to `https` and set the TLS settings in your configmap or respective CRD. 
 Please follow the below steps.
 
-1. Create a secret object using the TLS certificate in the **kube-system** namespace named **ama-metrics-mtls-secret**. 
+1. Create a secret object using the TLS certificate in the **kube-system** namespace named **ama-metrics-mtls-secret**. Inside the secret object , you can specify as many number of secret values under data section and name them how ever you want.
+   Each secret name-value pair specified in the data section of the secret object will be mounted as a seperate file in this /etc/prometheus/certs  location with filename(s) same as key(s) specified in the data section.
+   The secret values should be base64 encoded before putting them under the data section, in case of creating secret with YAML as shown below.
+   
    Below is an example command for creating a secret using the TLS self-signed certificate, in case of CRD based scraping. Please make sure that the secret object is created using the file naming format exactly as in the example below, in case of a CRD based scraping.
      ```console
     kubectl create secret generic ama-metrics-mtls-secret --from-file=secret_kube-system_ama-metrics-mtls-secret_<certfile>=secret_kube-system_ama-metrics-mtls-secret_<certfile> --from-file=secret_kube-system_ama-metrics-mtls-secret_<keyfile>=secret_kube-system_ama-metrics-mtls-secret_<keyfile> -n kube-system
     ```
-  Below is an example command for creating a secret using the TLS self-signed certificate, in case of config map based scraping. 
+
+   Below is an example command for creating a secret using the TLS self-signed certificate, in case of config map based scraping. 
      ```console
     kubectl create secret generic ama-metrics-mtls-secret --from-file=<certfile>=<certfile> --from-file=<keyfile>=<keyfile> -n kube-system
     ```   
+    
+    Below is an example of creating secret through YAML, in case of config map based scraping. 
 
-2. Below are the details about how to provide the TLS config settings through a configmap or CRD. 
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: ama-metrics-mtls-secret
+  namespace: kube-system
+type: Opaque
+data:
+  <certfile>: base64_cert_content    
+  <keyfile>: base64_key_content 
+```
+The **ama-metrics-mtls-secret** secret is mounted on to the ama-metrics containers at path - **/etc/prometheus/certs/**  and is made available to the process that is scraping prometheus metrics. The key( ex - certfile) in the above example will be the file name and the value is base64 decoded and added to the contents of the file within the container and the prometheus scraper uses the contents of this file to get the value that is used as the password used to scrape the endpoint.
+
+2. Below are the details about how to provide the TLS config settings through a configmap or CRD.
+   
+### [Scrape Config using Config File](#tab/ConfigFileScrapeConfigTLSAuth)
 
 - To provide the TLS config setting in a configmap, please follow the below example.
 
@@ -527,7 +548,10 @@ tls_config:
     insecure_skip_verify: false
 ```
 
-- To provide the TLS config setting in a configmap, please follow the below example.
+---
+### [Scrape Config using CRD(Pod/Service Monitor)](#tab/CRDScrapeConfigTLSAuth)
+
+- To provide the TLS config setting in a CRD(Pod/Service Monitor), please follow the below example.
 
 ```yaml
 tlsConfig:
@@ -545,15 +569,27 @@ tlsConfig:
     insecureSkipVerify: false
 ```
 
+---
 > [!NOTE]
->
-> Pod and Service monitors currently do not support basic authentication. Support for the same is coming up soon.
 > 
 > The **/etc/prometheus/certs/** path is mandatory, but *password1* can be any string and needs to match the key for the data in the secret created above. This is because the secret **ama-metrics-mtls-secret** is mounted in the path **/etc/prometheus/certs/** within the container.
 >
 > The base64 encoded value is automatically decoded by the agent pods when the secret is mounted as file.
 >
 > Make sure the secret name is **ama-metrics-mtls-secret** and it is in **kube-system** namespace.
+>
+> If you want to use both basic and Tls authentication settings in your configmap/CRD, just make sure that the secret **ama-metrics-mtls-secret** includes all the files(keys) under the data section with their corresponding base 64 encoded values, as shown below.
+apiVersion: v1
+kind: Secret
+metadata:
+  name: ama-metrics-mtls-secret
+  namespace: kube-system
+type: Opaque
+data:
+  <certfile>: base64_cert_content    # used for Tls
+  <keyfile>: base64_key_content      # used for Tls
+  password1: <base64-encoded-string> # used for basic auth
+  password2: <base64-encoded-string> # used for basic auth
 > 
 > The secret should be created and then the configmap/CRD should be created in kube-system namespace. The order of secret creation matters. When there's no secret but a valid CRD/config map, you will find errors in collector log -> `no file found for cert....`
 >