honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[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 2017-08-10 12:56:03 -07:00 committed by GitHub
parent 1066a6f877
commit e500fba354
6 changed files with 39 additions and 565 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
docs/en/security/authorization.asciidoc
View File

@ -1,7 +1,7 @@
[[authorization]] [[authorization]]
== Configuring Role-based Access Control == 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 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 request is allowed to execute it. This process takes place once a request is
successfully authenticated and the user behind the request is identified. 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_:: _Secured Resource_::
A resource to which access is restricted. Indices/aliases, documents, fields, 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_:: _Privilege_::
A named group representing one or more actions that a user may execute against a 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_:: _User_::
The authenticated 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 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 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 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. must be defined in a separate role.
[[built-in-roles-kibana-system]] `kibana_system` :: [[built-in-roles-kibana-system]] `kibana_system` ::
Grants access necessary for the <<kibana, Kibana system user>> Grants access necessary for the {kib} system user
to read from and write to the Kibana indices and check the availability of the to read from and write to the {kib} indices and check the availability of the
Elasticsearch cluster. {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 NOTE: This role should not be assigned to users as the granted permissions may
change between releases. change between releases.
[[built-in-roles-kibana-user]] `kibana_user`:: [[built-in-roles-kibana-user]] `kibana_user`::
Grants the minimum privileges required for any user of Kibana. This role grants Grants the minimum privileges required for any user of {kib}. This role grants
access to the Kibana indices and grants monitoring privileges for the cluster. access to the {kib} indices and grants monitoring privileges for the cluster.
[[built-in-roles-logstash-system]] `logstash_system` :: [[built-in-roles-logstash-system]] `logstash_system` ::
Grants access necessary for the <<ls-monitoring-user, Logstash system user>> 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 NOTE: This role should not be assigned to users as the granted permissions may
change between releases. change between releases.
@ -97,8 +98,8 @@ read access to the `.ml-notifications` and `.ml-anomalies*` indices,
which store {ml} results. which store {ml} results.
[[built-in-roles-monitoring-user]] `monitoring_user`:: [[built-in-roles-monitoring-user]] `monitoring_user`::
Grants the minimum privileges required for any user of Monitoring other than those 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. required to use {kib}. This role grants access to the monitoring indices.
Monitoring users should also be assigned the `kibana_user` role. Monitoring users should also be assigned the `kibana_user` role.
[[built-in-roles-remote-monitoring-agent]] `remote_monitoring_agent`:: [[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. into this cluster.
[[built-in-roles-reporting-user]] `reporting_user`:: [[built-in-roles-reporting-user]] `reporting_user`::
Grants the specific privileges required for users of Reporting other than those 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 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 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. 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: Based on the above definition, users owning the `clicks_admin` role can:
* Impersonate the `clicks_watcher_1` user and execute requests on its behalf. * 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-` * Read data from all indices prefixed with `events-`
* Within these indices, only read the events of the `click` category * Within these indices, only read the events of the `click` category
* Within these document, only read the `category`, `@timestamp` and `message` * 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>> 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_ 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 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, user roles, you can build a custom roles provider plugin. For more information,
see <<custom-roles-provider, Custom Roles Provider Extension>>. see <<custom-roles-provider, Custom Roles Provider Extension>>.
@ -257,9 +258,10 @@ see <<custom-roles-provider, Custom Roles Provider Extension>>.
[[roles-management-ui]] [[roles-management-ui]]
=== Role Management UI === Role Management UI
If you are a Kibana user, make sure to <<installing-xpack, install {xpack} in Kibana>>. If you are a {kib} user, make sure to
This enables you to easily manage users and roles from within Kibana. To manage roles, <<installing-xpack, install {xpack} in {kib}>>.
log in to Kibana and go to *Management / Elasticsearch / Roles*. 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] [float]
[[roles-management-api]] [[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 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 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]] [[roles-api-add]]
==== Adding a Role ==== 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, 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 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. would be able to change.
[IMPORTANT] [IMPORTANT]

2
docs/en/security/reference/privileges.asciidoc
View File

@ -67,7 +67,7 @@ search shards, templates, validate).
`view_index_metadata`:: `view_index_metadata`::
Read-only access to index metadata (aliases, aliases exists, get index, exists, field mappings, Read-only access to index metadata (aliases, aliases exists, get index, exists, field mappings,
mappings, search shards, type exists, validate, warmers, settings). This 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`::
Read only access to actions (count, explain, get, mget, get indexed scripts, Read only access to actions (count, explain, get, mget, get indexed scripts,

330
docs/en/security/release-notes.asciidoc
View File

@ -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

4
docs/en/security/tribe-clients-integrations.asciidoc
View File

@ -22,7 +22,7 @@ or at least communicate with the cluster in a secured way:
* <<hadoop, Apache Hadoop>> * <<hadoop, Apache Hadoop>>
* <<logstash, Logstash>> * <<logstash, Logstash>>
* <<kibana, Kibana>> * {kibana-ref}/using-kibana-with-security.html[{kib}]
* <<secure-monitoring, Monitoring>> * <<secure-monitoring, Monitoring>>
* {kibana-ref}/secure-reporting.html[Reporting] * {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/beats.asciidoc[]
include::tribe-clients-integrations/kibana.asciidoc[]
include::tribe-clients-integrations/monitoring.asciidoc[] include::tribe-clients-integrations/monitoring.asciidoc[]

197
docs/en/security/tribe-clients-integrations/kibana.asciidoc
View File

@ -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).
|======

29
docs/en/security/tribe-clients-integrations/monitoring.asciidoc
View File

@ -2,31 +2,32 @@
=== Monitoring and Security === Monitoring and Security
<<xpack-monitoring, {monitoring}>> consists of two components: an agent <<xpack-monitoring, {monitoring}>> consists of two components: an agent
that you install on on each Elasticsearch and Logstash node, and a Monitoring UI that you install on on each {es} and Logstash node, and a Monitoring UI
in Kibana. The monitoring agent collects and indexes metrics from the nodes in {kib}. The monitoring agent collects and indexes metrics from the nodes
and you visualize the data through the Monitoring dashboards in Kibana. The agent and you visualize the data through the Monitoring dashboards in {kib}. The agent
can index data on the same Elasticsearch cluster, or send it to an external can index data on the same {es} cluster, or send it to an external
monitoring cluster. monitoring cluster.
To use {monitoring} with {security} enabled, you need to To use {monitoring} with {security} enabled, you need to
<<kibana, set up Kibana to work with {security}>> and create at least one user {kibana-ref}/using-kibana-with-security.html[set up {kib} to work with {security}]
for the Monitoring UI. If you are using an external monitoring cluster, you also and create at least one user for the Monitoring UI. If you are using an external
need to configure a user for the monitoring agent and configure the agent to use monitoring cluster, you also need to configure a user for the monitoring agent
the appropriate credentials when communicating with the monitoring cluster. and configure the agent to use the appropriate credentials when communicating
with the monitoring cluster.
[float] [float]
[[monitoring-ui-users]] [[monitoring-ui-users]]
==== Setting Up Monitoring UI Users ==== Setting Up Monitoring UI Users
When {security} is enabled, Kibana users are prompted to log in when they access 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 Kibana indices the UI. To use the Monitoring UI, a user must have access to the {kib} indices
and permission to read from the monitoring indices. and permission to read from the monitoring indices.
You set up Monitoring UI users on the cluster where the monitoring data is being 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 stored. To grant all of the necessary permissions, assign the user the
`monitoring_user` and `kibana_user` roles: `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 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 command creates a user named `jacknich` and assigns him the `kibana_user` and
`monitoring_user` roles: `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 . 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: 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 .. Include the CA certificate in each node's trusted certificates in order to verify
the identities of the nodes in the monitoring cluster. 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 can specify the location of the PEM encoded certificate with the
`certificate_authorities` setting: `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.path: /path/to/file
xpack.monitoring.elasticsearch.ssl.truststore.password: x-pack-test-password xpack.monitoring.elasticsearch.ssl.truststore.password: x-pack-test-password
-------------------------------------------------- --------------------------------------------------
-- --