diff --git a/docs/en/security/tribe-clients-integrations.asciidoc b/docs/en/security/tribe-clients-integrations.asciidoc index d915006ed05..1d0c0cf99ac 100644 --- a/docs/en/security/tribe-clients-integrations.asciidoc +++ b/docs/en/security/tribe-clients-integrations.asciidoc @@ -21,10 +21,16 @@ the stack are connected to the cluster and therefore need to be secured as well, or at least communicate with the cluster in a secured way: * <> -* {logstash-ref}/ls-security.html[Logstash] +* {auditbeat-ref}/securing-beats.html[Auditbeat] +* {filebeat-ref}/securing-beats.html[Filebeat] +* {heartbeat-ref}/securing-beats.html[Heartbeat] * {kibana-ref}/using-kibana-with-security.html[{kib}] +* {logstash-ref}/ls-security.html[Logstash] +* {metricbeat-ref}/securing-beats.html[Metricbeat] * <> +* {packetbeat-ref}/securing-beats.html[Packetbeat] * {kibana-ref}/secure-reporting.html[Reporting] +* {winlogbeat-ref}/securing-beats.html[Winlogbeat] include::tribe-clients-integrations/cross-cluster.asciidoc[] diff --git a/docs/en/security/tribe-clients-integrations/beats.asciidoc b/docs/en/security/tribe-clients-integrations/beats.asciidoc index 439d726c840..43c8be5409c 100644 --- a/docs/en/security/tribe-clients-integrations/beats.asciidoc +++ b/docs/en/security/tribe-clients-integrations/beats.asciidoc @@ -1,187 +1,11 @@ [[beats]] === Beats and Security -To send data to a secured cluster through the `elasticsearch` output, -a Beat needs to authenticate as a user who can manage index templates, -monitor the cluster, create indices, and read, and write to the indices -it creates. +See: -If encryption is enabled on the cluster, you also need to enable HTTPS in the -Beat configuration. - -In addition to configuring authentication credentials for the Beat itself, you -need to grant authorized users permission to access the indices it creates. - -[float] -[[beats-basic-auth]] -==== Configuring Authentication Credentials for a Beat - -When sending data to a secured cluster through the `elasticsearch` -output, a Beat must either provide basic authentication credentials -or present a client certificate. - -To configure authentication credentials for a Beat: - -. Create a role that has the `manage_index_templates` and -`monitor` cluster privileges, and `read`, `write`, and `create_index` -privileges for the indices the Beat creates. You can create roles from the -**Management / Roles** UI in Kibana or through the `role` API. -For example, the following request creates a `packetbeat_writer` role: -+ -[source, sh] ---------------------------------------------------------------- -POST _xpack/security/role/packetbeat_writer -{ - "cluster": ["manage_index_templates", "monitor"], - "indices": [ - { - "names": [ "packetbeat-*" ], <1> - "privileges": ["write","create_index"] - } - ] -} ---------------------------------------------------------------- -<1> If you use a custom Packetbeat index pattern, specify that pattern -instead of the default `packetbeat-*` pattern. - -. Assign the writer role to the user the Beat is going to use to -connect to Elasticsearch: - -.. To authenticate as a native user, create a user for the Beat -to use internally and assign it the writer role. You can create -users from the **Management / Users** UI in Kibana or through the -`user` API. For example, the following request creates a -`packetbeat_internal` user that has the `packetbeat_writer` role: -+ -[source, sh] ---------------------------------------------------------------- -POST /_xpack/security/user/packetbeat_internal -{ - "password" : "x-pack-test-password", - "roles" : [ "packetbeat_writer"], - "full_name" : "Internal Packetbeat User" -} ---------------------------------------------------------------- - -.. To authenticate using PKI authentication, assign the writer role -to the internal Beat user in the <> -configuration file. Specify the user by the distinguished name that -appears in its certificate. -+ -[source, yaml] ---------------------------------------------------------------- -packetbeat_writer: - - "cn=Internal Packetbeat User,ou=example,o=com" ---------------------------------------------------------------- - -. Configure authentication credentials for the `elasticsearch` output -in the Beat configuration file: - -.. To use basic authentication, configure the `username` and `password` -settings. For example, the following Packetbeat output configuration -uses the native `packetbeat_internal` user to connect to Elasticsearch: -+ -[source,js] --------------------------------------------------- -output.elasticsearch: - hosts: ["localhost:9200"] - index: "packetbeat" - username: "packetbeat_internal" - password: "x-pack-test-password" --------------------------------------------------- - -.. To use PKI authentication, configure the `certificate` and -`key` settings: -+ -[source,js] --------------------------------------------------- -output.elasticsearch: - hosts: ["localhost:9200"] - index: "packetbeat" - ssl.certificate: "/etc/pki/client/cert.pem" <1> - ssl.key: "/etc/pki/client/cert.key" --------------------------------------------------- -<1> The distinguished name (DN) in the certificate must be mapped to -the writer role in the `role_mapping.yml` configuration file on each -node in the Elasticsearch cluster. - -[float] -[[beats-user-access]] -==== Granting Users Access to Beats Indices - -To enable users to access the indices a Beat creates, grant them `read` and -`view_index_metadata` privileges on the Beat indices: - -. Create a role that has the `read` and `view_index_metadata` -privileges for the Beat indices. You can create roles from the -**Management > Roles** UI in Kibana or through the `role` API. -For example, the following request creates a `packetbeat_reader` -role: -+ -[source, sh] ---------------------------------------------------------------- -POST _xpack/security/role/packetbeat_reader -{ - "indices": [ - { - "names": [ "packetbeat-*" ], <1> - "privileges": ["read","view_index_metadata"] - } - ] -} ---------------------------------------------------------------- -<1> If you use a custom Packetbeat index pattern, specify that pattern -instead of the default `packetbeat-*` pattern. - -. Assign your users the reader role so they can access the Beat indices: - -.. If you're using the `native` realm, you can assign roles with the -**Management > Users** UI in Kibana or through the `user` API. For -example, the following request grants `packetbeat_user` -the `packetbeat_reader` role: -+ -[source, sh] ---------------------------------------------------------------- -POST /_xpack/security/user/packetbeat_user -{ - "password" : "x-pack-test-password", - "roles" : [ "packetbeat_reader"], - "full_name" : "Packetbeat User" -} ---------------------------------------------------------------- - -.. If you're using the LDAP, Active Directory, or PKI realms, you -assign the roles in the <> configuration -file. For example, the following snippet grants `Packetbeat User` -the `packetbeat_reader` role: -+ -[source, yaml] ---------------------------------------------------------------- -packetbeat_reader: - - "cn=Packetbeat User,dc=example,dc=com" ---------------------------------------------------------------- - -[float] -[[beats-tls]] -===== Configuring Beats to use Encrypted Connections - -If encryption is enabled on the Elasticsearch cluster, you need to -connect to Elasticsearch via HTTPS. If the CA that signed your node certificates -is not in the host system's trusted certificate authorities list, you also need -to add the path to the `.pem` file that contains your CA's certificate to the -Beat configuration. - -To configure a Beat to connect to Elasticsearch via HTTPS, add the `https` protocol -to all host URLs: - -[source,js] --------------------------------------------------- -output.elasticsearch: - hosts: ["https://localhost:9200"] <1> - index: "packetbeat" - ssl.certificate_authorities: ["/etc/pki/root/ca.pem"] <2> --------------------------------------------------- -<1> Specify the `https` protocol to connect the Elasticsearch cluster. -<2> Specify the path to the local `.pem` file that contains your Certificate -Authority's certificate. This is generally only needed if you use your -own CA to sign your node certificates. \ No newline at end of file +* {auditbeat-ref}/securing-beats.html[Auditbeat and {security}] +* {filebeat-ref}/securing-beats.html[Filebeat and {security}] +* {heartbeat-ref}/securing-beats.html[Heartbeat and {security}] +* {metricbeat-ref}/securing-beats.html[Metricbeat and {security}] +* {packetbeat-ref}/securing-beats.html[Packetbeat and {security}] +* {winlogbeat-ref}/securing-beats.html[Winlogbeat and {security}]