After testing out beats central management for a few days I wondering how you scale this feature. From my understanding when you enroll a beat its on a one to one ratio. A user clicks on Enroll Beats, gets a link/token/command and then runs the beat with the autogenerated command. With this setup it seems like theres no efficient way to deploy central manager to 100's or 1000's of beats since each UUID is specific to the beat it was run on, unless you can use the same UUID on multiple beats.
If I'm misunderstanding the use of CM feel free to let me know. Appreciate the guidance.
Seems like my answer was right here unless anyone else has something to add to this.
https://www.elastic.co/guide/en/beats/metricbeat/current/enroll-beats.html
Username and password-based enrollmentedit
You can also enroll by specifying a username and password. This is the recommended way for scripted deploys:
metricbeat enroll KIBANA_URL --username USER --password METHOD [--force]
--username USER
The username to use for password-based enrollment. The default username is elastic .
--password METHOD
The method to use for getting the password. Available options are:
-
env:VAR_NAME gets the password from the environment variable VAR_NAME
-
stdin prompts the user for a password. This is the default.
--force
Overwrites the current settings without asking for confirmation.
2 Likes
Are the username/password creds saved on each Beat for it to continually retrieve management from Kibana?
Or are they just used to generate a unique token?
Reusing credentials doesn't seem like a good way of controlling hundreds and thousands of Beats, considering other credentials (like to output to Elasticsearch) are potentially able to be retrieved from Central Management.