* [DOCS] Steps for updating TLS certificates
* Updates for changing CA
* Updates for rotating certs with a new CA
* Add instructions for generating HTTP certs with a new CA
* Add steps for creating HTTP certs with new CA
* Clarify note about cluser restart and other edits
* Clarifying scenarios
* Apply suggestions from code review
Co-authored-by: Ioannis Kakavas <ikakavas@protonmail.com>
* Incorporating review feedback and making necessary changes
* Clarifications and changes regarding restarts
* Remove errant --pem in basic security setup
* Incorporate suggestions from code review
Co-authored-by: Ioannis Kakavas <ikakavas@protonmail.com>
* Many, many updates. But good ones.
* Add languages for snippets
* Reorder steps to reference rolling restart throughout for consistency
* Add clarifying what's next steps
* Add instructions for updating Kibana certificate
* Apply suggestions from Ioannis' stellar code review
Co-authored-by: Ioannis Kakavas <ikakavas@protonmail.com>
* Update instructions to use a single keystore, plus other review changes
* Incorporating another round of review comments
* Minor updates from reviewer feedback
* Clarifying examples and fixing numbering
* Skip tests that are creating unnecessary noise
* Quieting other tests
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Ioannis Kakavas <ikakavas@protonmail.com>
* [DOCS] Clarify usage of the enroll Kibana API
I had a discussion with @bytebilly about whether users will call the enroll Kibana API on their own, or if it's only intended for internal use. It seems that only Kibana uses this API to verify the enrollment token from Elasticsearch, so I'm adding a note to indicate this usage, along with some explanatory information about when Kibana calls this API.
* Incorporate changes from review feedback
* [DOCS] Clarify API key format for create API key
* Removing unnecessary NOTCONSOLE
* Clarifying information about UTF-8 format
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Changes:
* Adds a tutorial for search templates.
* Adds reference docs for the render search template API.
* Improves parameter documentation for the multi search template API.
* Removes duplicate examples from the search template API, multi search API, and create stored script API docs.
* Splits the source files for the search template API and the multi search template API docs.
* [DOCS] Remove beta label for most service accounts docs
* Remove beta label from additional service account files
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
During implementation we discovered that the clusters should not
necessarily have a unique name and thus we don't need to convey
this information in the response of the Enroll Node API.
Both SAML complete logout and SAML invalidate session APIs use a camelCase
request parameter, queryString, while the convention is to use snake_case
parameters. This PR deprecates queryString and replaces it with query_string.
It is an error to if a request specifies both of them.
* Put all service accounts information on one page
* De-emphasize connection with built-in accounts + edits
* Iterate on the docs: tweak, correction and more details.
* fix test
* Edits and minor text changes
Co-authored-by: Yang Wang <yang.wang@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
You shouldn't use Elasticsearch's anonymous access to provide access to Kibana
without requiring credentials. Instead, you should use Kibana's anonymous
authentication feature. However, the Elasticsearch anonymous access tends to be
more popular in search results.
This adds a brief tip that directs users to Kibana's anonymous authentication
feature.
Closes#73022
Recent JDK releases have disabled TLS v1.0 and TLS v1.1 by default
See
- https://java.com/en/jre-jdk-cryptoroadmap.html
- https://bugs.openjdk.java.net/browse/JDK-8202343
This change adds documentation clarifying which TLS versions are
supported on which JDKs (in general terms, rather than specific builds)
and how to change the configuration if necessary.
Co-authored-by: Adam Locke <adam.locke@elastic.co>
In 7.14+, you can create data stream aliases. This updates the related security documentation. It also streamlines the docs to remove redundant examples.
Add authentication.token.type to audit log. This is to complement the
authentication.token.name field added by #72198. The log is now unambiguous
about exactly where the service token is from. It also helps if we decide to
log additional information for other types of tokens in future.
Relates: #73135, #72198
* [DOCS] Changing event table to a list for easier viewing
* Make audit event types more readable
* Adding system_access_granted user and cross-links
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Multiple service tokens can be created for the same service account. Each token
has a name to uniquely identify itself. This PR ensures the token name is
logged for audit events of authentication_success, authentication_failed (when
applicable), access_granted and access_denied.
* wip
* Service Accounts - add beta documentation
* consistent names
* fix test
* Update service accounts overview and token creation files.
* Rename get service tokens to get service credentials
* fix tests
* Changes for create and get service tokens.
* Changes for get token creds, delete token, clear token cache, and token auth.
* add manage_service_account privilege to list
* List service accounts APIs
* Move xpack setting to Security API page, plus other cleanup.
* Shorten secret tokens in examples, add cross links, plus other cleanup.
* Clarifying parameter descriptions.
* Clarify language for authenticating with a token.
* Tweaks
* Typo fix
* Adding redirects to work around CI build checks
* Revert "Adding redirects to work around CI build checks"
This reverts commit 20a1b53591.
* Remove redirects that were implemented to satisfy CI checks in master branch
* Move note about not supporting basic auth
* Clarify what service accounts are specifically for
* Apply suggestions from code review
Co-authored-by: Tim Vernum <tim@adjective.org>
* Addressing review feedback
* tweak
* Improve doc tests
* fix test
Co-authored-by: Adam Locke <adam.locke@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Tim Vernum <tim@adjective.org>
Enroll node API can be used by new nodes in order to join an
existing cluster that has security features enabled. The response
of a call to this API contains all the necessary information that
the new node requires in order to configure itself and bootstrap
trust with the existing cluster.
* [DOCS] Use same certificate on every node
* Incorporate review feedback
Co-authored-by: Tim Vernum <tim@adjective.org>
Co-authored-by: Tim Vernum <tim@adjective.org>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* [DOC] Clarify usage of elastic user for Kibana
* Change URL to http
Co-authored-by: Yang Wang <ywangd@gmail.com>
* Clarify use of the kibana_system user
Co-authored-by: Yang Wang <ywangd@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
The `kibana_system` user is specifically intended for use within
Kibana, and has access to all the privileges that are needed or useful
to Kibana. We should advise admins to use that user (rather than
`elastic`) when they set up Kibana for the first time.
Recommending `elastic` puts this at odds with the Kibana setup docs,
and increases the security risk for customers, yet provides no
substantial benefit (other than having a single password to deal with).
* [DOCS] Add stronger and clearer language about single-node security
* Clarifying admonition about minimal security being insufficient for production.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR makes sure that the file and native realms are always added to the
beginning of the realm chain unless explicitly disabled.
Currently, they are only impliciltly added when:
* No other realms are configured
* No configured realms can be used with current license (so an expired license
can fallback to these basic realms)
A side effect (intended?) is that file and native realm cannot be truely
disabled at all time because the above two rules always apply regardless
whether the realms are disabled or not.
This PR makes the behaviour more explicit. If the file or native realm is
explicitly disabled, it will be disabled at all time. If they are not
explicitly disabled, they will always be added to the beginning of the realm
chain. Two scenarios are possible:
* File or native realm is explicitly configured. In this case, their order
value must be provided and honoured
* File or native realm is not configured. In this case, they are implicitly
added to the beginning of the realm chain (file then native).
This PR implements rest of the pieces needed for Fleet integration, including:
* Get service account role descriptor for authorization
* API for creating service account token and storing in the security index
* API for list tokens for a service account
* New named privilege for manage service account
* Mandate HTTP TLS for both service account auth and service account related
APIs
* Tests for API key related operations using service account
This PR adds metadata support for API keys. Metadata are of type
Map<String, Object> and can be optionally provided at API key creation time.
It is returned as part of GetApiKey response. It is also stored as part of
the authentication object to transfer throw the wire.
Note that it is not yet searchable and not exposed to any ingest processors.
They will be handled by separate PRs.
Adam Locke
Alexander Reelsen
Yang Wang
James Rodewig
Ioannis Kakavas
DeDe Morton
Lisa Cawley
Tim Vernum
Fabio Busatto
Brandon Morelli
Julie Tibshirani