[DOCS] Fixes title capitalization in security content
This commit is contained in:
lcawl
parent
69481b4059
commit
7f47ff9fcd
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[auditing]]
|
||||
== Auditing Security Events
|
||||
== Auditing security events
|
||||
|
||||
You can enable auditing to keep track of security-related events such as
|
||||
authentication failures and refused connections. Logging these events enables you
|
||||
|
|
@ -40,7 +41,7 @@ events are pushed to the index by setting
|
|||
|
||||
[float]
|
||||
[[audit-event-types]]
|
||||
=== Audit Event Types
|
||||
=== Audit event types
|
||||
|
||||
Each request may generate multiple audit events.
|
||||
The following is a list of the events that can be generated:
|
||||
|
|
@ -81,11 +82,11 @@ The following is a list of the events that can be generated:
|
|||
|
||||
[float]
|
||||
[[audit-event-attributes]]
|
||||
=== Audit Event Attributes
|
||||
=== Audit event attributes
|
||||
|
||||
The following table shows the common attributes that can be associated with every event.
|
||||
|
||||
.Common Attributes
|
||||
.Common attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -103,7 +104,7 @@ The following table shows the common attributes that can be associated with ever
|
|||
The following tables show the attributes that can be associated with each type of event.
|
||||
The log level determines which attributes are included in a log entry.
|
||||
|
||||
.REST anonymous_access_denied Attributes
|
||||
.REST anonymous_access_denied attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -112,7 +113,7 @@ The log level determines which attributes are included in a log entry.
|
|||
| `request_body` | The body of the request, if enabled.
|
||||
|======
|
||||
|
||||
.REST authentication_success Attributes
|
||||
.REST authentication_success attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -123,7 +124,7 @@ The log level determines which attributes are included in a log entry.
|
|||
| `request_body` | The body of the request, if enabled.
|
||||
|======
|
||||
|
||||
.REST authentication_failed Attributes
|
||||
.REST authentication_failed attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -133,7 +134,7 @@ The log level determines which attributes are included in a log entry.
|
|||
| `request_body` | The body of the request, if enabled.
|
||||
|======
|
||||
|
||||
.REST realm_authentication_failed Attributes
|
||||
.REST realm_authentication_failed attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -146,7 +147,7 @@ The log level determines which attributes are included in a log entry.
|
|||
consulted realm.
|
||||
|======
|
||||
|
||||
.Transport anonymous_access_denied Attributes
|
||||
.Transport anonymous_access_denied attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -161,7 +162,7 @@ The log level determines which attributes are included in a log entry.
|
|||
pertains to (when applicable).
|
||||
|======
|
||||
|
||||
.Transport authentication_success Attributes
|
||||
.Transport authentication_success attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -176,7 +177,7 @@ The log level determines which attributes are included in a log entry.
|
|||
| `request` | The type of request that was executed.
|
||||
|======
|
||||
|
||||
.Transport authentication_failed Attributes
|
||||
.Transport authentication_failed attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -192,7 +193,7 @@ The log level determines which attributes are included in a log entry.
|
|||
pertains to (when applicable).
|
||||
|======
|
||||
|
||||
.Transport realm_authentication_failed Attributes
|
||||
.Transport realm_authentication_failed attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -211,7 +212,7 @@ The log level determines which attributes are included in a log entry.
|
|||
consulted realm.
|
||||
|======
|
||||
|
||||
.Transport access_granted Attributes
|
||||
.Transport access_granted attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -228,7 +229,7 @@ The log level determines which attributes are included in a log entry.
|
|||
pertains to (when applicable).
|
||||
|======
|
||||
|
||||
.Transport access_denied Attributes
|
||||
.Transport access_denied attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -245,7 +246,7 @@ The log level determines which attributes are included in a log entry.
|
|||
relates to (when applicable).
|
||||
|======
|
||||
|
||||
.Transport tampered_request Attributes
|
||||
.Transport tampered_request attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -261,7 +262,7 @@ The log level determines which attributes are included in a log entry.
|
|||
pertains to (when applicable).
|
||||
|======
|
||||
|
||||
.IP Filter connection_granted Attributes
|
||||
.IP filter connection_granted attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -271,7 +272,7 @@ The log level determines which attributes are included in a log entry.
|
|||
the request.
|
||||
|======
|
||||
|
||||
.IP Filter connection_denied Attributes
|
||||
.IP filter connection_denied attributes
|
||||
[cols="2,7",options="header"]
|
||||
|======
|
||||
| Attribute | Description
|
||||
|
|
@ -283,14 +284,14 @@ The log level determines which attributes are included in a log entry.
|
|||
|
||||
[float]
|
||||
[[audit-log-output]]
|
||||
=== Logfile Audit Output
|
||||
=== Logfile audit output
|
||||
|
||||
The `logfile` audit output is the default output for auditing. It writes data to
|
||||
the `<clustername>_access.log` file in the logs directory.
|
||||
|
||||
[float]
|
||||
[[audit-log-entry-format]]
|
||||
=== Log Entry Format
|
||||
=== Log entry format
|
||||
|
||||
The format of a log entry is:
|
||||
|
||||
|
|
@ -318,7 +319,7 @@ The format of a log entry is:
|
|||
|
||||
[float]
|
||||
[[audit-log-settings]]
|
||||
=== Logfile Output Settings
|
||||
=== Logfile output settings
|
||||
|
||||
The events and some other information about what gets logged can be
|
||||
controlled using settings in the `elasticsearch.yml` file. See
|
||||
|
|
@ -336,7 +337,7 @@ file located in `CONFIG_DIR`. By default, audit information is appended to the
|
|||
|
||||
[float]
|
||||
[[audit-log-ignore-policy]]
|
||||
=== Logfile Audit Events Ignore Policies
|
||||
=== Logfile audit events ignore policies
|
||||
|
||||
The comprehensive audit trail is necessary to ensure accountability. It offers tremendous
|
||||
value during incident response and can even be required for demonstrating compliance.
|
||||
|
|
@ -414,7 +415,7 @@ xpack.security.audit.logfile.events.ignore_filters:
|
|||
|
||||
[float]
|
||||
[[audit-index]]
|
||||
=== Index Audit Output
|
||||
=== Index audit output
|
||||
|
||||
In addition to logging to a file, you can store audit logs in Elasticsearch
|
||||
rolling indices. These indices can be either on the same cluster, or on a
|
||||
|
|
@ -429,13 +430,13 @@ xpack.security.audit.outputs: [ index, logfile ]
|
|||
----------------------------
|
||||
|
||||
For more configuration options, see
|
||||
{ref}/auditing-settings.html#index-audit-settings[Audit Log Indexing Configuration Settings].
|
||||
{ref}/auditing-settings.html#index-audit-settings[Audit log indexing configuration settings].
|
||||
|
||||
IMPORTANT: No filtering is performed when auditing, so sensitive data may be
|
||||
audited in plain text when including the request body in audit events.
|
||||
|
||||
[float]
|
||||
==== Audit Index Settings
|
||||
==== Audit index settings
|
||||
|
||||
You can also configure settings for the indices that the events are stored in.
|
||||
These settings are configured in the `xpack.security.audit.index.settings` namespace
|
||||
|
|
@ -451,7 +452,7 @@ xpack.security.audit.index.settings:
|
|||
----------------------------
|
||||
|
||||
[float]
|
||||
==== Forwarding Audit Logs to a Remote Cluster
|
||||
==== Forwarding audit logs to a remote cluster
|
||||
|
||||
To index audit events to a remote Elasticsearch cluster, you configure
|
||||
the following `xpack.security.audit.index.client` settings:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[active-directory-realm]]
|
||||
=== Active Directory user authentication
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[anonymous-access]]
|
||||
=== Enabling Anonymous Access
|
||||
=== Enabling anonymous access
|
||||
|
||||
Incoming requests are considered to be _anonymous_ if no authentication token
|
||||
can be extracted from the incoming request. By default, anonymous requests are rejected and an authentication error is returned (status code `401`).
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[built-in-users]]
|
||||
=== Built-in users
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[custom-realms]]
|
||||
=== Integrating with Other Authentication Systems
|
||||
=== Integrating with other authentication systems
|
||||
|
||||
If you are using an authentication system that is not supported out-of-the-box
|
||||
by {security}, you can create a custom realm to interact with it to authenticate
|
||||
|
|
@ -7,7 +8,7 @@ users. You implement a custom realm as an SPI loaded security extension
|
|||
as part of an ordinary elasticsearch plugin.
|
||||
|
||||
[[implementing-custom-realm]]
|
||||
==== Implementing a Custom Realm
|
||||
==== Implementing a custom realm
|
||||
|
||||
Sample code that illustrates the structure and implementation of a custom realm
|
||||
is provided in the https://github.com/elastic/shield-custom-realm-example[custom-realm-example]
|
||||
|
|
@ -70,7 +71,7 @@ part of the `SecurityExtension` interface, it's available as part of the elastic
|
|||
. Bundle all in a single zip file.
|
||||
|
||||
[[using-custom-realm]]
|
||||
==== Using a Custom Realm to Authenticate Users
|
||||
==== Using a custom realm to authenticate users
|
||||
|
||||
To use a custom realm:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[file-realm]]
|
||||
=== File-based user authentication
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[internal-users]]
|
||||
=== Internal users
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[ldap-realm]]
|
||||
=== LDAP user authentication
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[native-realm]]
|
||||
=== Native user authentication
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[setting-up-authentication]]
|
||||
== User authentication
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[pki-realm]]
|
||||
=== PKI user authentication
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[realms]]
|
||||
=== Realms
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
[role="xpack"]
|
||||
[[saml-guide]]
|
||||
|
||||
== Configuring SAML single-sign-on on the Elastic Stack
|
||||
== Configuring SAML single-sign-on on the {stack}
|
||||
|
||||
The Elastic Stack supports SAML single-sign-on (SSO) into {kib}, using {es} as
|
||||
a backend service. In SAML terminology, the Elastic Stack is operating as a
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[saml-realm]]
|
||||
=== SAML authentication
|
||||
{security} supports user authentication using SAML Single Sign On.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[controlling-user-cache]]
|
||||
=== Controlling the User Cache
|
||||
=== Controlling the user cache
|
||||
|
||||
User credentials are cached in memory on each node to avoid connecting to a
|
||||
remote authentication service or hitting the disk for every incoming request.
|
||||
|
|
@ -34,7 +35,7 @@ setting the `cache_hash_algo` setting to any of the following:
|
|||
|=======================
|
||||
|
||||
[[cache-eviction-api]]
|
||||
==== Evicting Users from the Cache
|
||||
==== Evicting users from the cache
|
||||
|
||||
{security} exposes a
|
||||
{ref}/security-api-clear-cache.html[Clear Cache API] you can use
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[securing-aliases]]
|
||||
=== Granting Privileges for Indices & Aliases
|
||||
=== Granting privileges for indices and aliases
|
||||
|
||||
Elasticsearch allows to execute operations against {ref}/indices-aliases.html[index aliases],
|
||||
which are effectively virtual indices. An alias points to one or more indices,
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[custom-roles-provider]]
|
||||
=== Custom Roles Provider Extension
|
||||
=== Custom roles provider extension
|
||||
|
||||
If you need to retrieve user roles from a system not supported out-of-the-box
|
||||
by {security}, you can create a custom roles provider to retrieve and resolve
|
||||
|
|
@ -7,7 +8,7 @@ roles. You implement a custom roles provider as an SPI loaded security extension
|
|||
as part of an ordinary elasticsearch plugin.
|
||||
|
||||
[[implementing-custom-roles-provider]]
|
||||
==== Implementing a Custom Roles Provider
|
||||
==== Implementing a custom roles provider
|
||||
|
||||
To create a custom roles provider:
|
||||
|
||||
|
|
@ -62,7 +63,7 @@ part of the `SecurityExtension` interface, it's available as part of the elastic
|
|||
. Bundle all in a single zip file.
|
||||
|
||||
[[using-custom-roles-provider]]
|
||||
==== Using a Custom Roles Provider to Resolve Roles
|
||||
==== Using a custom roles provider to resolve roles
|
||||
|
||||
To use a custom roles provider:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[field-and-document-access-control]]
|
||||
=== Setting Up Field and Document Level Security
|
||||
=== Setting up field and document level security
|
||||
|
||||
You can control access to data within an index by adding field and document level
|
||||
security permissions to a role. Field level security permissions restrict access
|
||||
|
|
@ -23,7 +24,7 @@ document level permissions per index. See <<multiple-roles-dls-fls>>.
|
|||
=====================================================================
|
||||
|
||||
[[field-level-security]]
|
||||
==== Field Level Security
|
||||
==== Field level security
|
||||
|
||||
To enable field level security, specify the fields that each role can access
|
||||
as part of the indices permissions in a role definition. Field level security is
|
||||
|
|
@ -235,7 +236,7 @@ The resulting permission is equal to:
|
|||
|
||||
|
||||
[[document-level-security]]
|
||||
==== Document Level Security
|
||||
==== Document level security
|
||||
|
||||
Document level security restricts the documents that users have read access to.
|
||||
To enable document level security, specify a query that matches all the
|
||||
|
|
@ -292,7 +293,7 @@ For example, the following role grants read access only to the documents whose
|
|||
NOTE: `query` also accepts queries written as string values.
|
||||
|
||||
[[templating-role-query]]
|
||||
===== Templating a Role Query
|
||||
===== Templating a role query
|
||||
|
||||
You can use Mustache templates in a role query to insert the username of the
|
||||
current authenticated user into the role. Like other places in {es} that support
|
||||
|
|
@ -358,7 +359,7 @@ based on the `group.id` field in your documents:
|
|||
--------------------------------------------------
|
||||
|
||||
[[set-security-user-processor]]
|
||||
===== Set Security User Ingest Processor
|
||||
===== Set security user ingest processor
|
||||
|
||||
If an index is shared by many small users it makes sense to put all these users
|
||||
into the same index. Having a dedicated index or shard per user is wasteful.
|
||||
|
|
@ -416,7 +417,7 @@ to the `user` field for all documents that are processed by this pipeline:
|
|||
--------------------------------------------------
|
||||
|
||||
[[multiple-roles-dls-fls]]
|
||||
==== Multiple Roles with Document and Field Level Security
|
||||
==== Multiple roles with document and field level security
|
||||
|
||||
A user can have many roles and each role can define different permissions on the
|
||||
same index. It is important to understand the behavior of document and field
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[mapping-roles]]
|
||||
=== Mapping Users and Groups to Roles
|
||||
=== Mapping users and groups to roles
|
||||
|
||||
If you authenticate users with the `native` or `file` realms, you can manage
|
||||
role assignment by using the <<managing-native-users, User Management APIs>> or
|
||||
|
|
@ -24,13 +25,13 @@ you are able to map users to both API-managed roles and file-managed roles
|
|||
(and likewise for file-based role-mappings).
|
||||
|
||||
[[mapping-roles-api]]
|
||||
==== Using the Role Mapping API
|
||||
==== Using the role mapping API
|
||||
|
||||
You can define role-mappings through the
|
||||
{ref}/security-api-role-mapping.html[role mapping API].
|
||||
|
||||
[[mapping-roles-file]]
|
||||
==== Using Role Mapping Files
|
||||
==== Using role mapping files
|
||||
|
||||
To use file based role-mappings, you must configure the mappings in a YAML file
|
||||
and copy it to each node in the cluster. Tools like Puppet or Chef can help with
|
||||
|
|
@ -56,10 +57,10 @@ You can change this default behavior by changing the
|
|||
this is a common setting in Elasticsearch, changing its value might effect other
|
||||
schedules in the system.
|
||||
|
||||
==== Realm Specific Details
|
||||
==== Realm specific details
|
||||
[float]
|
||||
[[ldap-role-mapping]]
|
||||
===== Active Directory and LDAP Realms
|
||||
===== Active Directory and LDAP realms
|
||||
|
||||
To specify users and groups in the role mappings, you use their
|
||||
_Distinguished Names_ (DNs). A DN is a string that uniquely identifies the user
|
||||
|
|
@ -113,7 +114,7 @@ PUT _xpack/security/role_mapping/basic_users
|
|||
|
||||
[float]
|
||||
[[pki-role-mapping]]
|
||||
===== PKI Realms
|
||||
===== PKI realms
|
||||
|
||||
PKI realms support mapping users to roles, but you cannot map groups as
|
||||
the PKI realm has no notion of a group.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[authorization]]
|
||||
== Configuring Role-based Access Control
|
||||
== Configuring role-based access control
|
||||
|
||||
{security} introduces the concept of _authorization_ to {es}.
|
||||
Authorization is the process of determining whether the user behind an incoming
|
||||
|
|
@ -8,7 +9,7 @@ successfully authenticated and the user behind the request is identified.
|
|||
|
||||
[[roles]]
|
||||
[float]
|
||||
=== Roles, Permissions and Privileges
|
||||
=== Roles, permissions, and privileges
|
||||
|
||||
The authorization process revolves around the following 5 constructs:
|
||||
|
||||
|
|
@ -49,7 +50,7 @@ then assign users to the roles. These can be assigned to users in a number of
|
|||
ways depending on the realms by which the users are authenticated.
|
||||
|
||||
[[built-in-roles]]
|
||||
=== Built-in Roles
|
||||
=== Built-in roles
|
||||
|
||||
{security} applies a default role to all users, including
|
||||
<<anonymous-access, anonymous users>>. The default role enables users to access
|
||||
|
|
@ -164,7 +165,7 @@ stats.
|
|||
|
||||
|
||||
[[defining-roles]]
|
||||
=== Defining Roles
|
||||
=== Defining roles
|
||||
|
||||
A role is defined by the following JSON structure:
|
||||
|
||||
|
|
@ -276,14 +277,14 @@ see <<custom-roles-provider, Custom Roles Provider Extension>>.
|
|||
|
||||
[float]
|
||||
[[roles-management-ui]]
|
||||
=== Role Management UI
|
||||
=== Role management UI
|
||||
|
||||
{security} 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]]
|
||||
=== Role Management API
|
||||
=== Role management API
|
||||
|
||||
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
|
||||
|
|
@ -292,7 +293,7 @@ see {ref}/security-api-roles.html[Role Management APIs].
|
|||
|
||||
[float]
|
||||
[[roles-management-file]]
|
||||
=== File-based Role Management
|
||||
=== File-based role management
|
||||
|
||||
Apart from the _Role Management APIs_, roles can also be defined in local
|
||||
`roles.yml` file located in `CONFIG_DIR`. This is a YAML file where each
|
||||
|
|
@ -338,12 +339,12 @@ click_admins:
|
|||
{security} continuously monitors the `roles.yml` file and automatically picks
|
||||
up and applies any changes to it.
|
||||
|
||||
include::authorization/alias-privileges.asciidoc[]
|
||||
include::alias-privileges.asciidoc[]
|
||||
|
||||
include::authorization/mapping-roles.asciidoc[]
|
||||
include::mapping-roles.asciidoc[]
|
||||
|
||||
include::authorization/field-and-document-access-control.asciidoc[]
|
||||
include::field-and-document-access-control.asciidoc[]
|
||||
|
||||
include::authorization/run-as-privilege.asciidoc[]
|
||||
include::run-as-privilege.asciidoc[]
|
||||
|
||||
include::authorization/custom-roles-provider.asciidoc[]
|
||||
include::custom-roles-provider.asciidoc[]
|
||||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[run-as-privilege]]
|
||||
=== Submitting Requests on Behalf of Other Users
|
||||
=== Submitting requests on behalf of other users
|
||||
|
||||
{security} supports a permission that enables an authenticated user to submit
|
||||
requests on behalf of other users. If your application already authenticates
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[ccs-clients-integrations]]
|
||||
== Cross Cluster Search, Clients and Integrations
|
||||
== Cross cluster search, clients, and integrations
|
||||
|
||||
When using {ref}/modules-cross-cluster-search.html[Cross Cluster Search]
|
||||
you need to take extra steps to secure communications with the connected
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[security-getting-started]]
|
||||
== Getting Started with Security
|
||||
== Getting started with security
|
||||
|
||||
To secure a cluster, you must enable {security} on every node in the
|
||||
cluster. Basic authentication is enabled by default--to communicate
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[how-security-works]]
|
||||
== How Security Works
|
||||
== How security works
|
||||
|
||||
An Elasticsearch cluster is typically made out of many moving parts. There are
|
||||
the Elasticsearch nodes that form the cluster, and often Logstash instances,
|
||||
|
|
@ -64,7 +65,7 @@ For more information on user authentication see <<authorization>>
|
|||
|
||||
|
||||
[float]
|
||||
=== Node/Client Authentication and Channel Encryption
|
||||
=== Node/client authentication and channel encryption
|
||||
|
||||
{security} supports configuring SSL/TLS for securing the communication channels
|
||||
to, from and within the cluster. This support accounts for:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[xpack-security]]
|
||||
= Securing the Elastic Stack
|
||||
= Securing the {stack}
|
||||
|
||||
[partintro]
|
||||
--
|
||||
|
|
@ -100,7 +101,7 @@ include::how-security-works.asciidoc[]
|
|||
|
||||
include::authentication/overview.asciidoc[]
|
||||
|
||||
include::authorization.asciidoc[]
|
||||
include::authorization/overview.asciidoc[]
|
||||
|
||||
include::auditing.asciidoc[]
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[security-limitations]]
|
||||
== Security Limitations
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[security-reference]]
|
||||
== Reference
|
||||
* <<security-privileges, Security Privileges>>
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[encrypting-communications]]
|
||||
== Encrypting Communications
|
||||
== Encrypting communications
|
||||
|
||||
Elasticsearch nodes store data that may be confidential. Attacks on the data may
|
||||
come from the network. These attacks could include sniffing of the data,
|
||||
|
|
@ -21,7 +22,7 @@ include::securing-communications/setting-up-ssl.asciidoc[]
|
|||
//TO-DO: These sections can be removed when all links to them are removed.
|
||||
|
||||
[[ciphers]]
|
||||
=== Enabling Cipher Suites for Stronger Encryption
|
||||
=== Enabling cipher suites for stronger encryption
|
||||
|
||||
See {ref}/ciphers.html[Enabling Cipher Suites for Stronger Encryption].
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
[role="xpack"]
|
||||
[[security-troubleshooting]]
|
||||
== {security} Troubleshooting
|
||||
++++
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[ip-filtering]]
|
||||
== Restricting Connections with IP Filtering
|
||||
== Restricting connections with IP filtering
|
||||
|
||||
You can apply IP filtering to application clients, node clients, or transport
|
||||
clients, in addition to other nodes that are attempting to join the cluster.
|
||||
|
|
@ -92,7 +93,7 @@ transport.profiles.client.xpack.security.filter.deny: _all
|
|||
NOTE: When you do not specify a profile, `default` is used automatically.
|
||||
|
||||
[float]
|
||||
=== HTTP Filtering
|
||||
=== HTTP filtering
|
||||
|
||||
You may want to have different IP filtering for the transport and HTTP protocols.
|
||||
|
||||
|
|
@ -106,7 +107,7 @@ xpack.security.http.filter.deny: _all
|
|||
|
||||
[float]
|
||||
[[dynamic-ip-filtering]]
|
||||
==== Dynamically updating ip filter settings
|
||||
==== Dynamically updating IP filter settings
|
||||
|
||||
In case of running in an environment with highly dynamic IP addresses like cloud
|
||||
based hosting, it is very hard to know the IP addresses upfront when provisioning
|
||||
|
|
|
|||
Loading…
Reference in New Issue