Allow auditbeat setup to run without elevated privileges

[jordansissel]

Tested on Auditbeat 6.2.4 (docker.elastic.co/beats/auditbeat:6.2.4).

Running auditbeat setup --dashboards results in:

Exiting: 1 error: 1 error: failed to create audit client: failed to get audit status: operation not permitted

Proposal: Have auditbeat setup skip creation of the audit client because it probably doesn't need it.

[andrewkroh]

I found that there is an InSetupCmd flag that gets set during setup. I think it would be sufficient to modify metricbeat to basically be a no-op during setup. This would stop any initialization of metricsets when setup runs.

We might want to move the return to just after the config validation, but before instantiating the metricsets.

@ruflin @exekias @jsoriano Do you foresee any side-effects for doing this?

diff --git a/metricbeat/beater/metricbeat.go b/metricbeat/beater/metricbeat.go
index f0d26263a..168797573 100644
--- a/metricbeat/beater/metricbeat.go
+++ b/metricbeat/beater/metricbeat.go
@@ -77,6 +77,10 @@ func DefaultCreator() beat.Creator {
 
 // newMetricbeat creates and returns a new Metricbeat instance.
 func newMetricbeat(b *beat.Beat, c *common.Config, options ...Option) (*Metricbeat, error) {
+       if b.InSetupCmd {
+               return nil, nil
+       }
+
        // List all registered modules and metricsets.
        logp.Debug("modules", "%s", mb.Registry.String())

[exekias]

uhm, that could do the trick, I think in the past some things (like template loading) were configured here, but that doesn't seem to be the case anymore.

also sorry, I think I introduced this 🙈