[DOCS] Update links to Kibana security (elastic/x-pack-elasticsearch#2235)
Original commit: elastic/x-pack-elasticsearch@88f29b3321
This commit is contained in:
Lisa Cawley
GitHub
parent
1066a6f877
commit
e500fba354
|
|
@ -1,7 +1,7 @@
|
|||
[[authorization]]
|
||||
== Configuring Role-based Access Control
|
||||
|
||||
{security} introduces the concept of _authorization_ to Elasticsearch.
|
||||
{security} introduces the concept of _authorization_ to {es}.
|
||||
Authorization is the process of determining whether the user behind an incoming
|
||||
request is allowed to execute it. This process takes place once a request is
|
||||
successfully authenticated and the user behind the request is identified.
|
||||
|
|
@ -14,7 +14,7 @@ The authorization process revolves around the following 5 constructs:
|
|||
|
||||
_Secured Resource_::
|
||||
A resource to which access is restricted. Indices/aliases, documents, fields,
|
||||
users and the Elasticsearch cluster itself are all examples of secured objects.
|
||||
users and the {es} cluster itself are all examples of secured objects.
|
||||
|
||||
_Privilege_::
|
||||
A named group representing one or more actions that a user may execute against a
|
||||
|
|
@ -38,7 +38,7 @@ A named sets of permissions
|
|||
_User_::
|
||||
The authenticated user.
|
||||
|
||||
A secure Elasticsearch cluster manages the privileges of users through _roles_.
|
||||
A secure {es} cluster manages the privileges of users through _roles_.
|
||||
A role has a unique name and identifies a set of permissions that translate to
|
||||
privileges on resources. A user can be associated with an arbitrary number of
|
||||
roles. The total set of permissions that a user has is therefore defined by
|
||||
|
|
@ -66,20 +66,21 @@ NOTE: This role does *not* provide the ability to create indices; those privileg
|
|||
must be defined in a separate role.
|
||||
|
||||
[[built-in-roles-kibana-system]] `kibana_system` ::
|
||||
Grants access necessary for the <<kibana, Kibana system user>>
|
||||
to read from and write to the Kibana indices and check the availability of the
|
||||
Elasticsearch cluster.
|
||||
Grants access necessary for the {kib} system user
|
||||
to read from and write to the {kib} indices and check the availability of the
|
||||
{es} cluster. For more information, see
|
||||
{kibana-ref}/using-kibana-with-security.html[Configuring Security in {kib}]
|
||||
+
|
||||
NOTE: This role should not be assigned to users as the granted permissions may
|
||||
change between releases.
|
||||
|
||||
[[built-in-roles-kibana-user]] `kibana_user`::
|
||||
Grants the minimum privileges required for any user of Kibana. This role grants
|
||||
access to the Kibana indices and grants monitoring privileges for the cluster.
|
||||
Grants the minimum privileges required for any user of {kib}. This role grants
|
||||
access to the {kib} indices and grants monitoring privileges for the cluster.
|
||||
|
||||
[[built-in-roles-logstash-system]] `logstash_system` ::
|
||||
Grants access necessary for the <<ls-monitoring-user, Logstash system user>>
|
||||
to send system-level data (such as monitoring) to Elasticsearch.
|
||||
to send system-level data (such as monitoring) to {es}.
|
||||
+
|
||||
NOTE: This role should not be assigned to users as the granted permissions may
|
||||
change between releases.
|
||||
|
|
@ -97,8 +98,8 @@ read access to the `.ml-notifications` and `.ml-anomalies*` indices,
|
|||
which store {ml} results.
|
||||
|
||||
[[built-in-roles-monitoring-user]] `monitoring_user`::
|
||||
Grants the minimum privileges required for any user of Monitoring other than those
|
||||
required to use Kibana. This role grants access to the monitoring indices.
|
||||
Grants the minimum privileges required for any user of {monitoring} other than those
|
||||
required to use {kib}. This role grants access to the monitoring indices.
|
||||
Monitoring users should also be assigned the `kibana_user` role.
|
||||
|
||||
[[built-in-roles-remote-monitoring-agent]] `remote_monitoring_agent`::
|
||||
|
|
@ -106,8 +107,8 @@ Grants the minimum privileges required for a remote monitoring agent to write da
|
|||
into this cluster.
|
||||
|
||||
[[built-in-roles-reporting-user]] `reporting_user`::
|
||||
Grants the specific privileges required for users of Reporting other than those
|
||||
required to use Kibana. This role grants access to the reporting indices. Reporting
|
||||
Grants the specific privileges required for users of {reporting} other than those
|
||||
required to use {kib}. This role grants access to the reporting indices. Reporting
|
||||
users should also be assigned the `kibana_user` role and a role that grants them
|
||||
access to the data that will be used to generate reports with.
|
||||
|
||||
|
|
@ -239,7 +240,7 @@ The following snippet shows an example definition of a `clicks_admin` role:
|
|||
Based on the above definition, users owning the `clicks_admin` role can:
|
||||
|
||||
* Impersonate the `clicks_watcher_1` user and execute requests on its behalf.
|
||||
* Monitor the Elasticsearch cluster
|
||||
* Monitor the {es} cluster
|
||||
* Read data from all indices prefixed with `events-`
|
||||
* Within these indices, only read the events of the `click` category
|
||||
* Within these document, only read the `category`, `@timestamp` and `message`
|
||||
|
|
@ -248,7 +249,7 @@ Based on the above definition, users owning the `clicks_admin` role can:
|
|||
TIP: For a complete list of available <<security-privileges, cluster and indices privileges>>
|
||||
|
||||
There are two available mechanisms to define roles: using the _Role Management APIs_
|
||||
or in local files on the Elasticsearch nodes. {security} also supports implementing
|
||||
or in local files on the {es} nodes. {security} also supports implementing
|
||||
custom roles providers. If you need to integrate with another system to retrieve
|
||||
user roles, you can build a custom roles provider plugin. For more information,
|
||||
see <<custom-roles-provider, Custom Roles Provider Extension>>.
|
||||
|
|
@ -257,9 +258,10 @@ see <<custom-roles-provider, Custom Roles Provider Extension>>.
|
|||
[[roles-management-ui]]
|
||||
=== Role Management UI
|
||||
|
||||
If you are a Kibana user, make sure to <<installing-xpack, install {xpack} in Kibana>>.
|
||||
This enables you to easily manage users and roles from within Kibana. To manage roles,
|
||||
log in to Kibana and go to *Management / Elasticsearch / Roles*.
|
||||
If you are a {kib} user, make sure to
|
||||
<<installing-xpack, install {xpack} in {kib}>>.
|
||||
This enables you to easily manage users and roles from within {kib}. To manage roles,
|
||||
log in to {kib} and go to *Management / Elasticsearch / Roles*.
|
||||
|
||||
[float]
|
||||
[[roles-management-api]]
|
||||
|
|
@ -267,7 +269,7 @@ log in to Kibana and go to *Management / Elasticsearch / Roles*.
|
|||
|
||||
The _Role Management APIs_ enable you to add, update, remove and retrieve roles
|
||||
dynamically. When you use the APIs to manage roles in the `native` realm, the
|
||||
roles are stored in an internal Elasticsearch index.
|
||||
roles are stored in an internal {es} index.
|
||||
|
||||
[[roles-api-add]]
|
||||
==== Adding a Role
|
||||
|
|
@ -376,7 +378,7 @@ _Role Management APIs_, the role found in the file will be used.
|
|||
|
||||
While the _Role Management APIs_ is the preferred mechanism to define roles,
|
||||
using the `roles.yml` file becomes useful if you want to define fixed roles that
|
||||
no one (beside an administrator having physical access to the Elasticsearch nodes)
|
||||
no one (beside an administrator having physical access to the {es} nodes)
|
||||
would be able to change.
|
||||
|
||||
[IMPORTANT]
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ search shards, templates, validate).
|
|||
`view_index_metadata`::
|
||||
Read-only access to index metadata (aliases, aliases exists, get index, exists, field mappings,
|
||||
mappings, search shards, type exists, validate, warmers, settings). This
|
||||
privilege is primarily available for use by <<kibana-roles, Kibana users>>.
|
||||
privilege is primarily available for use by {kib} users.
|
||||
|
||||
`read`::
|
||||
Read only access to actions (count, explain, get, mget, get indexed scripts,
|
||||
|
|
|
|||
|
|
@ -1,330 +0,0 @@
|
|||
[[security-release-notes]]
|
||||
== Shield Release Notes (Pre-5.0)
|
||||
|
||||
[float]
|
||||
[[update-roles]]
|
||||
=== Updated Role Definitions
|
||||
The default role definitions in the `roles.yml` file may need to be changed to ensure proper interoperation with other
|
||||
applications such as Monitoring and Kibana. Any role changes are stored in `roles.yml.new` when you upgrade. We recommend copying the following changes to your `roles.yml` file.
|
||||
|
||||
* The `kibana4` role now grants access to the Field Stats API.
|
||||
* The permission on all the roles are updated to the verbose format to make it easier to enable field level and document level security. The `transport_client` role has been updated to work with Elasticsearch 2.0.0.
|
||||
The `marvel_user` role has been updated to work with Monitoring 2.0 and a `remote_marvel_agent` role has been added. The `kibana3` and `marvel_agent` roles have been removed.
|
||||
* `kibana` role added that defines the minimum set of permissions necessary for the Kibana 4 server.
|
||||
* `kibana4` role updated to work with new features in Kibana 4 RC1
|
||||
|
||||
[float]
|
||||
[[security-change-list]]
|
||||
=== Change List
|
||||
|
||||
[float]
|
||||
==== 2.4.2
|
||||
November 22, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* Users with `manage` or `manage_security` cluster privileges can now access the `.security` index if they have the appropriate index
|
||||
privileges.
|
||||
|
||||
.Breaking Changes
|
||||
* Shield on tribe nodes now requires `tribe.on_conflict` to prefer one of the clusters.
|
||||
|
||||
[float]
|
||||
==== 2.4.0
|
||||
August 31, 2016
|
||||
|
||||
.Breaking Changes
|
||||
* The `monitor` cluster privilege now grants access to the GET `/_license` API
|
||||
|
||||
|
||||
[float]
|
||||
==== 2.3.5
|
||||
August 3, 2016
|
||||
|
||||
.Bug Fixes
|
||||
|
||||
* Fixed a license problem that was preventing tribe nodes from working with
|
||||
Shield.
|
||||
|
||||
[float]
|
||||
==== 2.3.4
|
||||
July 7, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* The `default` transport profile SSL settings now override the `shield.ssl.*`
|
||||
settings properly.
|
||||
* Fixed a memory leak that occured when indices were deleted or closed.
|
||||
|
||||
[float]
|
||||
==== 2.3.3
|
||||
May 18, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* Fixed the `/_shield/realm/{realms}/_cache/clear` REST endpoint. This endpoint is deprecated and `/_shield/realm/{realms}/_clear_cache` should be used going forward.
|
||||
|
||||
[float]
|
||||
==== 2.3.2
|
||||
April 26, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* Date math expressions in index names are now resolved before attempting to authorize access to the indices.
|
||||
* Fixed an issue where active directory realms did not work unless the url setting was configured.
|
||||
* Enabled `_cat/indices` to be used when Shield is installed.
|
||||
|
||||
[float]
|
||||
==== 2.3.1
|
||||
April 4, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* Fixed an issue that could prevent nodes from joining the cluster.
|
||||
|
||||
[float]
|
||||
==== 2.3.0
|
||||
March 30, 2016
|
||||
|
||||
.New Features
|
||||
* <<native-realm,Native realm>> with support for
|
||||
{ref}/security-api-users.html[user management APIs].
|
||||
* <<security-api-roles,Role management APIs>> have been added.
|
||||
|
||||
.Bug Fixes
|
||||
* When evaluating permissions for multiple roles that have document level security enabled for the same index, Shield performed an `AND`
|
||||
on the queries, which is not consistent with how role privileges work in Shield. This has been changed to an `OR` relationship and may
|
||||
affect the behavior of existing roles; please ensure you are not relying on the `AND` behavior of document level security queries.
|
||||
* When evaluation permissions for user that has roles with and without document level security (and/or field level security), the roles that
|
||||
granted unrestricted access were not being applied properly and the user's access was still being restricted.
|
||||
|
||||
.Enhancements
|
||||
* Added new <<security-privileges, privileges>> to simplify access control.
|
||||
|
||||
[float]
|
||||
==== 2.2.1
|
||||
March 15, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* Enable <<field-and-document-access-control,document and field level security>> by default.
|
||||
* Fix issues with message authentication on certain JDKs that do not support cloning message
|
||||
authentication codes.
|
||||
* Built in <<setting-up-authentication, realms>> no longer throw an exception if the `Authorization` header does not contain a basic
|
||||
authentication token.
|
||||
* Ensure each tribe client node has the same shield configuration as defined in the settings.
|
||||
|
||||
[float]
|
||||
==== 2.2.0
|
||||
February 2, 2016
|
||||
|
||||
.New Features
|
||||
* Shield plugin for Kibana: Secures user sessions and enables users to log in and out of Kibana.
|
||||
For information about installing the Shield plugin, see <<kibana, Using Kibana with Shield>>.
|
||||
|
||||
.Bug Fixes
|
||||
* Update requests (including within bulk requests) are blocked when document
|
||||
and field level security is enabled
|
||||
|
||||
[float]
|
||||
==== 2.1.2
|
||||
February 2, 2016
|
||||
|
||||
.Enhancements
|
||||
* Adds support for Elasticssearch 2.1.2
|
||||
|
||||
[float]
|
||||
==== 2.1.1
|
||||
December 17, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* Disable the request cache when <<document-level-security, document level security>> is in use for a search request.
|
||||
* Fix startup failures when using auditing and <<audit-log-entry-local-node-info, enabling network information output>>.
|
||||
* Updated the `kibana4` role to include the Field Stats API.
|
||||
|
||||
[float]
|
||||
==== 2.1.0
|
||||
November 24, 2015
|
||||
|
||||
.Breaking Changes
|
||||
* Same as 2.0.1. <<field-and-document-access-control, Document and Field Level Security>> is now disabled by default. Set `shield.dls_fls.enabled` to `true` in `elasticsearch.yml` to enable it. You cannot submit `_bulk` update requests when document and field level security is enabled.
|
||||
|
||||
.Enhancements
|
||||
* Adds support for Elasticsearch 2.1.0.
|
||||
|
||||
[float]
|
||||
==== 2.0.2
|
||||
December 16, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* Disable the request cache when <<document-level-security, document level security>> is in use for a search request.
|
||||
|
||||
[float]
|
||||
==== 2.0.1
|
||||
November 24, 2015
|
||||
|
||||
.Breaking Changes
|
||||
* <<field-and-document-access-control, Document and Field Level Security>> is now disabled by default. Set `shield.dls_fls.enabled` to `true` in `elasticsearch.yml` to enable it. You cannot submit `_bulk` update requests when document and field level security is enabled.
|
||||
|
||||
.Enhancement
|
||||
* Adds support for Elasticsearch 2.0.1.
|
||||
|
||||
[float]
|
||||
==== 2.0.0
|
||||
October 28, 2015
|
||||
|
||||
.Breaking Changes
|
||||
* All files that Shield uses must be kept in the <<security-files-location, configuration directory>> due to the enhanced security of Elasticsearch 2.0.
|
||||
* The network format has been changed from all previous versions of Shield and a full cluster restart is required to upgrade to Shield 2.0.
|
||||
|
||||
.New Features
|
||||
* <<field-and-document-access-control, Document and Field Level Security>> support has been added and can be
|
||||
configured per role.
|
||||
* Support for <<custom-realms, custom authentication realms>> has been added, allowing Shield to integrate with more authentication sources and methods.
|
||||
* <<run-as-privilege, User impersonation support>> has also been added, which allows a user to send a request to Elasticsearch that will be run
|
||||
with the specified user's permissions.
|
||||
|
||||
.Bug Fixes
|
||||
* <<auditing, Auditing>> now captures requests from nodes using a different system key as tampered requests.
|
||||
* The <<audit-index, index output for auditing>> stores the type of request when available.
|
||||
* `esusers` and `syskeygen` work when spaces are in the Elasticsearch installation path.
|
||||
* Fixed a rare issue where authentication fails even when the username and password are correct.
|
||||
|
||||
[float]
|
||||
==== 1.3.3
|
||||
|
||||
.Bug Fixes
|
||||
* Fixed a rare issue where authentication fails even when the username and password are correct.
|
||||
* The <<audit-index, index output for auditing>> stores the type of request when available.
|
||||
|
||||
.Enhancements
|
||||
* Tampered requests with a bad header are now audited.
|
||||
|
||||
[float]
|
||||
==== 1.3.2
|
||||
August 10, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* When using the <<ldap-user-search,LDAP user search>> mechanism, connection errors during startup no longer cause the node to stop.
|
||||
* The {ref}/security-api-clear-cache.html[Clear Cache API] no longer generates invalid JSON.
|
||||
* The <<audit-index,index output for auditing>> starts properly when forwarding the audit events to a remote cluster and uses
|
||||
the correct user to index the audit events.
|
||||
|
||||
[float]
|
||||
==== 1.3.1
|
||||
July 21, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* Fixes message authentication serialization to work with Shield 1.2.1 and earlier.
|
||||
** NOTE: if you are upgrading from Shield 1.3.0 or Shield 1.2.2 a {ref-17}/setup-upgrade.html#restart-upgrade[cluster restart upgrade]
|
||||
will be necessary. When upgrading from other versions of Shield, follow the normal upgrade procedure.
|
||||
|
||||
[float]
|
||||
==== 1.3.0
|
||||
June 24, 2015
|
||||
|
||||
.Breaking Changes
|
||||
* The `sha2` and `apr1` hashing algorithms have been removed as options for the <<cache-hash-algo,`cache.hash_algo` setting>>.
|
||||
If your existing Shield installation uses either of these options, remove the setting and use the default `ssha256`
|
||||
algorithm.
|
||||
* The `users` file now only supports `bcrypt` password hashing. All existing passwords stored using the `esusers` tool
|
||||
have been hashed with `bcrypt` and are not affected.
|
||||
|
||||
.New Features
|
||||
* <<pki-realm,PKI Realm>>: Adds Public Key Infrastructure (PKI) authentication through the use of X.509 certificates in place of
|
||||
username and password credentials.
|
||||
* <<auditing, Index Output for Audit Events>>: An index based output has been added for storing audit events in an Elasticsearch index.
|
||||
|
||||
.Enhancements
|
||||
* TLS 1.2 is now the default protocol.
|
||||
* Clients that do not support pre-emptive basic authentication can now support both anonymous and authenticated access
|
||||
by specifying the `shield.authc.anonymous.authz_exception` <<anonymous-access,setting>> with a value of `false`.
|
||||
* Reduced logging for common SSL exceptions, such as a client closing the connection during a handshake.
|
||||
|
||||
.Bug Fixes
|
||||
* The `esusers` and `syskeygen` tools now work correctly with environment variables in the RPM and DEB installation
|
||||
environment files `/etc/sysconfig/elasticsearch` and `/etc/default/elasticsearch`.
|
||||
* Default ciphers no longer include `TLS_DHE_RSA_WITH_AES_128_CBC_SHA`.
|
||||
|
||||
[float]
|
||||
==== 1.2.3
|
||||
July 21, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* Fixes message authentication serialization to work with Shield 1.2.1 and earlier.
|
||||
** NOTE: if you are upgrading from Shield 1.2.2 a {ref-17}/setup-upgrade.html#restart-upgrade[cluster restart upgrade]
|
||||
will be necessary. When upgrading from other versions of Shield, follow the normal upgrade procedure.
|
||||
|
||||
[float]
|
||||
==== 1.2.2
|
||||
June 24, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* The `esusers` tool no longer warns about missing roles that are properly defined in the `roles.yml` file.
|
||||
* The period character, `.`, is now allowed in usernames and role names.
|
||||
* The {ref-17}/query-dsl-terms-filter.html#_caching_19[terms filter lookup cache] has been disabled to ensure all requests
|
||||
are properly authorized. This removes the need to manually disable the terms filter cache.
|
||||
* For LDAP client connections, only the protocols and ciphers specified in the `shield.ssl.supported_protocols` and
|
||||
`shield.ssl.ciphers` {ref}/security-settings.html#ssl-tls-settings[settings] will be used.
|
||||
* The auditing mechanism now logs authentication failed events when a request contains an invalid authentication token.
|
||||
|
||||
[float]
|
||||
==== 1.2.1
|
||||
April 29, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* Several bug fixes including a fix to ensure that {ref}/disk-allocator.html[Disk-based Shard Allocation]
|
||||
works properly with Shield
|
||||
|
||||
[float]
|
||||
==== 1.2.0
|
||||
March 24, 2015
|
||||
|
||||
.Enhancements
|
||||
* Adds support for Elasticsearch 1.5
|
||||
|
||||
[float]
|
||||
==== 1.1.1
|
||||
April 29, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* Several bug fixes including a fix to ensure that {ref}/disk-allocator.html[Disk-based Shard Allocation]
|
||||
works properly with Shield
|
||||
|
||||
[float]
|
||||
==== 1.1.0
|
||||
March 24, 2015
|
||||
|
||||
.New Features
|
||||
* LDAP:
|
||||
** Add the ability to bind as a specific user for LDAP searches, which removes the need to specify `user_dn_templates`.
|
||||
This mode of operation also makes use of connection pooling for better performance. Please see <<ldap-user-search, ldap user search>>
|
||||
for more information.
|
||||
** User distinguished names (DNs) can now be used for <<ldap-role-mapping, role mapping>>.
|
||||
* Authentication:
|
||||
** <<anonymous-access, Anonymous access>> is now supported (disabled by default).
|
||||
* IP Filtering:
|
||||
** IP Filtering settings can now be <<dynamic-ip-filtering,dynamically updated>> using the {ref}/cluster-update-settings.html[Cluster Update Settings API].
|
||||
|
||||
.Enhancements
|
||||
* Significant memory footprint reduction of internal data structures
|
||||
* Test if SSL/TLS ciphers are supported and warn if any of the specified ciphers are not supported
|
||||
* Reduce the amount of logging when a non-encrypted connection is opened and `https` is being used
|
||||
* Added the <<kibana-roles, `kibana_server` role>>, which is a role that contains the minimum set of permissions required for the Kibana 4 server.
|
||||
* In-memory user credential caching hash algorithm defaults now to salted SHA-256 (see <<cache-hash-algo, Cache hash algorithms>>
|
||||
|
||||
.Bug Fixes
|
||||
* Filter out sensitive settings from the settings APIs
|
||||
|
||||
[float]
|
||||
==== 1.0.2
|
||||
March 24, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* Filter out sensitive settings from the settings APIs
|
||||
* Significant memory footprint reduction of internal data structures
|
||||
|
||||
[float]
|
||||
==== 1.0.1
|
||||
February 13, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* Fixed dependency issues with Elasticsearch 1.4.3 and (Lucene 4.10.3 that comes with it)
|
||||
* Fixed bug in how user roles were handled. When multiple roles were defined for a user, and one of the
|
||||
roles only had cluster permissions, not all privileges were properly evaluated.
|
||||
* Updated `kibana4` permissions to be compatible with Kibana 4 RC1
|
||||
* Ensure the mandatory `base_dn` settings is set in the `ldap` realm configuration
|
||||
|
|
@ -22,7 +22,7 @@ or at least communicate with the cluster in a secured way:
|
|||
|
||||
* <<hadoop, Apache Hadoop>>
|
||||
* <<logstash, Logstash>>
|
||||
* <<kibana, Kibana>>
|
||||
* {kibana-ref}/using-kibana-with-security.html[{kib}]
|
||||
* <<secure-monitoring, Monitoring>>
|
||||
* {kibana-ref}/secure-reporting.html[Reporting]
|
||||
|
||||
|
|
@ -40,6 +40,4 @@ include::tribe-clients-integrations/logstash.asciidoc[]
|
|||
|
||||
include::tribe-clients-integrations/beats.asciidoc[]
|
||||
|
||||
include::tribe-clients-integrations/kibana.asciidoc[]
|
||||
|
||||
include::tribe-clients-integrations/monitoring.asciidoc[]
|
||||
|
|
|
|||
|
|
@ -1,197 +0,0 @@
|
|||
|
||||
[[kibana]]
|
||||
=== Kibana and Security
|
||||
|
||||
[[using-kibana-with-security]]
|
||||
Kibana users have to log in when {security} is enabled on your cluster. You
|
||||
configure {security} roles for your Kibana users to control what data those users
|
||||
can access. You also need to configure credentials for the
|
||||
Kibana server so the requests it submits to Elasticsearch on the user's
|
||||
behalf can be authenticated.
|
||||
|
||||
To prevent user passwords from being sent in the clear, you must configure
|
||||
Kibana to encrypt communications between the browser and the Kibana server.
|
||||
If are encrypting traffic to and from the nodes in your Elasticsearch cluster,
|
||||
you must also configure Kibana to connect to Elasticsearch via HTTPS.
|
||||
|
||||
With {security} enabled, if you load a Kibana dashboard that accesses data in an
|
||||
index that you are not authorized to view, you get an error that indicates the
|
||||
index does not exist. {security} do not currently provide a way to control which
|
||||
users can load which dashboards.
|
||||
|
||||
IMPORTANT: Support for tribe nodes in Kibana was added in v5.2.
|
||||
|
||||
To use Kibana with {security}:
|
||||
|
||||
. Configure the password for the built-in `kibana` user. The Kibana server submits
|
||||
requests as this user to access the cluster monitoring APIs and the `.kibana` index.
|
||||
The server does _not_ need access to user indices.
|
||||
+
|
||||
By default, the `kibana` does not have a password. The user will not be enabled until
|
||||
a password is set. Set the password through the reset password API:
|
||||
+
|
||||
[source,shell]
|
||||
--------------------------------------------------------------------------------
|
||||
PUT /_xpack/security/user/kibana/_password
|
||||
{
|
||||
"password" : "s0m3th1ngs3cr3t"
|
||||
}
|
||||
--------------------------------------------------------------------------------
|
||||
// CONSOLE
|
||||
+
|
||||
Once you change the password, you need to specify it with the `elasticsearch.password`
|
||||
property in `kibana.yml`:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
elasticsearch.password: "s0m3th1ngs3cr3t"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
[[kibana-roles]]
|
||||
. Assign the `kibana_user` role to grant Kibana users the privileges they
|
||||
need to use Kibana.
|
||||
+
|
||||
IMPORTANT: You also need to grant Kibana users access to the
|
||||
indices that they will be working with in Kibana.
|
||||
+
|
||||
** If you're using the `native` realm, you can assign roles using the
|
||||
<<managing-native-users, User Management API>>. For example, the following
|
||||
creates a user named `jacknich` and assigns it the `kibana_user` role:
|
||||
+
|
||||
[source,js]
|
||||
--------------------------------------------------------------------------------
|
||||
POST /_xpack/security/user/jacknich
|
||||
{
|
||||
"password" : "t0pS3cr3t",
|
||||
"roles" : [ "kibana_user" ]
|
||||
}
|
||||
--------------------------------------------------------------------------------
|
||||
// CONSOLE
|
||||
|
||||
** If you are using an LDAP or Active Directory realm, you can either assign
|
||||
roles on a per user basis, or assign roles to groups of users. By default, role
|
||||
mappings are stored in <<mapping-roles, `CONFIGDIR/x-pack/role_mapping.yml`>>.
|
||||
For example, the following snippet assigns the `kibana_user` role to the
|
||||
group named `admins` and the user named Jack Nicholson:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
kibana_user:
|
||||
- "cn=admins,dc=example,dc=com"
|
||||
- "cn=Jack Nicholson,dc=example,dc=com"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
[[configure-kibana-cert]]
|
||||
. Configure Kibana to encrypt communications between the browser and the Kibana
|
||||
server:
|
||||
.. Generate a server certificate for Kibana. You must either set the certificate's
|
||||
`subjectAltName` to the hostname, fully-qualified domain name (FQDN), or IP
|
||||
address of the Kibana server, or set the CN to the Kibana server's hostname
|
||||
or FQDN. Using the server's IP address as the CN does not work.
|
||||
.. Set the `server.ssl.key` and `server.ssl.certificate` properties in `kibana.yml`:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
server.ssl.key: /path/to/your/server.key
|
||||
server.ssl.certificate: /path/to/your/server.crt
|
||||
--------------------------------------------------------------------------------
|
||||
+
|
||||
Once you enable SSL encryption between the browser and the Kibana server,
|
||||
access Kibana via HTTPS. For example, `https://localhost:5601`.
|
||||
+
|
||||
NOTE: You must enable SSL encryption between the browser and the Kibana
|
||||
server to use Kibana with {security} enabled. If {security} is configured to
|
||||
encrypt connections to Elasticsearch, you must also <<configure-kibana-ssl,
|
||||
configure Kibana to connect to Elasticsearch via HTTPS>>.
|
||||
|
||||
[[configure-kibana-ssl]]
|
||||
. If you have enabled SSL encryption in {security}, configure Kibana to connect
|
||||
to Elasticsearch via HTTPS:
|
||||
|
||||
.. Specify the HTTPS protocol in the `elasticsearch.url` setting in the Kibana
|
||||
configuration file, `kibana.yml`:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
elasticsearch.url: "https://<your_elasticsearch_host>.com:9200"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
.. If you are using your own CA to sign certificates for Elasticsearch, set the
|
||||
`elasticsearch.ssl.certificateAuthorities` setting in `kibana.yml` to specify
|
||||
the location of the PEM file.
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
elasticsearch.ssl.certificateAuthorities: /path/to/your/cacert.pem
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
. Install {xpack} into Kibana to secure user sessions and enable users
|
||||
to log in and out of Kibana:
|
||||
|
||||
.. Run the following command in your Kibana installation directory.
|
||||
+
|
||||
[source,console]
|
||||
--------------------------------------------------------------------------------
|
||||
bin/kibana-plugin install x-pack
|
||||
--------------------------------------------------------------------------------
|
||||
+
|
||||
[NOTE]
|
||||
=============================================================================
|
||||
To perform an offline install, download the {xpack} zip file from
|
||||
https://artifacts.elastic.co/downloads/packs/x-pack/x-pack-{version}.zip[
|
||||
+https://artifacts.elastic.co/downloads/packs/x-pack/x-pack-{version}.zip+]
|
||||
(https://artifacts.elastic.co/downloads/packs/x-pack/x-pack-{version}.zip.sha1[sha1])
|
||||
and run:
|
||||
|
||||
["source","sh",subs="attributes"]
|
||||
---------------------------------------------------------
|
||||
bin/kibana-plugin install file:///path/to/file/x-pack-{version}.zip
|
||||
---------------------------------------------------------
|
||||
=============================================================================
|
||||
|
||||
.. Set the `xpack.security.encryptionKey` property in the `kibana.yml` configuration file.
|
||||
You can use any text string that is 32 characters or longer as the encryption key.
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
xpack.security.encryptionKey: "something_at_least_32_characters"
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
.. To change the default session duration, set the `xpack.security.sessionTimeout` property
|
||||
in the `kibana.yml` configuration file. By default, sessions will stay active until the
|
||||
browser is closed. The timeout is specified in milliseconds. For example, set the timeout
|
||||
to 600000 to expire sessions after 10 minutes:
|
||||
+
|
||||
[source,yaml]
|
||||
--------------------------------------------------------------------------------
|
||||
xpack.security.sessionTimeout: 600000
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
. Restart Kibana and verify that you can log in as a user. If you are running
|
||||
Kibana locally, go to `https://localhost:5601` and enter the credentials for a
|
||||
user you've assigned a Kibana user role. For example, you could log in as the
|
||||
`jacknich` user created above.
|
||||
+
|
||||
image::images/kibana-login.jpg["Kibana Login",link="images/kibana-login.jpg"]
|
||||
+
|
||||
NOTE: This must be a user who has been assigned the `kibana_user` role.
|
||||
Kibana server credentials should only be used internally by the
|
||||
Kibana server.
|
||||
|
||||
[float]
|
||||
[[security-ui-settings]]
|
||||
===== Kibana {security} UI Settings
|
||||
[options="header"]
|
||||
|======
|
||||
| Name | Default | Description
|
||||
| `xpack.security.encryptionKey` | - | An arbitrary string of 32 characters or more used to encrypt credentials in a
|
||||
cookie. It is crucial that this key is not exposed to
|
||||
users of Kibana. Required.
|
||||
| `xpack.security.sessionTimeout` | `1800000` (30 minutes) | Sets the session duration (in milliseconds).
|
||||
| `xpack.security.cookieName` | `"sid"` | Sets the name of the cookie used for the session.
|
||||
| `xpack.security.secureCookies` | `false` | Sets the `secure` flag of the session cookie. Is set
|
||||
to `true` if `server.ssl.certificate` and `server.ssl.key`
|
||||
are set. Set this to `true` if SSL is configured
|
||||
outside of Kibana (for example, you are routing
|
||||
requests through a load balancer or proxy).
|
||||
|======
|
||||
|
|
@ -2,31 +2,32 @@
|
|||
=== Monitoring and Security
|
||||
|
||||
<<xpack-monitoring, {monitoring}>> consists of two components: an agent
|
||||
that you install on on each Elasticsearch and Logstash node, and a Monitoring UI
|
||||
in Kibana. The monitoring agent collects and indexes metrics from the nodes
|
||||
and you visualize the data through the Monitoring dashboards in Kibana. The agent
|
||||
can index data on the same Elasticsearch cluster, or send it to an external
|
||||
that you install on on each {es} and Logstash node, and a Monitoring UI
|
||||
in {kib}. The monitoring agent collects and indexes metrics from the nodes
|
||||
and you visualize the data through the Monitoring dashboards in {kib}. The agent
|
||||
can index data on the same {es} cluster, or send it to an external
|
||||
monitoring cluster.
|
||||
|
||||
To use {monitoring} with {security} enabled, you need to
|
||||
<<kibana, set up Kibana to work with {security}>> and create at least one user
|
||||
for the Monitoring UI. If you are using an external monitoring cluster, you also
|
||||
need to configure a user for the monitoring agent and configure the agent to use
|
||||
the appropriate credentials when communicating with the monitoring cluster.
|
||||
{kibana-ref}/using-kibana-with-security.html[set up {kib} to work with {security}]
|
||||
and create at least one user for the Monitoring UI. If you are using an external
|
||||
monitoring cluster, you also need to configure a user for the monitoring agent
|
||||
and configure the agent to use the appropriate credentials when communicating
|
||||
with the monitoring cluster.
|
||||
|
||||
[float]
|
||||
[[monitoring-ui-users]]
|
||||
==== Setting Up Monitoring UI Users
|
||||
|
||||
When {security} is enabled, Kibana users are prompted to log in when they access
|
||||
the UI. To use the Monitoring UI, a user must have access to the Kibana indices
|
||||
When {security} is enabled, {kib} users are prompted to log in when they access
|
||||
the UI. To use the Monitoring UI, a user must have access to the {kib} indices
|
||||
and permission to read from the monitoring indices.
|
||||
|
||||
You set up Monitoring UI users on the cluster where the monitoring data is being
|
||||
stored. To grant all of the necessary permissions, assign the user the
|
||||
`monitoring_user` and `kibana_user` roles:
|
||||
|
||||
* If you're using the `native` realm, you can assign roles through Kibana or
|
||||
* If you're using the `native` realm, you can assign roles through {kib} or
|
||||
with the <<managing-native-users, User Management API>>. For example, the following
|
||||
command creates a user named `jacknich` and assigns him the `kibana_user` and
|
||||
`monitoring_user` roles:
|
||||
|
|
@ -76,7 +77,7 @@ POST /_xpack/security/user/agent-user
|
|||
+
|
||||
|
||||
. On each node in the cluster being monitored, configure a Monitoring HTTP exporter
|
||||
in `elasticsearch.yml` and restart Elasticsearch. In the exporter configuration,
|
||||
in `elasticsearch.yml` and restart {es}. In the exporter configuration,
|
||||
you need to:
|
||||
+
|
||||
--
|
||||
|
|
@ -103,7 +104,7 @@ If SSL/TLS is enabled on the monitoring cluster:
|
|||
.. Include the CA certificate in each node's trusted certificates in order to verify
|
||||
the identities of the nodes in the monitoring cluster.
|
||||
|
||||
To add a CA certificate to an Elasticsearch node's trusted certificates, you
|
||||
To add a CA certificate to an {es} node's trusted certificates, you
|
||||
can specify the location of the PEM encoded certificate with the
|
||||
`certificate_authorities` setting:
|
||||
|
||||
|
|
@ -178,4 +179,4 @@ Alternatively, you can configure trusted certificates using a truststore
|
|||
xpack.monitoring.elasticsearch.ssl.truststore.path: /path/to/file
|
||||
xpack.monitoring.elasticsearch.ssl.truststore.password: x-pack-test-password
|
||||
--------------------------------------------------
|
||||
--
|
||||
--
|
||||
|
|
|
|||
Loading…
Reference in New Issue