Currently autodiscovery only supports unauthenticated module metricset collection via autodiscovery hints.
As container orchestration platforms can generate passwords and usernames that are unknown to metricbeat at container launch we need a way to collect and utilize these passwords.
Kubernetes and OpenShift have a secrets api that could be allowed for metricbeat to read secrets for containers autodiscovered https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#-strong-read-operations-strong--211
From an RBAC perspective we can start testing with a permissive role that allows metricbeat to read and list all secrets and move towards a role where it can only read secrets that it knows that exist through autodiscovery by name to limit access further.
Here is an example application secret api call response, note that we can have several values in the data object to reference:
{
"apiVersion": "v1",
"data": {
"database-admin-password": "aFV0B0VzME1YbXZLSjgzNA==",
"database-password": "Mjc2RkHhN1VydnNSVUxPUA==",
"database-user": "dXWlcjFOMA=="
},
"kind": "Secret",
"metadata": {
"annotations": {
"openshift.io/generated-by": "OpenShiftNewApp"
},
"creationTimestamp": "2018-06-01T19:12:38Z",
"labels": {
"app": "nodejs-mongodb-example",
"template": "nodejs-mongodb-example"
},
"name": "nodejs-mongodb-example",
"namespace": "apm",
"resourceVersion": "593414",
"selfLink": "/api/v1/namespaces/apm/secrets/nodejs-mongodb-example",
"uid": "bf9295cd-65cf-11e8-9ec5-42010a800003"
},
"type": "Opaque"
}
Using the annotations autodiscover hints, and knowing the namespace of the pod, we could support something like this example to pull the secret by name and value from the correct namespace and write an autodiscover module config with username and password:
co.elastic.metrics/secret.username: secret-name.database-user
co.elastic.metrics/secret.password: secret-name.database-password
Currently autodiscovery only supports unauthenticated module metricset collection via autodiscovery hints.
As container orchestration platforms can generate passwords and usernames that are unknown to metricbeat at container launch we need a way to collect and utilize these passwords.
Kubernetes and OpenShift have a secrets api that could be allowed for metricbeat to read secrets for containers autodiscovered https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#-strong-read-operations-strong--211
From an RBAC perspective we can start testing with a permissive role that allows metricbeat to read and list all secrets and move towards a role where it can only read secrets that it knows that exist through autodiscovery by name to limit access further.
Here is an example application secret api call response, note that we can have several values in the data object to reference:
Using the annotations autodiscover hints, and knowing the namespace of the pod, we could support something like this example to pull the secret by name and value from the correct namespace and write an autodiscover module config with username and password: