Commit Graph

34 Commits

Author SHA1 Message Date
István Zoltán Szabó ecd62934f6 [DOCS] Applies rename of transform related roles and privileges (#48123) 2019-10-17 10:24:56 +02:00
Michael Basnight 74812f78dd Add enrich_user to security docs (#48079) 2019-10-16 12:55:19 -05:00
Ioannis Kakavas 2b1372adfd
File based role mappings vs the role mapping APIs (#47015) (#47978)
Make clear in the docs that the role mapping APIs is the preferred
way to manage role mappings and that the role mappings that are
defined in files cannot be viewed or managed with the APIs
2019-10-14 17:55:46 +03:00
Yogesh Gaikwad 1139cce9a3
[DOCS] Add docs for `create_doc` index privilege (#47584) (#47778)
This commit adds documentation for new index privilege
create_doc which only allows indexing of new documents
but no updates to existing documents via Index or Bulk APIs.

Relates: #45806
2019-10-09 21:22:36 +11:00
Lisa Cawley f35fcf7204
[DOCS] Adds security content in the Elasticsearch Reference (#47596) 2019-10-04 13:11:05 -07:00
Lisa Cawley 9b3e5409c1
[7.x][DOCS] Copies security source files from stack-docs (#47534) 2019-10-04 08:19:10 -07:00
Ioannis Kakavas f785c31531
File based role definition documentation additions (#46304) (#47085)
This commit clarifies and points out that the Role management UI and
the Role management API cannot be used to manage roles that are
defined in roles.yml and that file based role management is
intended to have a small administrative scope and not handle all
possible RBAC use cases.
2019-09-25 13:52:05 +03:00
James Rodewig e253ee6ba6
[DOCS] Change // CONSOLE comments to [source,console] (#46440) (#46494) 2019-09-09 12:35:50 -04:00
Albert Zaharovits 1ebee5bf9b
PKI realm authentication delegation (#45906)
This commit introduces PKI realm delegation. This feature
supports the PKI authentication feature in Kibana.

In essence, this creates a new API endpoint which Kibana must
call to authenticate clients that use certificates in their TLS
connection to Kibana. The API call passes to Elasticsearch the client's
certificate chain. The response contains an access token to be further
used to authenticate as the client. The client's certificates are validated
by the PKI realms that have been explicitly configured to permit
certificates from the proxy (Kibana). The user calling the delegation
API must have the delegate_pki privilege.

Closes #34396
2019-08-27 14:42:46 +03:00
Mayya Sharipova 22ab389531 Clarify that FLS/DLS disable shard request cache (#45462) 2019-08-13 09:05:57 -04:00
Yogesh Gaikwad 280567da8d
Correct documentation link for authorization engine example (#40261) (#40292)
This commit fixes the link for authorization engine example.
2019-03-22 12:38:03 +11:00
Mark Vovchuk a054a9866e Update managing-roles.asciidoc 2019-03-19 08:21:29 -07:00
Jay Modi 7ca5495d86
Allow custom authorization with an authorization engine (#38358)
For some users, the built in authorization mechanism does not fit their
needs and no feature that we offer would allow them to control the
authorization process to meet their needs. In order to support this,
a concept of an AuthorizationEngine is being introduced, which can be
provided using the security extension mechanism.

An AuthorizationEngine is responsible for making the authorization
decisions about a request. The engine is responsible for knowing how to
authorize and can be backed by whatever mechanism a user wants. The
default mechanism is one backed by roles to provide the authorization
decisions. The AuthorizationEngine will be called by the
AuthorizationService, which handles more of the internal workings that
apply in general to authorization within Elasticsearch.

In order to support external authorization services that would back an
authorization engine, the entire authorization process has become
asynchronous, which also includes all calls to the AuthorizationEngine.

The use of roles also leaked out of the AuthorizationService in our
existing code that is not specifically related to roles so this also
needed to be addressed. RequestInterceptor instances sometimes used a
role to ensure a user was not attempting to escalate their privileges.
Addressing this leakage of roles meant that the RequestInterceptor
execution needed to move within the AuthorizationService and that
AuthorizationEngines needed to support detection of whether a user has
more privileges on a name than another. The second area where roles
leaked to the user is in the handling of a few privilege APIs that
could be used to retrieve the user's privileges or ask if a user has
privileges to perform an action. To remove the leakage of roles from
these actions, the AuthorizationService and AuthorizationEngine gained
methods that enabled an AuthorizationEngine to return the response for
these APIs.

Ultimately this feature is the work included in:
#37785
#37495
#37328
#36245
#38137
#38219

Closes #32435
2019-02-05 13:39:29 -07:00
Christoph Büscher 34f2d2ec91
Remove remaining occurances of "include_type_name=true" in docs (#37646) 2019-01-22 15:13:52 +01:00
Julie Tibshirani 36a3b84fc9
Update the default for include_type_name to false. (#37285)
* Default include_type_name to false for get and put mappings.

* Default include_type_name to false for get field mappings.

* Add a constant for the default include_type_name value.

* Default include_type_name to false for get and put index templates.

* Default include_type_name to false for create index.

* Update create index calls in REST documentation to use include_type_name=true.

* Some minor clean-ups around the get index API.

* In REST tests, use include_type_name=true by default for index creation.

* Make sure to use 'expression == false'.

* Clarify the different IndexTemplateMetaData toXContent methods.

* Fix FullClusterRestartIT#testSnapshotRestore.

* Fix the ml_anomalies_default_mappings test.

* Fix GetFieldMappingsResponseTests and GetIndexTemplateResponseTests.

We make sure to specify include_type_name=true during xContent parsing,
so we continue to test the legacy typed responses. XContent generation
for the typeless responses is currently only covered by REST tests,
but we will be adding unit test coverage for these as we implement
each typeless API in the Java HLRC.

This commit also refactors GetMappingsResponse to follow the same appraoch
as the other mappings-related responses, where we read include_type_name
out of the xContent params, instead of creating a second toXContent method.
This gives better consistency in the response parsing code.

* Fix more REST tests.

* Improve some wording in the create index documentation.

* Add a note about types removal in the create index docs.

* Fix SmokeTestMonitoringWithSecurityIT#testHTTPExporterWithSSL.

* Make sure to mention include_type_name in the REST docs for affected APIs.

* Make sure to use 'expression == false' in FullClusterRestartIT.

* Mention include_type_name in the REST templates docs.
2019-01-14 13:08:01 -08:00
Lisa Cawley 4140b9eede
[DOCS] Update X-Pack terminology in security docs (#36564) 2018-12-19 14:53:37 -08:00
Ioannis Kakavas d7c5d8049a
Deprecate /_xpack/security/* in favor of /_security/* (#36293)
* This commit is part of our plan to deprecate and ultimately remove the use of _xpack in the REST APIs.

- REST API docs
- HLRC docs and doc tests
- Handle REST actions with deprecation warnings
- Changed endpoints in rest-api-spec and relevant file names
2018-12-11 11:13:10 +02:00
Jake Landis c2766b65cf
ingest: raise visibility of ingest plugin documentation (#35048)
* move the set security user processor to the main documentation
* link to plugin processors

part of #33188
2018-11-05 11:44:10 -06:00
Tim Vernum 273c82d7c9
Add support for "authorization_realms" (#33262)
Authorization Realms allow an authenticating realm to delegate the task
of constructing a User object (with name, roles, etc) to one or more
other realms.

E.g. A client could authenticate using PKI, but then delegate to an LDAP
realm. The LDAP realm performs a "lookup" by principal, and then does
regular role-mapping from the discovered user.

This commit includes:
- authorization_realm support in the pki, ldap, saml & kerberos realms
- docs for authorization_realms
- checks that there are no "authorization chains"
   (whereby "realm-a" delegates to "realm-b", but "realm-b" delegates to "realm-c")

Authorization realms is a platinum feature.
2018-08-31 13:25:27 +10:00
Tim Vernum a211d24bda [DOCS] Add docs for Application Privileges (#32635) 2018-08-23 18:04:02 -07:00
Lisa Cawley 2feda8aae0
[DOC] Splits role mapping APIs into separate pages (#32797) 2018-08-20 14:30:42 -07:00
lcawl 1efee66d16 [DOCS] Creates redirects for role management APIs page 2018-08-17 21:55:18 -07:00
lcawl 967b1785fa [DOCS] Fixes more broken links to role management APIs 2018-08-17 10:41:06 -07:00
lcawl a608205510 [DOCS] Fixes links to role management APIs 2018-08-17 10:22:06 -07:00
Lisa Cawley 101d675f90
[DOCS] Replace CONFIG_DIR with ES_PATH_CONF (#31635) 2018-06-28 08:27:04 -07:00
Lisa Cawley bd06563e78
[DOCS] Creates field and document level security overview (#30937) 2018-06-21 10:08:50 -07:00
Lisa Cawley 840a3bd5a6
[DOCS] Fixes security example (#31082) 2018-06-05 08:50:06 -07:00
lcawl 024400bcb8 [DOCS] Removes redundant authorization pages 2018-06-04 12:02:50 -07:00
Lisa Cawley ab047ca28d
[DOCS] Fix more edit URLs in Stack Overview (#30704) 2018-05-23 09:37:55 -07:00
lcawl 4f41018753 [DOCS] Reorganizes RBAC documentation 2018-05-16 12:22:52 -07:00
lcawl 7f47ff9fcd [DOCS] Fixes title capitalization in security content 2018-05-14 15:36:03 -07:00
Lisa Cawley 7928270610
[DOCS] Fix realm setting names (#30499) 2018-05-14 13:13:26 -07:00
Lisa Cawley fa45c6c9a6
[DOCS] Fix path info for various security files (#30502) 2018-05-14 13:07:27 -07:00
Ryan Ernst 2efd22454a Migrate x-pack-elasticsearch source to elasticsearch 2018-04-20 15:29:54 -07:00