-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metricbeat can't automatically connect #248
Comments
There is a deeper lying confusion about when to enable TLS in connections to Elasticsearch. If you browse all roles in the collection you will different conditions that will enable TLS for the connection to Elasticsearch. Most only allow TLS when the full stack variable is set. I think we should allow to have TLS with or without the full stack variable being set (e.g. using managed Elasticsearch). So my idea is to have a local variable in each role to en- or disable TLS. It should default to |
fixes #248 This is something between a workaround and a partial solution. While it makes more sense to use a role related variable for both Logstash and Elasticsearch output (other than before) it's still not the goal we want. So overhauling the whole process of determining whether we need TLS or not is due. I'll start a discussion and we need to adjust all roles to the solution we find. Now there are similarities but it's not exactly the same in every role.
I guess, I found the culprit: https://github.com/NETWAYS/ansible-collection-elasticstack/blob/main/roles/beats/templates/metricbeat.yml.j2#L18 Here we use a variable for a password that's not set anywhere. We're using the hardcoded user I hoped for a module for user management before we need to create more users the way we did with Logstash. But it looks, like we need to copy the code from |
Part of the solution should also be to make sure, |
When running the collection with defaults (only activating Metricbeat) it fails, because the variable
elasticsearch_http_security
isn't set for Metricbeat hosts. This looks like it's some legacy code from before we built the collection. It's possible that Auditbeat suffers the same problem.I'll investigate and I hope I can provide a solution.
The text was updated successfully, but these errors were encountered: