[[configuration-central-management]]
[role="xpack"]
= {beats} central management

[partintro]
--

beta[]

[WARNING]
=======================================
When you use central management, configurations are stored centrally in {es}. To
prevent an attacker from leveraging the configurations to attack your
infrastructure, you must {stack-ov}/elasticsearch-security.html[secure {es} and
{kib}] before using central management.
=======================================

{beats} central management provides a way to define and manage configurations in
a central location in {kib} and quickly deploy configuration changes to all
{beats} running across your enterprise. 

To learn more, see <<how-central-managment-works>>.

To use central management, <<enroll-beats,enroll your {beats}>>, then use
the {cm-ui} UI in {kib} to create and apply the configurations.

[NOTE]
=====
This feature requires an Elastic license that includes {beats} central
management.  

include::shared-license-statement.asciidoc[]
=====

--

[[how-central-managment-works]]
[role="xpack"]
== How central management works

beta[]

{beats} central management uses a mechanism called configuration tags to group
related configurations. You define configuration tags in the {cm-ui} UI in {kib}
after <<enroll-beats,enrolling your first beat.>>

A _configuration tag_ is a group of configuration blocks that you can apply to
one or more {beats}. A tag can have configuration blocks for different types of
{beats}. For example, you might have a tag called `development` that you use to
group all configurations that are valid for running {beats} in your development
environment. The `development` tag might have:

* Two Metricbeat module configuration blocks: one that reads system metrics and
another that reads metrics from Apache HTTP servers
* Two Filebeat module configuration blocks: one that reads Apache HTTP server
logs and another that reads system logs
* One Elasticsearch output configuration block that sends the output to your
{es} development cluster

[role="screenshot"]
image::./images/configuration-blocks.png[Screen showing configuration blocks in a tag]

You apply the tag to any {beats} that will use the configurations defined in the
tag.

[role="screenshot"]
image::./images/enrolled-beats.png[Screen showing {beats} with tags applied]

When the enrolled {beats} run, each Beat uses the configuration blocks that are
valid for its type.

You can add, modify, or remove configuration blocks from a tag. Any changes that
you make to the configuration blocks in a tag are automatically applied to all
{beats} that have that tag.

You can add or remove tags to change the set of configuration blocks applied to
your {beats}. For example, after you've tested configurations in your
`development` environment, you can remove the `development` tag and add a
`production` tag that has an {es} output configuration block for sending the
data to your production cluster.

[role="screenshot"]
image::./images/enrolled-beats-dev-prod.png[Screen showing {beats} with development and production tags applied]

You can apply multiple tags to a Beat. For example, instead of defining the
apache modules under the `development` tag as described earlier, you could
create a separate tag called `apache` that contains the Apache module
configurations, then apply the tag to all {beats} running on Apache servers.
This would enable you to maintain your Apache module configurations under a
single tag, while also using a `development` tag to send output for some
instances to your development cluster. 

[role="screenshot"]
image::./images/enrolled-beats-apache.png[Screen showing {beats} with multiple tags]

You can apply as many tags as you need. Just keep in mind that the
configurations for all assigned tags are merged, which means that you should not
specify conflicting configurations. If there are errors in the configuration,
you'll see an Error status in the {cm-ui} UI and need to look at the logs for
the Beat to troubleshoot the problem. 

[[enroll-beats]]
[role="xpack"]
== Enroll {beats} in central management

beta[]

You need to enroll {beats} to register them in
<<configuration-central-management,central management>> and establish
trust. Enrolled {beats} will have the credentials needed to retrieve
configurations from {kib}.

During the enrollment process:

 . The Beat contacts {kib} and tries to register
 . {kib} registers the Beat instance and returns an access token
 for configuration polling
 . The enroll command creates a backup of your configuration and then
 **overwrites the current settings** so they can be managed centrally

To enroll {beats}, use either <<token-based-enrollment,token-based>>
or <<username-password-enrollment,username and password-based>> enrollment.


[float]
=== Prerequisites

* Verify that your Elastic license includes the {beats} central management
feature.
+
include::shared-license-statement.asciidoc[]

* {kibana-ref}/using-kibana-with-security.html[Enable security] in {kib} to
ensure that only users with sufficient privileges are able to access {beats}
configurations. 
* Assign the `beats_admin` role to any users who need to enroll {beats} or
manage configuration settings in central management.
ifndef::no_dashboards[]
* If you plan to use the sample {kib} dashboards provided with {beatname_uc},
<<load-kibana-dashboards,load the dashboards>> before enrolling the
Beat.
endif::[]
ifeval::["{beatname_lc}"=="filebeat"]
* If you plan to define module configurations in central management, set up the
ingest pipelines before enrolling the Beat. For more information, see
<<load-ingest-pipelines>>.
endif::[]

[float]
[[token-based-enrollment]]
=== Token-based enrollment

Token-based enrollment is recommended if you are enrolling {beats} manually.

To use token-based enrollment, go to {kib} -> Management -> {beats} and click
`Enroll Beat`. Select the Beat type and operating system, then copy and run the
command for enrolling the Beat.

The command has this format:

["source","shell",subs="attributes"]
----------------------------------------------------------------------
{beatname_lc} enroll KIBANA_URL TOKEN
----------------------------------------------------------------------

*`KIBANA_URL`*::
The URL of the {kib} instance you will use for central management.

*`TOKEN`*::
The enrollment token generated by the {cm-ui} UI. The enrollment token will
expire as soon as it's used.

For example:
["source","shell",subs="attributes"]
----------------------------------------------------------------------
{beatname_lc} enroll http://xyz.gov:5601 70f4b584e8024b96b682c46125a8d81
----------------------------------------------------------------------

Repeat this process to enroll additional {beats}.

// Maintainers: If you update the following note, also update the note that
// appears later in this file.

[IMPORTANT]
=====
*Windows users:* If you installed {beatname_uc} as a service, you must also set
`-path.data` to +"C:{backslash}ProgramData{backslash}{beatname_lc}"+ when you
run the enroll command. For example:

+.{backslash}{beatname_lc}.exe enroll http://xyz.gov:5601 70f4b584e8024b96b682c46125a8d81a
-path.data "C:{backslash}ProgramData{backslash}{beatname_lc}"+

Why? The service installation script, +install-service-{beatname_lc}.ps1+,
changes the default data path to match the convention used for Windows. If you
run the enroll command without specifying the correct data path, {beatname_uc}
will be enrolled in central management with the wrong UUID and unable to receive
the configuration.
=====

[float]
[[username-password-enrollment]]
=== Username and password-based enrollment

You can also enroll by specifying a username and password. This is the
recommended way for scripted deploys:

["source","shell",subs="attributes"]
----------------------------------------------------------------------
{beatname_lc} 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.

For example:

["source","shell",subs="attributes"]
----------------------------------------------------------------------
{beatname_lc} enroll http://xyz.gov:5601 --username myuser --password stdin
----------------------------------------------------------------------

[IMPORTANT]
=====
*Windows users:* If you installed {beatname_uc} as a service, you must also set
`-path.data` to +"C:{backslash}ProgramData{backslash}{beatname_lc}"+ when you
run the enroll command. For example:

+.{backslash}{beatname_lc}.exe enroll http://xyz.gov:5601 --username myuser --password stdin
-path.data "C:{backslash}ProgramData{backslash}{beatname_lc}"+

Why? The service installation script, +install-service-{beatname_lc}.ps1+,
changes the default data path to match the convention used for Windows. If you
run the enroll command without specifying the correct data path, {beatname_uc}
will be enrolled in central management with the wrong UUID and unable to receive
the configuration.
=====



//[[central-management-API]]
//== Enrollment API (not documented for beta)
//
//available.

