Description

At a high level, this PR replaces the venerable add-team.sh script with some Dynamicbeat subcommands. However, it also does a lot more than just that.

First, Dynamicbeat is now used to configure Kibana and Elasticsearch. The deployments will only set up the cluster's PKI, configure initial passwords, and add the plugin to Kibana. Everything else is done by Dynamicbeat. Separate credentials must be provided in the configuration file for the purposes of setup.

Second, Dynamicbeat is used to load checks from files and add them into Elasticsearch. As a result, the bash-variable-esque templating of team names and numbers has been replaced with proper golang templating. Also, support has been added for configuring attribute overrides on a per-team basis. This means you can use templates within attribute values, and define the values that get inserted separately for each team. Also, you can define attributes at the team level that will override attributes defined in a check file.

This brings me to check files. Instead of creating a folder with the check's base ID (i.e. without the team name), and then creating up to three files within that folder (check.json, admin-attribs.json, user-attribs.json), checks are now configured in a single file that combines the contents of the old check.json file with any attributes that are defined. This file is named with the check's base ID. For example, a check with an ID of http-kibana-team01 would be configured via a file named http-kibana.json. Also, the id and group fields are no longer necessary, and should not be specified. Dynamicbeat will populate these fields based on the filename and the names of the teams that are configured.

Lastly, teams are no longer defined on the command-line. With the add-team.sh script, you had to pass the name of each team as an argument to the script. That is no longer necessary - now you can configure the number of teams, their team names, and optionally override the TeamNum variable within the Dynamicbeat configuration file. Like all settings used by the setup command, these settings don't have to be specified when executing the run command.

Oh, and the actual last thing - all example check definitions have been updated to only use attributes when appropriate. User attributes are defined for passwords (or other things teams should be able to modify), and admin attributes are defined for things that teams should be able to see the values of, but not modify.

Fixes #273

Merge Checklist

• I have tested this change locally to make sure it works
• I have updated the documentation as necessary
• I have added a release note under the Unreleased section of the Changelog
• This PR is being merged into dev, unless it's a PR for a release