* [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>
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>
* [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>
* Removing security overview and condensing.
* Adding new security file.
* Minor changes.
* Removing link to pass build.
* Adding minimal security page.
* Adding minimal security page.
* Changes to intro.
* Add basic and basic + http configurations.
* Lots of changes, removed files, and redirects.
* Moving some AD and LDAP sections, plus more redirects.
* Redirects for SAML.
* Updating snippet languages and redirects.
* Adding another SAML redirect.
* Hopefully fixing the ci/2 error.
* Fixing another broken link for SAML.
* Adding what's next sections and some cleanup.
* Removes both security tutorials from the TOC.
* Adding redirect for removed tutorial.
* Add graphic for Elastic Security layers.
* Incorporating reviewer feedback.
* Update x-pack/docs/en/security/securing-communications/security-basic-setup.asciidoc
Co-authored-by: Ioannis Kakavas <ikakavas@protonmail.com>
* Update x-pack/docs/en/security/securing-communications/security-minimal-setup.asciidoc
Co-authored-by: Yang Wang <ywangd@gmail.com>
* Update x-pack/docs/en/security/securing-communications/security-basic-setup.asciidoc
Co-authored-by: Yang Wang <ywangd@gmail.com>
* Update x-pack/docs/en/security/index.asciidoc
Co-authored-by: Ioannis Kakavas <ikakavas@protonmail.com>
* Update x-pack/docs/en/security/securing-communications/security-basic-setup-https.asciidoc
Co-authored-by: Ioannis Kakavas <ikakavas@protonmail.com>
* Apply suggestions from code review
Co-authored-by: Ioannis Kakavas <ikakavas@protonmail.com>
Co-authored-by: Yang Wang <ywangd@gmail.com>
* Additional changes from review feedback.
* Incorporating reviewer feedback.
* Incorporating more reviewer feedback.
* Clarify that TLS is for authenticating nodes
Co-authored-by: Tim Vernum <tim@adjective.org>
* Clarify security between nodes
Co-authored-by: Tim Vernum <tim@adjective.org>
* Clarify that TLS is between nodes
Co-authored-by: Tim Vernum <tim@adjective.org>
* Update title for configuring Kibana with a password
Co-authored-by: Tim Vernum <tim@adjective.org>
* Move section for enabling passwords between Kibana and ES to minimal security.
* Add section for transport description, plus incorporate more reviewer feedback.
* Moving operator privileges lower in the navigation.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Ioannis Kakavas <ikakavas@protonmail.com>
Co-authored-by: Yang Wang <ywangd@gmail.com>
Co-authored-by: Tim Vernum <tim@adjective.org>
Today's network config docs are split into "Network", "HTTP" and
"Transport" pages, with unclear relationships between them. We often
encounter users with weird configs that indicate they don't really
understand how these settings all relate. In fact these pages are all
very interrelated, and the HTTP and Transport pages are almost all only
for advanced users. This commit brings these docs into a single page and
rewords some things to try and guide users away from the advanced
settings unless their configuration needs all the extra complexity.
It also adds a section entitled "Binding and publishing" which clarifies
the meanings of the `bind_host` and `publish_host` parameters. This is
also a common source of confusion amongst users.
It also clarifies that many of these settings accept a list of
addresses, and warns that this may not be what you want. Closes#67956.
Co-authored-by: Adam Locke <adam.locke@elastic.co>
Generating certificates with the cert sub-command now requires either: 1) a CA
to be provided with --ca or --ca-cert/--ca-key; or 2) make them self-signed
with the --self-signed option. Generating a CA on the fly is no longer
supported. The --keep-ca-key option is removed and the tool throws an error
saying the CA needs to be generated separately if the option is specified.
This is a follow-up PR for #61884, which deprecated the "ca-on-the-fly" usage.
* deprecate the kibana reserved user; introduce kibana_system user
* fix license and test errors
* fix IdentityProviderAuthenticationIT tests
* test deprecation logging
* First pass at SetupPasswordTool updates
* fix checkstyle
* update docs
* update number of expected users
* update test to expect deprecation header
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes#45223.
The current Docker entrypoint script picks up environment variables and
translates them into -E command line arguments. However, since any tool
executes via `docker exec` doesn't run the entrypoint, it results in
a poorer user experience.
Therefore, refactor the env var handling so that the -E options are
generated in `elasticsearch-env`. These have to be appended to any
existing command arguments, since some CLI tools have subcommands and
-E arguments must come after the subcommand.
Also extract the support for `_FILE` env vars into a separate script, so
that it can be called from more than once place (the behaviour is
idempotent).
Finally, add noop -E handling to CronEvalTool for parity, and support
`-E` in MultiCommand before subcommands.
Remove references to the `platinum` image and add a self-generated trial
licence to the example for TLS on Docker.
Fixeselastic/elasticsearch-docker#176
Although elasticsearch-certutil generates PKCS#12
files which are usable as both keystore and truststore
this is uncommon in practice. Settle these expectations
for the users following our security guides.
Adam Locke
DeDe Morton
Tim Vernum
James Rodewig
David Turner
Yang Wang
Lisa Cawley
Brandon Morelli
Larry Gregory
Rory Hunter
Alex Pang
Ioannis Kakavas
Toby McLaughlin
Albert Zaharovits
Jason Tedor