Metricbeat supports templates for modules:

["source","yaml",subs="attributes"]
-------------------------------------------------------------------------------------
metricbeat.autodiscover:
  providers:
    - type: kubernetes
      include_annotations: ["prometheus.io.scrape"]
      templates:
        - condition:
            contains:
              kubernetes.annotations.prometheus.io/scrape: "true"
          config:
            - module: prometheus
              metricsets: ["collector"]
              hosts: "${data.host}:${data.port}"
-------------------------------------------------------------------------------------

This configuration launches a `prometheus` module for all containers of pods annotated `prometheus.io/scrape=true`.

[float]
===== Manually Defining Ports with Kubernetes

Declare exposed ports in your pod spec if possible. Otherwise, you will need to use
multiple templates with complex filtering rules. The {port} variable will not be
present, and you will need to hardcode ports. Example: `{data.host}:1234`

When ports are not declared, Autodiscover generates a config using your provided
template once per pod, and once per container. These generated configs are
de-duplicated after they are generated. If the generated configs for multiple
containers are identical, they will be merged into one config.

Pods share an identical host. If only the `{data.host}` variable is interpolated,
then one config will be generated per host. The configs will be identical.
After they are de-duplicated, only one will be used.

In order to target one specific exposed port `{data.host}:{data.ports.web}` can be used
in template config, where `web` is the name of the exposed container port.

[float]
[[kubernetes-secrets]]
===== Metricbeat Autodiscover Secret Management

[float]
====== Local Keystore
Metricbeat autodiscover supports leveraging <<keystore>> in order to retrieve sensitive data like passwords.
Here is an example of how a configuration using keystore would look like:

["source","yaml",subs="attributes"]
-------------------------------------------------------------------------------------
metricbeat.autodiscover:
  providers:
    - type: kubernetes
      templates:
        - condition:
            contains:
              kubernetes.labels.app: "redis"
          config:
            - module: redis
              metricsets: ["info", "keyspace"]
              hosts: "${data.host}:6379"
              password: "${REDIS_PASSWORD}"
-------------------------------------------------------------------------------------

where `REDIS_PASSWORD` is a key stored in local keystore of Metricbeat.

[float]
===== Kubernetes Secrets
Metricbeat autodiscover supports leveraging https://kubernetes.io/docs/concepts/configuration/secret/[Kubernetes secrets]
in order to retrieve sensitive data like passwords.
Here is an example of how a configuration using Kubernetes secrets would look like:

["source","yaml",subs="attributes"]
-------------------------------------------------------------------------------------
metricbeat.autodiscover:
  providers:
    - type: kubernetes
      templates:
        - condition:
            contains:
              kubernetes.labels.app: "redis"
          config:
            - module: redis
              metricsets: ["info", "keyspace"]
              hosts: "${data.host}:6379"
              password: "${kubernetes.default.somesecret.value}"
-------------------------------------------------------------------------------------

where `kubernetes.default.somesecret.value` specifies a key stored as Kubernetes secret as following:

. Kubernetes Namespace: `default`
. Kubernetes Secret Name: `somesecret`
. Secret Data Key: `value`

This secret can be created in a Kubernetes environment using the following the command:
["source","yaml",subs="attributes"]
-------------------------------------------------------------------------------------
cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: somesecret
type: Opaque
data:
  value: $(echo -n "passpass" | base64)
EOF
-------------------------------------------------------------------------------------


Note that Pods can only consume secrets that belong to the same Kubernetes namespace. For instance if Pod `my-redis`
is running under `staging` namespace, it cannot access a secret under `testing` namespace for example `kubernetes.testing.xxx.yyy`.
