From a4472c70c562358a526ca1b027020d29d335cab1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 26 Mar 2025 09:00:06 +0100 Subject: [PATCH 01/42] merging shaina's PR with my WIP changes --- deploy-manage/security.md | 18 +++ ...figure-security-in-self-managed-cluster.md | 46 ------- .../security/secure-http-communications.md | 121 +---------------- .../secure-your-cluster-deployment.md | 126 ++++++++++++++++++ .../security/security-certificates-keys.md | 5 +- .../set-up-basic-security-plus-https.md | 5 +- .../security/set-up-basic-security.md | 5 +- .../security/set-up-minimal-security.md | 11 +- .../security/using-kibana-with-security.md | 6 +- deploy-manage/toc.yml | 25 ++-- 10 files changed, 178 insertions(+), 190 deletions(-) diff --git a/deploy-manage/security.md b/deploy-manage/security.md index 6f1bf34209..59b63c486c 100644 --- a/deploy-manage/security.md +++ b/deploy-manage/security.md @@ -25,6 +25,24 @@ The availability and configurability of security features vary by deployment typ :::{include} /deploy-manage/security/_snippets/complete-security.md ::: +## Security principles (from manual config orig page) + +### Run {{es}} with security enabled [security-run-with-security] + +Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. [Start the {{stack}} with security enabled](/deploy-manage/security/security-certificates-keys.md) or [manually configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md) to prevent unauthorized access to your clusters and ensure that internode communication is secure. + +### Run {{es}} with a dedicated non-root user [security-not-root-user] + +Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. + +### Protect {{es}} from public internet traffic [security-protect-cluster-traffic] + +Even with security enabled, never expose {{es}} to public internet traffic. Using an application to sanitize requests to {{es}} still poses risks, such as a malicious user writing [`_search`](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-search) requests that could overwhelm an {{es}} cluster and bring it down. Keep {{es}} as isolated as possible, preferably behind a firewall and a VPN. Any internet-facing applications should run pre-canned aggregations, or not run aggregations at all. + +### Implement role based access control [security-create-appropriate-users] + +[Define roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request. + ## Managed security in Elastic Cloud ```yaml {applies_to} deployment: diff --git a/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md b/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md index a79552ddc3..8564422c2b 100644 --- a/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md +++ b/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md @@ -68,49 +68,3 @@ If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. [Set up basic security plus HTTPS traffic](secure-http-communications.md) - - -## Cases when security auto configuration is skipped [stack-skip-auto-configuration] - -When you start {{es}} for the first time, the node startup process tries to automatically configure security for you. The process runs some checks to determine: - -* If this is the first time that the node is starting -* Whether security is already configured -* If the startup process can modify the node configuration - -If any of those checks fail, there’s a good indication that you manually configured security, or don’t want security to be configured automatically. In these cases, the node starts normally using the existing configuration. - -::::{important} -If you redirect {{es}} output to a file, security autoconfiguration is skipped. Autoconfigured credentials can only be viewed on the terminal the first time you start {{es}}. If you need to redirect output to a file, start {{es}} without redirection the first time and use redirection on all subsequent starts. -:::: - - - -### Existing environment detected [stack-existing-environment-detected] - -If certain directories already exist, there’s a strong indication that the node was started previously. Similarly, if certain files *don’t* exist, or we can’t read or write to specific files or directories, then we’re likely not running as the user who installed {{es}} or an administrator imposed restrictions. If any of the following environment checks are true, security isn’t configured automatically. - -The {{es}} `/data` directory exists and isn’t empty -: The existence of this directory is a strong indicator that the node was started previously, and might already be part of a cluster. - -The `elasticsearch.yml` file doesn’t exist (or isn’t readable), or the `elasticsearch.keystore` isn’t readable -: If either of these files aren’t readable, we can’t determine whether {{es}} security features are already enabled. This state can also indicate that the node startup process isn’t running as a user with sufficient privileges to modify the node configuration. - -The {{es}} configuration directory isn’t writable -: This state likely indicates that an administrator made this directory read-only, or that the user who is starting {{es}} is not the user that installed {{es}}. - - -### Existing settings detected [stack-existing-settings-detected] - -The following settings are incompatible with security auto configuration. If any of these settings exist, the node startup process skips configuring security automatically and the node starts normally. - -* [`node.roles`](elasticsearch://reference/elasticsearch/configuration-reference/node-settings.md#node-roles) is set to a value where the node can’t be elected as `master`, or if the node can’t hold data -* [`xpack.security.autoconfiguration.enabled`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#general-security-settings) is set to `false` -* [`xpack.security.enabled`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#general-security-settings) has a value set -* Any of the [`xpack.security.transport.ssl.*`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings) or [`xpack.security.http.ssl.*`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#http-tls-ssl-settings) settings have a value set in the `elasticsearch.yml` configuration file or in the `elasticsearch.keystore` -* Any of the `discovery.type`, `discovery.seed_hosts`, or `cluster.initial_master_nodes` [discovery and cluster formation settings](elasticsearch://reference/elasticsearch/configuration-reference/discovery-cluster-formation-settings.md) have a value set - - ::::{note} - Exceptions are when `discovery.type` is set to `single-node`, or when `cluster.initial_master_nodes` exists but contains only the name of the current node. - - :::: diff --git a/deploy-manage/security/secure-http-communications.md b/deploy-manage/security/secure-http-communications.md index 5787ae2701..4b390a037d 100644 --- a/deploy-manage/security/secure-http-communications.md +++ b/deploy-manage/security/secure-http-communications.md @@ -60,126 +60,7 @@ Complete all steps in: - [Set up basic security](/deploy-manage/security/set-up-basic-security.md) - [](/deploy-manage/security/set-up-basic-security-plus-https.md) -### Mutual TLS between {{kib}} and {{es}} [elasticsearch-mutual-tls] - -Secure Sockets Layer (SSL) and Transport Layer Security (TLS) provide encryption for data-in-transit. While these terms are often used interchangeably, {{kib}} supports only TLS, which supersedes the old SSL protocols. - -TLS requires X.509 certificates to authenticate the communicating parties and perform encryption of data-in-transit. Each certificate contains a public key and has and an associated — but separate — private key; these keys are used for cryptographic operations. {{kib}} supports certificates and private keys in PEM or PKCS#12 format. - -In a standard TLS configuration, the server presents a signed certificate to authenticate itself to the client. In a mutual TLS configuration, the client also presents a signed certificate to authenticate itself to the server. - -{{es}} {{security-features}} are enabled on your cluster by default, so each request that {{kib}} (the client) makes to {{es}} (the server) is authenticated. Most requests made by end users through {{kib}} to {{es}} are authenticated by using the credentials of the logged-in user. - -To [enroll {{kib}} with an {{es}} cluster](/deploy-manage/security/security-certificates-keys.md#stack-start-with-security), you pass a generated enrollment token. This token configures {{kib}} to authenticate with {{es}} using a [service account token](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#service-accounts-tokens). {{kib}} also supports mutual TLS authentication with {{es}} via a [Public Key Infrastructure (PKI) realm](/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md). With this setup, {{es}} needs to verify the signature on the {{kib}} client certificate, and it also needs to map the client certificate’s distinguished name (DN) to the appropriate `kibana_system` role. - -::::{note} -Using a PKI realm is a [subscription feature](https://www.elastic.co/subscriptions). -:::: - -#### Configure {{kib}} and {{es}} to use mutual TLS authentication [_configure_kib_and_es_to_use_mutual_tls_authentication] - -If you haven’t already, start {{kib}} and connect it to {{es}} using the [enrollment token](/deploy-manage/security/security-certificates-keys.md#stack-start-with-security). - -1. Obtain a client certificate and private key for {{kib}}. - - {{kib}} uses the client certificate and corresponding private key when connecting to {{es}}. - - ::::{note} - This is not the same as the server certificate that {{kib}} will present to web browsers. - :::: - - - You may choose to generate a client certificate and private key using the [`elasticsearch-certutil`](elasticsearch://reference/elasticsearch/command-line-tools/certutil.md) tool. If you followed the {{es}} documentation for [generating the certificates authority](/deploy-manage/security/set-up-basic-security.md#generate-certificates), then you already have a certificate authority (CA) to sign the {{es}} server certificate. You may choose to use the same CA to sign the {{kib}} client certificate. For example: - - ```sh - bin/elasticsearch-certutil cert -ca elastic-stack-ca.p12 -name kibana-client -dns - ``` - - This will generate a client certificate and private key in a PKCS#12 file named `kibana-client.p12`. In this example, the client certificate has a Common Name (CN) of `"kibana-client"` and a subject alternative name (SAN) of `""`. The SAN may be required if you have hostname verification enabled on {{es}}. - -2. Obtain the certificate authority (CA) certificate chain for {{kib}}. - - {{es}} needs the appropriate CA certificate chain to properly establish trust when receiving connections from {{kib}}. - - If you followed the instructions to generate a client certificate, then you will have a PKCS#12 file for {{kib}}. You can extract the CA certificate chain from this file. For example: - - ```sh - openssl pkcs12 -in kibana-client.p12 -cacerts -nokeys -out kibana-ca.crt - ``` - - This will produce a PEM-formatted file named `kibana-ca.crt` that contains the CA certificate from the PKCS#12 file. - -3. Configure {{es}} with a PKI realm and a native realm. - - By default, {{es}} provides a native realm for authenticating with a username and password. However, to support both a PKI realm (for {{kib}}) and a native realm (for end users), you must configure each realm in `elasticsearch.yml`: - - ```yaml - xpack.security.authc.realms.pki.realm1.order: 1 - xpack.security.authc.realms.pki.realm1.certificate_authorities: "/path/to/kibana-ca.crt" - xpack.security.authc.realms.native.realm2.order: 2 - ``` - -4. Configure {{es}} to request client certificates. - - By default, {{es}} will not request a client certificate when establishing a TLS connection. To change this, you must set up optional client certificate authentication in `elasticsearch.yml`: - - ```yaml - xpack.security.http.ssl.client_authentication: "optional" - ``` - -5. Restart {{es}}. -6. Use {{kib}} to create a role mapping in {{es}} for the client certificate. - - This role mapping will assign the `kibana_system` role to any user that matches the included mapping rule, which is set to equal the client certificate’s DN attribute: - - ![Role mapping for the {{kib}} client certificate](/deploy-manage/images/kibana-mutual-tls-role-mapping.png "") - - For more information, see [](/deploy-manage/users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md). - -7. Configure {{kib}} to use the client certificate and private key. - - You need to specify the information required to access your client certificate and corresponding private key. - - 1. If your certificate and private key are contained in a PKCS#12 file: - - Specify your PKCS#12 file in `kibana.yml`: - - ```yaml - elasticsearch.ssl.keystore.path: "/path/to/kibana-client.p12" - ``` - - If your PKCS#12 file is encrypted, add the decryption password to your [{{kib}} keystore](secure-settings.md): - - ```yaml - bin/kibana-keystore add elasticsearch.ssl.keystore.password - ``` - - ::::{tip} - If your PKCS#12 file isn’t protected with a password, depending on how it was generated, you may need to set `elasticsearch.ssl.keystore.password` to an empty string. - :::: - - 2. Otherwise, if your certificate and private key are in PEM format: - - Specify your certificate and private key in `kibana.yml`: - - ```yaml - elasticsearch.ssl.certificate: "/path/to/kibana-client.crt" - elasticsearch.ssl.key: "/path/to/kibana-client.key" - ``` - - If your private key is encrypted, add the decryption password to your [{{kib}} keystore](secure-settings.md): - - ```yaml - bin/kibana-keystore add elasticsearch.ssl.keyPassphrase - ``` - -8. Configure {{kib}} *not* to use a username and password for {{es}}. - - You must remove the `elasticsearch.username` and `elasticsearch.password` settings from `kibana.yml`. If these are present, {{kib}} will attempt to use them to authenticate to {{es}} via the native realm. - -9. Restart {{kib}}. - -These steps enable {{kib}} to authenticate to {{es}} using a certificate. However, end users will only be able to authenticate to {{kib}} with a username and password. To allow end users to authenticate to {{kib}} using a client certificate, see [{{kib}} PKI authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md#pki-authentication). +### Mutual TLS removed ## Securing client applications diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index 13926288d2..f7379b464f 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -5,13 +5,139 @@ applies_to: eck: all ece: all ess: all +mapped_pages: + - https://www.elastic.co/guide/en/elasticsearch/reference/current/manually-configure-security.html --- # Secure your cluster or deployment It's important to protect your {{es}} cluster and the data it contains. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. +From shaina include: + :::{include} /deploy-manage/security/_snippets/complete-security.md + +$$$install-stack-demo-secure-ca$$$ + +$$$install-stack-demo-secure-fleet$$$ + +$$$install-stack-demo-secure-http$$$ + +$$$install-stack-demo-secure-kib-es$$$ + +$$$install-stack-demo-secure-prereqs$$$ + +$$$install-stack-demo-secure-second-node$$$ + +$$$install-stack-demo-secure-transport$$$ + +$$$install-stack-demo-secure-view-data$$$ + +$$$security-configure-settings$$$ + + +Protecting your {{es}} cluster and the data it contains is of utmost importance. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. + +:::{important} +Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. +::: + +To secure your clusters and deployments, consider the following: + +## Security activation and requirements + +Not needed in orchestrated deployments. +Automatically or manually, links + +minimam / basic / HTTPS + +single nodes and multiple-nodes. +What is required, what is optional. Single-node vs multi-node +Consider Kibana HTTPS + +Security gives access to users and roles and certificates, links + +copying here the original content that we will probably discard! + +:::{note} +This page describes important aspects to consider and common end-to-end scenarios for securing your self-managed {{stack}}. For a more granular view of the available security options for your clusters and nodes, refer to [](secure-your-cluster-deployment.md). +::: + +Security needs vary depending on whether you’re developing locally on your laptop or securing all communications in a production environment. Regardless of where you’re deploying the {{stack}} ("ELK"), running a secure cluster is incredibly important to protect your data. That’s why security is [enabled and configured by default](../deploy/self-managed/installing-elasticsearch.md) since {{es}} 8.0. + +## Common security scenarios + +:::{image} /deploy-manage/images/elasticsearch-reference-elastic-security-overview.png +:alt: Elastic Security layers +::: + +### Minimal security ({{es}} Development) [security-minimal-overview] + +::::{important} +The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. +:::: + +If you’ve been working with {{es}} and want to enable security on your existing, unsecured cluster, start here. You’ll set passwords for the built-in users to prevent unauthorized access to your local cluster, and also configure password authentication for {{kib}}. + +[Set up minimal security](set-up-minimal-security.md) + +### Basic security ({{es}} + {{kib}}) [security-basic-overview] + +This scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your {{es}} cluster. + +Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but internode communication will be secured. + +[Set up basic security](secure-cluster-communications.md) + +### Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview] + +This scenario builds on the one for basic security and secures all HTTP traffic with TLS. In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. + +::::{note} +If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption. +:::: + +You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. + +[Set up basic security plus HTTPS traffic](secure-http-communications.md) + + + + + +## Network access + +Control which systems can access your Elastic deployments and clusters through traffic filtering and network controls: + +- **IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges. +- **Private link filters**: Secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. +- **Static IPs**: Use static IP addresses for predictable firewall rules. +- **Remote cluster access**: Secure cross-cluster operations. + +Refer to [](traffic-filtering.md). + + +## Cluster communication + +- **HTTP and HTTPs** +- **TLS certificates and keys** + + +## Data, objects and settings security + +- **Bring your own encryption key**: Use your own encryption key instead of the default encryption at rest provided by Elastic. +- **{{es}} and {{kib}} keystores**: Secure sensitive settings using keystores +- **{{kib}} saved objects**: Customize the encryption for {{kib}} objects such as dashboards. +- **{{kib}} session management**: Customize {{kib}} session expiration settings. + +Refer to [](data-security.md). + +## User roles + +[Define roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request. + +:::{important} +Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. ::: :::{important} diff --git a/deploy-manage/security/security-certificates-keys.md b/deploy-manage/security/security-certificates-keys.md index d4dbae761d..771954ae42 100644 --- a/deploy-manage/security/security-certificates-keys.md +++ b/deploy-manage/security/security-certificates-keys.md @@ -1,10 +1,13 @@ --- +navigation_title: Automatic security setup applies_to: self: ga mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-stack-security.html --- +% Scope: Automatic setup +% Original title: Start the Elastic Stack with security enabled automatically # Self-managed certificates and keys [configuring-stack-security] When you start {{es}} for the first time, the following security configuration occurs automatically: @@ -240,5 +243,3 @@ The following settings are incompatible with security auto configuration. If any Exceptions are when `discovery.type` is set to `single-node`, or when `cluster.initial_master_nodes` exists but contains only the name of the current node. :::: - - diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 259c1fc75d..e934ef2e6d 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -1,5 +1,5 @@ --- -navigation_title: "Set up basic security plus HTTPS" +navigation_title: "Basic / HTTP SSL" applies_to: deployment: self: ga @@ -8,7 +8,8 @@ mapped_pages: --- - +% Scope: HTTP certificates setup / manual configuration / multi or single node cluster +% original title: Set up basic security for the Elastic Stack plus secured HTTPS traffic # Set up basic security plus HTTPS [security-basic-setup-https] diff --git a/deploy-manage/security/set-up-basic-security.md b/deploy-manage/security/set-up-basic-security.md index 53ed3b8424..6eaa465233 100644 --- a/deploy-manage/security/set-up-basic-security.md +++ b/deploy-manage/security/set-up-basic-security.md @@ -1,5 +1,5 @@ --- -navigation_title: "Set up basic security" +navigation_title: "Basic / Transport SSL" applies_to: deployment: self: ga @@ -8,7 +8,8 @@ mapped_pages: --- - +% Scope: TLS certificates setup / multi-node cluster / manual configuration +% original title: Set up basic security for the Elastic Stack # Set up basic security [security-basic-setup] diff --git a/deploy-manage/security/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index 856bebdb1e..bdcf4ff42d 100644 --- a/deploy-manage/security/set-up-minimal-security.md +++ b/deploy-manage/security/set-up-minimal-security.md @@ -1,5 +1,5 @@ --- -navigation_title: "Set up minimal security" +navigation_title: "Secure an unsecured cluster" applies_to: deployment: self: ga @@ -7,16 +7,15 @@ mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-minimal-setup.html --- - - +% alternative title: Manual security setup +% Scope: Just enabling security, resetting passwords, and configuring kibana. Manual approach, opposite to automatic security configuration +% Original title: Set up minimal security # Set up minimal security [security-minimal-setup] - ::::{important} You only need to complete the following steps if you’re running an existing, unsecured cluster and want to enable the {{es}} {{security-features}}. :::: - In {{es}} 8.0 and later, security is [enabled automatically](../deploy/self-managed/installing-elasticsearch.md) when you start {{es}} for the first time. If you’re running an existing {{es}} cluster where security is disabled, you can manually enable the {{es}} {{security-features}} and then create passwords for built-in users. You can add more users later, but using the built-in users simplifies the process of enabling security for your cluster. @@ -138,4 +137,6 @@ If your cluster has multiple nodes, then you must configure Transport Layer Secu [Set up basic security for the {{stack}}](secure-cluster-communications.md) to secure all internal communication between nodes in your cluster. +TBD -> Previous link should point to TRANSPORT SSL (basic) + diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index 58c2b5d3ab..582238d7f5 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -6,8 +6,10 @@ mapped_urls: - https://www.elastic.co/guide/en/kibana/current/using-kibana-with-security.html --- -$$$kibana-roles$$$ - +% Kibana security had 2 original docs: +% https://www.elastic.co/guide/en/kibana/current/using-kibana-with-security.html +% https://www.elastic.co/guide/en/kibana/current/Security-production-considerations.html +% Scope: TBD # Configure security in {{kib}} [using-kibana-with-security] When you start {{es}} for the first time, {{stack-security-features}} are enabled on your cluster and TLS is configured automatically. The security configuration process generates a password for the `elastic` user and an enrollment token for {{kib}}. [Start the {{stack}} with security enabled](/deploy-manage/security/security-certificates-keys.md) and then enroll {{kib}} as part of the configuration process. diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index c13f5fcefc..52863569b9 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -456,16 +456,22 @@ toc: - file: security/secure-your-eck-installation.md - file: security/secure-your-cluster-deployment.md children: + - file: security/security-certificates-keys.md + - file: security/set-up-minimal-security.md - file: security/secure-cluster-communications.md children: - file: security/secure-http-communications.md - - file: security/k8s-transport-settings.md - - file: security/security-certificates-keys.md + - file: security/set-up-basic-security.md + - file: security/set-up-basic-security-plus-https.md + - file: security/updating-certificates.md children: - - file: security/updating-certificates.md - children: - - file: security/same-ca.md - - file: security/different-ca.md + - file: security/same-ca.md + - file: security/different-ca.md + - file: security/kibana-es-mutual-tls.md + - file: security/eck-tls.md + children: + - file: security/k8s-https-settings.md + - file: security/k8s-transport-settings.md - file: security/supported-ssltls-versions-by-jdk-version.md - file: security/enabling-cipher-suites-for-stronger-encryption.md - file: security/traffic-filtering.md @@ -499,14 +505,11 @@ toc: - file: security/logging-configuration/logfile-audit-output.md - file: security/logging-configuration/auditing-search-queries.md - file: security/logging-configuration/correlating-kibana-elasticsearch-audit-logs.md + - file: security/fips-140-2.md + - file: security/install-stack-demo-secure.md - file: security/manually-configure-security-in-self-managed-cluster.md children: - - file: security/set-up-minimal-security.md - - file: security/set-up-basic-security.md - - file: security/set-up-basic-security-plus-https.md - file: security/using-kibana-with-security.md - - file: security/install-stack-demo-secure.md - - file: security/fips-140-2.md - file: security/secure-clients-integrations.md - file: security/httprest-clients-security.md - file: security/limitations.md From 8f374d0480d83ab053df8f51d9fe076605add8c8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 26 Mar 2025 16:19:26 +0100 Subject: [PATCH 02/42] security certificates work in progress --- .../deploy/cloud-on-k8s/accessing-services.md | 2 +- .../cloud-on-k8s/advanced-configuration.md | 2 +- .../cloud-on-k8s/configuration-fleet.md | 2 +- .../elasticsearch-configuration.md | 2 +- .../elasticsearch-deployment-quickstart.md | 2 +- .../deploy/cloud-on-k8s/http-configuration.md | 6 +- .../k8s-kibana-advanced-configuration.md | 2 +- .../cloud-on-k8s/kibana-configuration.md | 8 +- .../kibana-instance-quickstart.md | 2 +- .../cloud-on-k8s/securing-logstash-api.md | 2 +- .../deploy/self-managed/access-kibana.md | 2 +- .../remote-clusters/remote-clusters-cert.md | 2 +- deploy-manage/security.md | 18 -- .../_snippets/kibana-client-https-setup.md | 26 +++ .../security/_snippets/kibana-https-setup.md | 52 +++++ deploy-manage/security/eck-tls.md | 15 ++ .../security/httprest-clients-security.md | 21 +- ...ommunications.md => k8s-https-settings.md} | 137 ++--------- .../security/k8s-transport-settings.md | 2 +- .../security/kibana-es-mutual-tls.md | 130 +++++++++++ ...figure-security-in-self-managed-cluster.md | 70 ------ .../security/secure-cluster-communications.md | 139 ++++++++---- .../secure-cluster-communications.md.backup | 172 ++++++++++++++ .../secure-your-cluster-deployment.md | 183 ++++++++------- .../secure-your-cluster-deployment.md.backup | 213 ++++++++++++++++++ .../security/security-certificates-keys.md | 2 +- .../set-up-basic-security-plus-https.md | 110 ++------- .../security/set-up-basic-security.md | 9 +- .../security/set-up-minimal-security.md | 4 +- .../security/updating-certificates.md | 6 +- .../security/using-kibana-with-security.md | 3 +- deploy-manage/toc.yml | 5 +- .../tools/cross-cluster-replication.md | 2 +- .../cluster-or-deployment-auth/pki.md | 2 +- 34 files changed, 886 insertions(+), 469 deletions(-) create mode 100644 deploy-manage/security/_snippets/kibana-client-https-setup.md create mode 100644 deploy-manage/security/_snippets/kibana-https-setup.md create mode 100644 deploy-manage/security/eck-tls.md rename deploy-manage/security/{secure-http-communications.md => k8s-https-settings.md} (62%) create mode 100644 deploy-manage/security/kibana-es-mutual-tls.md delete mode 100644 deploy-manage/security/manually-configure-security-in-self-managed-cluster.md create mode 100644 deploy-manage/security/secure-cluster-communications.md.backup create mode 100644 deploy-manage/security/secure-your-cluster-deployment.md.backup diff --git a/deploy-manage/deploy/cloud-on-k8s/accessing-services.md b/deploy-manage/deploy/cloud-on-k8s/accessing-services.md index 564a1c02da..d048741e74 100644 --- a/deploy-manage/deploy/cloud-on-k8s/accessing-services.md +++ b/deploy-manage/deploy/cloud-on-k8s/accessing-services.md @@ -22,7 +22,7 @@ This section explains how to access and customize the Kubernetes services and se For advanced use cases related to exposing and accessing orchestrated applications, see: -* [](/deploy-manage/security/secure-http-communications.md): Configuration options for the HTTP SSL certificates, including integration with certificate management systems such as [cert-manager](https://cert-manager.io/). +* [](/deploy-manage/security/secure-cluster-communications.md): Configuration options for the HTTP SSL certificates, including integration with certificate management systems such as [cert-manager](https://cert-manager.io/). * [](./service-meshes.md): Connect ECK and your managed deployments to service mesh implementations such as [Istio](https://istio.io) and [Linkerd](https://linkerd.io). * [](./requests-routing-to-elasticsearch-nodes.md): Create custom services to expose different node types. * [Use Ingress to expose {{es}} or {{kib}}](./managing-deployments-using-helm-chart.md#k8s-eck-stack-ingress): Helm based installation also facilitates the creation of Ingress resources. diff --git a/deploy-manage/deploy/cloud-on-k8s/advanced-configuration.md b/deploy-manage/deploy/cloud-on-k8s/advanced-configuration.md index 6acdc8a8d7..67a0ea21e1 100644 --- a/deploy-manage/deploy/cloud-on-k8s/advanced-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/advanced-configuration.md @@ -169,6 +169,6 @@ Now that you know how to use the APM keystore and customize the server configura By default the operator manages a private CA and generates a self-signed certificate used to secure the communication between APM agents and the server. -This behavior and the relevant configuration is identical to what is done for Elasticsearch and Kibana. Check [Setting up your own certificate](/deploy-manage/security/secure-http-communications.md) for more information on how to use your own certificate to configure the TLS endpoint of the APM Server. +This behavior and the relevant configuration is identical to what is done for Elasticsearch and Kibana. Check [Setting up your own certificate](/deploy-manage/security/secure-cluster-communications.md) for more information on how to use your own certificate to configure the TLS endpoint of the APM Server. For more details on how to configure the APM agents to work with custom certificates, check the [APM agents documentation](https://www.elastic.co/guide/en/apm/agent/index.html). diff --git a/deploy-manage/deploy/cloud-on-k8s/configuration-fleet.md b/deploy-manage/deploy/cloud-on-k8s/configuration-fleet.md index a30c5d11dd..915420bbd7 100644 --- a/deploy-manage/deploy/cloud-on-k8s/configuration-fleet.md +++ b/deploy-manage/deploy/cloud-on-k8s/configuration-fleet.md @@ -224,7 +224,7 @@ To deploy {{agent}} in clusters with the Pod Security Policy admission controlle ## Customize {{fleet-server}} Service [k8s-elastic-agent-fleet-configuration-customize-fleet-server-service] -By default, ECK creates a Service for {{fleet-server}} that {{agents}} can connect through. You can customize it using the `http` configuration element. Check more information on how to [make changes](accessing-services.md) to the Service and [customize](/deploy-manage/security/secure-http-communications.md) the TLS configuration. +By default, ECK creates a Service for {{fleet-server}} that {{agents}} can connect through. You can customize it using the `http` configuration element. Check more information on how to [make changes](accessing-services.md) to the Service and [customize](/deploy-manage/security/secure-cluster-communications.md) the TLS configuration. ## Control {{fleet}} policy selection [k8s-elastic-agent-control-fleet-policy-selection] diff --git a/deploy-manage/deploy/cloud-on-k8s/elasticsearch-configuration.md b/deploy-manage/deploy/cloud-on-k8s/elasticsearch-configuration.md index b87ab8a98b..48b61e4f24 100644 --- a/deploy-manage/deploy/cloud-on-k8s/elasticsearch-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/elasticsearch-configuration.md @@ -38,7 +38,7 @@ Before deploying and running ECK in production, review the basic and advanced se ## TLS/SSL Certificates -* [Secure HTTP communications](/deploy-manage/security/secure-http-communications.md): Customize the service and TLS certificates used for transport traffic. +* [Secure HTTP communications](/deploy-manage/security/secure-cluster-communications.md): Customize the service and TLS certificates used for transport traffic. * [Transport settings](../../security/k8s-transport-settings.md): Customize the service and TLS certificates used for transport traffic. ## Traffic handling diff --git a/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md b/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md index faa5017fdf..e564a2cddc 100644 --- a/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md +++ b/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md @@ -118,7 +118,7 @@ In order to make requests to the [{{es}} API](elasticsearch://reference/elastics PASSWORD=$(kubectl get secret quickstart-es-elastic-user -o go-template='{{.data.elastic | base64decode}}') ``` -2. Request the [{{es}} root API](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-info). You can do so from inside the Kubernetes cluster or from your local workstation. For demonstration purposes, certificate verification is disabled using the `-k` curl flag; however, this is not recommended outside of testing purposes. Refer to [Setup your own certificate](/deploy-manage/security/secure-http-communications.md#k8s-setting-up-your-own-certificate) for more information. +2. Request the [{{es}} root API](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-info). You can do so from inside the Kubernetes cluster or from your local workstation. For demonstration purposes, certificate verification is disabled using the `-k` curl flag; however, this is not recommended outside of testing purposes. Refer to [Setup your own certificate](/deploy-manage/security/secure-cluster-communications.md#k8s-setting-up-your-own-certificate) for more information. * From inside the Kubernetes cluster: diff --git a/deploy-manage/deploy/cloud-on-k8s/http-configuration.md b/deploy-manage/deploy/cloud-on-k8s/http-configuration.md index 44a0534f0b..6c0aac6fc8 100644 --- a/deploy-manage/deploy/cloud-on-k8s/http-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/http-configuration.md @@ -17,17 +17,17 @@ This functionality is in technical preview and may be changed or removed in a fu By default a `ClusterIP` [service](https://kubernetes.io/docs/concepts/services-networking/service/) is created and associated with the Elastic Maps Server deployment. If you want to expose maps externally with a [load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer), it is recommended to include a custom DNS name or IP in the self-generated certificate. -Refer to [Reserve static IP and custom domain](/deploy-manage/security/secure-http-communications.md#k8s-static-ip-custom-domain) for more details. +Refer to [Reserve static IP and custom domain](/deploy-manage/security/secure-cluster-communications.md#k8s-static-ip-custom-domain) for more details. ## Provide your own certificate [k8s-maps-http-custom-tls] -If you want to use your own certificate, the required configuration is identical to Elasticsearch. Check [Custom HTTP certificate](../../security/secure-http-communications.md). +If you want to use your own certificate, the required configuration is identical to Elasticsearch. Check [Custom HTTP certificate](../../security/secure-cluster-communications.md). ## Disable TLS [k8s-maps-http-disable-tls] -You can disable the generation of the self-signed certificate and hence disable TLS. Check [Disable TLS](/deploy-manage/security/secure-http-communications.md#k8s-disable-tls). +You can disable the generation of the self-signed certificate and hence disable TLS. Check [Disable TLS](/deploy-manage/security/secure-cluster-communications.md#k8s-disable-tls). ### Ingress and Kibana configuration [k8s-maps-ingress] diff --git a/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md b/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md index 4cb6ba81a4..c3871c9d1b 100644 --- a/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md @@ -12,7 +12,7 @@ If you already looked at the [Elasticsearch on ECK](elasticsearch-configuration. * [Customize the Pod configuration](#k8s-kibana-pod-configuration) * [Customize the product configuration](#k8s-kibana-configuration) -* [Manage HTTP settings](/deploy-manage/security/secure-http-communications.md#k8s-kibana-http-configuration) +* [Manage HTTP settings](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-configuration) * [Use secure settings](../../security/k8s-secure-settings.md) * [Install {{kib}} plugins](k8s-kibana-plugins.md) diff --git a/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md b/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md index 11fd37da76..a40537d6bb 100644 --- a/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md @@ -22,11 +22,11 @@ The following sections describe how to customize a {{kib}} deployment to suit yo * [Scaling out a {{kib}} deployment](k8s-kibana-advanced-configuration.md#k8s-kibana-scaling) * [Secure settings](../../security/k8s-secure-settings.md#k8s-kibana-secure-settings) -* [HTTP Configuration](/deploy-manage/security/secure-http-communications.md#k8s-kibana-http-configuration) +* [HTTP Configuration](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-configuration) - * [Load balancer settings and TLS SANs](/deploy-manage/security/secure-http-communications.md#k8s-kibana-http-publish) - * [Provide your own certificate](/deploy-manage/security/secure-http-communications.md#k8s-kibana-http-custom-tls) - * [Disable TLS](/deploy-manage/security/secure-http-communications.md#k8s-kibana-http-disable-tls) + * [Load balancer settings and TLS SANs](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-publish) + * [Provide your own certificate](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-custom-tls) + * [Disable TLS](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-disable-tls) * [Install {{kib}} plugins](k8s-kibana-plugins.md) * [Autoscaling stateless applications](../../autoscaling/autoscaling-in-eck.md#k8s-stateless-autoscaling): Use [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) for {{kib}} or other stateless applications. diff --git a/deploy-manage/deploy/cloud-on-k8s/kibana-instance-quickstart.md b/deploy-manage/deploy/cloud-on-k8s/kibana-instance-quickstart.md index 8e27c7a539..4da7a45498 100644 --- a/deploy-manage/deploy/cloud-on-k8s/kibana-instance-quickstart.md +++ b/deploy-manage/deploy/cloud-on-k8s/kibana-instance-quickstart.md @@ -57,7 +57,7 @@ To deploy a simple [{{kib}}](/get-started/the-stack.md#stack-components-kibana) kubectl port-forward service/quickstart-kb-http 5601 ``` - Open `https://localhost:5601` in your browser. Your browser will show a warning because the self-signed certificate configured by default is not verified by a known certificate authority and not trusted by your browser. You can temporarily acknowledge the warning for the purposes of this quick start but it is highly recommended that you [configure valid certificates](/deploy-manage/security/secure-http-communications.md#k8s-setting-up-your-own-certificate) for any production deployments. + Open `https://localhost:5601` in your browser. Your browser will show a warning because the self-signed certificate configured by default is not verified by a known certificate authority and not trusted by your browser. You can temporarily acknowledge the warning for the purposes of this quick start but it is highly recommended that you [configure valid certificates](/deploy-manage/security/secure-cluster-communications.md#k8s-setting-up-your-own-certificate) for any production deployments. Login as the `elastic` user. The password can be obtained with the following command: diff --git a/deploy-manage/deploy/cloud-on-k8s/securing-logstash-api.md b/deploy-manage/deploy/cloud-on-k8s/securing-logstash-api.md index c50c29acef..4182812001 100644 --- a/deploy-manage/deploy/cloud-on-k8s/securing-logstash-api.md +++ b/deploy-manage/deploy/cloud-on-k8s/securing-logstash-api.md @@ -75,7 +75,7 @@ spec: ## Provide your own certificate [k8s-logstash-http-custom-tls] -If you want to use your own certificate, the required configuration is similar to Elasticsearch. Configure the certificate in `api` Service. Check [Custom HTTP certificate](../../security/secure-http-communications.md). +If you want to use your own certificate, the required configuration is similar to Elasticsearch. Configure the certificate in `api` Service. Check [Custom HTTP certificate](../../security/secure-cluster-communications.md). ```yaml apiVersion: logstash.k8s.elastic.co/v1alpha1 diff --git a/deploy-manage/deploy/self-managed/access-kibana.md b/deploy-manage/deploy/self-managed/access-kibana.md index f53b4afd3b..4cb278cbbc 100644 --- a/deploy-manage/deploy/self-managed/access-kibana.md +++ b/deploy-manage/deploy/self-managed/access-kibana.md @@ -15,7 +15,7 @@ Access {{kib}} through the web application on port 5601. To remotely connect to {{kib}}, set [`server.host`](kibana://reference/configuration-reference/general-settings.md#server-host) to a non-loopback address. :::{note} - For production deployments, you should always [secure {{kib}} with a certificate](/deploy-manage/security/secure-http-communications.md#encrypt-kibana-http) and access it over HTTPS. + For production deployments, you should always [secure {{kib}} with a certificate](/deploy-manage/security/secure-cluster-communications.md#encrypt-kibana-http) and access it over HTTPS. ::: 2. Log on to your account. diff --git a/deploy-manage/remote-clusters/remote-clusters-cert.md b/deploy-manage/remote-clusters/remote-clusters-cert.md index ba751510aa..a49125f5e1 100644 --- a/deploy-manage/remote-clusters/remote-clusters-cert.md +++ b/deploy-manage/remote-clusters/remote-clusters-cert.md @@ -34,7 +34,7 @@ If you run into any issues, refer to [Troubleshooting](/troubleshoot/elasticsear ## Establish trust with a remote cluster [remote-clusters-security-cert] -To use {{ccr}} or {{ccs}} safely with remote clusters, enable security on all connected clusters and configure Transport Layer Security (TLS) on every node. Configuring TLS security on the transport interface is minimally required for remote clusters. For additional security, configure TLS on the [HTTP interface](../security/secure-http-communications.md) as well. +To use {{ccr}} or {{ccs}} safely with remote clusters, enable security on all connected clusters and configure Transport Layer Security (TLS) on every node. Configuring TLS security on the transport interface is minimally required for remote clusters. For additional security, configure TLS on the [HTTP interface](../security/secure-cluster-communications.md) as well. All connected clusters must trust one another and be mutually authenticated with TLS on the transport interface. This means that the local cluster trusts the certificate authority (CA) of the remote cluster, and the remote cluster trusts the CA of the local cluster. When establishing a connection, all nodes will verify certificates from nodes on the other side. This mutual trust is required to securely connect a remote cluster, because all connected nodes effectively form a single security domain. diff --git a/deploy-manage/security.md b/deploy-manage/security.md index 59b63c486c..6f1bf34209 100644 --- a/deploy-manage/security.md +++ b/deploy-manage/security.md @@ -25,24 +25,6 @@ The availability and configurability of security features vary by deployment typ :::{include} /deploy-manage/security/_snippets/complete-security.md ::: -## Security principles (from manual config orig page) - -### Run {{es}} with security enabled [security-run-with-security] - -Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. [Start the {{stack}} with security enabled](/deploy-manage/security/security-certificates-keys.md) or [manually configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md) to prevent unauthorized access to your clusters and ensure that internode communication is secure. - -### Run {{es}} with a dedicated non-root user [security-not-root-user] - -Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. - -### Protect {{es}} from public internet traffic [security-protect-cluster-traffic] - -Even with security enabled, never expose {{es}} to public internet traffic. Using an application to sanitize requests to {{es}} still poses risks, such as a malicious user writing [`_search`](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-search) requests that could overwhelm an {{es}} cluster and bring it down. Keep {{es}} as isolated as possible, preferably behind a firewall and a VPN. Any internet-facing applications should run pre-canned aggregations, or not run aggregations at all. - -### Implement role based access control [security-create-appropriate-users] - -[Define roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request. - ## Managed security in Elastic Cloud ```yaml {applies_to} deployment: diff --git a/deploy-manage/security/_snippets/kibana-client-https-setup.md b/deploy-manage/security/_snippets/kibana-client-https-setup.md new file mode 100644 index 0000000000..4ee483e120 --- /dev/null +++ b/deploy-manage/security/_snippets/kibana-client-https-setup.md @@ -0,0 +1,26 @@ +When you ran the `elasticsearch-certutil` tool with the `http` option, it created a `/kibana` directory containing an `elasticsearch-ca.pem` file. You use this file to configure {{kib}} to trust the {{es}} CA for the HTTP layer. + +1. Copy the `elasticsearch-ca.pem` file to the {{kib}} configuration directory, as defined by the `$KBN_PATH_CONF` path. +2. Open `kibana.yml` and add the following line to specify the location of the security certificate for the HTTP layer. + + ```yaml + elasticsearch.ssl.certificateAuthorities: $KBN_PATH_CONF/elasticsearch-ca.pem + ``` + +3. Add the following line to specify the HTTPS URL for your {{es}} cluster. + + ```yaml + elasticsearch.hosts: https://:9200 + ``` + +4. Restart {{kib}}. + +:::::{admonition} Connect to a secure monitoring cluster +If the Elastic monitoring features are enabled and you configured a separate {{es}} monitoring cluster, you can also configure {{kib}} to connect to the monitoring cluster through HTTPS. The steps are the same, but each setting is prefixed by `monitoring`. For example, `monitoring.ui.elasticsearch.hosts` and `monitoring.ui.elasticsearch.ssl.truststore.path`. + +::::{note} +You must create a separate `elasticsearch-ca.pem` security file for the monitoring cluster. +:::: + +::::: + diff --git a/deploy-manage/security/_snippets/kibana-https-setup.md b/deploy-manage/security/_snippets/kibana-https-setup.md new file mode 100644 index 0000000000..2756647cae --- /dev/null +++ b/deploy-manage/security/_snippets/kibana-https-setup.md @@ -0,0 +1,52 @@ +You create a server certificate and private key for {{kib}}. {{kib}} uses this server certificate and corresponding private key when receiving connections from web browsers. + +When you obtain a server certificate, you must set its subject alternative name (SAN) correctly to ensure that browsers will trust it. You can set one or more SANs to the {{kib}} server’s fully-qualified domain name (FQDN), hostname, or IP address. When choosing the SAN, pick whichever attribute you’ll use to connect to {{kib}} in your browser, which is likely the FQDN. + +The following instructions create a Certificate Signing Request (CSR) for {{kib}}. A CSR contains information that a CA uses to generate and sign a security certificate. The certificate can be trusted (signed by a public, trusted CA) or untrusted (signed by an internal CA). A self-signed or internally-signed certificate is acceptable for development environments and building a proof of concept, but should not be used in a production environment. + +::::{warning} +Before going to production, use a trusted CA such as [Let’s Encrypt](https://letsencrypt.org/) or your organization’s internal CA to sign the certificate. Using a signed certificate establishes browser trust for connections to {{kib}} for internal access or on the public internet. +:::: + + +1. Generate a server certificate and private key for {{kib}}. + + ```shell + ./bin/elasticsearch-certutil csr -name kibana-server -dns example.com,www.example.com + ``` + + The CSR has a common name (CN) of `kibana-server`, a SAN of `example.com`, and another SAN of `www.example.com`. + + This command generates a `csr-bundle.zip` file by default with the following contents: + + ```txt + /kibana-server + |_ kibana-server.csr + |_ kibana-server.key + ``` + +2. Unzip the `csr-bundle.zip` file to obtain the `kibana-server.csr` unsigned security certificate and the `kibana-server.key` unencrypted private key. +3. Send the `kibana-server.csr` certificate signing request to your internal CA or trusted CA for signing to obtain a signed certificate. The signed file can be in different formats, such as a `.crt` file like `kibana-server.crt`. +4. Open `kibana.yml` and add the following lines to configure {{kib}} to access the server certificate and unencrypted private key. + + ```yaml + server.ssl.certificate: $KBN_PATH_CONF/kibana-server.crt + server.ssl.key: $KBN_PATH_CONF/kibana-server.key + ``` + + ::::{note} + `$KBN_PATH_CONF` contains the path for the {{kib}} configuration files. If you installed {{kib}} using archive distributions (`zip` or `tar.gz`), the path defaults to `$KBN_HOME/config`. If you used package distributions (Debian or RPM), the path defaults to `/etc/kibana`. + :::: + +5. Add the following line to `kibana.yml` to enable TLS for inbound connections. + + ```yaml + server.ssl.enabled: true + ``` + +6. Start {{kib}}. + +::::{note} +After making these changes, you must always access {{kib}} via HTTPS. For example, `https://.com`. +:::: + diff --git a/deploy-manage/security/eck-tls.md b/deploy-manage/security/eck-tls.md new file mode 100644 index 0000000000..c524fdf0aa --- /dev/null +++ b/deploy-manage/security/eck-tls.md @@ -0,0 +1,15 @@ +--- +applies_to: + deployment: + eck: all +navigation_title: ECK +mapped_pages: + - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-security.html +--- + +# Manage TLS certificates on ECK + +All {{stack}} resources deployed by the ECK operator are secured by default. The operator sets up basic authentication and TLS to encrypt network traffic to, from, and within your {{es}} cluster and {{kib}} instances. + +% TBD +(Pending to write a quick intro about use cases and links) \ No newline at end of file diff --git a/deploy-manage/security/httprest-clients-security.md b/deploy-manage/security/httprest-clients-security.md index 5764ac124f..9d472fe84e 100644 --- a/deploy-manage/security/httprest-clients-security.md +++ b/deploy-manage/security/httprest-clients-security.md @@ -3,7 +3,17 @@ mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/http-clients.html --- -# HTTP/REST clients and security [http-clients] +# Securing HTTP client applications + +When connecting client applications to {{es}}, use these best practices: + +- Always use HTTPS for all connections +- Validate server certificates to prevent man-in-the-middle attacks +- Use API keys or token-based authentication rather than basic auth where possible +- Implement appropriate connection pooling and retry mechanisms +- Consider mutual TLS for high-security environments + +## HTTP/REST clients and security [http-clients] The {{es}} {{security-features}} work with standard HTTP [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) headers to authenticate users. Since {{es}} is stateless, this header must be sent with every request: @@ -17,7 +27,7 @@ Authorization: Basic <1> Alternatively, you can use [token-based authentication services](../users-roles/cluster-or-deployment-auth/token-based-authentication-services.md). -## Client examples [http-clients-examples] +### Client examples [http-clients-examples] This example uses `curl` without basic auth to create an index: @@ -44,8 +54,7 @@ curl --user rdeniro:taxidriver -XPUT 'localhost:9200/idx' } ``` - -## Secondary authorization [http-clients-secondary-authorization] +### Secondary authorization [http-clients-secondary-authorization] Some APIs support secondary authorization headers for situations where you want tasks to run with a different set of credentials. For example, you can send the following header in addition to the basic authentication header: @@ -64,9 +73,7 @@ es-secondary-authorization: ApiKey <1> 1. The `` is computed as `base64(API key ID:API key)` - - -## Client libraries over HTTP [http-clients-libraries] +### Client libraries over HTTP [http-clients-libraries] For more information about using {{security-features}} with the language specific clients, refer to: diff --git a/deploy-manage/security/secure-http-communications.md b/deploy-manage/security/k8s-https-settings.md similarity index 62% rename from deploy-manage/security/secure-http-communications.md rename to deploy-manage/security/k8s-https-settings.md index 4b390a037d..459c8fe35f 100644 --- a/deploy-manage/security/secure-http-communications.md +++ b/deploy-manage/security/k8s-https-settings.md @@ -2,106 +2,15 @@ applies_to: deployment: eck: - ece: - self: mapped_urls: - - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup-https.html - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-tls-certificates.html - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-custom-http-certificate.html - - https://www.elastic.co/guide/en/kibana/current/Security-production-considerations.html - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-kibana-http-configuration.html --- -% EEDUGON NOTE: security section might miss a section to secure the transport layer (not the HTTP). -% There we should integrate the content of https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-transport-settings.html which is currently in ECK (/deploy-manage) doc. +# Manage HTTP certificates on ECK -% Internal links rely on the following IDs being on this page (e.g. as a heading ID, paragraph ID, etc): - -% pending to solve too - -$$$configuring-tls-browser-kib$$$ -$$$encrypt-http-communication$$$ -$$$encrypt-kibana-http$$$ - -% Weird redirect in current system, not sure what to do - -# Secure HTTP communications - -## Overview - -Securing HTTP communications is essential for protecting data transmitted between: - -- {{kib}} and {{es}} -- {{kib}} and web browsers -- External monitoring systems and {{es}} -- Any HTTP client and your {{stack}} deployment - -Different deployment types have different requirements: - -| Deployment Type | HTTP Security Configuration | -|-----------------|----------------------------| -| {{ech}}/{{serverless-short}} | Automatically configured | -| Self-managed | Manual configuration required | -| {{eck}} | Configurable with defaults | -| {{ece}} | Manual configuration required | - -## Self-managed deployments - -```{applies_to} -self: -``` - -For self-managed deployments, you need to generate and configure certificates for secure HTTP communications. - -### Prerequisites - -Complete all steps in: - -- [Set up basic security](/deploy-manage/security/set-up-basic-security.md) -- [](/deploy-manage/security/set-up-basic-security-plus-https.md) - -### Mutual TLS removed - - -## Securing client applications - -When connecting client applications to {{es}}, use these best practices: - -- Always use HTTPS for all connections -- Validate server certificates to prevent man-in-the-middle attacks -- Use API keys or token-based authentication rather than basic auth where possible -- Implement appropriate connection pooling and retry mechanisms -- Consider mutual TLS for high-security environments - -For code examples and library-specific guidance, see [HTTP/REST client security](httprest-clients-security.md). - -## Securing Beats connections - -% TODO: Put in clients section - -When sending data from Beats to Elasticsearch, you need to secure those communications with TLS and proper authentication. - -Key configuration requirements: -- Configure Beats to use HTTPS when connecting to Elasticsearch -- Set up appropriate authentication (API keys recommended) -- Verify Elasticsearch server certificates - -For detailed instructions on configuring Beats security settings, see [Configure Beats security](/deploy-manage/security/set-up-basic-security-plus-https.md#configure-beats-security). - -## {{ece}} (ECE) - -```{applies_to} -deployment: - ece: all -``` - -For ECE deployments, certificate management and TLS configuration are handled at the platform level. Refer to these guides for ECE-specific security configurations: - -- [Manage security certificates in ECE](secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) -- [Allow x509 Certificates Signed with SHA-1](secure-your-elastic-cloud-enterprise-installation/allow-x509-certificates-signed-with-sha-1.md) -- [Configure TLS version](secure-your-elastic-cloud-enterprise-installation/configure-tls-version.md) - -## {{eck}} (ECK) [k8s-tls-certificates] +## {{es}} certificates [k8s-tls-certificates] ```{applies_to} deployment: @@ -252,7 +161,7 @@ spec: - dns: hulk.example.com ``` -### Setup your own certificate [k8s-setting-up-your-own-certificate] +### Provide your own certificate [k8s-setting-up-your-own-certificate] You can bring your own certificate to configure TLS to ensure that communication between HTTP clients and the Elastic Stack application is encrypted. @@ -291,21 +200,9 @@ spec: secretName: my-cert ``` -### Disable TLS [k8s-disable-tls] - -You can explicitly disable TLS for Kibana, APM Server, and the HTTP layer of Elasticsearch. +## Kibana HTTP configuration in ECK [k8s-kibana-http-configuration] -```yaml -spec: - http: - tls: - selfSignedCertificate: - disabled: true -``` - -### Kibana HTTP configuration in ECK [k8s-kibana-http-configuration] - -#### Load balancer settings and TLS SANs [k8s-kibana-http-publish] +### Load balancer settings and TLS SANs [k8s-kibana-http-publish] By default a `ClusterIP` [Service](https://kubernetes.io/docs/concepts/services-networking/service/) is created and associated with the {{kib}} deployment. If you want to expose {{kib}} externally with a [load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer), it is recommended to include a custom DNS name or IP in the self-generated certificate. @@ -331,26 +228,24 @@ spec: ``` -#### Provide your own certificate [k8s-kibana-http-custom-tls] +### Provide your own certificate [k8s-kibana-http-custom-tls] -If you want to use your own certificate, the required configuration is identical to {{es}}. Refer to [Set up HTTPS for the Elastic Stack](/deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-http-communication). +If you want to use your own certificate, the required configuration is identical to {{es}}. Refer to [setup your own {{es}} certificate](#k8s-setting-up-your-own-certificate). -#### Disable TLS [k8s-kibana-http-disable-tls] +## Disable TLS [k8s-disable-tls] -You can disable the generation of the self-signed certificate and hence [disable TLS](/deploy-manage/security/secure-your-cluster-deployment.md). This is not recommended outside of testing clusters. +You can explicitly disable the generation of the self-signed certificate and hence disable TLS for {{kib}}, APM Server, and the HTTP layer of {{es}}. + +::::{important} +Disabling TLS is not recommended outside of test or development environments. +:::: + +To disable TLS, add the following setting to the appropriate resource: ```yaml -apiVersion: kibana.k8s.elastic.co/v1 -kind: Kibana -metadata: - name: kibana-sample spec: - version: 8.16.1 - count: 1 - elasticsearchRef: - name: "elasticsearch-sample" http: tls: selfSignedCertificate: disabled: true -``` \ No newline at end of file +``` diff --git a/deploy-manage/security/k8s-transport-settings.md b/deploy-manage/security/k8s-transport-settings.md index 621b028993..a3bcd73ed7 100644 --- a/deploy-manage/security/k8s-transport-settings.md +++ b/deploy-manage/security/k8s-transport-settings.md @@ -6,7 +6,7 @@ mapped_pages: - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-transport-settings.html --- -# Transport certificates on ECK [k8s-transport-settings] +# Manage transport certificates on ECK [k8s-transport-settings] The transport module in Elasticsearch is used for internal communication between nodes within the cluster as well as communication between remote clusters. Check the [Elasticsearch documentation](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md) for details. For customization options of the HTTP layer, check [Services](../deploy/cloud-on-k8s/accessing-services.md) and [TLS certificates](/deploy-manage/security/secure-http-communications.md). diff --git a/deploy-manage/security/kibana-es-mutual-tls.md b/deploy-manage/security/kibana-es-mutual-tls.md new file mode 100644 index 0000000000..89737dad1f --- /dev/null +++ b/deploy-manage/security/kibana-es-mutual-tls.md @@ -0,0 +1,130 @@ +--- +navigation_title: Kibana > Elasticsearch mutual TLS +applies_to: + deployment: + self: all +mapped_urls: + - https://www.elastic.co/guide/en/kibana/current/elasticsearch-mutual-tls.html +--- + +# Mutual TLS authentication between {{kib}} and {{es}} [elasticsearch-mutual-tls] + +Secure Sockets Layer (SSL) and Transport Layer Security (TLS) provide encryption for data-in-transit. While these terms are often used interchangeably, {{kib}} supports only TLS, which supersedes the old SSL protocols. + +TLS requires X.509 certificates to authenticate the communicating parties and perform encryption of data-in-transit. Each certificate contains a public key and has and an associated — but separate — private key; these keys are used for cryptographic operations. {{kib}} supports certificates and private keys in PEM or PKCS#12 format. + +In a standard TLS configuration, the server presents a signed certificate to authenticate itself to the client. In a mutual TLS configuration, the client also presents a signed certificate to authenticate itself to the server. + +{{es}} {{security-features}} are enabled on your cluster by default, so each request that {{kib}} (the client) makes to {{es}} (the server) is authenticated. Most requests made by end users through {{kib}} to {{es}} are authenticated by using the credentials of the logged-in user. + +To [enroll {{kib}} with an {{es}} cluster](/deploy-manage/security/security-certificates-keys.md#stack-start-with-security), you pass a generated enrollment token. This token configures {{kib}} to authenticate with {{es}} using a [service account token](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#service-accounts-tokens). {{kib}} also supports mutual TLS authentication with {{es}} via a [Public Key Infrastructure (PKI) realm](/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md). With this setup, {{es}} needs to verify the signature on the {{kib}} client certificate, and it also needs to map the client certificate’s distinguished name (DN) to the appropriate `kibana_system` role. + +::::{note} +Using a PKI realm is a [subscription feature](https://www.elastic.co/subscriptions). +:::: + +#### Configure {{kib}} and {{es}} to use mutual TLS authentication [_configure_kib_and_es_to_use_mutual_tls_authentication] + +If you haven’t already, start {{kib}} and connect it to {{es}} using the [enrollment token](/deploy-manage/security/security-certificates-keys.md#stack-start-with-security). + +1. Obtain a client certificate and private key for {{kib}}. + + {{kib}} uses the client certificate and corresponding private key when connecting to {{es}}. + + ::::{note} + This is not the same as the server certificate that {{kib}} will present to web browsers. + :::: + + + You may choose to generate a client certificate and private key using the [`elasticsearch-certutil`](elasticsearch://reference/elasticsearch/command-line-tools/certutil.md) tool. If you followed the {{es}} documentation for [generating the certificates authority](/deploy-manage/security/set-up-basic-security.md#generate-certificates), then you already have a certificate authority (CA) to sign the {{es}} server certificate. You may choose to use the same CA to sign the {{kib}} client certificate. For example: + + ```sh + bin/elasticsearch-certutil cert -ca elastic-stack-ca.p12 -name kibana-client -dns + ``` + + This will generate a client certificate and private key in a PKCS#12 file named `kibana-client.p12`. In this example, the client certificate has a Common Name (CN) of `"kibana-client"` and a subject alternative name (SAN) of `""`. The SAN may be required if you have hostname verification enabled on {{es}}. + +2. Obtain the certificate authority (CA) certificate chain for {{kib}}. + + {{es}} needs the appropriate CA certificate chain to properly establish trust when receiving connections from {{kib}}. + + If you followed the instructions to generate a client certificate, then you will have a PKCS#12 file for {{kib}}. You can extract the CA certificate chain from this file. For example: + + ```sh + openssl pkcs12 -in kibana-client.p12 -cacerts -nokeys -out kibana-ca.crt + ``` + + This will produce a PEM-formatted file named `kibana-ca.crt` that contains the CA certificate from the PKCS#12 file. + +3. Configure {{es}} with a PKI realm and a native realm. + + By default, {{es}} provides a native realm for authenticating with a username and password. However, to support both a PKI realm (for {{kib}}) and a native realm (for end users), you must configure each realm in `elasticsearch.yml`: + + ```yaml + xpack.security.authc.realms.pki.realm1.order: 1 + xpack.security.authc.realms.pki.realm1.certificate_authorities: "/path/to/kibana-ca.crt" + xpack.security.authc.realms.native.realm2.order: 2 + ``` + +4. Configure {{es}} to request client certificates. + + By default, {{es}} will not request a client certificate when establishing a TLS connection. To change this, you must set up optional client certificate authentication in `elasticsearch.yml`: + + ```yaml + xpack.security.http.ssl.client_authentication: "optional" + ``` + +5. Restart {{es}}. +6. Use {{kib}} to create a role mapping in {{es}} for the client certificate. + + This role mapping will assign the `kibana_system` role to any user that matches the included mapping rule, which is set to equal the client certificate’s DN attribute: + + ![Role mapping for the {{kib}} client certificate](/deploy-manage/images/kibana-mutual-tls-role-mapping.png "") + + For more information, see [](/deploy-manage/users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md). + +7. Configure {{kib}} to use the client certificate and private key. + + You need to specify the information required to access your client certificate and corresponding private key. + + 1. If your certificate and private key are contained in a PKCS#12 file: + + Specify your PKCS#12 file in `kibana.yml`: + + ```yaml + elasticsearch.ssl.keystore.path: "/path/to/kibana-client.p12" + ``` + + If your PKCS#12 file is encrypted, add the decryption password to your [{{kib}} keystore](secure-settings.md): + + ```yaml + bin/kibana-keystore add elasticsearch.ssl.keystore.password + ``` + + ::::{tip} + If your PKCS#12 file isn’t protected with a password, depending on how it was generated, you may need to set `elasticsearch.ssl.keystore.password` to an empty string. + :::: + + 2. Otherwise, if your certificate and private key are in PEM format: + + Specify your certificate and private key in `kibana.yml`: + + ```yaml + elasticsearch.ssl.certificate: "/path/to/kibana-client.crt" + elasticsearch.ssl.key: "/path/to/kibana-client.key" + ``` + + If your private key is encrypted, add the decryption password to your [{{kib}} keystore](secure-settings.md): + + ```yaml + bin/kibana-keystore add elasticsearch.ssl.keyPassphrase + ``` + +8. Configure {{kib}} *not* to use a username and password for {{es}}. + + You must remove the `elasticsearch.username` and `elasticsearch.password` settings from `kibana.yml`. If these are present, {{kib}} will attempt to use them to authenticate to {{es}} via the native realm. + +9. Restart {{kib}}. + +These steps enable {{kib}} to authenticate to {{es}} using a certificate. However, end users will only be able to authenticate to {{kib}} with a username and password. To allow end users to authenticate to {{kib}} using a client certificate, see [{{kib}} PKI authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md#pki-authentication). + diff --git a/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md b/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md deleted file mode 100644 index 8564422c2b..0000000000 --- a/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -navigation_title: Configure security in a self-managed cluster -applies_to: - deployment: - self: ga -mapped_pages: - - https://www.elastic.co/guide/en/elasticsearch/reference/current/manually-configure-security.html ---- - -# Configure security in a self-managed cluster [manually-configure-security] - -:::{note} -This page describes important aspects to consider and common end-to-end scenarios for securing your self-managed {{stack}}. For a more granular view of the available security options for your clusters and nodes, refer to [](secure-your-cluster-deployment.md). -::: - -Security needs vary depending on whether you’re developing locally on your laptop or securing all communications in a production environment. Regardless of where you’re deploying the {{stack}} ("ELK"), running a secure cluster is incredibly important to protect your data. That’s why security is [enabled and configured by default](../deploy/self-managed/installing-elasticsearch.md) since {{es}} 8.0. - -## Security principles - -### Run {{es}} with security enabled [security-run-with-security] - -Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. [Start the {{stack}} with security enabled](/deploy-manage/security/security-certificates-keys.md) or [manually configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md) to prevent unauthorized access to your clusters and ensure that internode communication is secure. - -### Run {{es}} with a dedicated non-root user [security-not-root-user] - -Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. - -### Protect {{es}} from public internet traffic [security-protect-cluster-traffic] - -Even with security enabled, never expose {{es}} to public internet traffic. Using an application to sanitize requests to {{es}} still poses risks, such as a malicious user writing [`_search`](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-search) requests that could overwhelm an {{es}} cluster and bring it down. Keep {{es}} as isolated as possible, preferably behind a firewall and a VPN. Any internet-facing applications should run pre-canned aggregations, or not run aggregations at all. - -### Implement role based access control [security-create-appropriate-users] - -[Define roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request. - -## Common security scenarios - -:::{image} /deploy-manage/images/elasticsearch-reference-elastic-security-overview.png -:alt: Elastic Security layers -::: - -### Minimal security ({{es}} Development) [security-minimal-overview] - -::::{important} -The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. -:::: - -If you’ve been working with {{es}} and want to enable security on your existing, unsecured cluster, start here. You’ll set passwords for the built-in users to prevent unauthorized access to your local cluster, and also configure password authentication for {{kib}}. - -[Set up minimal security](set-up-minimal-security.md) - -### Basic security ({{es}} + {{kib}}) [security-basic-overview] - -This scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your {{es}} cluster. - -Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but internode communication will be secured. - -[Set up basic security](secure-cluster-communications.md) - -### Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview] - -This scenario builds on the one for basic security and secures all HTTP traffic with TLS. In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. - -::::{note} -If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption. -:::: - -You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. - -[Set up basic security plus HTTPS traffic](secure-http-communications.md) diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 084f647bb4..c562b486cb 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -1,29 +1,21 @@ --- -navigation_title: Manage TLS certificates +navigation_title: Manage TLS encryption applies_to: deployment: self: eck: ece: mapped_urls: - - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-security.html - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html - https://www.elastic.co/guide/en/kibana/current/elasticsearch-mutual-tls.html --- +% Scope: landing page for manually handling TLS certificates, and for information about TLS in Elastic Stack in general. +# TLS encryption for cluster communications -% TODO: what to do about this page that doesn't exist -% * [/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-security.md](/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-security.md) +This page explains how to secure communications and setup TLS certificates between components in your {{stack}} deployment. -$$$encrypt-internode-communication$$$ -$$$generate-certificates$$$ - - -# Manage TLS certificates - -This page explains how to secure communications between components in your {{stack}} deployment. - -For {{ech}} and {{serverless-full}} deployments, communications security is fully managed by Elastic with no configuration required. +For {{ech}} and {{serverless-full}} deployments, communication security is fully managed by Elastic with no configuration required, including TLS certificates. For ECE, ECK, and self-managed deployments, this page provides specific configuration guidance to secure the various communication channels between components. @@ -31,63 +23,112 @@ For ECE, ECK, and self-managed deployments, this page provides specific configur For a complete comparison of security feature availability and responsibility by deployment type, see [Security features by deployment type](/deploy-manage/security.md#comparison-table). ::: - ## Communication channels overview -Your {{stack}} deployment includes several distinct communication channels that must be secured to protect your data and infrastructure. +Both {{es}} and {{kib}}, the core components of the {{stack}}, expose service endpoints that must be secured. {{es}} handles traffic at two levels: +* The **transport layer**, used for internal communication between nodes in the cluster. +* The **HTTP layer**, used by external clients — including Kibana — to send requests via the REST API. -| **Channel** | **Description** | **Security needs** | -|-------------|-----------------|--------------------| -| [Transport layer](#transport-layer-security) | Communication between {{es}} nodes within a cluster | - Mutual TLS (required)
- Node authentication
- Node role verification | -| [HTTP layer](#http-layer-security) | Communication between external clients and {{es}} through the REST API | - TLS encryption
- Authentication (basic auth, API keys, or token-based)
- Optional client certificate authentication | -| [{{kib}}-to-{{es}}](#kib-to-es-communications) | Communication from the {{kib}} server to {{es}} for user requests and queries | - TLS encryption
- Service authentication (API keys, service tokens, or mutual TLS) | +Additionally, {{kib}} functions as a web server, exposing its own **HTTP endpoint** to users, and also acts as a client when sending requests to {{es}}. + +To ensure secure operation, it’s important to understand the communication channels and their specific security requirements. +| **Channel** | **Description** | **TLS requirements** | +|-------------|-----------------|--------------------| +| [{{es}} transport layer](#transport-layer-security) | Communication between {{es}} nodes within a cluster | Mutual TLS/SSL required for multi-node clusters | +| [{{es}} HTTP layer](#http-layer-security) | Communication between external clients and {{es}} through the REST API | TLS/SSL optional (but recommended) | +| [{{kib}} HTTP layer](#http-layer-security) | Communication between external browsers and {{kib}} through the REST API | TLS/SSL optional (but recommended) | -## Transport layer security +### Transport layer security -The transport layer is used for communication between {{es}} nodes in a cluster. Securing this layer prevents unauthorized nodes from joining your cluster and protects internode data. +The transport layer is responsible for internal communication between {{es}} nodes in the cluster. Securing this layer prevents unauthorized nodes from joining your cluster and protects internode traffic. The way that transport layer security is managed depends on your deployment type: -- **ECH, ECE, and Serverless**: Transport security is fully managed by Elastic. No configuration is required. -- **ECK**: Transport security is automatically configured by the operator, but you can [customize its service and SSL certificates](/deploy-manage/security/k8s-transport-settings.md). -- **Self-managed**: Transport security must be manually configured following the steps in [Set up basic security](set-up-basic-security.md). +::::{tab-set} + +:::{tab-item} ECH and Serverless +{{es}} transport security is fully managed by Elastic, and no configuration is required. +::: + +:::{tab-item} ECE +{{es}} transport security is fully managed by {{ece}} platform, and no configuration is required. +::: + +:::{tab-item} ECK +{{es}} transport security and TLS certificates are automatically configured by the operator, but you can still [customize its service and CA certificates](/deploy-manage/security/k8s-transport-settings.md). +::: + +:::{tab-item} Self-managed +{{es}} transport security can be [automatically configured](security-certificates-keys.md), or manually set up by following the steps in [Set up basic security](set-up-basic-security.md). +::: + +:::: -## HTTP layer security +### HTTP layer security -The HTTP layer secures client communication with your {{es}} cluster via its REST API, preventing unauthorized access and protecting data in transit. +The HTTP layer includes the service endpoints exposed by both {{es}} and {{kib}}, supporting communications such as REST API requests, browser access to {{kib}}, and {{kib}}’s own traffic to {{es}}. Securing these endpoints helps prevent unauthorized access and protects sensitive data in transit. + +::::{important} +While HTTP TLS encryption is optional in self-managed environments, it is strongly recommended for both production and non-production deployments. Even in non-production environments, unsecured endpoints can expose sensitive data or introduce avoidable risks. +:::: The way that HTTP layer security is managed depends on your deployment type: -- **ECH and Serverless**: HTTP security is fully managed by Elastic. No configuration is required. -- **ECE**: HTTP security is automatically enforced at ECE proxies using self-signed certificates and a default [wildcard DNS record](/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md). However, it's recommended to [configure your own certificates](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). -- **ECK**: HTTP security is automatically configured with self-signed certificates. [Custom certificates and domain names can be configured](/deploy-manage/security/secure-http-communications.md#k8s-custom-http-certificate). -- **Self-managed**: HTTP security must be manually configured following [](secure-http-communications.md). +::::{tab-set} -## {{kib}}-to-{{es}} communications +:::{tab-item} ECH and Serverless +HTTP TLS for {{es}} and {{kib}} is fully managed by Elastic. No configuration is required. +{{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. +::: -{{kib}} connects to {{es}} as a client but requires special configuration as it performs operations on behalf of end users. +:::{tab-item} ECE +HTTP TLS for deployments is managed at the platform proxy level. Refer to these guides for ECE-specific security customizations: +* [Manage security certificates in ECE](./secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) +* [Allow x509 Certificates Signed with SHA-1](./secure-your-elastic-cloud-enterprise-installation/allow-x509-certificates-signed-with-sha-1.md) +* [Configure TLS version](./secure-your-elastic-cloud-enterprise-installation/configure-tls-version.md) -The way that {{kib}}-to-{{es}} communication security is managed depends on your deployment type: +{{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. +::: -- **ECH and Serverless**: {{kib}}-{{es}} communication is fully managed using HTTPS and service tokens. -- **ECE and ECK**: {{kib}}-{{es}} communication is automatically secured with service tokens. -- **Self-managed**: {{kib}}-{{es}} communication must be manually secured. For mutual TLS configuration, refer to [Mutual TLS authentication between {{kib}} and {{es}}](secure-http-communications.md#elasticsearch-mutual-tls). +:::{tab-item} ECK +HTTP TLS is automatically enabled for {{es}} and {{kib}} using self-signed certificates, with [several options available for customization](./k8s-https-settings.md), including custom certificates and domain names. + +{{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. +::: + +:::{tab-item} Self-managed +HTTP TLS certificates for {{es}} can be [automatically configured](security-certificates-keys.md), or manually set up by following the steps in [Set up HTTP SSL](./set-up-basic-security-plus-https.md). + +{{kib}} acts as both an HTTP client to {{es}} and a server for browser access. It performs operations on behalf of users, so it must be properly configured to trust the {{es}} certificates, and to present its own TLS certificate for secure browser connections. These configurations must be performed manually in self-managed deployments. + +For environments with stricter security requirements, refer to [Mutual TLS authentication between {{kib}} and {{es}}](secure-http-communications.md#elasticsearch-mutual-tls). +::: -## Certificate management [generate-certificates] +:::: -Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. +## Maintaining and rotating TLS certificates [generate-certificates] -The way that you manage certificates depends on your deployment type: +Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. Each deployment type provides different tools or responsibilities for managing certificates lifecycle. -- **ECH and Serverless**: Certificate management is fully automated by Elastic. -- **ECE**: ECE generates certificates for you. Refer to [](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). -- **ECK**: ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. -- **Self-managed**: Certificate management is your responsibility. See [Security certificates and keys](security-certificates-keys.md). +::::{tab-set} -## Next steps +:::{tab-item} ECH and Serverless +Certificate lifecycle is fully managed by Elastic, including renewal and rotation. +::: + +:::{tab-item} ECE +In ECE, the platform automatically renews internal certificates. However, you must manually renew your custom proxy and Cloud UI certificates. For more details, refer to [Manage security certificates](secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). +::: + +:::{tab-item} ECK +ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. + +TBD, add links to cert validity settings and cert configuration +::: + +:::{tab-item} Self-managed +You are responsible for certificate lifecycle management, including monitoring expiration dates, renewing certificates, and redeploying them as needed. If you used Elastic tools to generate your certificates, refer to [Update TLS certificates](./updating-certificates.md) for guidance on rotating or replacing them. +::: -- Configure [basic security and HTTPS](set-up-basic-security-plus-https.md) for self-managed deployments. -- Learn about [HTTP communication security](secure-http-communications.md) best practices. -- Understand how to securely manage [security certificates and keys](security-certificates-keys.md). -- Check [SSL/TLS version compatibility](supported-ssltls-versions-by-jdk-version.md) for optimal encryption. +:::: diff --git a/deploy-manage/security/secure-cluster-communications.md.backup b/deploy-manage/security/secure-cluster-communications.md.backup new file mode 100644 index 0000000000..0105bba785 --- /dev/null +++ b/deploy-manage/security/secure-cluster-communications.md.backup @@ -0,0 +1,172 @@ +--- +navigation_title: Manage TLS certificates +applies_to: + deployment: + self: + eck: + ece: +mapped_urls: + - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-security.html + - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html + - https://www.elastic.co/guide/en/kibana/current/elasticsearch-mutual-tls.html +--- + + +% TODO: what to do about this page that doesn't exist +% * [/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-security.md](/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-security.md) + +$$$encrypt-internode-communication$$$ +$$$generate-certificates$$$ + + +# Manage TLS certificates + +This page explains how to secure communications between components in your {{stack}} deployment. + +For {{ech}} and {{serverless-full}} deployments, communications security is fully managed by Elastic with no configuration required. + +For ECE, ECK, and self-managed deployments, this page provides specific configuration guidance to secure the various communication channels between components. + +:::{tip} +For a complete comparison of security feature availability and responsibility by deployment type, see [Security features by deployment type](/deploy-manage/security.md#comparison-table). +::: + + +## Communication channels overview + +Your {{stack}} deployment includes several distinct communication channels that must be secured to protect your data and infrastructure. + +| **Channel** | **Description** | **Security needs** | +|-------------|-----------------|--------------------| +| [Transport layer](#transport-layer-security) | Communication between {{es}} nodes within a cluster | - Mutual TLS (required)
- Node authentication
- Node role verification | +| [HTTP layer](#http-layer-security) | Communication between external clients and {{es}} through the REST API | - TLS encryption
- Authentication (basic auth, API keys, or token-based)
- Optional client certificate authentication | +| [{{kib}}-to-{{es}}](#kib-to-es-communications) | Communication from the {{kib}} server to {{es}} for user requests and queries | - TLS encryption
- Service authentication (API keys, service tokens, or mutual TLS) | + + +## Transport layer security + +The transport layer is used for communication between {{es}} nodes in a cluster. Securing this layer prevents unauthorized nodes from joining your cluster and protects internode data. + +The way that transport layer security is managed depends on your deployment type: + +- **ECH, ECE, and Serverless**: Transport security is fully managed by Elastic. No configuration is required. +- **ECK**: Transport security is automatically configured by the operator, but you can [customize its service and SSL certificates](/deploy-manage/security/k8s-transport-settings.md). +- **Self-managed**: Transport security must be manually configured following the steps in [Set up basic security](set-up-basic-security.md). + +## HTTP layer security + +The HTTP layer secures client communication with your {{es}} cluster via its REST API, preventing unauthorized access and protecting data in transit. + +The way that HTTP layer security is managed depends on your deployment type: + +- **ECH and Serverless**: HTTP security is fully managed by Elastic. No configuration is required. +- **ECE**: HTTP security is automatically enforced at ECE proxies using self-signed certificates and a default [wildcard DNS record](/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md). However, it's recommended to [configure your own certificates](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). +- **ECK**: HTTP security is automatically configured with self-signed certificates. [Custom certificates and domain names can be configured](/deploy-manage/security/secure-http-communications.md#k8s-custom-http-certificate). +- **Self-managed**: HTTP security must be manually configured following [](secure-http-communications.md). + +## {{kib}}-to-{{es}} communications + +{{kib}} connects to {{es}} as a client but requires special configuration as it performs operations on behalf of end users. + +The way that {{kib}}-to-{{es}} communication security is managed depends on your deployment type: + +- **ECH and Serverless**: {{kib}}-{{es}} communication is fully managed using HTTPS and service tokens. +- **ECE and ECK**: {{kib}}-{{es}} communication is automatically secured with service tokens. +- **Self-managed**: {{kib}}-{{es}} communication must be manually secured. For mutual TLS configuration, refer to [Mutual TLS authentication between {{kib}} and {{es}}](secure-http-communications.md#elasticsearch-mutual-tls). + +## Certificate management [generate-certificates] + +Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. + +The way that you manage certificates depends on your deployment type: + +- **ECH and Serverless**: Certificate management is fully automated by Elastic. +- **ECE**: ECE generates certificates for you. Refer to [](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). +- **ECK**: ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. +- **Self-managed**: Certificate management is your responsibility. See [Security certificates and keys](security-certificates-keys.md). + +## Next steps + +- Configure [basic security and HTTPS](set-up-basic-security-plus-https.md) for self-managed deployments. +- Learn about [HTTP communication security](secure-http-communications.md) best practices. +- Understand how to securely manage [security certificates and keys](security-certificates-keys.md). +- Check [SSL/TLS version compatibility](supported-ssltls-versions-by-jdk-version.md) for optimal encryption. + +## IMPORTED CONTENT STARTS + +## Overview HTTP security + +Securing HTTP communications is essential for protecting data transmitted between: + +- {{kib}} and {{es}} +- {{kib}} and web browsers +- External monitoring systems and {{es}} +- Any HTTP client and your {{stack}} deployment + +Different deployment types have different requirements: + +| Deployment Type | HTTP Security Configuration | +|-----------------|----------------------------| +| {{ech}}/{{serverless-short}} | Automatically configured | +| Self-managed | Manual configuration required | +| {{eck}} | Configurable with defaults | +| {{ece}} | Manual configuration required | + +## Self-managed deployments + +```{applies_to} +self: +``` + +For self-managed deployments, you need to generate and configure certificates for secure HTTP communications. + +### Prerequisites + +Complete all steps in: + +- [Set up basic security](/deploy-manage/security/set-up-basic-security.md) +- [](/deploy-manage/security/set-up-basic-security-plus-https.md) + +### Mutual TLS removed + + +## Securing client applications + +When connecting client applications to {{es}}, use these best practices: + +- Always use HTTPS for all connections +- Validate server certificates to prevent man-in-the-middle attacks +- Use API keys or token-based authentication rather than basic auth where possible +- Implement appropriate connection pooling and retry mechanisms +- Consider mutual TLS for high-security environments + +For code examples and library-specific guidance, see [HTTP/REST client security](httprest-clients-security.md). + +## Securing Beats connections + +% TODO: Put in clients section + +When sending data from Beats to Elasticsearch, you need to secure those communications with TLS and proper authentication. + +Key configuration requirements: +- Configure Beats to use HTTPS when connecting to Elasticsearch +- Set up appropriate authentication (API keys recommended) +- Verify Elasticsearch server certificates + +For detailed instructions on configuring Beats security settings, see [Configure Beats security](/deploy-manage/security/set-up-basic-security-plus-https.md#configure-beats-security). + + + +## {{ece}} (ECE) + +```{applies_to} +deployment: + ece: all +``` + +For ECE deployments, certificate management and TLS configuration are handled at the platform level. Refer to these guides for ECE-specific security configurations: + +- [Manage security certificates in ECE](secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) +- [Allow x509 Certificates Signed with SHA-1](secure-your-elastic-cloud-enterprise-installation/allow-x509-certificates-signed-with-sha-1.md) +- [Configure TLS version](secure-your-elastic-cloud-enterprise-installation/configure-tls-version.md) + diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index f7379b464f..972e4cd769 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -13,43 +13,52 @@ mapped_pages: It's important to protect your {{es}} cluster and the data it contains. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. -From shaina include: :::{include} /deploy-manage/security/_snippets/complete-security.md +::: + +:::{important} +* Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. +* Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. +::: -$$$install-stack-demo-secure-ca$$$ +:::{tip} +You must secure [other {{stack}} components](/deploy-manage/security/secure-clients-integrations.md), as well as [client and integration communications](/deploy-manage/security/httprest-clients-security.md), separately. +::: -$$$install-stack-demo-secure-fleet$$$ +You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: -$$$install-stack-demo-secure-http$$$ +## Security activation [manually-configure-security] -$$$install-stack-demo-secure-kib-es$$$ +% Intro to link automatic setup and manual setup process of security -$$$install-stack-demo-secure-prereqs$$$ +Everything starts with the security feature activation in {{es}}, which enables authentication and authorization, TLS encryption of communications, and all other security related functionality described in this section. -$$$install-stack-demo-secure-second-node$$$ +::::{note} +Orchestrated deployments automatically configures security by default, the elastic user password, TLS certificates, and configure {{kib}} to access {{es}} in a secure way. Disabling security is not an option in managed deployments. +:::: -$$$install-stack-demo-secure-transport$$$ +Since {{es}} 8.0, security is enabled and configured by default. However, security auto configuration [might be skipped](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md#stack-skip-auto-configuration) in certain scenarios. In these cases, you can [manually configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md). -$$$install-stack-demo-secure-view-data$$$ +In self-managed clusters, there are two ways to perform the initial security setup, depending on your needs: -$$$security-configure-settings$$$ +* Automatic security setup: {{es}} security requires TLS certificates to be configured for inter-node communications (transport layer), and in order to facilitate the initial setup, there's an automatic configuration. +* Manual security setup: If you are configuring security in an unsecured cluster, or if you want to use your own certificates, you can follow the manual approach, which consists of three steps, depending whether your cluster is a single-node or multi-node cluster: + * Minimal security + * Basic transport TLS security: for multi-node clusters only, as single-node clusters don't need to talk with other nodes. + * HTTP TLS: optional but highly recommended -Protecting your {{es}} cluster and the data it contains is of utmost importance. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. +Refer to [skipxxxx]() to understand in what cases autoconfiguration works and when a manual configuration will be expected. -:::{important} -Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. -::: +Kibana also supports HTTPS. -To secure your clusters and deployments, consider the following: +Mutual authentication is also an option. -## Security activation and requirements +### Security basics (a decidir) -Not needed in orchestrated deployments. -Automatically or manually, links +For {{es}} to be able to start with security enabled, the following is necessary: -minimam / basic / HTTPS single nodes and multiple-nodes. What is required, what is optional. Single-node vs multi-node @@ -57,19 +66,10 @@ Consider Kibana HTTPS Security gives access to users and roles and certificates, links -copying here the original content that we will probably discard! - -:::{note} -This page describes important aspects to consider and common end-to-end scenarios for securing your self-managed {{stack}}. For a more granular view of the available security options for your clusters and nodes, refer to [](secure-your-cluster-deployment.md). -::: - Security needs vary depending on whether you’re developing locally on your laptop or securing all communications in a production environment. Regardless of where you’re deploying the {{stack}} ("ELK"), running a secure cluster is incredibly important to protect your data. That’s why security is [enabled and configured by default](../deploy/self-managed/installing-elasticsearch.md) since {{es}} 8.0. -## Common security scenarios +A decidir esto tambien: -:::{image} /deploy-manage/images/elasticsearch-reference-elastic-security-overview.png -:alt: Elastic Security layers -::: ### Minimal security ({{es}} Development) [security-minimal-overview] @@ -99,57 +99,9 @@ If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. -[Set up basic security plus HTTPS traffic](secure-http-communications.md) - - - - - -## Network access - -Control which systems can access your Elastic deployments and clusters through traffic filtering and network controls: - -- **IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges. -- **Private link filters**: Secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. -- **Static IPs**: Use static IP addresses for predictable firewall rules. -- **Remote cluster access**: Secure cross-cluster operations. - -Refer to [](traffic-filtering.md). - - -## Cluster communication - -- **HTTP and HTTPs** -- **TLS certificates and keys** - - -## Data, objects and settings security - -- **Bring your own encryption key**: Use your own encryption key instead of the default encryption at rest provided by Elastic. -- **{{es}} and {{kib}} keystores**: Secure sensitive settings using keystores -- **{{kib}} saved objects**: Customize the encryption for {{kib}} objects such as dashboards. -- **{{kib}} session management**: Customize {{kib}} session expiration settings. - -Refer to [](data-security.md). - -## User roles - -[Define roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request. - -:::{important} -Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. -::: - -:::{important} -* Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. -* Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. -::: +[Set up basic security plus HTTPS traffic](secure-cluster-communications.md) -:::{tip} -You must secure [other {{stack}} components](/deploy-manage/security/secure-clients-integrations.md), as well as [client and integration communications](/deploy-manage/security/httprest-clients-security.md), separately. -::: -You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: ## Communication and network security @@ -171,10 +123,6 @@ You can configure the following aspects of your Elastic cluster or deployment to :::{include} /deploy-manage/security/_snippets/audit-logging.md ::: -## Configure security in a self-managed cluster - -Since {{es}} 8.0, security is enabled and configured by default. However, security auto configuration [might be skipped](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md#stack-skip-auto-configuration) in certain scenarios. In these cases, you can [manually configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md). - ## FIPS 140-2 compliant mode ```{applies_to} deployment: @@ -192,4 +140,73 @@ The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB ## Security features by deployment type [comparison-table] :::{include} /deploy-manage/security/_snippets/cluster-comparison.md -::: \ No newline at end of file +::: + +## Old content + +### Common security scenarios + +:::{image} /deploy-manage/images/elasticsearch-reference-elastic-security-overview.png +:alt: Elastic Security layers +::: + +#### Minimal security ({{es}} Development) [security-minimal-overview] + +::::{important} +The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. +:::: + +If you’ve been working with {{es}} and want to enable security on your existing, unsecured cluster, start here. You’ll set passwords for the built-in users to prevent unauthorized access to your local cluster, and also configure password authentication for {{kib}}. + +[Set up minimal security](set-up-minimal-security.md) + +#### Basic security ({{es}} + {{kib}}) [security-basic-overview] + +This scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your {{es}} cluster. + +Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but internode communication will be secured. + +[Set up basic security](secure-cluster-communications.md) + +#### Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview] + +This scenario builds on the one for basic security and secures all HTTP traffic with TLS. In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. + +::::{note} +If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption. +:::: + +You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. + +[Set up basic security plus HTTPS traffic](secure-cluster-communications.md) + +### Network access + +Control which systems can access your Elastic deployments and clusters through traffic filtering and network controls: + +- **IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges. +- **Private link filters**: Secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. +- **Static IPs**: Use static IP addresses for predictable firewall rules. +- **Remote cluster access**: Secure cross-cluster operations. + +Refer to [](traffic-filtering.md). + + +### Cluster communication + +- **HTTP and HTTPs** +- **TLS certificates and keys** + + +### Data, objects and settings security + +- **Bring your own encryption key**: Use your own encryption key instead of the default encryption at rest provided by Elastic. +- **{{es}} and {{kib}} keystores**: Secure sensitive settings using keystores +- **{{kib}} saved objects**: Customize the encryption for {{kib}} objects such as dashboards. +- **{{kib}} session management**: Customize {{kib}} session expiration settings. + +Refer to [](data-security.md). + +### User roles + +[Define roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request. diff --git a/deploy-manage/security/secure-your-cluster-deployment.md.backup b/deploy-manage/security/secure-your-cluster-deployment.md.backup new file mode 100644 index 0000000000..e7530b0e60 --- /dev/null +++ b/deploy-manage/security/secure-your-cluster-deployment.md.backup @@ -0,0 +1,213 @@ +--- +applies_to: + deployment: + self: ga + eck: all + ece: all + ess: all +mapped_pages: + - https://www.elastic.co/guide/en/elasticsearch/reference/current/manually-configure-security.html +--- + +# Secure your cluster or deployment + +It's important to protect your {{es}} cluster and the data it contains. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. + +:::{include} /deploy-manage/security/_snippets/complete-security.md +::: + +:::{important} +* Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. +* Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. +::: + +:::{tip} +You must secure [other {{stack}} components](/deploy-manage/security/secure-clients-integrations.md), as well as [client and integration communications](/deploy-manage/security/httprest-clients-security.md), separately. +::: + +You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: + +## Security activation [manually-configure-security] + +% Intro to link automatic setup and manual setup process of security + +Everything starts with the security feature activation in {{es}}, which enables authentication and authorization, TLS encryption of communications, and all other security related functionality described in this section. + +::::{note} +Orchestrated deployments automatically configures security by default, the elastic user password, TLS certificates, and configure {{kib}} to access {{es}} in a secure way. Disabling security is not an option in managed deployments. +:::: + +In self-managed clusters, there are two ways to perform the initial security setup, depending on your needs: + +* Automatic security setup: {{es}} security requires TLS certificates to be configured for inter-node communications (transport layer), and in order to facilitate the initial setup, there's an automatic configuration. + +* Manual security setup: If you are configuring security in an unsecured cluster, or if you want to use your own certificates, you can follow the manual approach, which consists of three steps, depending whether your cluster is a single-node or multi-node cluster: + * Minimal security + * Basic transport TLS security: for multi-node clusters only, as single-node clusters don't need to talk with other nodes. + * HTTP TLS: optional but highly recommended + +Refer to [skipxxxx]() to understand in what cases autoconfiguration works and when a manual configuration will be expected. + +Kibana also supports HTTPS. + +Mutual authentication is also an option. + +### Security basics (a decidir) + +For {{es}} to be able to start with security enabled, the following is necessary: + + +single nodes and multiple-nodes. +What is required, what is optional. Single-node vs multi-node +Consider Kibana HTTPS + +Security gives access to users and roles and certificates, links + +Security needs vary depending on whether you’re developing locally on your laptop or securing all communications in a production environment. Regardless of where you’re deploying the {{stack}} ("ELK"), running a secure cluster is incredibly important to protect your data. That’s why security is [enabled and configured by default](../deploy/self-managed/installing-elasticsearch.md) since {{es}} 8.0. + +A decidir esto tambien: + + +### Minimal security ({{es}} Development) [security-minimal-overview] + +::::{important} +The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. +:::: + +If you’ve been working with {{es}} and want to enable security on your existing, unsecured cluster, start here. You’ll set passwords for the built-in users to prevent unauthorized access to your local cluster, and also configure password authentication for {{kib}}. + +[Set up minimal security](set-up-minimal-security.md) + +### Basic security ({{es}} + {{kib}}) [security-basic-overview] + +This scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your {{es}} cluster. + +Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but internode communication will be secured. + +[Set up basic security](secure-cluster-communications.md) + +### Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview] + +This scenario builds on the one for basic security and secures all HTTP traffic with TLS. In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. + +::::{note} +If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption. +:::: + +You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. + +[Set up basic security plus HTTPS traffic](secure-http-communications.md) + + + +## Communication and network security + +:::{include} /deploy-manage/security/_snippets/cluster-communication-network.md +::: + +## Data security + +:::{include} /deploy-manage/security/_snippets/cluster-data.md +::: + +## User session security + +:::{include} /deploy-manage/security/_snippets/cluster-user-session.md +::: + +## Security event audit logging + +:::{include} /deploy-manage/security/_snippets/audit-logging.md +::: + +## Configure security in a self-managed cluster + +Since {{es}} 8.0, security is enabled and configured by default. However, security auto configuration [might be skipped](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md#stack-skip-auto-configuration) in certain scenarios. In these cases, you can [manually configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md). + +## FIPS 140-2 compliant mode +```{applies_to} +deployment: + self: + eck: +``` + +The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB 140-2), titled "Security Requirements for Cryptographic Modules" is a U.S. government computer security standard used to approve cryptographic modules. You can run a self-managed cluster or {{eck}} cluster in FIPS-compliant mode: + +* [Self-managed](/deploy-manage/security/fips-140-2.md) +* [ECK](/deploy-manage/deploy/cloud-on-k8s/deploy-fips-compatible-version-of-eck.md) + +% we need to refine this table, but the idea is awesome IMO + +## Security features by deployment type [comparison-table] + +:::{include} /deploy-manage/security/_snippets/cluster-comparison.md +::: + +## Old content + +### Common security scenarios + +:::{image} /deploy-manage/images/elasticsearch-reference-elastic-security-overview.png +:alt: Elastic Security layers +::: + +#### Minimal security ({{es}} Development) [security-minimal-overview] + +::::{important} +The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. +:::: + +If you’ve been working with {{es}} and want to enable security on your existing, unsecured cluster, start here. You’ll set passwords for the built-in users to prevent unauthorized access to your local cluster, and also configure password authentication for {{kib}}. + +[Set up minimal security](set-up-minimal-security.md) + +#### Basic security ({{es}} + {{kib}}) [security-basic-overview] + +This scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your {{es}} cluster. + +Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but internode communication will be secured. + +[Set up basic security](secure-cluster-communications.md) + +#### Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview] + +This scenario builds on the one for basic security and secures all HTTP traffic with TLS. In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. + +::::{note} +If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption. +:::: + +You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. + +[Set up basic security plus HTTPS traffic](secure-http-communications.md) + +### Network access + +Control which systems can access your Elastic deployments and clusters through traffic filtering and network controls: + +- **IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges. +- **Private link filters**: Secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. +- **Static IPs**: Use static IP addresses for predictable firewall rules. +- **Remote cluster access**: Secure cross-cluster operations. + +Refer to [](traffic-filtering.md). + + +### Cluster communication + +- **HTTP and HTTPs** +- **TLS certificates and keys** + + +### Data, objects and settings security + +- **Bring your own encryption key**: Use your own encryption key instead of the default encryption at rest provided by Elastic. +- **{{es}} and {{kib}} keystores**: Secure sensitive settings using keystores +- **{{kib}} saved objects**: Customize the encryption for {{kib}} objects such as dashboards. +- **{{kib}} session management**: Customize {{kib}} session expiration settings. + +Refer to [](data-security.md). + +### User roles + +[Define roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request. diff --git a/deploy-manage/security/security-certificates-keys.md b/deploy-manage/security/security-certificates-keys.md index 771954ae42..e1cadfad49 100644 --- a/deploy-manage/security/security-certificates-keys.md +++ b/deploy-manage/security/security-certificates-keys.md @@ -8,7 +8,7 @@ mapped_pages: % Scope: Automatic setup % Original title: Start the Elastic Stack with security enabled automatically -# Self-managed certificates and keys [configuring-stack-security] +# Automatic security setup [configuring-stack-security] When you start {{es}} for the first time, the following security configuration occurs automatically: diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index e934ef2e6d..baf2a49936 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -1,5 +1,5 @@ --- -navigation_title: "Basic / HTTP SSL" +navigation_title: "Set up HTTP TLS" applies_to: deployment: self: ga @@ -10,10 +10,14 @@ mapped_pages: % Scope: HTTP certificates setup / manual configuration / multi or single node cluster % original title: Set up basic security for the Elastic Stack plus secured HTTPS traffic -# Set up basic security plus HTTPS [security-basic-setup-https] +# Set up HTTP TLS [security-basic-setup-https] +Enabling TLS on the HTTP layer ensures that all client communications with your cluster are encrypted, providing an additional layer of security. -When you enable TLS on the HTTP layer it provides an additional layer of security to ensure that all communications to and from your cluster are encrypted. +This documents describes the following topics: +- Generate and configure TLS certificates for {{es}} HTTP endpoint +- How to configure {{kib}} to connect to {{es}} using HTTPS, and adding the CA certificate of {{es}} to the list of trusted CAs in {{kib}} +- Generate and configure TLS certificate for {{kib}} using When you run the `elasticsearch-certutil` tool in `http` mode, the tool asks several questions about how you want to generate certificates. While there are numerous options, the following choices result in certificates that should work for most environments. @@ -34,16 +38,17 @@ If you work in an environment with a central security team, they can likely gene :::: - ## Prerequisites [basic-setup-https-prerequisites] -Complete all steps in [Set up basic security for the Elastic Stack](secure-cluster-communications.md). +If security feature wasn't already enabled in your cluster, complete all steps in [Manual security setup](./set-up-minimal-security.md). +## Generate and configure TLS certificates for {{es}} nodes [encrypt-http-communication] -## Encrypt HTTP client communications for {{es}} [encrypt-http-communication] +% Encrypt HTTP client communications for {{es}} +Doing this will encrypt all client communications with the cluster. Clients will have to be configured to use `https` protocol when connecting to {{es}}, and will need the CA certificate associated to the {{es}} certificates for trusting purposes. 1. On **every** node in your cluster, stop {{es}} and {{kib}} if they are running. -2. On any single node, from the directory where you installed {{es}}, run the {{es}} HTTP certificate tool to generate a Certificate Signing Request (CSR). +2. On any single node, from the directory where you installed {{es}}, run the {{es}} HTTP certificate tool to generate TLS certificates for your nodes. ```shell ./bin/elasticsearch-certutil http @@ -106,103 +111,34 @@ Complete all steps in [Set up basic security for the Elastic Stack](secure-clust **Next**: [Encrypt HTTP client communications for {{kib}}](#encrypt-kibana-http) - ## Encrypt HTTP client communications for {{kib}} [encrypt-kibana-http] Browsers send traffic to {{kib}} and {{kib}} sends traffic to {{es}}. These communication channels are configured separately to use TLS. You encrypt traffic between {{kib}} and {{es}}, and then encrypt traffic between your browser and {{kib}}. -### Encrypt traffic between {{kib}} and {{es}} [encrypt-kibana-elasticsearch] - -When you ran the `elasticsearch-certutil` tool with the `http` option, it created a `/kibana` directory containing an `elasticsearch-ca.pem` file. You use this file to configure {{kib}} to trust the {{es}} CA for the HTTP layer. - -1. Copy the `elasticsearch-ca.pem` file to the {{kib}} configuration directory, as defined by the `$KBN_PATH_CONF` path. -2. Open `kibana.yml` and add the following line to specify the location of the security certificate for the HTTP layer. - - ```yaml - elasticsearch.ssl.certificateAuthorities: $KBN_PATH_CONF/elasticsearch-ca.pem - ``` - -3. Add the following line to specify the HTTPS URL for your {{es}} cluster. - - ```yaml - elasticsearch.hosts: https://:9200 - ``` - -4. Restart {{kib}}. - -:::::{admonition} Connect to a secure monitoring cluster -If the Elastic monitoring features are enabled and you configured a separate {{es}} monitoring cluster, you can also configure {{kib}} to connect to the monitoring cluster via HTTPS. The steps are the same, but each setting is prefixed by `monitoring`. For example, `monitoring.ui.elasticsearch.hosts` and `monitoring.ui.elasticsearch.ssl.truststore.path`. - -::::{note} -You must create a separate `elasticsearch-ca.pem` security file for the monitoring cluster. -:::: +{{kib}} handles two separate types of HTTP traffic that should be encrypted: +* Outgoing traffic from {{kib}} to {{es}} – {{kib}} acts as an HTTP client and must be configured to trust the TLS certificate used by {{es}}. +* Incoming traffic from browsers to {{kib}} – {{kib}} also acts as an HTTP server, and you should configure a TLS certificate for its public-facing endpoint to secure browser access. -::::: +### Encrypt traffic between {{kib}} and {{es}} [encrypt-kibana-elasticsearch] +:::{include} /deploy-manage/security/_snippets/kibana-client-https-setup.md +::: **Next**: [Encrypt traffic between your browser and {{kib}}](#encrypt-kibana-browser) ### Encrypt traffic between your browser and {{kib}} [encrypt-kibana-browser] -You create a server certificate and private key for {{kib}}. {{kib}} uses this server certificate and corresponding private key when receiving connections from web browsers. - -When you obtain a server certificate, you must set its subject alternative name (SAN) correctly to ensure that browsers will trust it. You can set one or more SANs to the {{kib}} server’s fully-qualified domain name (FQDN), hostname, or IP address. When choosing the SAN, pick whichever attribute you’ll use to connect to {{kib}} in your browser, which is likely the FQDN. - -The following instructions create a Certificate Signing Request (CSR) for {{kib}}. A CSR contains information that a CA uses to generate and sign a security certificate. The certificate can be trusted (signed by a public, trusted CA) or untrusted (signed by an internal CA). A self-signed or internally-signed certificate is acceptable for development environments and building a proof of concept, but should not be used in a production environment. - -::::{warning} -Before going to production, use a trusted CA such as [Let’s Encrypt](https://letsencrypt.org/) or your organization’s internal CA to sign the certificate. Using a signed certificate establishes browser trust for connections to {{kib}} for internal access or on the public internet. -:::: - - -1. Generate a server certificate and private key for {{kib}}. - - ```shell - ./bin/elasticsearch-certutil csr -name kibana-server -dns example.com,www.example.com - ``` - - The CSR has a common name (CN) of `kibana-server`, a SAN of `example.com`, and another SAN of `www.example.com`. - - This command generates a `csr-bundle.zip` file by default with the following contents: - - ```txt - /kibana-server - |_ kibana-server.csr - |_ kibana-server.key - ``` - -2. Unzip the `csr-bundle.zip` file to obtain the `kibana-server.csr` unsigned security certificate and the `kibana-server.key` unencrypted private key. -3. Send the `kibana-server.csr` certificate signing request to your internal CA or trusted CA for signing to obtain a signed certificate. The signed file can be in different formats, such as a `.crt` file like `kibana-server.crt`. -4. Open `kibana.yml` and add the following lines to configure {{kib}} to access the server certificate and unencrypted private key. - - ```yaml - server.ssl.certificate: $KBN_PATH_CONF/kibana-server.crt - server.ssl.key: $KBN_PATH_CONF/kibana-server.key - ``` - - ::::{note} - `$KBN_PATH_CONF` contains the path for the {{kib}} configuration files. If you installed {{kib}} using archive distributions (`zip` or `tar.gz`), the path defaults to `$KBN_HOME/config`. If you used package distributions (Debian or RPM), the path defaults to `/etc/kibana`. - :::: - -5. Add the following line to `kibana.yml` to enable TLS for inbound connections. - - ```yaml - server.ssl.enabled: true - ``` - -6. Start {{kib}}. - -::::{note} -After making these changes, you must always access {{kib}} via HTTPS. For example, `https://.com`. -:::: +In order to ensure clients communication to {{kib}} are encrypted, you have to create a TLS certificate for {{kib}} and, the same way as with {{es}}, configure the clients to use `https` when connecting to {{kib}} and trust the CA used to sign {{kib}} certificate. +(WORK IN PROGRESS) +:::{include} /deploy-manage/security/_snippets/kibana-https-setup.md +::: **Next**: [Configure {{beats}} security](#configure-beats-security) - - +% All this should be already in beats repository, including roles, etc ## Configure {{beats}} security [configure-beats-security] {{beats}} are open source data shippers that you install as agents on your servers to send operational data to {{es}}. Each Beat is a separately installable product. The following steps cover configuring security for {{metricbeat}}. Follow these steps for each [additional Beat](beats://reference/index.md) you want to configure security for. diff --git a/deploy-manage/security/set-up-basic-security.md b/deploy-manage/security/set-up-basic-security.md index 6eaa465233..ce779200b9 100644 --- a/deploy-manage/security/set-up-basic-security.md +++ b/deploy-manage/security/set-up-basic-security.md @@ -1,5 +1,5 @@ --- -navigation_title: "Basic / Transport SSL" +navigation_title: "Set up transport TLS" applies_to: deployment: self: ga @@ -7,18 +7,17 @@ mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html --- - % Scope: TLS certificates setup / multi-node cluster / manual configuration % original title: Set up basic security for the Elastic Stack -# Set up basic security [security-basic-setup] - +# Set up transport TLS [security-basic-setup] When you start {{es}} for the first time, passwords are generated for the `elastic` user and TLS is automatically configured for you. If you configure security manually *before* starting your {{es}} nodes, the auto-configuration process will respect your security configuration. You can adjust your TLS configuration at any time, such as [updating node certificates](updating-certificates.md). ::::{important} If your cluster has multiple nodes, then you must configure TLS between nodes. [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. -:::: +This document focuses on manual configuration of the TLS certificates for multi-node clusters. Single node clusters do not require transport TLS. +:::: The transport layer relies on mutual TLS for both encryption and authentication of nodes. Correctly applying TLS ensures that a malicious node cannot join the cluster and exchange data with other nodes. While implementing username and password authentication at the HTTP layer is useful for securing a local cluster, the security of communication between nodes requires TLS. diff --git a/deploy-manage/security/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index bdcf4ff42d..9dbcf03cca 100644 --- a/deploy-manage/security/set-up-minimal-security.md +++ b/deploy-manage/security/set-up-minimal-security.md @@ -1,5 +1,5 @@ --- -navigation_title: "Secure an unsecured cluster" +navigation_title: "Manual security setup" applies_to: deployment: self: ga @@ -10,7 +10,7 @@ mapped_pages: % alternative title: Manual security setup % Scope: Just enabling security, resetting passwords, and configuring kibana. Manual approach, opposite to automatic security configuration % Original title: Set up minimal security -# Set up minimal security [security-minimal-setup] +# Manual security setup [security-minimal-setup] ::::{important} You only need to complete the following steps if you’re running an existing, unsecured cluster and want to enable the {{es}} {{security-features}}. diff --git a/deploy-manage/security/updating-certificates.md b/deploy-manage/security/updating-certificates.md index be20e93324..1285ff53bc 100644 --- a/deploy-manage/security/updating-certificates.md +++ b/deploy-manage/security/updating-certificates.md @@ -1,9 +1,13 @@ --- +navigation_title: Update TLS certificates mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/update-node-certs.html +applies_to: + deployment: + self: all --- -# Updating certificates [update-node-certs] +# Update TLS certificates [update-node-certs] You might need to update your TLS certificates if your current node certificates expire soon, you’re adding new nodes to your secured cluster, or a security breach has broken the trust of your certificate chain. Use the [SSL certificate](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-ssl-certificates) API to check when your certificates are expiring. diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index 582238d7f5..733f7665d8 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -4,6 +4,7 @@ applies_to: self: ga mapped_urls: - https://www.elastic.co/guide/en/kibana/current/using-kibana-with-security.html + - https://www.elastic.co/guide/en/kibana/current/Security-production-considerations.html --- % Kibana security had 2 original docs: @@ -91,7 +92,7 @@ You should use SSL/TLS encryption to ensure that traffic between browsers and th ### Enabling mutual TLS between {{kib}} and {{es}} -Refer to [](/deploy-manage/security/secure-http-communications.md#elasticsearch-mutual-tls) for information on how to enable mutual TLS between {{kib}} and {{es}}. +Refer to [](/deploy-manage/security/secure-cluster-communications.md#elasticsearch-mutual-tls) for information on how to enable mutual TLS between {{kib}} and {{es}}. ### Use {{stack}} {{security-features}} [configuring-kibana-shield] diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 52863569b9..0779886781 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -460,7 +460,6 @@ toc: - file: security/set-up-minimal-security.md - file: security/secure-cluster-communications.md children: - - file: security/secure-http-communications.md - file: security/set-up-basic-security.md - file: security/set-up-basic-security-plus-https.md - file: security/updating-certificates.md @@ -507,9 +506,7 @@ toc: - file: security/logging-configuration/correlating-kibana-elasticsearch-audit-logs.md - file: security/fips-140-2.md - file: security/install-stack-demo-secure.md - - file: security/manually-configure-security-in-self-managed-cluster.md - children: - - file: security/using-kibana-with-security.md + - file: security/using-kibana-with-security.md - file: security/secure-clients-integrations.md - file: security/httprest-clients-security.md - file: security/limitations.md diff --git a/deploy-manage/tools/cross-cluster-replication.md b/deploy-manage/tools/cross-cluster-replication.md index c62c86ad78..8606862f8e 100644 --- a/deploy-manage/tools/cross-cluster-replication.md +++ b/deploy-manage/tools/cross-cluster-replication.md @@ -67,7 +67,7 @@ Use {{ccr}} to construct several multi-cluster architectures within the Elastic Watch the [{{ccr}} webinar](https://www.elastic.co/webinars/replicate-elasticsearch-data-with-cross-cluster-replication-ccr) to learn more about the following use cases. Then, [set up {{ccr}}](cross-cluster-replication/set-up-cross-cluster-replication.md) on your local machine and work through the demo from the webinar. ::::{important} -In all of these use cases, you must [configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md) independently on every cluster. The security configuration is not replicated when configuring {{ccr}} for disaster recovery. To ensure that the {{es}} `security` feature state is backed up, [take snapshots](snapshot-and-restore/create-snapshots.md#back-up-specific-feature-state) regularly. You can then restore the native users, roles, and tokens from your security configuration. +In all of these use cases, you must [configure security](/deploy-manage/security/secure-your-cluster-deployment.md) independently on every cluster. The security configuration is not replicated when configuring {{ccr}} for disaster recovery. To ensure that the {{es}} `security` feature state is backed up, [take snapshots](snapshot-and-restore/create-snapshots.md#back-up-specific-feature-state) regularly. You can then restore the native users, roles, and tokens from your security configuration. :::: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md b/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md index 3574f6119d..fb10f728df 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md @@ -168,7 +168,7 @@ By default, the PKI realm relies on the node’s network interface to perform th Specifically, when clients presenting X.509 certificates connect to {{kib}}, {{kib}} performs the SSL/TLS authentication. {{kib}} then forwards the client’s certificate chain (by calling an {{es}} API) to have them further validated by the PKI realms that have been configured for delegation. -To permit authentication delegation for a specific {{es}} PKI realm, start by [configuring the realm](#pki-realm-for-direct-clients). In this scenario, for self-managed clusters, it is mandatory that you [encrypt HTTP client communications](../../security/secure-http-communications.md#encrypt-http-communication) when you enable TLS. +To permit authentication delegation for a specific {{es}} PKI realm, start by [configuring the realm](#pki-realm-for-direct-clients). In this scenario, for self-managed clusters, it is mandatory that you [encrypt HTTP client communications](../../security/secure-cluster-communications.md#encrypt-http-communication) when you enable TLS. You must also explicitly configure a `truststore` (or, equivalently `certificate_authorities`) even though it is the same trust configuration that you have configured on the network layer. The `xpack.security.authc.token.enabled` and `delegation.enabled` settings must also be `true`. For example: From 0fa525105b1329822ade408289ae37a0ae9d9d27 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 26 Mar 2025 18:26:22 +0100 Subject: [PATCH 03/42] HTTPS setup ongoing --- .../set-up-basic-security-plus-https.md | 29 +++++++++++++++---- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index baf2a49936..b63d0e97c9 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -12,12 +12,21 @@ mapped_pages: % original title: Set up basic security for the Elastic Stack plus secured HTTPS traffic # Set up HTTP TLS [security-basic-setup-https] -Enabling TLS on the HTTP layer ensures that all client communications with your cluster are encrypted, providing an additional layer of security. +Enabling TLS on the HTTP layer ensures that all client communications with your cluster are encrypted, adding a critical layer of security. -This documents describes the following topics: -- Generate and configure TLS certificates for {{es}} HTTP endpoint -- How to configure {{kib}} to connect to {{es}} using HTTPS, and adding the CA certificate of {{es}} to the list of trusted CAs in {{kib}} -- Generate and configure TLS certificate for {{kib}} using +This document provides guidance on how to: + +* Generate and configure TLS certificates for the HTTP endpoints of your {{es}} nodes. +* Configure {{kib}} to securely connect to {{es}} over HTTPS by trusting the Certificate Authority (CA) used by {{es}}. +* Generate and configure TLS certificates for the {{kib}} HTTP interface to secure {{kib}} access. + +::::{note} +This guide uses the `elasticsearch-certutil` tool to generate Certificate Authorities (CAs) and TLS certificates. However, using this tool is not required. You can use publicly trusted certificates, your organization's internal certificate management system, or any other method that produces valid certificates. + +If you already have certificates available, you can skip the certificate generation steps and proceed directly to the {{es}} and {{kib}} configuration steps. +:::: + +## `elasticsearch-certutil` When you run the `elasticsearch-certutil` tool in `http` mode, the tool asks several questions about how you want to generate certificates. While there are numerous options, the following choices result in certificates that should work for most environments. @@ -42,6 +51,16 @@ If you work in an environment with a central security team, they can likely gene If security feature wasn't already enabled in your cluster, complete all steps in [Manual security setup](./set-up-minimal-security.md). +For multi-node clusters, ensure you have completed the [transport TLS setup](./set-up-basic-security.md). As part of that process, you will have created a Certificate Authority (CA) that this guide reuses to issue HTTP certificates. + +If you prefer to use a separate CA for HTTP, you can generate a new one using the same process. For example: + +```bash +elasticsearch-certutil ca --out http-ca.p12 +``` + +Then, use this CA to sign your HTTP certificates instead. + ## Generate and configure TLS certificates for {{es}} nodes [encrypt-http-communication] % Encrypt HTTP client communications for {{es}} From e4601e14c330ad9a8d384571539108bf6e4d8496 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 26 Mar 2025 21:52:21 +0100 Subject: [PATCH 04/42] kibana https updated --- .../_snippets/kibana-client-https-setup.md | 10 +++-- .../security/_snippets/kibana-https-setup.md | 24 ++++------ .../set-up-basic-security-plus-https.md | 44 ++++++------------- 3 files changed, 30 insertions(+), 48 deletions(-) diff --git a/deploy-manage/security/_snippets/kibana-client-https-setup.md b/deploy-manage/security/_snippets/kibana-client-https-setup.md index 4ee483e120..cd11d2b906 100644 --- a/deploy-manage/security/_snippets/kibana-client-https-setup.md +++ b/deploy-manage/security/_snippets/kibana-client-https-setup.md @@ -1,4 +1,8 @@ -When you ran the `elasticsearch-certutil` tool with the `http` option, it created a `/kibana` directory containing an `elasticsearch-ca.pem` file. You use this file to configure {{kib}} to trust the {{es}} CA for the HTTP layer. +When you ran the `elasticsearch-certutil` tool with the `http` option to create the {{es}} certificates, it created a `/kibana` directory containing an `elasticsearch-ca.pem` file. You use this file to configure {{kib}} to trust the {{es}} CA for the HTTP layer. + +::::{note} +If you obtained the {{es}} certificates using a different method, you must provide {{kib}} with the appropriate CA certificates to establish trust. This may include the root CA and one or more intermediate CAs, depending on how the certificates were issued. +:::: 1. Copy the `elasticsearch-ca.pem` file to the {{kib}} configuration directory, as defined by the `$KBN_PATH_CONF` path. 2. Open `kibana.yml` and add the following line to specify the location of the security certificate for the HTTP layer. @@ -16,10 +20,10 @@ When you ran the `elasticsearch-certutil` tool with the `http` option, it create 4. Restart {{kib}}. :::::{admonition} Connect to a secure monitoring cluster -If the Elastic monitoring features are enabled and you configured a separate {{es}} monitoring cluster, you can also configure {{kib}} to connect to the monitoring cluster through HTTPS. The steps are the same, but each setting is prefixed by `monitoring`. For example, `monitoring.ui.elasticsearch.hosts` and `monitoring.ui.elasticsearch.ssl.truststore.path`. +If the Elastic monitoring features are enabled and you configured a separate {{es}} monitoring cluster, you can also configure {{kib}} to connect to the monitoring cluster through HTTPS. The steps are the same, but each setting is prefixed by `monitoring.ui`. For example, `monitoring.ui.elasticsearch.hosts` and `monitoring.ui.elasticsearch.ssl.certificateAuthorities`. ::::{note} -You must create a separate `elasticsearch-ca.pem` security file for the monitoring cluster. +If the monitoring cluster uses certificates signed by a different CA than the main cluster, you must provide a separate `elasticsearch-ca.pem` file that corresponds to the monitoring cluster's CA. :::: ::::: diff --git a/deploy-manage/security/_snippets/kibana-https-setup.md b/deploy-manage/security/_snippets/kibana-https-setup.md index 2756647cae..cf8d06282b 100644 --- a/deploy-manage/security/_snippets/kibana-https-setup.md +++ b/deploy-manage/security/_snippets/kibana-https-setup.md @@ -1,15 +1,12 @@ -You create a server certificate and private key for {{kib}}. {{kib}} uses this server certificate and corresponding private key when receiving connections from web browsers. +To secure browser access to {{kib}}, you need to generate a TLS certificate and private key for the server. {{kib}} uses these to encrypt HTTP traffic and establish trust with connecting browsers or API clients. -When you obtain a server certificate, you must set its subject alternative name (SAN) correctly to ensure that browsers will trust it. You can set one or more SANs to the {{kib}} server’s fully-qualified domain name (FQDN), hostname, or IP address. When choosing the SAN, pick whichever attribute you’ll use to connect to {{kib}} in your browser, which is likely the FQDN. - -The following instructions create a Certificate Signing Request (CSR) for {{kib}}. A CSR contains information that a CA uses to generate and sign a security certificate. The certificate can be trusted (signed by a public, trusted CA) or untrusted (signed by an internal CA). A self-signed or internally-signed certificate is acceptable for development environments and building a proof of concept, but should not be used in a production environment. - -::::{warning} -Before going to production, use a trusted CA such as [Let’s Encrypt](https://letsencrypt.org/) or your organization’s internal CA to sign the certificate. Using a signed certificate establishes browser trust for connections to {{kib}} for internal access or on the public internet. +::::{important} +When creating or requesting a TLS certificate, make sure to include one or more valid **Subject Alternative Names (SANs)** that match how users will access {{kib}}, typically a fully qualified domain name (FQDN), hostname, or IP address. Most browsers will reject the certificate if none of the SANs match the address used to connect. :::: +The following steps guide you through creating a Certificate Signing Request (CSR) for {{kib}}. A CSR is used to obtain a TLS certificate from a Certificate Authority (CA). For production environments, use a trusted CA such as [Let’s Encrypt](https://letsencrypt.org/) or your organization’s internal CA to ensure browser trust. -1. Generate a server certificate and private key for {{kib}}. +1. Generate a CSR and private key for {{kib}}. ```shell ./bin/elasticsearch-certutil csr -name kibana-server -dns example.com,www.example.com @@ -26,8 +23,8 @@ Before going to production, use a trusted CA such as [Let’s Encrypt](https://l ``` 2. Unzip the `csr-bundle.zip` file to obtain the `kibana-server.csr` unsigned security certificate and the `kibana-server.key` unencrypted private key. -3. Send the `kibana-server.csr` certificate signing request to your internal CA or trusted CA for signing to obtain a signed certificate. The signed file can be in different formats, such as a `.crt` file like `kibana-server.crt`. -4. Open `kibana.yml` and add the following lines to configure {{kib}} to access the server certificate and unencrypted private key. +3. Submit the `kibana-server.csr` certificate signing request to your organization’s security team or certificate authority to obtain a signed certificate. The resulting certificate might be in different formats, such as a `.crt` file like `kibana-server.crt`. +4. Open `kibana.yml` and add the following lines to configure {{kib}} HTTPS endpoint to use the server certificate and unencrypted private key. ```yaml server.ssl.certificate: $KBN_PATH_CONF/kibana-server.crt @@ -38,7 +35,7 @@ Before going to production, use a trusted CA such as [Let’s Encrypt](https://l `$KBN_PATH_CONF` contains the path for the {{kib}} configuration files. If you installed {{kib}} using archive distributions (`zip` or `tar.gz`), the path defaults to `$KBN_HOME/config`. If you used package distributions (Debian or RPM), the path defaults to `/etc/kibana`. :::: -5. Add the following line to `kibana.yml` to enable TLS for inbound connections. +5. Add the following line to `kibana.yml` to enable HTTPS for incoming connections. ```yaml server.ssl.enabled: true @@ -46,7 +43,4 @@ Before going to production, use a trusted CA such as [Let’s Encrypt](https://l 6. Start {{kib}}. -::::{note} -After making these changes, you must always access {{kib}} via HTTPS. For example, `https://.com`. -:::: - + After making these changes, you must always access {{kib}} through HTTPS. For example, `https://.com:5601`. diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index b63d0e97c9..712e6c67a5 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -16,9 +16,9 @@ Enabling TLS on the HTTP layer ensures that all client communications with your This document provides guidance on how to: -* Generate and configure TLS certificates for the HTTP endpoints of your {{es}} nodes. -* Configure {{kib}} to securely connect to {{es}} over HTTPS by trusting the Certificate Authority (CA) used by {{es}}. -* Generate and configure TLS certificates for the {{kib}} HTTP interface to secure {{kib}} access. +* [Generate and configure TLS certificates for the HTTP endpoints of your {{es}} nodes](#encrypt-http-communication). +* [Configure {{kib}} to securely connect to {{es}} over HTTPS](#encrypt-kibana-elasticsearch) by trusting the Certificate Authority (CA) used by {{es}}. +* [Generate and configure TLS certificates for the {{kib}} HTTP interface to secure {{kib}} access](#encrypt-kibana-browser). ::::{note} This guide uses the `elasticsearch-certutil` tool to generate Certificate Authorities (CAs) and TLS certificates. However, using this tool is not required. You can use publicly trusted certificates, your organization's internal certificate management system, or any other method that produces valid certificates. @@ -26,27 +26,16 @@ This guide uses the `elasticsearch-certutil` tool to generate Certificate Author If you already have certificates available, you can skip the certificate generation steps and proceed directly to the {{es}} and {{kib}} configuration steps. :::: -## `elasticsearch-certutil` +::::{tip} +When running `elasticsearch-certutil` in `http` mode, the tool prompts you to choose how to generate the TLS certificates. One key question is whether you want to generate a Certificate Signing Request (CSR). -When you run the `elasticsearch-certutil` tool in `http` mode, the tool asks several questions about how you want to generate certificates. While there are numerous options, the following choices result in certificates that should work for most environments. - -::::{admonition} Signing certificates -:name: signing-certificates - -The first question that the `elasticsearch-certutil` tool prompts you with is whether you want to generate a Certificate Signing Request (CSR). Answer `n` if you want to sign your own certificates, or `y` if you want to sign certificates with a central CA. - - -#### Sign your own certificates [_sign_your_own_certificates] - -If you want to use the CA that you created when [Generating the certificate authority](secure-cluster-communications.md#generate-certificates) answer `n` when asked if you want to generate a CSR. You then specify the location of your CA, which the tool uses to sign and generate a `.p12` certificate. The steps in this procedure follow this workflow. - - -#### Sign certificates with a central CA [_sign_certificates_with_a_central_ca] - -If you work in an environment with a central security team, they can likely generate a certificate for you. Infrastructure within your organization might already be configured to trust an existing CA, so it may be easier for clients to connect to {{es}} if you use a CSR and send that request to the team that controls your CA. To use a central CA, answer `y` to the first question. +* Answer `n` to skip the CSR and sign your certificates using a Certificate Authority (CA) [you previously created](./set-up-basic-security.md#generate-the-certificate-authority). You’ll be prompted to provide the path to your CA, which the tool will use to generate a `.p12` certificate. The steps in this guide follow this workflow for {{es}} certificates. +* Answer `y` to generate a CSR that can be signed by your organization's internal CA or external certificate provider. This is common in environments where trust is managed centrally. The steps in this guide follow this workflow for {{kib}} certificate. +Both workflows are supported. Choose the one that best fits your infrastructure and trust model. :::: + ## Prerequisites [basic-setup-https-prerequisites] If security feature wasn't already enabled in your cluster, complete all steps in [Manual security setup](./set-up-minimal-security.md). @@ -59,12 +48,12 @@ If you prefer to use a separate CA for HTTP, you can generate a new one using th elasticsearch-certutil ca --out http-ca.p12 ``` -Then, use this CA to sign your HTTP certificates instead. +Then, use this CA to sign your HTTP certificates in the next section and for {{kib}} HTTP endpoint. ## Generate and configure TLS certificates for {{es}} nodes [encrypt-http-communication] - % Encrypt HTTP client communications for {{es}} -Doing this will encrypt all client communications with the cluster. Clients will have to be configured to use `https` protocol when connecting to {{es}}, and will need the CA certificate associated to the {{es}} certificates for trusting purposes. + +Once TLS is enabled, all client communications with the cluster will be encrypted. Clients must connect using `https` and be configured to trust the Certificate Authority (CA) that signed the {{es}} certificates. 1. On **every** node in your cluster, stop {{es}} and {{kib}} if they are running. 2. On any single node, from the directory where you installed {{es}}, run the {{es}} HTTP certificate tool to generate TLS certificates for your nodes. @@ -132,11 +121,9 @@ Doing this will encrypt all client communications with the cluster. Clients will ## Encrypt HTTP client communications for {{kib}} [encrypt-kibana-http] -Browsers send traffic to {{kib}} and {{kib}} sends traffic to {{es}}. These communication channels are configured separately to use TLS. You encrypt traffic between {{kib}} and {{es}}, and then encrypt traffic between your browser and {{kib}}. - {{kib}} handles two separate types of HTTP traffic that should be encrypted: -* Outgoing traffic from {{kib}} to {{es}} – {{kib}} acts as an HTTP client and must be configured to trust the TLS certificate used by {{es}}. -* Incoming traffic from browsers to {{kib}} – {{kib}} also acts as an HTTP server, and you should configure a TLS certificate for its public-facing endpoint to secure browser access. +* **Outgoing requests from {{kib}} to {{es}}**: {{kib}} acts as an HTTP client and must be configured to trust the TLS certificate used by {{es}}. +* **Incoming requests from browsers or API clients to {{kib}}**: {{kib}} acts as an HTTP server, and you should configure a TLS certificate for its public-facing endpoint to secure clients traffic. ### Encrypt traffic between {{kib}} and {{es}} [encrypt-kibana-elasticsearch] @@ -149,9 +136,6 @@ Browsers send traffic to {{kib}} and {{kib}} sends traffic to {{es}}. These comm ### Encrypt traffic between your browser and {{kib}} [encrypt-kibana-browser] -In order to ensure clients communication to {{kib}} are encrypted, you have to create a TLS certificate for {{kib}} and, the same way as with {{es}}, configure the clients to use `https` when connecting to {{kib}} and trust the CA used to sign {{kib}} certificate. -(WORK IN PROGRESS) - :::{include} /deploy-manage/security/_snippets/kibana-https-setup.md ::: From 155e78ff61121582f3cf60d38c2b699c50482dfd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 26 Mar 2025 22:07:18 +0100 Subject: [PATCH 05/42] syncing tabs --- .../security/secure-cluster-communications.md | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index c562b486cb..2a0ffce8df 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -46,20 +46,25 @@ The transport layer is responsible for internal communication between {{es}} nod The way that transport layer security is managed depends on your deployment type: ::::{tab-set} +:group: deployments :::{tab-item} ECH and Serverless +:sync: ech {{es}} transport security is fully managed by Elastic, and no configuration is required. ::: :::{tab-item} ECE +:sync: ece {{es}} transport security is fully managed by {{ece}} platform, and no configuration is required. ::: :::{tab-item} ECK +:sync: eck {{es}} transport security and TLS certificates are automatically configured by the operator, but you can still [customize its service and CA certificates](/deploy-manage/security/k8s-transport-settings.md). ::: :::{tab-item} Self-managed +:sync: self {{es}} transport security can be [automatically configured](security-certificates-keys.md), or manually set up by following the steps in [Set up basic security](set-up-basic-security.md). ::: @@ -76,13 +81,18 @@ While HTTP TLS encryption is optional in self-managed environments, it is strong The way that HTTP layer security is managed depends on your deployment type: ::::{tab-set} +:group: deployments :::{tab-item} ECH and Serverless +:sync: ech + HTTP TLS for {{es}} and {{kib}} is fully managed by Elastic. No configuration is required. {{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. ::: :::{tab-item} ECE +:sync: ece + HTTP TLS for deployments is managed at the platform proxy level. Refer to these guides for ECE-specific security customizations: * [Manage security certificates in ECE](./secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) * [Allow x509 Certificates Signed with SHA-1](./secure-your-elastic-cloud-enterprise-installation/allow-x509-certificates-signed-with-sha-1.md) @@ -92,12 +102,16 @@ HTTP TLS for deployments is managed at the platform proxy level. Refer to these ::: :::{tab-item} ECK +:sync: eck + HTTP TLS is automatically enabled for {{es}} and {{kib}} using self-signed certificates, with [several options available for customization](./k8s-https-settings.md), including custom certificates and domain names. {{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. ::: :::{tab-item} Self-managed +:sync: self + HTTP TLS certificates for {{es}} can be [automatically configured](security-certificates-keys.md), or manually set up by following the steps in [Set up HTTP SSL](./set-up-basic-security-plus-https.md). {{kib}} acts as both an HTTP client to {{es}} and a server for browser access. It performs operations on behalf of users, so it must be properly configured to trust the {{es}} certificates, and to present its own TLS certificate for secure browser connections. These configurations must be performed manually in self-managed deployments. @@ -112,22 +126,31 @@ For environments with stricter security requirements, refer to [Mutual TLS authe Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. Each deployment type provides different tools or responsibilities for managing certificates lifecycle. ::::{tab-set} +:group: deployments :::{tab-item} ECH and Serverless +:sync: ech + Certificate lifecycle is fully managed by Elastic, including renewal and rotation. ::: :::{tab-item} ECE +:sync: ece + In ECE, the platform automatically renews internal certificates. However, you must manually renew your custom proxy and Cloud UI certificates. For more details, refer to [Manage security certificates](secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). ::: :::{tab-item} ECK +:sync: eck + ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. TBD, add links to cert validity settings and cert configuration ::: :::{tab-item} Self-managed +:sync: self + You are responsible for certificate lifecycle management, including monitoring expiration dates, renewing certificates, and redeploying them as needed. If you used Elastic tools to generate your certificates, refer to [Update TLS certificates](./updating-certificates.md) for guidance on rotating or replacing them. ::: From f6da69c8e45fd971767f3d96b26e744a557d7f4d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 26 Mar 2025 23:16:43 +0100 Subject: [PATCH 06/42] working in progress --- .../secure-your-cluster-deployment.md | 64 ++-- .../set-up-basic-security-plus-https.md | 275 +----------------- .../security/set-up-minimal-security.md | 1 + 3 files changed, 22 insertions(+), 318 deletions(-) diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index 972e4cd769..c1db9b0eb9 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -13,7 +13,6 @@ mapped_pages: It's important to protect your {{es}} cluster and the data it contains. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. - :::{include} /deploy-manage/security/_snippets/complete-security.md ::: @@ -28,18 +27,24 @@ You must secure [other {{stack}} components](/deploy-manage/security/secure-clie You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: -## Security activation [manually-configure-security] +## Enable security [manually-configure-security] % Intro to link automatic setup and manual setup process of security Everything starts with the security feature activation in {{es}}, which enables authentication and authorization, TLS encryption of communications, and all other security related functionality described in this section. ::::{note} +{{ech}}, {{ece}}, Orchestrated deployments automatically configures security by default, the elastic user password, TLS certificates, and configure {{kib}} to access {{es}} in a secure way. Disabling security is not an option in managed deployments. :::: -Since {{es}} 8.0, security is enabled and configured by default. However, security auto configuration [might be skipped](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md#stack-skip-auto-configuration) in certain scenarios. In these cases, you can [manually configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md). +In self-managed clusters, security is enabled and automatically configured by default since {{es}} 8.0. However, security auto configuration [might be skipped](./security-certificates-keys.md#stack-skip-auto-configuration) in certain scenarios. In these cases, you can [manually configure security](./set-up-minimal-security.md). + +Security needs vary depending on whether you’re developing locally on your laptop or securing all communications in a production environment. Regardless of where you’re deploying the {{stack}} ("ELK"), running a secure cluster is incredibly important to protect your data. That’s why security is [enabled and configured by default](../deploy/self-managed/installing-elasticsearch.md) since {{es}} 8.0. + +guides links +{{kib}} needs to be manually configured In self-managed clusters, there are two ways to perform the initial security setup, depending on your needs: * Automatic security setup: {{es}} security requires TLS certificates to be configured for inter-node communications (transport layer), and in order to facilitate the initial setup, there's an automatic configuration. @@ -49,58 +54,29 @@ In self-managed clusters, there are two ways to perform the initial security set * Basic transport TLS security: for multi-node clusters only, as single-node clusters don't need to talk with other nodes. * HTTP TLS: optional but highly recommended -Refer to [skipxxxx]() to understand in what cases autoconfiguration works and when a manual configuration will be expected. - -Kibana also supports HTTPS. - -Mutual authentication is also an option. - -### Security basics (a decidir) - -For {{es}} to be able to start with security enabled, the following is necessary: - - -single nodes and multiple-nodes. -What is required, what is optional. Single-node vs multi-node -Consider Kibana HTTPS - -Security gives access to users and roles and certificates, links - -Security needs vary depending on whether you’re developing locally on your laptop or securing all communications in a production environment. Regardless of where you’re deploying the {{stack}} ("ELK"), running a secure cluster is incredibly important to protect your data. That’s why security is [enabled and configured by default](../deploy/self-managed/installing-elasticsearch.md) since {{es}} 8.0. - -A decidir esto tambien: - - -### Minimal security ({{es}} Development) [security-minimal-overview] +### Security auto configuration -::::{important} -The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. -:::: +explain what it involves -If you’ve been working with {{es}} and want to enable security on your existing, unsecured cluster, start here. You’ll set passwords for the built-in users to prevent unauthorized access to your local cluster, and also configure password authentication for {{kib}}. +Link to the guide that includes kibana setup +Refer to [skipxxxx]() to understand in what cases autoconfiguration works and when a manual configuration will be expected. -[Set up minimal security](set-up-minimal-security.md) -### Basic security ({{es}} + {{kib}}) [security-basic-overview] +### Manual configuration -This scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your {{es}} cluster. +If you’re securing an existing unsecured cluster, or prefer to use your own TLS certificates, follow the manual approach. It involves enabling different layers of protection in sequence, depending on your cluster architecture and security requirements. -Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but internode communication will be secured. +- **Start with [minimal security](set-up-minimal-security.md)**: Enables password-based authentication for built-in users and configures {{kib}} to connect securely. Suitable for single-node clusters, but not sufficient for production. -[Set up basic security](secure-cluster-communications.md) +- **Then [configure transport TLS](secure-cluster-communications.md)**: Required for multi-node clusters running in [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode). This secures communication between nodes and prevents unauthorized nodes from joining the cluster. -### Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview] +- **Finally, [configure HTTP TLS](set-up-basic-security-plus-https.md)**: Secures all client communications over HTTPS, including traffic between {{kib}} and {{es}}, and between browsers and {{kib}}. -This scenario builds on the one for basic security and secures all HTTP traffic with TLS. In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. +Each step builds on the previous one. For production environments, it’s strongly recommended to complete all three. -::::{note} -If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption. -:::: - -You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. - -[Set up basic security plus HTTPS traffic](secure-cluster-communications.md) +Kibana also supports HTTPS. +Mutual authentication is also an option. ## Communication and network security diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 712e6c67a5..7e2d4034b6 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -139,277 +139,4 @@ Once TLS is enabled, all client communications with the cluster will be encrypte :::{include} /deploy-manage/security/_snippets/kibana-https-setup.md ::: -**Next**: [Configure {{beats}} security](#configure-beats-security) - -% All this should be already in beats repository, including roles, etc -## Configure {{beats}} security [configure-beats-security] - -{{beats}} are open source data shippers that you install as agents on your servers to send operational data to {{es}}. Each Beat is a separately installable product. The following steps cover configuring security for {{metricbeat}}. Follow these steps for each [additional Beat](beats://reference/index.md) you want to configure security for. - -### Prerequisites [_prerequisites_13] - -[Install {{metricbeat}}](beats://reference/metricbeat/metricbeat-installation-configuration.md) using your preferred method. - -::::{important} -You cannot connect to the {{stack}} or configure assets for {{metricbeat}} before completing the following steps. -:::: - - - -### Create roles for {{metricbeat}} [_create_roles_for_metricbeat] - -Typically, you need to create the following separate roles: - -* **setup** role for setting up index templates and other dependencies -* **monitoring** role for sending monitoring information -* **writer** role for publishing events collected by {{metricbeat}} -* **reader** role for {{kib}} users who need to view and create visualizations that access {{metricbeat}} data - -::::{note} -These instructions assume that you are using the default name for {{metricbeat}} indices. If the indicated index names are not listed, or you are using a custom name, enter it manually when defining roles and modify the privileges to match your index naming pattern. -:::: - - -To create users and roles from Stack Management in {{kib}}, select **Roles** or **Users** from the side navigation. - -**Next**: [Create a setup role](#beats-setup-role) - - -##### Create a setup role and user [beats-setup-role] - -Administrators who set up {{metricbeat}} typically need to load mappings, dashboards, and other objects used to index data into {{es}} and visualize it in {{kib}}. - -::::{warning} -Setting up {{metricbeat}} is an admin-level task that requires extra privileges. As a best practice, grant the setup role to administrators only, and use a more restrictive role for event publishing. -:::: - - -1. Create the setup role: -2. Enter **metricbeat_setup** as the role name. -3. Choose the **monitor** and **manage_ilm** cluster privileges. -4. On the **metricbeat-\** indices, choose the ***manage** and **write** privileges. - - If the **metricbeat-\*** indices aren’t listed, enter that pattern into the list of indices. - -5. Create the setup user: -6. Enter **metricbeat_setup** as the user name. -7. Enter the username, password, and other user details. -8. Assign the following roles to the **metricbeat_setup** user: - - | Role | Purpose | - | --- | --- | - | `metricbeat_setup` | Set up {{metricbeat}}. | - | `kibana_admin` | Load dependencies, such as example dashboards, if available, into {{kib}} | - | `ingest_admin` | Set up index templates and, if available, ingest pipelines | - - -**Next**: [Create a monitoring role](#beats-monitoring-role) - - -##### Create a monitoring role and user [beats-monitoring-role] - -To send monitoring data securely, create a monitoring user and grant it the necessary privileges. - -You can use the built-in `beats_system` user, if it’s available in your environment. Because the built-in users are not available in {{ecloud}}, these instructions create a user that is explicitly used for monitoring {{metricbeat}}. - -1. If you’re using the built-in `beats_system` user, on any node in your cluster, run the [`elasticsearch-reset-password`](elasticsearch://reference/elasticsearch/command-line-tools/reset-password.md) utility to set the password for that user: - - This command resets the password for the `beats_system` user to an auto-generated value. - - ```shell - ./bin/elasticsearch-reset-password -u beats_system - ``` - - If you want to set the password to a specific value, run the command with the interactive (`-i`) parameter. - - ```shell - ./bin/elasticsearch-reset-password -i -u beats_system - ``` - -2. Create the monitoring role: -3. Enter **metricbeat_monitoring** as the role name. -4. Choose the **monitor** cluster privilege. -5. On the **.monitoring-beats-\** indices, choose the ***create_index** and **create_doc** privileges. -6. Create the monitoring user: -7. Enter **metricbeat_monitoring** as the user name. -8. Enter the username, password, and other user details. -9. Assign the following roles to the **metricbeat_monitoring** user: - - | Role | Purpose | - | --- | --- | - | `metricbeat_monitoring` | Monitor {{metricbeat}}. | - | `kibana_admin` | Use {{kib}} | - | `monitoring_user` | Use Stack Monitoring in {{kib}} to monitor {{metricbeat}} | - - -**Next**: [Create a writer role](#beats-writer-role) - - -##### Create a writer role and user [beats-writer-role] - -Users who publish events to {{es}} need to create and write to {{metricbeat}} indices. To minimize the privileges required by the writer role, use the setup role to pre-load dependencies. This section assumes that you’ve [created the setup role](#beats-setup-role). - -1. Create the writer role: -2. Enter **metricbeat_writer** as the role name. -3. Choose the **monitor** and **read_ilm** cluster privileges. -4. On the **metricbeat-\** indices, choose the ***create_doc***, ***create_index**, and **view_index_metadata** privileges. -5. Create the writer user: -6. Enter **metricbeat_writer** as the user name. -7. Enter the username, password, and other user details. -8. Assign the following roles to the **metricbeat_writer** user: - - | Role | Purpose | - | --- | --- | - | `metricbeat_writer` | Monitor {{metricbeat}} | - | `remote_monitoring_collector` | Collect monitoring metrics from {{metricbeat}} | - | `remote_monitoring_agent` | Send monitoring data to the monitoring cluster | - - -**Next**: [Create a reader role](#beats-reader-role) - - -##### Create a reader role and user [beats-reader-role] - -{{kib}} users typically need to view dashboards and visualizations that contain {{metricbeat}} data. These users might also need to create and edit dashboards and visualizations. Create the reader role to assign proper privileges to these users. - -1. Create the reader role: -2. Enter **metricbeat_reader** as the role name. -3. On the **metricbeat-\*** indices, choose the **read** privilege. -4. Under **{{kib}}**, click **Add {{kib}} privilege**. - - * Under **Spaces**, choose **Default**. - * Choose **Read** or **All** for Discover, Visualize, Dashboard, and Metrics. - -5. Create the reader user: -6. Enter **metricbeat_reader** as the user name. -7. Enter the username, password, and other user details. -8. Assign the following roles to the **metricbeat_reader** user: - - | Role | Purpose | - | --- | --- | - | `metricbeat_reader` | Read {{metricbeat}} data. | - | `monitoring_user` | Allow users to monitor the health of {{metricbeat}}itself. Only assign this role to users who manage {{metricbeat}} | - | `beats_admin` | Create and manage configurations in {{beats}} centralmanagement. Only assign this role to users who need to use {{beats}} centralmanagement. | - - -**Next**: [Configure {{metricbeat}} to use TLS](#configure-metricbeat-tls) - - -#### Configure {{metricbeat}} to use TLS [configure-metricbeat-tls] - -Before starting {{metricbeat}}, you configure the connections to {{es}} and {{kib}}. You can configure authentication to send data to your secured cluster using basic authentication, API key authentication, or Public Key Infrastructure (PKI) certificates. - -The following instructions use the credentials for the `metricbeat_writer` and `metricbeat_setup` users that you created. If you need a greater level of security, we recommend using PKI certificates. - -After configuring connections to {{es}} and {{kib}}, you’ll enable the `elasticsearch-xpack` module and configure that module to use HTTPS. - -::::{warning} -In production environments, we strongly recommend using a separate cluster (referred to as the monitoring cluster) to store your data. Using a separate monitoring cluster prevents production cluster outages from impacting your ability to access your monitoring data. It also prevents monitoring activities from impacting the performance of your production cluster. -:::: - - -1. On the node where you [generated certificates for the HTTP layer](#encrypt-http-communication), navigate to the `/kibana` directory. -2. Copy the `elasticsearch-ca.pem` certificate to the directory where you installed {{metricbeat}}. -3. Open the `metricbeat.yml` configuration file and configure the connection to {{es}}. - - Under `output.elasticsearch`, specify the following fields: - - ```yaml - output.elasticsearch: - hosts: [":9200"] - protocol: "https" - username: "metricbeat_writer" - password: "" - ssl: - certificate_authorities: ["elasticsearch-ca.pem"] - verification_mode: "certificate" - ``` - - `hosts` - : Specifies the host where your {{es}} cluster is running. - - `protocol` - : Indicates the protocol to use when connecting to {{es}}. This value must be `https`. - - `username` - : Name of the user with privileges required to publish events to {{es}}. The `metricbeat_writer` user that you created has these privileges. - - `password` - : Password for the indicated `username`. - - `certificate_authorities` - : Indicates the path to the local `.pem` file that contains your CA’s certificate. - -4. Configure the connection to {{kib}}. - - Under `setup.kibana`, specify the following fields: - - ```yaml - setup.kibana - host: "https://:5601" - ssl.enabled: true - username: "metricbeat_setup" - password: "p@ssw0rd" - ``` - - `hosts` - : The URLs of the {{es}} instances to use for all your queries. Ensure that you include `https` in the URL. - - `username` - : Name of the user with privileges required to set up dashboards in {{kib}}. The `metricbeat_setup` user that you created has these privileges. - - `password` - : Password for the indicated `username`. - -5. Enable the `elasticsearch-xpack` module. - - ```shell - ./metricbeat modules enable elasticsearch-xpack - ``` - -6. Modify the `elasticsearch-xpack` module to use HTTPS. This module collects metrics about {{es}}. - - Open `/modules.d/elasticsearch-xpack.yml` and specify the following fields: - - ```yaml - - module: elasticsearch - xpack.enabled: true - period: 10s - hosts: ["https://:9200"] - username: "remote_monitoring_user" - password: "" - ssl: <1> - enabled: true - certificate_authorities: ["elasticsearch-ca.pem"] - verification_mode: "certificate" - ``` - - 1. Configuring SSL is required when monitoring a node with encrypted traffic. See [Configure SSL for {{metricbeat}}](beats://reference/metricbeat/configuration-ssl.md).`hosts` - : Specifies the host where your {{es}} cluster is running. Ensure that you include `https` in the URL. - - `username` - : Name of the user with privileges to collect metric data. The built-in `monitoring_user` user has these privileges. Alternatively, you can create a user and assign it the `monitoring_user` role. - - `password` - : Password for the indicated `username`. - - `certificate_authorities` - : Indicates the path to the local `.pem` file that contains your CA’s certificate. - -7. If you want to use the predefined assets for parsing, indexing, and visualizing your data, run the following command to load these assets: - - ```shell - ./metricbeat setup -e - ``` - -8. Start {{es}}, and then start {{metricbeat}}. - - ```shell - ./metricbeat -e - ``` - - `-e` is optional and sends output to standard error instead of the configured log output. - -9. Log in to {{kib}}, open the main menu, and click **Stack Monitoring**. - - You’ll see cluster alerts that require your attention and a summary of the available monitoring metrics for {{es}}. Click any of the header links on the available cards to view additional information. +**Next**: Configure any other client that interacts with {{es}} or {{kib}} to use HTTPS and trust the appropriate CA certificate. Refer to [Secure other {{stack}} components](/deploy-manage/security/secure-clients-integrations.md) and [Securing HTTP client applications](./httprest-clients-security.md) for more details. diff --git a/deploy-manage/security/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index 9dbcf03cca..b0523225f6 100644 --- a/deploy-manage/security/set-up-minimal-security.md +++ b/deploy-manage/security/set-up-minimal-security.md @@ -8,6 +8,7 @@ mapped_pages: --- % alternative title: Manual security setup +$ Set up minimal security % Scope: Just enabling security, resetting passwords, and configuring kibana. Manual approach, opposite to automatic security configuration % Original title: Set up minimal security # Manual security setup [security-minimal-setup] From 613a131d3eafdd740096a5d3d42ead2a53c80365 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Thu, 27 Mar 2025 09:19:24 +0100 Subject: [PATCH 07/42] automatic and manual configs for self-managed almost completed --- .../secure-your-cluster-deployment.md | 52 +++---------------- deploy-manage/security/self-setup.md | 45 ++++++++++++++++ deploy-manage/security/self-tls.md | 12 +++++ .../security/set-up-minimal-security.md | 4 +- deploy-manage/toc.yml | 20 ++++--- 5 files changed, 78 insertions(+), 55 deletions(-) create mode 100644 deploy-manage/security/self-setup.md create mode 100644 deploy-manage/security/self-tls.md diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index c1db9b0eb9..2e39a76292 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -27,58 +27,20 @@ You must secure [other {{stack}} components](/deploy-manage/security/secure-clie You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: -## Enable security [manually-configure-security] +## Enable and set up security [manually-configure-security] -% Intro to link automatic setup and manual setup process of security - -Everything starts with the security feature activation in {{es}}, which enables authentication and authorization, TLS encryption of communications, and all other security related functionality described in this section. +The first step in securing your deployment is ensuring that the {{es}} security feature is enabled and properly set up. {{es}} security provides authentication, authorization, TLS encryption, and other capabilities described in this section. ::::{note} -{{ech}}, {{ece}}, -Orchestrated deployments automatically configures security by default, the elastic user password, TLS certificates, and configure {{kib}} to access {{es}} in a secure way. Disabling security is not an option in managed deployments. +Deployments managed by {{eck}}, {{ece}}, {{ech}}, and {{serverless-short}} automatically configure security by default. This includes setting the `elastic` user password, generating TLS certificates, and configuring {{kib}} to connect to {{es}} securely. Disabling security is not supported in these deployment types. :::: -In self-managed clusters, security is enabled and automatically configured by default since {{es}} 8.0. However, security auto configuration [might be skipped](./security-certificates-keys.md#stack-skip-auto-configuration) in certain scenarios. In these cases, you can [manually configure security](./set-up-minimal-security.md). - -Security needs vary depending on whether you’re developing locally on your laptop or securing all communications in a production environment. Regardless of where you’re deploying the {{stack}} ("ELK"), running a secure cluster is incredibly important to protect your data. That’s why security is [enabled and configured by default](../deploy/self-managed/installing-elasticsearch.md) since {{es}} 8.0. - - -guides links -{{kib}} needs to be manually configured -In self-managed clusters, there are two ways to perform the initial security setup, depending on your needs: - -* Automatic security setup: {{es}} security requires TLS certificates to be configured for inter-node communications (transport layer), and in order to facilitate the initial setup, there's an automatic configuration. - -* Manual security setup: If you are configuring security in an unsecured cluster, or if you want to use your own certificates, you can follow the manual approach, which consists of three steps, depending whether your cluster is a single-node or multi-node cluster: - * Minimal security - * Basic transport TLS security: for multi-node clusters only, as single-node clusters don't need to talk with other nodes. - * HTTP TLS: optional but highly recommended - -### Security auto configuration - -explain what it involves - -Link to the guide that includes kibana setup -Refer to [skipxxxx]() to understand in what cases autoconfiguration works and when a manual configuration will be expected. - - -### Manual configuration - -If you’re securing an existing unsecured cluster, or prefer to use your own TLS certificates, follow the manual approach. It involves enabling different layers of protection in sequence, depending on your cluster architecture and security requirements. - -- **Start with [minimal security](set-up-minimal-security.md)**: Enables password-based authentication for built-in users and configures {{kib}} to connect securely. Suitable for single-node clusters, but not sufficient for production. - -- **Then [configure transport TLS](secure-cluster-communications.md)**: Required for multi-node clusters running in [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode). This secures communication between nodes and prevents unauthorized nodes from joining the cluster. - -- **Finally, [configure HTTP TLS](set-up-basic-security-plus-https.md)**: Secures all client communications over HTTPS, including traffic between {{kib}} and {{es}}, and between browsers and {{kib}}. - -Each step builds on the previous one. For production environments, it’s strongly recommended to complete all three. - -Kibana also supports HTTPS. - -Mutual authentication is also an option. +In self-managed clusters, security is [enabled and configured by default](./security-certificates-keys.md) since {{es}} 8.0, but some additional setup steps are still required. Follow the guide to complete the configuration and understand how the automatic setup works. +If the automatic setup is skipped, or if you prefer full control, you can [configure security manually](./self-setup.md#manual-configuration). +For an overview of both approaches, refer to [Security configuration for self-managed deployments](./self-setup.md). + ## Communication and network security :::{include} /deploy-manage/security/_snippets/cluster-communication-network.md diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md new file mode 100644 index 0000000000..7347a982c4 --- /dev/null +++ b/deploy-manage/security/self-setup.md @@ -0,0 +1,45 @@ +--- +navigation_title: "Self-managed security setup" +applies_to: + deployment: + self: ga +mapped_pages: + - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup-https.html +--- + +# Setup security in self-managed deployments + +There are two approaches to configuring security in self-managed deployments of the Elastic Stack: + +## Automatic configuration [automatic-configuration] + +Since version 8.0, {{es}} automatically enables security features on first startup when the node is not part of an existing cluster and none of the [incompatible settings](./security-certificates-keys.md#stack-existing-settings-detected) have been explicitly configured. + +The automatic configuration:: + +* Generates TLS certificates for the transport and HTTP layers +* Applies security settings to elasticsearch.yml +* Sets a password for the elastic superuser +* Creates an enrollment token to securely connect {{kib}} to {{es}} + +This automatic setup is the quickest way to get started and ensures your cluster is protected by default. + +::::{note} +The automatic configuration does not enable TLS on the {{kib}} HTTP endpoint. To encrypt browser traffic to {{kib}}, follow the steps in [](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). +:::: + +Refer to [Automatic security setup](./security-certificates-keys.md) for the complete procedure, including [cases where it may be skipped](./security-certificates-keys.md#stack-skip-auto-configuration). + +## Manual configuration [manual-configuration] + +If you’re securing an existing unsecured cluster, or prefer to use your own TLS certificates, follow the manual approach. It involves enabling different layers of protection in sequence, depending on your cluster architecture and security requirements. + +* **Start with [minimal security](set-up-minimal-security.md)**: Enables password-based authentication for built-in users and configures {{kib}} to connect using credentials. Suitable for single-node clusters, but not sufficient for production or multi-node clusters. + +* **Then [configure transport TLS](secure-cluster-communications.md)**: Required for multi-node clusters running in [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode). Secures communication between nodes and prevents unauthorized nodes from joining the cluster. + +* **Finally, [configure HTTP TLS](set-up-basic-security-plus-https.md)**: Secures all client communications over HTTPS, including traffic between {{kib}} and {{es}}, and between browsers and {{kib}}. Recommended for all clusters, even single-node setups. + +Each step builds on the previous one. For production environments, it’s strongly recommended to complete all three. + + diff --git a/deploy-manage/security/self-tls.md b/deploy-manage/security/self-tls.md new file mode 100644 index 0000000000..256507a00d --- /dev/null +++ b/deploy-manage/security/self-tls.md @@ -0,0 +1,12 @@ +--- +navigation_title: "Self-managed" +applies_to: + deployment: + self: ga +mapped_pages: + - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup-https.html +--- + +# Manage TLS certificates in self-managed deployments + + diff --git a/deploy-manage/security/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index b0523225f6..c7a78f1ed9 100644 --- a/deploy-manage/security/set-up-minimal-security.md +++ b/deploy-manage/security/set-up-minimal-security.md @@ -1,5 +1,5 @@ --- -navigation_title: "Manual security setup" +navigation_title: "Minimal security setup" applies_to: deployment: self: ga @@ -11,7 +11,7 @@ mapped_pages: $ Set up minimal security % Scope: Just enabling security, resetting passwords, and configuring kibana. Manual approach, opposite to automatic security configuration % Original title: Set up minimal security -# Manual security setup [security-minimal-setup] +# Minimal security setup [security-minimal-setup] ::::{important} You only need to complete the following steps if you’re running an existing, unsecured cluster and want to enable the {{es}} {{security-features}}. diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 0779886781..4420b2d2a8 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -456,17 +456,21 @@ toc: - file: security/secure-your-eck-installation.md - file: security/secure-your-cluster-deployment.md children: - - file: security/security-certificates-keys.md - - file: security/set-up-minimal-security.md + - file: security/self-setup.md + children: + - file: security/security-certificates-keys.md + - file: security/set-up-minimal-security.md - file: security/secure-cluster-communications.md children: - - file: security/set-up-basic-security.md - - file: security/set-up-basic-security-plus-https.md - - file: security/updating-certificates.md + - file: security/self-tls.md children: - - file: security/same-ca.md - - file: security/different-ca.md - - file: security/kibana-es-mutual-tls.md + - file: security/set-up-basic-security.md + - file: security/set-up-basic-security-plus-https.md + - file: security/updating-certificates.md + children: + - file: security/same-ca.md + - file: security/different-ca.md + - file: security/kibana-es-mutual-tls.md - file: security/eck-tls.md children: - file: security/k8s-https-settings.md From 602e2808f9f221c253e3e363abe27a426fba4e3b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Thu, 27 Mar 2025 20:43:14 +0100 Subject: [PATCH 08/42] basic and basic plus concepts refined --- deploy-manage/security.md | 9 + .../cluster-communication-network.md | 2 +- .../security/_snippets/enable-security.md | 7 + .../security/install-stack-demo-secure.md | 2 +- deploy-manage/security/k8s-https-settings.md | 2 +- .../security/k8s-transport-settings.md | 2 +- .../security/secure-cluster-communications.md | 2 +- .../secure-cluster-communications.md.backup | 172 -------------- .../secure-your-cluster-deployment.md | 86 +------ .../secure-your-cluster-deployment.md.backup | 213 ------------------ deploy-manage/security/self-setup.md | 4 +- .../set-up-basic-security-plus-https.md | 4 +- .../security/set-up-basic-security.md | 6 +- .../security/set-up-minimal-security.md | 34 +-- .../security/using-kibana-with-security.md | 4 +- redirects.yml | 6 +- 16 files changed, 56 insertions(+), 499 deletions(-) create mode 100644 deploy-manage/security/_snippets/enable-security.md delete mode 100644 deploy-manage/security/secure-cluster-communications.md.backup delete mode 100644 deploy-manage/security/secure-your-cluster-deployment.md.backup diff --git a/deploy-manage/security.md b/deploy-manage/security.md index 6f1bf34209..656b8dd4ab 100644 --- a/deploy-manage/security.md +++ b/deploy-manage/security.md @@ -77,6 +77,15 @@ deployment: You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: +### Enable and set up security +```{applies_to} +deployment: + self: all +``` + +:::{include} /deploy-manage/security/_snippets/enable-security.md +::: + ### Communication and network security :::{include} /deploy-manage/security/_snippets/cluster-communication-network.md diff --git a/deploy-manage/security/_snippets/cluster-communication-network.md b/deploy-manage/security/_snippets/cluster-communication-network.md index 041a44aaf4..07e84aeebe 100644 --- a/deploy-manage/security/_snippets/cluster-communication-network.md +++ b/deploy-manage/security/_snippets/cluster-communication-network.md @@ -1,7 +1,7 @@ * [Manage TLS certificates](/deploy-manage/security/secure-cluster-communications.md): TLS certificates apply security controls to network communications. Elastic uses TLS certificates to secure communications in two places: * **The HTTP layer**: Used for communication between your cluster or deployment and the internet. * **The transport layer**: Used mainly for inter-node communications, and in certain cases for cluster to cluster communication. - * In self-managed {{es}} clusters, you can also [Configure Kibana and Elasticsearch to use mutual TLS](/deploy-manage/security/secure-http-communications.md#elasticsearch-mutual-tls). + * In self-managed {{es}} clusters, you can also [Configure Kibana and Elasticsearch to use mutual TLS](/deploy-manage/security/kibana-es-mutual-tls.md). * [Enable cipher suites for stronger encryption](/deploy-manage/security/enabling-cipher-suites-for-stronger-encryption.md): The TLS and SSL protocols use a cipher suite that determines the strength of encryption used to protect the data. You may want to enable the use of additional cipher suites, so you can use different cipher suites for your TLS communications or communications with authentication providers. * [Restrict connections using traffic filtering](/deploy-manage/security/traffic-filtering.md): Traffic filtering allows you to limit how your deployments can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust. Restrict access based on IP addresses or CIDR ranges, or secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. * [Allow or deny {{ech}} IP ranges](/deploy-manage/security/elastic-cloud-static-ips.md): {{ecloud}} publishes a list of IP addresses used by its {{ech}} services for both incoming and outgoing traffic. Users can use these lists to configure their network firewalls as needed to allow or restrict traffic related to {{ech}} services. \ No newline at end of file diff --git a/deploy-manage/security/_snippets/enable-security.md b/deploy-manage/security/_snippets/enable-security.md new file mode 100644 index 0000000000..7ec3385eb7 --- /dev/null +++ b/deploy-manage/security/_snippets/enable-security.md @@ -0,0 +1,7 @@ +{{es}} security provides authentication, authorization, TLS encryption, and other capabilities described in this section. The first step in securing your self-managed deployment is to ensure that the {{es}} security feature is enabled and properly configured. + +::::{note} +Deployments managed by {{eck}}, {{ece}}, {{ech}}, and {{serverless-short}} automatically configure security by default. This includes setting the `elastic` user password, generating TLS certificates, and configuring {{kib}} to connect to {{es}} securely. Disabling security is not supported in these deployment types. +:::: + +For self-managed deployments, refer to the [set up security](../self-setup.md) guide, which explains how to enable security using Elastic’s automatic configuration or by following the manual process. \ No newline at end of file diff --git a/deploy-manage/security/install-stack-demo-secure.md b/deploy-manage/security/install-stack-demo-secure.md index c486865bb4..af5f867350 100644 --- a/deploy-manage/security/install-stack-demo-secure.md +++ b/deploy-manage/security/install-stack-demo-secure.md @@ -516,7 +516,7 @@ Now that the security is configured for the first {{es}} node, some steps need t ## Step 5: Generate server-side and client-side certificates for {{kib}} [install-stack-demo-secure-kib-es] -Now that the transport and HTTP layers are configured with encryption using the new certificates, there are two more tasks that must be accomplished for end-to-end connectivity to {{es}}: Set up certificates for encryption between {{kib}} and {{es}}, and between the client browser and {{kib}}. For additional details about any of these steps, refer to [Mutual TLS authentication between {{kib}} and {{es}}](secure-cluster-communications.md) and [Encrypt traffic between your browser and {{kib}}](set-up-basic-security-plus-https.md#encrypt-kibana-browser). +Now that the transport and HTTP layers are configured with encryption using the new certificates, there are two more tasks that must be accomplished for end-to-end connectivity to {{es}}: Set up certificates for encryption between {{kib}} and {{es}}, and between the client browser and {{kib}}. For additional details about any of these steps, refer to [Mutual TLS authentication between {{kib}} and {{es}}](./kibana-es-mutual-tls.md) and [Encrypt traffic between your browser and {{kib}}](set-up-basic-security-plus-https.md#encrypt-kibana-browser). 1. In Step 3, when you generated a new certificate for the HTTP layer, the process created an archive `elasticsearch-ssl-http.zip`. diff --git a/deploy-manage/security/k8s-https-settings.md b/deploy-manage/security/k8s-https-settings.md index 459c8fe35f..531e1c89f6 100644 --- a/deploy-manage/security/k8s-https-settings.md +++ b/deploy-manage/security/k8s-https-settings.md @@ -45,7 +45,7 @@ QLYL4zLEby3vRxq65+xofVBJAaM= You can provide your own CA and certificates instead of the self-signed certificate to connect to Elastic stack applications through HTTPS using a Kubernetes secret. -Check [Setup your own certificate](/deploy-manage/security/secure-http-communications.md#k8s-setting-up-your-own-certificate) to learn how to do that. +Check [Setup your own certificate](./set-up-basic-security-plus-https.md#encrypt-http-communication) to learn how to do that with `elasticsearch-certutil` tool. #### Custom self-signed certificate using OpenSSL [k8s_custom_self_signed_certificate_using_openssl] diff --git a/deploy-manage/security/k8s-transport-settings.md b/deploy-manage/security/k8s-transport-settings.md index a3bcd73ed7..ec22d23ad8 100644 --- a/deploy-manage/security/k8s-transport-settings.md +++ b/deploy-manage/security/k8s-transport-settings.md @@ -8,7 +8,7 @@ mapped_pages: # Manage transport certificates on ECK [k8s-transport-settings] -The transport module in Elasticsearch is used for internal communication between nodes within the cluster as well as communication between remote clusters. Check the [Elasticsearch documentation](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md) for details. For customization options of the HTTP layer, check [Services](../deploy/cloud-on-k8s/accessing-services.md) and [TLS certificates](/deploy-manage/security/secure-http-communications.md). +The transport module in Elasticsearch is used for internal communication between nodes within the cluster as well as communication between remote clusters. Check the [Elasticsearch documentation](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md) for details. For customization options of the HTTP layer, check [Access services](../deploy/cloud-on-k8s/accessing-services.md) and [HTTP TLS certificates](./k8s-https-settings.md). ## Customize the Transport Service [k8s_customize_the_transport_service] diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 2a0ffce8df..305e7c872b 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -116,7 +116,7 @@ HTTP TLS certificates for {{es}} can be [automatically configured](security-cert {{kib}} acts as both an HTTP client to {{es}} and a server for browser access. It performs operations on behalf of users, so it must be properly configured to trust the {{es}} certificates, and to present its own TLS certificate for secure browser connections. These configurations must be performed manually in self-managed deployments. -For environments with stricter security requirements, refer to [Mutual TLS authentication between {{kib}} and {{es}}](secure-http-communications.md#elasticsearch-mutual-tls). +For environments with stricter security requirements, refer to [Mutual TLS authentication between {{kib}} and {{es}}](./kibana-es-mutual-tls.md). ::: :::: diff --git a/deploy-manage/security/secure-cluster-communications.md.backup b/deploy-manage/security/secure-cluster-communications.md.backup deleted file mode 100644 index 0105bba785..0000000000 --- a/deploy-manage/security/secure-cluster-communications.md.backup +++ /dev/null @@ -1,172 +0,0 @@ ---- -navigation_title: Manage TLS certificates -applies_to: - deployment: - self: - eck: - ece: -mapped_urls: - - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-security.html - - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html - - https://www.elastic.co/guide/en/kibana/current/elasticsearch-mutual-tls.html ---- - - -% TODO: what to do about this page that doesn't exist -% * [/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-security.md](/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-security.md) - -$$$encrypt-internode-communication$$$ -$$$generate-certificates$$$ - - -# Manage TLS certificates - -This page explains how to secure communications between components in your {{stack}} deployment. - -For {{ech}} and {{serverless-full}} deployments, communications security is fully managed by Elastic with no configuration required. - -For ECE, ECK, and self-managed deployments, this page provides specific configuration guidance to secure the various communication channels between components. - -:::{tip} -For a complete comparison of security feature availability and responsibility by deployment type, see [Security features by deployment type](/deploy-manage/security.md#comparison-table). -::: - - -## Communication channels overview - -Your {{stack}} deployment includes several distinct communication channels that must be secured to protect your data and infrastructure. - -| **Channel** | **Description** | **Security needs** | -|-------------|-----------------|--------------------| -| [Transport layer](#transport-layer-security) | Communication between {{es}} nodes within a cluster | - Mutual TLS (required)
- Node authentication
- Node role verification | -| [HTTP layer](#http-layer-security) | Communication between external clients and {{es}} through the REST API | - TLS encryption
- Authentication (basic auth, API keys, or token-based)
- Optional client certificate authentication | -| [{{kib}}-to-{{es}}](#kib-to-es-communications) | Communication from the {{kib}} server to {{es}} for user requests and queries | - TLS encryption
- Service authentication (API keys, service tokens, or mutual TLS) | - - -## Transport layer security - -The transport layer is used for communication between {{es}} nodes in a cluster. Securing this layer prevents unauthorized nodes from joining your cluster and protects internode data. - -The way that transport layer security is managed depends on your deployment type: - -- **ECH, ECE, and Serverless**: Transport security is fully managed by Elastic. No configuration is required. -- **ECK**: Transport security is automatically configured by the operator, but you can [customize its service and SSL certificates](/deploy-manage/security/k8s-transport-settings.md). -- **Self-managed**: Transport security must be manually configured following the steps in [Set up basic security](set-up-basic-security.md). - -## HTTP layer security - -The HTTP layer secures client communication with your {{es}} cluster via its REST API, preventing unauthorized access and protecting data in transit. - -The way that HTTP layer security is managed depends on your deployment type: - -- **ECH and Serverless**: HTTP security is fully managed by Elastic. No configuration is required. -- **ECE**: HTTP security is automatically enforced at ECE proxies using self-signed certificates and a default [wildcard DNS record](/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md). However, it's recommended to [configure your own certificates](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). -- **ECK**: HTTP security is automatically configured with self-signed certificates. [Custom certificates and domain names can be configured](/deploy-manage/security/secure-http-communications.md#k8s-custom-http-certificate). -- **Self-managed**: HTTP security must be manually configured following [](secure-http-communications.md). - -## {{kib}}-to-{{es}} communications - -{{kib}} connects to {{es}} as a client but requires special configuration as it performs operations on behalf of end users. - -The way that {{kib}}-to-{{es}} communication security is managed depends on your deployment type: - -- **ECH and Serverless**: {{kib}}-{{es}} communication is fully managed using HTTPS and service tokens. -- **ECE and ECK**: {{kib}}-{{es}} communication is automatically secured with service tokens. -- **Self-managed**: {{kib}}-{{es}} communication must be manually secured. For mutual TLS configuration, refer to [Mutual TLS authentication between {{kib}} and {{es}}](secure-http-communications.md#elasticsearch-mutual-tls). - -## Certificate management [generate-certificates] - -Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. - -The way that you manage certificates depends on your deployment type: - -- **ECH and Serverless**: Certificate management is fully automated by Elastic. -- **ECE**: ECE generates certificates for you. Refer to [](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). -- **ECK**: ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. -- **Self-managed**: Certificate management is your responsibility. See [Security certificates and keys](security-certificates-keys.md). - -## Next steps - -- Configure [basic security and HTTPS](set-up-basic-security-plus-https.md) for self-managed deployments. -- Learn about [HTTP communication security](secure-http-communications.md) best practices. -- Understand how to securely manage [security certificates and keys](security-certificates-keys.md). -- Check [SSL/TLS version compatibility](supported-ssltls-versions-by-jdk-version.md) for optimal encryption. - -## IMPORTED CONTENT STARTS - -## Overview HTTP security - -Securing HTTP communications is essential for protecting data transmitted between: - -- {{kib}} and {{es}} -- {{kib}} and web browsers -- External monitoring systems and {{es}} -- Any HTTP client and your {{stack}} deployment - -Different deployment types have different requirements: - -| Deployment Type | HTTP Security Configuration | -|-----------------|----------------------------| -| {{ech}}/{{serverless-short}} | Automatically configured | -| Self-managed | Manual configuration required | -| {{eck}} | Configurable with defaults | -| {{ece}} | Manual configuration required | - -## Self-managed deployments - -```{applies_to} -self: -``` - -For self-managed deployments, you need to generate and configure certificates for secure HTTP communications. - -### Prerequisites - -Complete all steps in: - -- [Set up basic security](/deploy-manage/security/set-up-basic-security.md) -- [](/deploy-manage/security/set-up-basic-security-plus-https.md) - -### Mutual TLS removed - - -## Securing client applications - -When connecting client applications to {{es}}, use these best practices: - -- Always use HTTPS for all connections -- Validate server certificates to prevent man-in-the-middle attacks -- Use API keys or token-based authentication rather than basic auth where possible -- Implement appropriate connection pooling and retry mechanisms -- Consider mutual TLS for high-security environments - -For code examples and library-specific guidance, see [HTTP/REST client security](httprest-clients-security.md). - -## Securing Beats connections - -% TODO: Put in clients section - -When sending data from Beats to Elasticsearch, you need to secure those communications with TLS and proper authentication. - -Key configuration requirements: -- Configure Beats to use HTTPS when connecting to Elasticsearch -- Set up appropriate authentication (API keys recommended) -- Verify Elasticsearch server certificates - -For detailed instructions on configuring Beats security settings, see [Configure Beats security](/deploy-manage/security/set-up-basic-security-plus-https.md#configure-beats-security). - - - -## {{ece}} (ECE) - -```{applies_to} -deployment: - ece: all -``` - -For ECE deployments, certificate management and TLS configuration are handled at the platform level. Refer to these guides for ECE-specific security configurations: - -- [Manage security certificates in ECE](secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) -- [Allow x509 Certificates Signed with SHA-1](secure-your-elastic-cloud-enterprise-installation/allow-x509-certificates-signed-with-sha-1.md) -- [Configure TLS version](secure-your-elastic-cloud-enterprise-installation/configure-tls-version.md) - diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index 2e39a76292..c999bc308f 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -28,18 +28,13 @@ You must secure [other {{stack}} components](/deploy-manage/security/secure-clie You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: ## Enable and set up security [manually-configure-security] +```{applies_to} +deployment: + self: all +``` -The first step in securing your deployment is ensuring that the {{es}} security feature is enabled and properly set up. {{es}} security provides authentication, authorization, TLS encryption, and other capabilities described in this section. - -::::{note} -Deployments managed by {{eck}}, {{ece}}, {{ech}}, and {{serverless-short}} automatically configure security by default. This includes setting the `elastic` user password, generating TLS certificates, and configuring {{kib}} to connect to {{es}} securely. Disabling security is not supported in these deployment types. -:::: - -In self-managed clusters, security is [enabled and configured by default](./security-certificates-keys.md) since {{es}} 8.0, but some additional setup steps are still required. Follow the guide to complete the configuration and understand how the automatic setup works. - -If the automatic setup is skipped, or if you prefer full control, you can [configure security manually](./self-setup.md#manual-configuration). - -For an overview of both approaches, refer to [Security configuration for self-managed deployments](./self-setup.md). +:::{include} /deploy-manage/security/_snippets/enable-security.md +::: ## Communication and network security @@ -79,72 +74,3 @@ The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB :::{include} /deploy-manage/security/_snippets/cluster-comparison.md ::: - -## Old content - -### Common security scenarios - -:::{image} /deploy-manage/images/elasticsearch-reference-elastic-security-overview.png -:alt: Elastic Security layers -::: - -#### Minimal security ({{es}} Development) [security-minimal-overview] - -::::{important} -The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. -:::: - -If you’ve been working with {{es}} and want to enable security on your existing, unsecured cluster, start here. You’ll set passwords for the built-in users to prevent unauthorized access to your local cluster, and also configure password authentication for {{kib}}. - -[Set up minimal security](set-up-minimal-security.md) - -#### Basic security ({{es}} + {{kib}}) [security-basic-overview] - -This scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your {{es}} cluster. - -Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but internode communication will be secured. - -[Set up basic security](secure-cluster-communications.md) - -#### Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview] - -This scenario builds on the one for basic security and secures all HTTP traffic with TLS. In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. - -::::{note} -If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption. -:::: - -You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. - -[Set up basic security plus HTTPS traffic](secure-cluster-communications.md) - -### Network access - -Control which systems can access your Elastic deployments and clusters through traffic filtering and network controls: - -- **IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges. -- **Private link filters**: Secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. -- **Static IPs**: Use static IP addresses for predictable firewall rules. -- **Remote cluster access**: Secure cross-cluster operations. - -Refer to [](traffic-filtering.md). - - -### Cluster communication - -- **HTTP and HTTPs** -- **TLS certificates and keys** - - -### Data, objects and settings security - -- **Bring your own encryption key**: Use your own encryption key instead of the default encryption at rest provided by Elastic. -- **{{es}} and {{kib}} keystores**: Secure sensitive settings using keystores -- **{{kib}} saved objects**: Customize the encryption for {{kib}} objects such as dashboards. -- **{{kib}} session management**: Customize {{kib}} session expiration settings. - -Refer to [](data-security.md). - -### User roles - -[Define roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request. diff --git a/deploy-manage/security/secure-your-cluster-deployment.md.backup b/deploy-manage/security/secure-your-cluster-deployment.md.backup deleted file mode 100644 index e7530b0e60..0000000000 --- a/deploy-manage/security/secure-your-cluster-deployment.md.backup +++ /dev/null @@ -1,213 +0,0 @@ ---- -applies_to: - deployment: - self: ga - eck: all - ece: all - ess: all -mapped_pages: - - https://www.elastic.co/guide/en/elasticsearch/reference/current/manually-configure-security.html ---- - -# Secure your cluster or deployment - -It's important to protect your {{es}} cluster and the data it contains. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. - -:::{include} /deploy-manage/security/_snippets/complete-security.md -::: - -:::{important} -* Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. -* Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. -::: - -:::{tip} -You must secure [other {{stack}} components](/deploy-manage/security/secure-clients-integrations.md), as well as [client and integration communications](/deploy-manage/security/httprest-clients-security.md), separately. -::: - -You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: - -## Security activation [manually-configure-security] - -% Intro to link automatic setup and manual setup process of security - -Everything starts with the security feature activation in {{es}}, which enables authentication and authorization, TLS encryption of communications, and all other security related functionality described in this section. - -::::{note} -Orchestrated deployments automatically configures security by default, the elastic user password, TLS certificates, and configure {{kib}} to access {{es}} in a secure way. Disabling security is not an option in managed deployments. -:::: - -In self-managed clusters, there are two ways to perform the initial security setup, depending on your needs: - -* Automatic security setup: {{es}} security requires TLS certificates to be configured for inter-node communications (transport layer), and in order to facilitate the initial setup, there's an automatic configuration. - -* Manual security setup: If you are configuring security in an unsecured cluster, or if you want to use your own certificates, you can follow the manual approach, which consists of three steps, depending whether your cluster is a single-node or multi-node cluster: - * Minimal security - * Basic transport TLS security: for multi-node clusters only, as single-node clusters don't need to talk with other nodes. - * HTTP TLS: optional but highly recommended - -Refer to [skipxxxx]() to understand in what cases autoconfiguration works and when a manual configuration will be expected. - -Kibana also supports HTTPS. - -Mutual authentication is also an option. - -### Security basics (a decidir) - -For {{es}} to be able to start with security enabled, the following is necessary: - - -single nodes and multiple-nodes. -What is required, what is optional. Single-node vs multi-node -Consider Kibana HTTPS - -Security gives access to users and roles and certificates, links - -Security needs vary depending on whether you’re developing locally on your laptop or securing all communications in a production environment. Regardless of where you’re deploying the {{stack}} ("ELK"), running a secure cluster is incredibly important to protect your data. That’s why security is [enabled and configured by default](../deploy/self-managed/installing-elasticsearch.md) since {{es}} 8.0. - -A decidir esto tambien: - - -### Minimal security ({{es}} Development) [security-minimal-overview] - -::::{important} -The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. -:::: - -If you’ve been working with {{es}} and want to enable security on your existing, unsecured cluster, start here. You’ll set passwords for the built-in users to prevent unauthorized access to your local cluster, and also configure password authentication for {{kib}}. - -[Set up minimal security](set-up-minimal-security.md) - -### Basic security ({{es}} + {{kib}}) [security-basic-overview] - -This scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your {{es}} cluster. - -Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but internode communication will be secured. - -[Set up basic security](secure-cluster-communications.md) - -### Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview] - -This scenario builds on the one for basic security and secures all HTTP traffic with TLS. In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. - -::::{note} -If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption. -:::: - -You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. - -[Set up basic security plus HTTPS traffic](secure-http-communications.md) - - - -## Communication and network security - -:::{include} /deploy-manage/security/_snippets/cluster-communication-network.md -::: - -## Data security - -:::{include} /deploy-manage/security/_snippets/cluster-data.md -::: - -## User session security - -:::{include} /deploy-manage/security/_snippets/cluster-user-session.md -::: - -## Security event audit logging - -:::{include} /deploy-manage/security/_snippets/audit-logging.md -::: - -## Configure security in a self-managed cluster - -Since {{es}} 8.0, security is enabled and configured by default. However, security auto configuration [might be skipped](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md#stack-skip-auto-configuration) in certain scenarios. In these cases, you can [manually configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md). - -## FIPS 140-2 compliant mode -```{applies_to} -deployment: - self: - eck: -``` - -The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB 140-2), titled "Security Requirements for Cryptographic Modules" is a U.S. government computer security standard used to approve cryptographic modules. You can run a self-managed cluster or {{eck}} cluster in FIPS-compliant mode: - -* [Self-managed](/deploy-manage/security/fips-140-2.md) -* [ECK](/deploy-manage/deploy/cloud-on-k8s/deploy-fips-compatible-version-of-eck.md) - -% we need to refine this table, but the idea is awesome IMO - -## Security features by deployment type [comparison-table] - -:::{include} /deploy-manage/security/_snippets/cluster-comparison.md -::: - -## Old content - -### Common security scenarios - -:::{image} /deploy-manage/images/elasticsearch-reference-elastic-security-overview.png -:alt: Elastic Security layers -::: - -#### Minimal security ({{es}} Development) [security-minimal-overview] - -::::{important} -The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. -:::: - -If you’ve been working with {{es}} and want to enable security on your existing, unsecured cluster, start here. You’ll set passwords for the built-in users to prevent unauthorized access to your local cluster, and also configure password authentication for {{kib}}. - -[Set up minimal security](set-up-minimal-security.md) - -#### Basic security ({{es}} + {{kib}}) [security-basic-overview] - -This scenario configures TLS for communication between nodes. This security layer requires that nodes verify security certificates, which prevents unauthorized nodes from joining your {{es}} cluster. - -Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but internode communication will be secured. - -[Set up basic security](secure-cluster-communications.md) - -#### Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview] - -This scenario builds on the one for basic security and secures all HTTP traffic with TLS. In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. - -::::{note} -If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption. -:::: - -You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure. - -[Set up basic security plus HTTPS traffic](secure-http-communications.md) - -### Network access - -Control which systems can access your Elastic deployments and clusters through traffic filtering and network controls: - -- **IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges. -- **Private link filters**: Secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. -- **Static IPs**: Use static IP addresses for predictable firewall rules. -- **Remote cluster access**: Secure cross-cluster operations. - -Refer to [](traffic-filtering.md). - - -### Cluster communication - -- **HTTP and HTTPs** -- **TLS certificates and keys** - - -### Data, objects and settings security - -- **Bring your own encryption key**: Use your own encryption key instead of the default encryption at rest provided by Elastic. -- **{{es}} and {{kib}} keystores**: Secure sensitive settings using keystores -- **{{kib}} saved objects**: Customize the encryption for {{kib}} objects such as dashboards. -- **{{kib}} session management**: Customize {{kib}} session expiration settings. - -Refer to [](data-security.md). - -### User roles - -[Define roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request. diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index 7347a982c4..c0d3432dc3 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -7,7 +7,7 @@ mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup-https.html --- -# Setup security in self-managed deployments +# Set up security in self-managed deployments There are two approaches to configuring security in self-managed deployments of the Elastic Stack: @@ -36,7 +36,7 @@ If you’re securing an existing unsecured cluster, or prefer to use your own TL * **Start with [minimal security](set-up-minimal-security.md)**: Enables password-based authentication for built-in users and configures {{kib}} to connect using credentials. Suitable for single-node clusters, but not sufficient for production or multi-node clusters. -* **Then [configure transport TLS](secure-cluster-communications.md)**: Required for multi-node clusters running in [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode). Secures communication between nodes and prevents unauthorized nodes from joining the cluster. +* **Then [configure transport TLS](./set-up-basic-security.md)**: Required for multi-node clusters running in [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode). Secures communication between nodes and prevents unauthorized nodes from joining the cluster. * **Finally, [configure HTTP TLS](set-up-basic-security-plus-https.md)**: Secures all client communications over HTTPS, including traffic between {{kib}} and {{es}}, and between browsers and {{kib}}. Recommended for all clusters, even single-node setups. diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 7e2d4034b6..65a0e06e60 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -73,7 +73,7 @@ Once TLS is enabled, all client communications with the cluster will be encrypte Each certificate will have its own private key, and will be issued for a specific hostname or IP address. - 7. When prompted, enter the name of the first node in your cluster. Use the same node name that you used when [generating node certificates](secure-cluster-communications.md#generate-certificates). + 7. When prompted, enter the name of the first node in your cluster. 8. Enter all hostnames used to connect to your first node. These hostnames will be added as DNS names in the Subject Alternative Name (SAN) field in your certificate. List every hostname and variant used to connect to your cluster over HTTPS. @@ -108,7 +108,7 @@ Once TLS is enabled, all client communications with the cluster will be encrypte xpack.security.http.ssl.keystore.path: http.p12 ``` - 3. Add the password for your private key to the secure settings in {{es}}. + 3. Add the password for your private key to the [secure settings](/deploy-manage/security/secure-settings.md) in {{es}}. ```shell ./bin/elasticsearch-keystore add xpack.security.http.ssl.keystore.secure_password diff --git a/deploy-manage/security/set-up-basic-security.md b/deploy-manage/security/set-up-basic-security.md index ce779200b9..b3f67d4ad7 100644 --- a/deploy-manage/security/set-up-basic-security.md +++ b/deploy-manage/security/set-up-basic-security.md @@ -11,7 +11,7 @@ mapped_pages: % original title: Set up basic security for the Elastic Stack # Set up transport TLS [security-basic-setup] -When you start {{es}} for the first time, passwords are generated for the `elastic` user and TLS is automatically configured for you. If you configure security manually *before* starting your {{es}} nodes, the auto-configuration process will respect your security configuration. You can adjust your TLS configuration at any time, such as [updating node certificates](updating-certificates.md). +When you start {{es}} for the first time, passwords are generated for the `elastic` user and TLS is automatically configured for you. If you configure security manually before starting your {{es}} nodes, the auto-configuration process will respect your security configuration. You can adjust your TLS configuration at any time, such as [updating node certificates](updating-certificates.md). ::::{important} If your cluster has multiple nodes, then you must configure TLS between nodes. [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. @@ -28,7 +28,7 @@ Transport Layer Security (TLS) is the name of an industry standard protocol for Transport Protocol is the name of the protocol that {{es}} nodes use to communicate with one another. This name is specific to {{es}} and distinguishes the transport port (default `9300`) from the HTTP port (default `9200`). Nodes communicate with one another using the transport port, and REST clients communicate with {{es}} using the HTTP port. -Although the word *transport* appears in both contexts, they mean different things. It’s possible to apply TLS to both the {{es}} transport port and the HTTP port. We know that these overlapping terms can be confusing, so to clarify, in this scenario we’re applying TLS to the {{es}} transport port. In [](secure-http-communications.md), we’ll apply TLS to the {{es}} HTTP port. +Although the word *transport* appears in both contexts, they mean different things. It’s possible to apply TLS to both the {{es}} transport port and the HTTP port. We know that these overlapping terms can be confusing, so to clarify, in this scenario we’re applying TLS to the {{es}} transport port. In [](./set-up-basic-security-plus-https.md), we’ll apply TLS to the {{es}} HTTP port. :::: @@ -135,6 +135,6 @@ Complete the following steps **for each node in your cluster**. To join the same Congratulations! You’ve encrypted communications between the nodes in your cluster and can pass the [TLS bootstrap check](../deploy/self-managed/bootstrap-checks.md#bootstrap-checks-tls). -To add another layer of security, [Set up basic security for the Elastic Stack plus secured HTTPS traffic](secure-http-communications.md). In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. +To add another layer of security, [Set up basic security for the Elastic Stack plus secured HTTPS traffic](./set-up-basic-security-plus-https.md). In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. diff --git a/deploy-manage/security/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index c7a78f1ed9..65bd86920c 100644 --- a/deploy-manage/security/set-up-minimal-security.md +++ b/deploy-manage/security/set-up-minimal-security.md @@ -8,7 +8,7 @@ mapped_pages: --- % alternative title: Manual security setup -$ Set up minimal security +% Set up minimal security % Scope: Just enabling security, resetting passwords, and configuring kibana. Manual approach, opposite to automatic security configuration % Original title: Set up minimal security # Minimal security setup [security-minimal-setup] @@ -17,12 +17,12 @@ $ Set up minimal security You only need to complete the following steps if you’re running an existing, unsecured cluster and want to enable the {{es}} {{security-features}}. :::: -In {{es}} 8.0 and later, security is [enabled automatically](../deploy/self-managed/installing-elasticsearch.md) when you start {{es}} for the first time. +In {{es}} 8.0 and later, security is [enabled automatically](./security-certificates-keys.md) when you start {{es}} for the first time. -If you’re running an existing {{es}} cluster where security is disabled, you can manually enable the {{es}} {{security-features}} and then create passwords for built-in users. You can add more users later, but using the built-in users simplifies the process of enabling security for your cluster. +If you’re running an existing {{es}} cluster where security is disabled, you can manually enable the {{es}} {{security-features}} and then create passwords for [built-in users](/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md). You can add more users later, but using the built-in users simplifies the process of enabling security for your cluster. ::::{important} -The minimal security scenario is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must enable minimal security and then [configure Transport Layer Security (TLS)](secure-cluster-communications.md) between nodes. +The minimal security scenario described in this document is not sufficient for [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters. If your cluster has multiple nodes, you must follow this guide, together with [configure Transport Layer Security (TLS)](./set-up-basic-security.md) between nodes. :::: @@ -47,16 +47,9 @@ Enabling the {{es}} security features provides basic authentication so that you discovery.type: single-node ``` - - ## Set passwords for built-in users [security-create-builtin-users] -To communicate with your cluster, you must configure a password for the `elastic` and `kibana_system` built-in users. Unless you enable anonymous access (not recommended), all requests that don’t include credentials are rejected. - -::::{note} -You only need to set passwords for the `elastic` and `kibana_system` users when enabling minimal or basic security. -:::: - +To communicate with your cluster, you must configure a password for the `elastic` and `kibana_system` [built-in users](/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md). Unless you enable anonymous access (not recommended), all requests that don’t include credentials are rejected. 1. On **every** node in your cluster, start {{es}}. For example, if you installed {{es}} with a `.tar.gz` package, run the following command from the `ES_HOME` directory: @@ -64,6 +57,10 @@ You only need to set passwords for the `elastic` and `kibana_system` users when ./bin/elasticsearch ``` + ::::{note} + If you are following this procedure for a multi-node cluster, you will have to setup [transport TLS certificates](./set-up-basic-security.md) in your nodes before being able to start the nodes. + :::: + 2. On any node in your cluster, open another terminal window and set the password for the `elastic` built-in user by running the [`elasticsearch-reset-password`](elasticsearch://reference/elasticsearch/command-line-tools/reset-password.md) utility. This command resets the password to an auto-generated value. ```shell @@ -89,6 +86,8 @@ You only need to set passwords for the `elastic` and `kibana_system` users when ## Configure {{kib}} to connect to {{es}} with a password [add-built-in-users] +% Consider including a note here or updating the procedure to use newer auth methods like service tokens + When the {{es}} security features are enabled, users must log in to {{kib}} with a valid username and password. You’ll configure {{kib}} to use the built-in `kibana_system` user and the password that you created earlier. {{kib}} performs some background tasks that require use of the `kibana_system` user. @@ -105,7 +104,7 @@ This account is not meant for individual users and does not have permission to l The `KBN_PATH_CONF` variable is the path for the {{kib}} configuration files. If you installed {{kib}} using archive distributions (`zip` or `tar.gz`), the variable defaults to `KIB_HOME/config`. If you used package distributions (Debian or RPM), the variable defaults to `/etc/kibana`. :::: -2. From the directory where you installed {{kib}}, run the following commands to create the {{kib}} keystore and add the secure settings: +2. From the directory where you installed {{kib}}, run the following commands to create the {{kib}} keystore and add the [secure settings](/deploy-manage/security/secure-settings.md): 1. Create the {{kib}} keystore: @@ -132,12 +131,13 @@ This account is not meant for individual users and does not have permission to l ## What’s next? [minimal-security-whatsnext] -Congratulations! You enabled password protection for your local cluster to prevent unauthorized access. You can log in to {{kib}} securely as the `elastic` user and create additional users and roles. If you’re running a [single-node cluster](../deploy/self-managed/bootstrap-checks.md#single-node-discovery), then you can stop here. +Congratulations! You enabled password protection for your local cluster to prevent unauthorized access. You can log in to {{kib}} as the `elastic` user and create additional users and roles, but take in mind that your browser connections and the traffic between {{kib}} and {{es}} will still be unencrypted with plain HTTP. + +If your cluster has multiple nodes, then you must [configure Transport Layer Security (TLS) between nodes](./set-up-basic-security.md). [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. -If your cluster has multiple nodes, then you must configure Transport Layer Security (TLS) between nodes. [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. +Regardless of your cluster being a [single-node](../deploy/self-managed/bootstrap-checks.md#single-node-discovery) or a multi-node cluster it's highly recommended to secure the HTTP layer -[Set up basic security for the {{stack}}](secure-cluster-communications.md) to secure all internal communication between nodes in your cluster. +If you’re running a , then you can stop here. -TBD -> Previous link should point to TRANSPORT SSL (basic) diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index 733f7665d8..42aea726bb 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -35,7 +35,7 @@ Set an encryption key so that sessions are not invalidated. You can optionally c {{kib}}'s reporting and saved objects features also have encryption key settings. Refer to [`xpack.reporting.encryptionKey`](kibana://reference/configuration-reference/reporting-settings.md#xpack-reporting-encryptionkey) and [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-encryptionkey) respectively. 2. Optional: [Configure {{kib}}'s session expiration settings](/deploy-manage/security/kibana-session-management.md). -3. Optional: [Configure {{kib}} to authenticate to {{es}} with a client certificate](/deploy-manage/security/secure-cluster-communications.md). +3. Optional: [Configure {{kib}} to authenticate to {{es}} with a client certificate (mutual authentication)](/deploy-manage/security/kibana-es-mutual-tls.md). 4. Restart {{kib}}. @@ -92,7 +92,7 @@ You should use SSL/TLS encryption to ensure that traffic between browsers and th ### Enabling mutual TLS between {{kib}} and {{es}} -Refer to [](/deploy-manage/security/secure-cluster-communications.md#elasticsearch-mutual-tls) for information on how to enable mutual TLS between {{kib}} and {{es}}. +Refer to [Mutual TLS authentication between {{kib}} and {{es}}](/deploy-manage/security/kibana-es-mutual-tls.md) for information on how to enable mutual TLS between {{kib}} and {{es}}. ### Use {{stack}} {{security-features}} [configuring-kibana-shield] diff --git a/redirects.yml b/redirects.yml index 212bdc72f3..1562609517 100644 --- a/redirects.yml +++ b/redirects.yml @@ -19,7 +19,7 @@ redirects: 'spaces-control-feature-visibility': 'deploy-manage/deploy/cloud-enterprise/deploy-large-installation-cloud.md': '!deploy-manage/deploy/cloud-enterprise/deploy-large-installation.md' 'deploy-manage/deploy/cloud-enterprise/find-cloud-id.md': '!deploy-manage/deploy/cloud-enterprise/connect-elasticsearch.md' - 'deploy-manage/deploy/cloud-on-k8s/k8s-kibana-http-configuration.md': '!deploy-manage/security/secure-http-communications.md' + 'deploy-manage/deploy/cloud-on-k8s/k8s-kibana-http-configuration.md': '!deploy-manage/security/k8s-https-settings.md' 'deploy-manage/deploy/self-managed/install-with-docker.md': '!deploy-manage/deploy/self-managed/install-kibana-with-docker.md' 'deploy-manage/deploy/self-managed/deploy-cluster.md': '!deploy-manage/deploy/self-managed/installing-elasticsearch.md' 'deploy-manage/deploy/self-managed/configure.md': '!deploy-manage/deploy/self-managed/configure-kibana.md' @@ -37,8 +37,8 @@ redirects: 'deploy-manage/monitor/logging-configuration/auditing-search-queries.md': 'deploy-manage/security/logging-configuration/auditing-search-queries.md' 'deploy-manage/monitor/logging-configuration/logfile-audit-output.md': 'deploy-manage/security/logging-configuration/logfile-audit-output.md' - ## temporary hack due to moved anchors - 'deploy-manage/security/secure-http-communications.md': '!deploy-manage/security/secure-http-communications.md' + ## temporary hack due to moved anchors (maybe could be removed) + 'deploy-manage/security/secure-http-communications.md': '!deploy-manage/security/secure-cluster-communications.md' ## explore-analyze 'explore-analyze/machine-learning/nlp/ml-nlp-auto-scale.md': '!deploy-manage/autoscaling/trained-model-autoscaling.md' From 4dd4b337d6c705445b28e779390435f4416a7b7a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Thu, 27 Mar 2025 21:45:29 +0100 Subject: [PATCH 09/42] TLS certificates extra landing pages added --- deploy-manage/security/data-security.md | 2 +- deploy-manage/security/eck-tls.md | 21 +++++++++++++++++-- .../security/kibana-es-mutual-tls.md | 2 +- .../security/secure-cluster-communications.md | 2 +- .../security/security-certificates-keys.md | 2 +- deploy-manage/security/self-tls.md | 13 ++++++++++++ .../set-up-basic-security-plus-https.md | 2 +- .../security/set-up-basic-security.md | 4 +--- .../security/set-up-minimal-security.md | 4 +--- deploy-manage/toc.yml | 6 +++--- 10 files changed, 42 insertions(+), 16 deletions(-) diff --git a/deploy-manage/security/data-security.md b/deploy-manage/security/data-security.md index 1e199e9ed2..75cd649767 100644 --- a/deploy-manage/security/data-security.md +++ b/deploy-manage/security/data-security.md @@ -15,7 +15,7 @@ For {{ech}} deployments, instead of the default, Elastic-managed encryption, you :::{note} -There is no encryption at rest out of the box for deployments orchestrated using [{{ece}}](secure-your-elastic-cloud-enterprise-installation.md) and [{{eck}}](secure-your-eck-installation.md), or for [self-managed clusters](manually-configure-security-in-self-managed-cluster.md). You must instead configure disk-level encryption on your hosts. +There is no encryption at rest out of the box for deployments orchestrated using [{{ece}}](secure-your-elastic-cloud-enterprise-installation.md) and [{{eck}}](secure-your-eck-installation.md), or for self-managed clusters. You must instead configure disk-level encryption on your hosts. Configuring dm-crypt or similar technologies is outside the scope of the Elastic documentation, and issues related to disk encryption are outside the scope of support. ::: diff --git a/deploy-manage/security/eck-tls.md b/deploy-manage/security/eck-tls.md index c524fdf0aa..17853ed9ef 100644 --- a/deploy-manage/security/eck-tls.md +++ b/deploy-manage/security/eck-tls.md @@ -11,5 +11,22 @@ mapped_pages: All {{stack}} resources deployed by the ECK operator are secured by default. The operator sets up basic authentication and TLS to encrypt network traffic to, from, and within your {{es}} cluster and {{kib}} instances. -% TBD -(Pending to write a quick intro about use cases and links) \ No newline at end of file +Refer to [Communication channels](./secure-cluster-communications.md#communication-channels) for an overview about the different endpoints and traffic flows to secure. + +## {{es}} transport layer configuration + +{{es}} transport security and TLS certificates are automatically configured by the operator, but you can still [customize its service and CA certificates](/deploy-manage/security/k8s-transport-settings.md). + +## {{es}} and {{kib}} HTTP configuration + +HTTP TLS is automatically enabled for {{es}} and {{kib}} using self-signed certificates, with [several options available for customization](./k8s-https-settings.md), including custom certificates and domain names. + +{{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. + +## Certificates maintenance and rotation + +ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. + +ECK automatically rotates any certificates and CAs that were generated by the operator and are under its management. + +For certificate management configuration options, refer to [ECK configuration flags](cloud-on-k8s://reference/eck-configuration-flags.md). \ No newline at end of file diff --git a/deploy-manage/security/kibana-es-mutual-tls.md b/deploy-manage/security/kibana-es-mutual-tls.md index 89737dad1f..b9dca4d3f7 100644 --- a/deploy-manage/security/kibana-es-mutual-tls.md +++ b/deploy-manage/security/kibana-es-mutual-tls.md @@ -1,5 +1,5 @@ --- -navigation_title: Kibana > Elasticsearch mutual TLS +navigation_title: Mutual authentication applies_to: deployment: self: all diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 305e7c872b..c4f1266966 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -23,7 +23,7 @@ For ECE, ECK, and self-managed deployments, this page provides specific configur For a complete comparison of security feature availability and responsibility by deployment type, see [Security features by deployment type](/deploy-manage/security.md#comparison-table). ::: -## Communication channels overview +## Communication channels overview [communication-channels] Both {{es}} and {{kib}}, the core components of the {{stack}}, expose service endpoints that must be secured. {{es}} handles traffic at two levels: * The **transport layer**, used for internal communication between nodes in the cluster. diff --git a/deploy-manage/security/security-certificates-keys.md b/deploy-manage/security/security-certificates-keys.md index e1cadfad49..8ceb22f3b1 100644 --- a/deploy-manage/security/security-certificates-keys.md +++ b/deploy-manage/security/security-certificates-keys.md @@ -207,7 +207,7 @@ When you start {{es}} for the first time, the node startup process tries to auto * Whether security is already configured * If the startup process can modify the node configuration -If any of those checks fail, there’s a good indication that you [manually configured security](manually-configure-security-in-self-managed-cluster.md), or don’t want security to be configured automatically. In these cases, the node starts normally using the existing configuration. +If any of those checks fail, there’s a good indication that you manually configured security, or don’t want security to be configured automatically. In these cases, the node starts normally using the existing configuration. ::::{important} If you redirect {{es}} output to a file, security autoconfiguration is skipped. Autoconfigured credentials can only be viewed on the terminal the first time you start {{es}}. If you need to redirect output to a file, start {{es}} without redirection the first time and use redirection on all subsequent starts. diff --git a/deploy-manage/security/self-tls.md b/deploy-manage/security/self-tls.md index 256507a00d..f5ac56cc4a 100644 --- a/deploy-manage/security/self-tls.md +++ b/deploy-manage/security/self-tls.md @@ -9,4 +9,17 @@ mapped_pages: # Manage TLS certificates in self-managed deployments +This section provides guides for manually configuring and maintaining the TLS certificates required by your deployment. For an overview of the endpoints that need securing in {{es}} and {{kib}}, refer to [Communication channels](./secure-cluster-communications.md#communication-channels). +Use the following guides to manage TLS certificates: + +* [Set up transport TLS](./set-up-basic-security.md): Create a CA and certificates to encrypt inter-node traffic in multi-node clusters. +* [Set up HTTP TLS](./set-up-basic-security-plus-https.md): Create and configure certificates to encrypt {{es}} and {{kib}} HTTP endpoints. +* [Mutual TLS authentication between {{kib}} and {{es}}](./kibana-es-mutual-tls.md): Strengthen security by requiring {{kib}} to use an additional client certificate in the communication to {{es}}. +* [Update TLS certificates](./updating-certificates.md): Renew or replace existing TLS certificates before they expire. + +As an alternative to the manual configuration, consider the [automatic security configuration](./security-certificates-keys.md) procedure, which includes automatic generation of TLS certificates for {{es}} HTTP and transport endpoints. + +## Certificates maintenance and rotation + +In self-managed deployments, you are responsible for certificate lifecycle management, including monitoring expiration dates, renewing certificates, and redeploying them as needed. If you used Elastic tools to generate your certificates, refer to [Update TLS certificates](./updating-certificates.md) for guidance on rotating or replacing them. diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 65a0e06e60..757996bb46 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -29,7 +29,7 @@ If you already have certificates available, you can skip the certificate generat ::::{tip} When running `elasticsearch-certutil` in `http` mode, the tool prompts you to choose how to generate the TLS certificates. One key question is whether you want to generate a Certificate Signing Request (CSR). -* Answer `n` to skip the CSR and sign your certificates using a Certificate Authority (CA) [you previously created](./set-up-basic-security.md#generate-the-certificate-authority). You’ll be prompted to provide the path to your CA, which the tool will use to generate a `.p12` certificate. The steps in this guide follow this workflow for {{es}} certificates. +* Answer `n` to skip the CSR and sign your certificates using a Certificate Authority (CA) [you previously created](./set-up-basic-security.md#generate-certificates). You’ll be prompted to provide the path to your CA, which the tool will use to generate a `.p12` certificate. The steps in this guide follow this workflow for {{es}} certificates. * Answer `y` to generate a CSR that can be signed by your organization's internal CA or external certificate provider. This is common in environments where trust is managed centrally. The steps in this guide follow this workflow for {{kib}} certificate. Both workflows are supported. Choose the one that best fits your infrastructure and trust model. diff --git a/deploy-manage/security/set-up-basic-security.md b/deploy-manage/security/set-up-basic-security.md index b3f67d4ad7..94fb1890b8 100644 --- a/deploy-manage/security/set-up-basic-security.md +++ b/deploy-manage/security/set-up-basic-security.md @@ -135,6 +135,4 @@ Complete the following steps **for each node in your cluster**. To join the same Congratulations! You’ve encrypted communications between the nodes in your cluster and can pass the [TLS bootstrap check](../deploy/self-managed/bootstrap-checks.md#bootstrap-checks-tls). -To add another layer of security, [Set up basic security for the Elastic Stack plus secured HTTPS traffic](./set-up-basic-security-plus-https.md). In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. - - +To add another layer of security, [set up HTTP TLS](./set-up-basic-security-plus-https.md) to encrypt client communications with both {{es}} and {{kib}}. diff --git a/deploy-manage/security/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index 65bd86920c..d13aa7af84 100644 --- a/deploy-manage/security/set-up-minimal-security.md +++ b/deploy-manage/security/set-up-minimal-security.md @@ -7,9 +7,7 @@ mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-minimal-setup.html --- -% alternative title: Manual security setup -% Set up minimal security -% Scope: Just enabling security, resetting passwords, and configuring kibana. Manual approach, opposite to automatic security configuration +% Scope: enable security, reset passwords and configure kibana to use authentication. Alternative approach to the automatic security configuration. % Original title: Set up minimal security # Minimal security setup [security-minimal-setup] diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 4420b2d2a8..1665f5f094 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -470,13 +470,13 @@ toc: children: - file: security/same-ca.md - file: security/different-ca.md - - file: security/kibana-es-mutual-tls.md + - file: security/kibana-es-mutual-tls.md + - file: security/supported-ssltls-versions-by-jdk-version.md + - file: security/enabling-cipher-suites-for-stronger-encryption.md - file: security/eck-tls.md children: - file: security/k8s-https-settings.md - file: security/k8s-transport-settings.md - - file: security/supported-ssltls-versions-by-jdk-version.md - - file: security/enabling-cipher-suites-for-stronger-encryption.md - file: security/traffic-filtering.md children: - file: security/ip-traffic-filtering.md From 6185393b3277cd0f148e40b6930782225b34ca45 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Thu, 27 Mar 2025 22:31:42 +0100 Subject: [PATCH 10/42] redirect for self-setup.md --- redirects.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/redirects.yml b/redirects.yml index 1562609517..b4e0cea67f 100644 --- a/redirects.yml +++ b/redirects.yml @@ -39,6 +39,7 @@ redirects: ## temporary hack due to moved anchors (maybe could be removed) 'deploy-manage/security/secure-http-communications.md': '!deploy-manage/security/secure-cluster-communications.md' + 'deploy-manage/security/manually-configure-security-in-self-managed-cluster.md': '!deploy-manage/security/self-setup.md' ## explore-analyze 'explore-analyze/machine-learning/nlp/ml-nlp-auto-scale.md': '!deploy-manage/autoscaling/trained-model-autoscaling.md' From 0a1558586f4604bc0707840723cfb6977035e607 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Thu, 27 Mar 2025 22:34:04 +0100 Subject: [PATCH 11/42] automatic security setup file renamed to self-auto-setup.md --- deploy-manage/deploy/self-managed/bootstrap-checks.md | 2 +- deploy-manage/security/kibana-es-mutual-tls.md | 4 ++-- deploy-manage/security/secure-cluster-communications.md | 4 ++-- .../{security-certificates-keys.md => self-auto-setup.md} | 2 +- deploy-manage/security/self-setup.md | 4 ++-- deploy-manage/security/self-tls.md | 2 +- deploy-manage/security/set-up-minimal-security.md | 2 +- deploy-manage/security/using-kibana-with-security.md | 2 +- deploy-manage/toc.yml | 2 +- 9 files changed, 12 insertions(+), 12 deletions(-) rename deploy-manage/security/{security-certificates-keys.md => self-auto-setup.md} (97%) diff --git a/deploy-manage/deploy/self-managed/bootstrap-checks.md b/deploy-manage/deploy/self-managed/bootstrap-checks.md index 534b91b106..f34eb901e7 100644 --- a/deploy-manage/deploy/self-managed/bootstrap-checks.md +++ b/deploy-manage/deploy/self-managed/bootstrap-checks.md @@ -215,7 +215,7 @@ $$$bootstrap-checks-tls$$$ If you enable {{es}} {{security-features}}, unless you have a trial license, you must configure SSL/TLS for internode-communication. :::{note} -Single-node clusters that use a loopback interface do not have this requirement. For more information, see [*Start the {{stack}} with security enabled automatically*](/deploy-manage/security/security-certificates-keys.md). +Single-node clusters that use a loopback interface do not have this requirement. For more information, see [*Start the {{stack}} with security enabled automatically*](/deploy-manage/security/self-auto-setup.md). ::: To pass this bootstrap check, you must [set up SSL/TLS in your cluster](/deploy-manage/security/set-up-basic-security.md#encrypt-internode-communication). diff --git a/deploy-manage/security/kibana-es-mutual-tls.md b/deploy-manage/security/kibana-es-mutual-tls.md index b9dca4d3f7..2d7cad61a9 100644 --- a/deploy-manage/security/kibana-es-mutual-tls.md +++ b/deploy-manage/security/kibana-es-mutual-tls.md @@ -17,7 +17,7 @@ In a standard TLS configuration, the server presents a signed certificate to aut {{es}} {{security-features}} are enabled on your cluster by default, so each request that {{kib}} (the client) makes to {{es}} (the server) is authenticated. Most requests made by end users through {{kib}} to {{es}} are authenticated by using the credentials of the logged-in user. -To [enroll {{kib}} with an {{es}} cluster](/deploy-manage/security/security-certificates-keys.md#stack-start-with-security), you pass a generated enrollment token. This token configures {{kib}} to authenticate with {{es}} using a [service account token](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#service-accounts-tokens). {{kib}} also supports mutual TLS authentication with {{es}} via a [Public Key Infrastructure (PKI) realm](/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md). With this setup, {{es}} needs to verify the signature on the {{kib}} client certificate, and it also needs to map the client certificate’s distinguished name (DN) to the appropriate `kibana_system` role. +To [enroll {{kib}} with an {{es}} cluster](/deploy-manage/security/self-auto-setup.md#stack-start-with-security), you pass a generated enrollment token. This token configures {{kib}} to authenticate with {{es}} using a [service account token](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#service-accounts-tokens). {{kib}} also supports mutual TLS authentication with {{es}} via a [Public Key Infrastructure (PKI) realm](/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md). With this setup, {{es}} needs to verify the signature on the {{kib}} client certificate, and it also needs to map the client certificate’s distinguished name (DN) to the appropriate `kibana_system` role. ::::{note} Using a PKI realm is a [subscription feature](https://www.elastic.co/subscriptions). @@ -25,7 +25,7 @@ Using a PKI realm is a [subscription feature](https://www.elastic.co/subscriptio #### Configure {{kib}} and {{es}} to use mutual TLS authentication [_configure_kib_and_es_to_use_mutual_tls_authentication] -If you haven’t already, start {{kib}} and connect it to {{es}} using the [enrollment token](/deploy-manage/security/security-certificates-keys.md#stack-start-with-security). +If you haven’t already, start {{kib}} and connect it to {{es}} using the [enrollment token](/deploy-manage/security/self-auto-setup.md#stack-start-with-security). 1. Obtain a client certificate and private key for {{kib}}. diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index c4f1266966..73c46ad556 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -65,7 +65,7 @@ The way that transport layer security is managed depends on your deployment type :::{tab-item} Self-managed :sync: self -{{es}} transport security can be [automatically configured](security-certificates-keys.md), or manually set up by following the steps in [Set up basic security](set-up-basic-security.md). +{{es}} transport security can be [automatically configured](self-auto-setup.md), or manually set up by following the steps in [Set up basic security](set-up-basic-security.md). ::: :::: @@ -112,7 +112,7 @@ HTTP TLS is automatically enabled for {{es}} and {{kib}} using self-signed certi :::{tab-item} Self-managed :sync: self -HTTP TLS certificates for {{es}} can be [automatically configured](security-certificates-keys.md), or manually set up by following the steps in [Set up HTTP SSL](./set-up-basic-security-plus-https.md). +HTTP TLS certificates for {{es}} can be [automatically configured](self-auto-setup.md), or manually set up by following the steps in [Set up HTTP SSL](./set-up-basic-security-plus-https.md). {{kib}} acts as both an HTTP client to {{es}} and a server for browser access. It performs operations on behalf of users, so it must be properly configured to trust the {{es}} certificates, and to present its own TLS certificate for secure browser connections. These configurations must be performed manually in self-managed deployments. diff --git a/deploy-manage/security/security-certificates-keys.md b/deploy-manage/security/self-auto-setup.md similarity index 97% rename from deploy-manage/security/security-certificates-keys.md rename to deploy-manage/security/self-auto-setup.md index 8ceb22f3b1..31d4d60058 100644 --- a/deploy-manage/security/security-certificates-keys.md +++ b/deploy-manage/security/self-auto-setup.md @@ -20,7 +20,7 @@ When you start {{es}} for the first time, the following security configuration o You can then start {{kib}} and enter the enrollment token, which is valid for 30 minutes. This token automatically applies the security settings from your {{es}} cluster, authenticates to {{es}} with the built-in `kibana` service account, and writes the security configuration to `kibana.yml`. ::::{note} -There are [some cases](/deploy-manage/security/security-certificates-keys.md#stack-skip-auto-configuration) where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled. +There are [some cases](/deploy-manage/security/self-auto-setup.md#stack-skip-auto-configuration) where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled. :::: diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index c0d3432dc3..57770801e0 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -13,7 +13,7 @@ There are two approaches to configuring security in self-managed deployments of ## Automatic configuration [automatic-configuration] -Since version 8.0, {{es}} automatically enables security features on first startup when the node is not part of an existing cluster and none of the [incompatible settings](./security-certificates-keys.md#stack-existing-settings-detected) have been explicitly configured. +Since version 8.0, {{es}} automatically enables security features on first startup when the node is not part of an existing cluster and none of the [incompatible settings](./self-auto-setup.md#stack-existing-settings-detected) have been explicitly configured. The automatic configuration:: @@ -28,7 +28,7 @@ This automatic setup is the quickest way to get started and ensures your cluster The automatic configuration does not enable TLS on the {{kib}} HTTP endpoint. To encrypt browser traffic to {{kib}}, follow the steps in [](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). :::: -Refer to [Automatic security setup](./security-certificates-keys.md) for the complete procedure, including [cases where it may be skipped](./security-certificates-keys.md#stack-skip-auto-configuration). +Refer to [Automatic security setup](./self-auto-setup.md) for the complete procedure, including [cases where it may be skipped](./self-auto-setup.md#stack-skip-auto-configuration). ## Manual configuration [manual-configuration] diff --git a/deploy-manage/security/self-tls.md b/deploy-manage/security/self-tls.md index f5ac56cc4a..c15576a6e8 100644 --- a/deploy-manage/security/self-tls.md +++ b/deploy-manage/security/self-tls.md @@ -18,7 +18,7 @@ Use the following guides to manage TLS certificates: * [Mutual TLS authentication between {{kib}} and {{es}}](./kibana-es-mutual-tls.md): Strengthen security by requiring {{kib}} to use an additional client certificate in the communication to {{es}}. * [Update TLS certificates](./updating-certificates.md): Renew or replace existing TLS certificates before they expire. -As an alternative to the manual configuration, consider the [automatic security configuration](./security-certificates-keys.md) procedure, which includes automatic generation of TLS certificates for {{es}} HTTP and transport endpoints. +As an alternative to the manual configuration, consider the [automatic security configuration](./self-auto-setup.md) procedure, which includes automatic generation of TLS certificates for {{es}} HTTP and transport endpoints. ## Certificates maintenance and rotation diff --git a/deploy-manage/security/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index d13aa7af84..64e997e328 100644 --- a/deploy-manage/security/set-up-minimal-security.md +++ b/deploy-manage/security/set-up-minimal-security.md @@ -15,7 +15,7 @@ mapped_pages: You only need to complete the following steps if you’re running an existing, unsecured cluster and want to enable the {{es}} {{security-features}}. :::: -In {{es}} 8.0 and later, security is [enabled automatically](./security-certificates-keys.md) when you start {{es}} for the first time. +In {{es}} 8.0 and later, security is [enabled automatically](./self-auto-setup.md) when you start {{es}} for the first time. If you’re running an existing {{es}} cluster where security is disabled, you can manually enable the {{es}} {{security-features}} and then create passwords for [built-in users](/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md). You can add more users later, but using the built-in users simplifies the process of enabling security for your cluster. diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index 42aea726bb..6452065295 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -13,7 +13,7 @@ mapped_urls: % Scope: TBD # Configure security in {{kib}} [using-kibana-with-security] -When you start {{es}} for the first time, {{stack-security-features}} are enabled on your cluster and TLS is configured automatically. The security configuration process generates a password for the `elastic` user and an enrollment token for {{kib}}. [Start the {{stack}} with security enabled](/deploy-manage/security/security-certificates-keys.md) and then enroll {{kib}} as part of the configuration process. +When you start {{es}} for the first time, {{stack-security-features}} are enabled on your cluster and TLS is configured automatically. The security configuration process generates a password for the `elastic` user and an enrollment token for {{kib}}. [Start the {{stack}} with security enabled](/deploy-manage/security/self-auto-setup.md) and then enroll {{kib}} as part of the configuration process. You can then log in to {{kib}} as the `elastic` user to create additional roles and users. diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 1665f5f094..c487af36ce 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -458,7 +458,7 @@ toc: children: - file: security/self-setup.md children: - - file: security/security-certificates-keys.md + - file: security/self-auto-setup.md - file: security/set-up-minimal-security.md - file: security/secure-cluster-communications.md children: From 6e86fa656dae19831446967dbfea76fa435cee41 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Fri, 28 Mar 2025 14:39:47 +0100 Subject: [PATCH 12/42] final refinements before ready for review --- .../security/_snippets/enable-security.md | 4 ++-- deploy-manage/security/eck-tls.md | 2 +- .../security/secure-cluster-communications.md | 10 +++++----- deploy-manage/security/self-tls.md | 14 ++++++++------ deploy-manage/security/set-up-basic-security.md | 16 ++++++++++------ .../security/set-up-minimal-security.md | 7 +------ redirects.yml | 2 +- 7 files changed, 28 insertions(+), 27 deletions(-) diff --git a/deploy-manage/security/_snippets/enable-security.md b/deploy-manage/security/_snippets/enable-security.md index 7ec3385eb7..8a0291d396 100644 --- a/deploy-manage/security/_snippets/enable-security.md +++ b/deploy-manage/security/_snippets/enable-security.md @@ -1,7 +1,7 @@ -{{es}} security provides authentication, authorization, TLS encryption, and other capabilities described in this section. The first step in securing your self-managed deployment is to ensure that the {{es}} security feature is enabled and properly configured. +{{es}} security unlocks key capabilities such as [Authentication and authorization](/deploy-manage/users-roles.md), TLS encryption, and other security-related functionality described in this section. The first step in securing your deployment is to ensure that the {{es}} security feature is enabled and properly configured. ::::{note} Deployments managed by {{eck}}, {{ece}}, {{ech}}, and {{serverless-short}} automatically configure security by default. This includes setting the `elastic` user password, generating TLS certificates, and configuring {{kib}} to connect to {{es}} securely. Disabling security is not supported in these deployment types. :::: -For self-managed deployments, refer to the [set up security](../self-setup.md) guide, which explains how to enable security using Elastic’s automatic configuration or by following the manual process. \ No newline at end of file +For self-managed deployments, [Learn how to set up security](/deploy-manage/security/self-setup.md) using Elastic’s automatic configuration or by following the manual process. \ No newline at end of file diff --git a/deploy-manage/security/eck-tls.md b/deploy-manage/security/eck-tls.md index 17853ed9ef..d0d9d90359 100644 --- a/deploy-manage/security/eck-tls.md +++ b/deploy-manage/security/eck-tls.md @@ -23,7 +23,7 @@ HTTP TLS is automatically enabled for {{es}} and {{kib}} using self-signed certi {{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. -## Certificates maintenance and rotation +## Certificates lifecycle ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 73c46ad556..36767b6dd9 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -26,10 +26,10 @@ For a complete comparison of security feature availability and responsibility by ## Communication channels overview [communication-channels] Both {{es}} and {{kib}}, the core components of the {{stack}}, expose service endpoints that must be secured. {{es}} handles traffic at two levels: -* The **transport layer**, used for internal communication between nodes in the cluster. -* The **HTTP layer**, used by external clients — including Kibana — to send requests via the REST API. +* The **transport layer** (defaults to port `9300`), used for internal communication between nodes in the cluster. +* The **HTTP layer** (defaults to port `9200`), used by external clients — including Kibana — to send requests via the REST API. -Additionally, {{kib}} functions as a web server, exposing its own **HTTP endpoint** to users, and also acts as a client when sending requests to {{es}}. +Additionally, {{kib}} functions as a web server, exposing its own **HTTP endpoint** (defaults to port `5601`) to users, and also acts as a client when sending requests to {{es}}. To ensure secure operation, it’s important to understand the communication channels and their specific security requirements. @@ -41,7 +41,7 @@ To ensure secure operation, it’s important to understand the communication cha ### Transport layer security -The transport layer is responsible for internal communication between {{es}} nodes in the cluster. Securing this layer prevents unauthorized nodes from joining your cluster and protects internode traffic. +Securing {{es}} transport layer, also known as transport protocol, prevents unauthorized nodes from joining your cluster and protects internode traffic. The way that transport layer security is managed depends on your deployment type: @@ -121,7 +121,7 @@ For environments with stricter security requirements, refer to [Mutual TLS authe :::: -## Maintaining and rotating TLS certificates [generate-certificates] +## Certificates lifecycle [generate-certificates] Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. Each deployment type provides different tools or responsibilities for managing certificates lifecycle. diff --git a/deploy-manage/security/self-tls.md b/deploy-manage/security/self-tls.md index c15576a6e8..8e69f4e001 100644 --- a/deploy-manage/security/self-tls.md +++ b/deploy-manage/security/self-tls.md @@ -9,17 +9,19 @@ mapped_pages: # Manage TLS certificates in self-managed deployments -This section provides guides for manually configuring and maintaining the TLS certificates required by your deployment. For an overview of the endpoints that need securing in {{es}} and {{kib}}, refer to [Communication channels](./secure-cluster-communications.md#communication-channels). +This section provides guides for manually configuring and maintaining the TLS certificates in self-managed deployments. For an overview of the endpoints that need securing in {{es}} and {{kib}}, refer to [Communication channels](./secure-cluster-communications.md#communication-channels). Use the following guides to manage TLS certificates: -* [Set up transport TLS](./set-up-basic-security.md): Create a CA and certificates to encrypt inter-node traffic in multi-node clusters. -* [Set up HTTP TLS](./set-up-basic-security-plus-https.md): Create and configure certificates to encrypt {{es}} and {{kib}} HTTP endpoints. -* [Mutual TLS authentication between {{kib}} and {{es}}](./kibana-es-mutual-tls.md): Strengthen security by requiring {{kib}} to use an additional client certificate in the communication to {{es}}. -* [Update TLS certificates](./updating-certificates.md): Renew or replace existing TLS certificates before they expire. +* [](./set-up-basic-security.md) (**required for multi-node clusters**): Create and configure a Certificate Authority (CA) and certificates to encrypt inter-node traffic. +* [](./set-up-basic-security-plus-https.md) (**optional but recommended**): Create and configure certificates to encrypt traffic on {{es}} and {{kib}} HTTP endpoints. +* [](./kibana-es-mutual-tls.md) (**optional**): Strengthen security by requiring {{kib}} to use an additional client certificate in the communication to {{es}}. +* [](./updating-certificates.md): Renew or replace existing TLS certificates before they expire. +* [](./supported-ssltls-versions-by-jdk-version.md): Customize the list of supported SSL/TLS versions in your cluster. +* [](./enabling-cipher-suites-for-stronger-encryption.md): Enable the use of additional cipher suites, so you can use different cipher suites for your TLS communications or communications with authentication providers. As an alternative to the manual configuration, consider the [automatic security configuration](./self-auto-setup.md) procedure, which includes automatic generation of TLS certificates for {{es}} HTTP and transport endpoints. -## Certificates maintenance and rotation +## Certificates lifecycle In self-managed deployments, you are responsible for certificate lifecycle management, including monitoring expiration dates, renewing certificates, and redeploying them as needed. If you used Elastic tools to generate your certificates, refer to [Update TLS certificates](./updating-certificates.md) for guidance on rotating or replacing them. diff --git a/deploy-manage/security/set-up-basic-security.md b/deploy-manage/security/set-up-basic-security.md index 94fb1890b8..22ef07f362 100644 --- a/deploy-manage/security/set-up-basic-security.md +++ b/deploy-manage/security/set-up-basic-security.md @@ -11,15 +11,19 @@ mapped_pages: % original title: Set up basic security for the Elastic Stack # Set up transport TLS [security-basic-setup] -When you start {{es}} for the first time, passwords are generated for the `elastic` user and TLS is automatically configured for you. If you configure security manually before starting your {{es}} nodes, the auto-configuration process will respect your security configuration. You can adjust your TLS configuration at any time, such as [updating node certificates](updating-certificates.md). +If your cluster has multiple nodes, then you must configure TLS between {{es}} nodes. [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. This document focuses on the manual generation and configuration of the TLS certificates for the transport protocol in multi-node self-managed clusters. -::::{important} -If your cluster has multiple nodes, then you must configure TLS between nodes. [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. - -This document focuses on manual configuration of the TLS certificates for multi-node clusters. Single node clusters do not require transport TLS. +::::{note} +For other deployment types, such as {{ech}}, {{ece}}, or {{eck}}, refer to [Manage TLS overview](./secure-cluster-communications.md). :::: -The transport layer relies on mutual TLS for both encryption and authentication of nodes. Correctly applying TLS ensures that a malicious node cannot join the cluster and exchange data with other nodes. While implementing username and password authentication at the HTTP layer is useful for securing a local cluster, the security of communication between nodes requires TLS. +When you start {{es}} for the first time, passwords are generated for the `elastic` user and TLS is [automatically configured](./self-auto-setup.md) for you. If you configure security [manually](./self-setup.md#manual-configuration) before starting your {{es}} nodes, the auto-configuration process will respect your security configuration. You can adjust your TLS configuration at any time, such as [updating node certificates](updating-certificates.md). + +## Transport protocol overview + +The {{es}} transport protocol, which listens in port `9300` by default, handles all inter-node communication within the cluster. + +It relies on mutual TLS for both encryption and authentication of nodes. Correctly applying TLS ensures that a malicious node cannot join the cluster and exchange data with other nodes. While implementing username and password authentication at the HTTP layer is useful for securing external access, the security of communication between nodes requires TLS. Configuring TLS between nodes is the basic security setup to prevent unauthorized nodes from accessing to your cluster. diff --git a/deploy-manage/security/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index 64e997e328..1d6b8836c3 100644 --- a/deploy-manage/security/set-up-minimal-security.md +++ b/deploy-manage/security/set-up-minimal-security.md @@ -133,9 +133,4 @@ Congratulations! You enabled password protection for your local cluster to preve If your cluster has multiple nodes, then you must [configure Transport Layer Security (TLS) between nodes](./set-up-basic-security.md). [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. -Regardless of your cluster being a [single-node](../deploy/self-managed/bootstrap-checks.md#single-node-discovery) or a multi-node cluster it's highly recommended to secure the HTTP layer - -If you’re running a , then you can stop here. - - - +Regardless of your cluster being a [single-node](../deploy/self-managed/bootstrap-checks.md#single-node-discovery) or a multi-node cluster, it's highly recommended to [secure the HTTP layer](./set-up-basic-security-plus-https.md) with TLS certificates. diff --git a/redirects.yml b/redirects.yml index b4e0cea67f..1ebfa66c5e 100644 --- a/redirects.yml +++ b/redirects.yml @@ -40,7 +40,7 @@ redirects: ## temporary hack due to moved anchors (maybe could be removed) 'deploy-manage/security/secure-http-communications.md': '!deploy-manage/security/secure-cluster-communications.md' 'deploy-manage/security/manually-configure-security-in-self-managed-cluster.md': '!deploy-manage/security/self-setup.md' - + 'deploy-manage/security/security-certificates-keys.md': '!deploy-manage/security/self-auto-setup.md' ## explore-analyze 'explore-analyze/machine-learning/nlp/ml-nlp-auto-scale.md': '!deploy-manage/autoscaling/trained-model-autoscaling.md' From 36b15c7bde14a11ba852258b43547a4430f6af46 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Fri, 28 Mar 2025 15:00:16 +0100 Subject: [PATCH 13/42] moved tutorial --- .../security/secure-cluster-communications.md | 4 +-- .../security/using-kibana-with-security.md | 26 +++++++------------ deploy-manage/toc.yml | 2 +- 3 files changed, 12 insertions(+), 20 deletions(-) diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 36767b6dd9..326705df7d 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -39,7 +39,7 @@ To ensure secure operation, it’s important to understand the communication cha | [{{es}} HTTP layer](#http-layer-security) | Communication between external clients and {{es}} through the REST API | TLS/SSL optional (but recommended) | | [{{kib}} HTTP layer](#http-layer-security) | Communication between external browsers and {{kib}} through the REST API | TLS/SSL optional (but recommended) | -### Transport layer security +### Transport layer security [encrypt-internode-communication] Securing {{es}} transport layer, also known as transport protocol, prevents unauthorized nodes from joining your cluster and protects internode traffic. @@ -70,7 +70,7 @@ The way that transport layer security is managed depends on your deployment type :::: -### HTTP layer security +### HTTP layer security [encrypt-http-communication] The HTTP layer includes the service endpoints exposed by both {{es}} and {{kib}}, supporting communications such as REST API requests, browser access to {{kib}}, and {{kib}}’s own traffic to {{es}}. Securing these endpoints helps prevent unauthorized access and protects sensitive data in transit. diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index 6452065295..c452adc8e1 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -11,8 +11,11 @@ mapped_urls: % https://www.elastic.co/guide/en/kibana/current/using-kibana-with-security.html % https://www.elastic.co/guide/en/kibana/current/Security-production-considerations.html % Scope: TBD + # Configure security in {{kib}} [using-kibana-with-security] +% check and move part of this if needed + When you start {{es}} for the first time, {{stack-security-features}} are enabled on your cluster and TLS is configured automatically. The security configuration process generates a password for the `elastic` user and an enrollment token for {{kib}}. [Start the {{stack}} with security enabled](/deploy-manage/security/self-auto-setup.md) and then enroll {{kib}} as part of the configuration process. You can then log in to {{kib}} as the `elastic` user to create additional roles and users. @@ -41,6 +44,10 @@ Set an encryption key so that sessions are not invalidated. You can optionally c ## Create roles and users [security-create-roles] +% ensure we have references to users and roles + +% check if part of this process should be merged with the other guides + Configure roles for your {{kib}} users to control what data those users can access. 1. Temporarily log in to {{kib}} using the built-in `elastic` superuser so you can create new users and assign roles. If you are running {{kib}} locally, go to `https://localhost:5601` to view the login page. @@ -83,24 +90,9 @@ Configure roles for your {{kib}} users to control what data those users can acce :::: ## Additional Kibana security configurations [Security-production-considerations] +% deleting a lot here... -To secure your {{kib}} installation in production, consider these high-priority topics to ensure that only authorized users can access {{kib}}. - -### Enable SSL/TLS [enabling-ssl] - -You should use SSL/TLS encryption to ensure that traffic between browsers and the {{kib}} server cannot be viewed or tampered with by third parties. See [encrypt HTTP client communications for {{kib}}](/deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-kibana-http). - -### Enabling mutual TLS between {{kib}} and {{es}} - -Refer to [Mutual TLS authentication between {{kib}} and {{es}}](/deploy-manage/security/kibana-es-mutual-tls.md) for information on how to enable mutual TLS between {{kib}} and {{es}}. - -### Use {{stack}} {{security-features}} [configuring-kibana-shield] - -You can use {{stack}} {{security-features}} to control what {{es}} data users can access through {{kib}}. - -When {{security-features}} are enabled, {{kib}} users have to log in. They must have a role granting [{{kib}} privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md) and access to the indices that they will be working with in {{kib}}. - -If a user loads a {{kib}} dashboard that accesses data in an index that they are not authorized to view, they get an error that indicates the index does not exist. +% Important sentence to include!!! For more information on granting access to {{kib}}, see [](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md). diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index c487af36ce..6dbc74c4ec 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -460,6 +460,7 @@ toc: children: - file: security/self-auto-setup.md - file: security/set-up-minimal-security.md + - file: security/install-stack-demo-secure.md - file: security/secure-cluster-communications.md children: - file: security/self-tls.md @@ -509,7 +510,6 @@ toc: - file: security/logging-configuration/auditing-search-queries.md - file: security/logging-configuration/correlating-kibana-elasticsearch-audit-logs.md - file: security/fips-140-2.md - - file: security/install-stack-demo-secure.md - file: security/using-kibana-with-security.md - file: security/secure-clients-integrations.md - file: security/httprest-clients-security.md From d3ba8d51c622177cfc673cde340156d04525e835 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Fri, 28 Mar 2025 15:05:24 +0100 Subject: [PATCH 14/42] fixing some links --- .../deploy/self-managed/_snippets/auto-security-config.md | 4 ++-- deploy-manage/security/secure-cluster-communications.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md b/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md index 6f9c39948d..b039da1155 100644 --- a/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md +++ b/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md @@ -1,6 +1,6 @@ When you start {{es}} for the first time, the following security configuration occurs automatically: -* [Certificates and keys](/deploy-manage/security/security-certificates-keys.md#stack-security-certificates) for TLS are generated for the transport and HTTP layers. +* [Certificates and keys](/deploy-manage/security/self-auto-setup.md#stack-security-certificates) for TLS are generated for the transport and HTTP layers. * The TLS configuration settings are written to `elasticsearch.yml`. * A password is generated for the `elastic` user. * An enrollment token is generated for {{kib}}, which is valid for 30 minutes. @@ -8,5 +8,5 @@ When you start {{es}} for the first time, the following security configuration o You can then start {{kib}} and enter the enrollment token. This token automatically applies the security settings from your {{es}} cluster, authenticates to {{es}} with the built-in `kibana` service account, and writes the security configuration to `kibana.yml`. ::::{note} -There are [some cases](/deploy-manage/security/security-certificates-keys.md#stack-skip-auto-configuration) where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled. +There are [some cases](/deploy-manage/security/self-auto-setup.md#stack-skip-auto-configuration) where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled. :::: \ No newline at end of file diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 326705df7d..da7c3c3d40 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -35,9 +35,9 @@ To ensure secure operation, it’s important to understand the communication cha | **Channel** | **Description** | **TLS requirements** | |-------------|-----------------|--------------------| -| [{{es}} transport layer](#transport-layer-security) | Communication between {{es}} nodes within a cluster | Mutual TLS/SSL required for multi-node clusters | -| [{{es}} HTTP layer](#http-layer-security) | Communication between external clients and {{es}} through the REST API | TLS/SSL optional (but recommended) | -| [{{kib}} HTTP layer](#http-layer-security) | Communication between external browsers and {{kib}} through the REST API | TLS/SSL optional (but recommended) | +| [{{es}} transport layer](#encrypt-internode-communication) | Communication between {{es}} nodes within a cluster | Mutual TLS/SSL required for multi-node clusters | +| [{{es}} HTTP layer](#encrypt-http-communication) | Communication between external clients and {{es}} through the REST API | TLS/SSL optional (but recommended) | +| [{{kib}} HTTP layer](#encrypt-http-communication) | Communication between external browsers and {{kib}} through the REST API | TLS/SSL optional (but recommended) | ### Transport layer security [encrypt-internode-communication] From d820457b49e9f91fb52092bd4cb800af17e47d8a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Sat, 29 Mar 2025 20:29:49 +0100 Subject: [PATCH 15/42] Apply suggestions from code review Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com> --- deploy-manage/security.md | 4 ---- .../_snippets/cluster-communication-network.md | 2 +- deploy-manage/security/_snippets/enable-security.md | 12 +++++++----- deploy-manage/security/self-setup.md | 6 +++--- deploy-manage/security/set-up-basic-security.md | 2 +- deploy-manage/security/set-up-minimal-security.md | 2 +- 6 files changed, 13 insertions(+), 15 deletions(-) diff --git a/deploy-manage/security.md b/deploy-manage/security.md index 656b8dd4ab..ddd4869949 100644 --- a/deploy-manage/security.md +++ b/deploy-manage/security.md @@ -78,10 +78,6 @@ deployment: You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: ### Enable and set up security -```{applies_to} -deployment: - self: all -``` :::{include} /deploy-manage/security/_snippets/enable-security.md ::: diff --git a/deploy-manage/security/_snippets/cluster-communication-network.md b/deploy-manage/security/_snippets/cluster-communication-network.md index 07e84aeebe..d4751d1f58 100644 --- a/deploy-manage/security/_snippets/cluster-communication-network.md +++ b/deploy-manage/security/_snippets/cluster-communication-network.md @@ -3,5 +3,5 @@ * **The transport layer**: Used mainly for inter-node communications, and in certain cases for cluster to cluster communication. * In self-managed {{es}} clusters, you can also [Configure Kibana and Elasticsearch to use mutual TLS](/deploy-manage/security/kibana-es-mutual-tls.md). * [Enable cipher suites for stronger encryption](/deploy-manage/security/enabling-cipher-suites-for-stronger-encryption.md): The TLS and SSL protocols use a cipher suite that determines the strength of encryption used to protect the data. You may want to enable the use of additional cipher suites, so you can use different cipher suites for your TLS communications or communications with authentication providers. -* [Restrict connections using traffic filtering](/deploy-manage/security/traffic-filtering.md): Traffic filtering allows you to limit how your deployments can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust. Restrict access based on IP addresses or CIDR ranges, or secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. +* [Restrict connections using traffic filtering](/deploy-manage/security/traffic-filtering.md): Traffic filtering allows you to limit how your deployments can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust. Restrict access based on IP addresses or CIDR ranges, or, in {{ech}} deployments, secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. * [Allow or deny {{ech}} IP ranges](/deploy-manage/security/elastic-cloud-static-ips.md): {{ecloud}} publishes a list of IP addresses used by its {{ech}} services for both incoming and outgoing traffic. Users can use these lists to configure their network firewalls as needed to allow or restrict traffic related to {{ech}} services. \ No newline at end of file diff --git a/deploy-manage/security/_snippets/enable-security.md b/deploy-manage/security/_snippets/enable-security.md index 8a0291d396..82d96e6c4c 100644 --- a/deploy-manage/security/_snippets/enable-security.md +++ b/deploy-manage/security/_snippets/enable-security.md @@ -1,7 +1,9 @@ -{{es}} security unlocks key capabilities such as [Authentication and authorization](/deploy-manage/users-roles.md), TLS encryption, and other security-related functionality described in this section. The first step in securing your deployment is to ensure that the {{es}} security feature is enabled and properly configured. +{{es}} security features unlock key capabilities such as [authentication and authorization](/deploy-manage/users-roles.md), TLS encryption, and other security-related functionality described in this section. The first step in securing your deployment is to ensure that the {{es}} security features are enabled and properly configured. -::::{note} -Deployments managed by {{eck}}, {{ece}}, {{ech}}, and {{serverless-short}} automatically configure security by default. This includes setting the `elastic` user password, generating TLS certificates, and configuring {{kib}} to connect to {{es}} securely. Disabling security is not supported in these deployment types. -:::: +For self-managed deployments, security features are automatically configured when possible. To learn about the automatic configuration process, the cases where automatic configuration might be skipped, and how to manually configure security, refer to [](/deploy-manage/security/self-setup.md). -For self-managed deployments, [Learn how to set up security](/deploy-manage/security/self-setup.md) using Elastic’s automatic configuration or by following the manual process. \ No newline at end of file +:::{tip} +If you want to use your own TLS certificates, then you should manually configure security. +::: + +Deployments managed by {{eck}}, {{ece}}, {{ech}}, and {{serverless-short}} automatically configure security by default. This includes setting the `elastic` user password, generating TLS certificates, and configuring {{kib}} to connect to {{es}} securely. Disabling security is not supported in these deployment types. \ No newline at end of file diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index 57770801e0..2c2b8f11a3 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -9,7 +9,7 @@ mapped_pages: # Set up security in self-managed deployments -There are two approaches to configuring security in self-managed deployments of the Elastic Stack: +There are two approaches to configuring security in self-managed deployments of the {{stack}}: ## Automatic configuration [automatic-configuration] @@ -18,8 +18,8 @@ Since version 8.0, {{es}} automatically enables security features on first start The automatic configuration:: * Generates TLS certificates for the transport and HTTP layers -* Applies security settings to elasticsearch.yml -* Sets a password for the elastic superuser +* Applies security settings to `elasticsearch.yml` +* Sets a password for the `elastic` superuser * Creates an enrollment token to securely connect {{kib}} to {{es}} This automatic setup is the quickest way to get started and ensures your cluster is protected by default. diff --git a/deploy-manage/security/set-up-basic-security.md b/deploy-manage/security/set-up-basic-security.md index 22ef07f362..88e7c194c8 100644 --- a/deploy-manage/security/set-up-basic-security.md +++ b/deploy-manage/security/set-up-basic-security.md @@ -14,7 +14,7 @@ mapped_pages: If your cluster has multiple nodes, then you must configure TLS between {{es}} nodes. [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. This document focuses on the manual generation and configuration of the TLS certificates for the transport protocol in multi-node self-managed clusters. ::::{note} -For other deployment types, such as {{ech}}, {{ece}}, or {{eck}}, refer to [Manage TLS overview](./secure-cluster-communications.md). +For other deployment types, such as {{ech}}, {{ece}}, or {{eck}}, refer to [](./secure-cluster-communications.md). :::: When you start {{es}} for the first time, passwords are generated for the `elastic` user and TLS is [automatically configured](./self-auto-setup.md) for you. If you configure security [manually](./self-setup.md#manual-configuration) before starting your {{es}} nodes, the auto-configuration process will respect your security configuration. You can adjust your TLS configuration at any time, such as [updating node certificates](updating-certificates.md). diff --git a/deploy-manage/security/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index 1d6b8836c3..b4a0f122d3 100644 --- a/deploy-manage/security/set-up-minimal-security.md +++ b/deploy-manage/security/set-up-minimal-security.md @@ -56,7 +56,7 @@ To communicate with your cluster, you must configure a password for the `elastic ``` ::::{note} - If you are following this procedure for a multi-node cluster, you will have to setup [transport TLS certificates](./set-up-basic-security.md) in your nodes before being able to start the nodes. + If you are following this procedure for a multi-node cluster, you will have to set up [transport TLS certificates](./set-up-basic-security.md) in your nodes before being able to start the nodes. :::: 2. On any node in your cluster, open another terminal window and set the password for the `elastic` built-in user by running the [`elasticsearch-reset-password`](elasticsearch://reference/elasticsearch/command-line-tools/reset-password.md) utility. This command resets the password to an auto-generated value. From fc987ad89d089e0f4187a3fda6efc93f573ffe96 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Mon, 31 Mar 2025 10:52:07 +0200 Subject: [PATCH 16/42] deploy guides updated --- .../self-managed/_snippets/auto-security-config.md | 12 ++++++------ ...tall-elasticsearch-from-archive-on-linux-macos.md | 2 +- .../install-elasticsearch-with-debian-package.md | 2 +- .../self-managed/install-elasticsearch-with-rpm.md | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md b/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md index b039da1155..60a1268da3 100644 --- a/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md +++ b/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md @@ -1,11 +1,11 @@ -When you start {{es}} for the first time, the following security configuration occurs automatically: +When you start {{es}} for the first time, it automatically performs the following security setup: -* [Certificates and keys](/deploy-manage/security/self-auto-setup.md#stack-security-certificates) for TLS are generated for the transport and HTTP layers. -* The TLS configuration settings are written to `elasticsearch.yml`. -* A password is generated for the `elastic` user. -* An enrollment token is generated for {{kib}}, which is valid for 30 minutes. +* Generates [TLS certificates](#stack-security-certificates) for the [transport and HTTP layers](/deploy-manage/security/secure-cluster-communications.md#communication-channels) +* Applies TLS configuration settings to `elasticsearch.yml` +* Sets a password for the `elastic` superuser +* Creates an enrollment token to securely connect {{kib}} to {{es}} -You can then start {{kib}} and enter the enrollment token. This token automatically applies the security settings from your {{es}} cluster, authenticates to {{es}} with the built-in `kibana` service account, and writes the security configuration to `kibana.yml`. +You can then start {{kib}} and enter the enrollment token, which is valid for 30 minutes. This token automatically applies the security settings from your {{es}} cluster, authenticates to {{es}} with the built-in `kibana` service account, and writes the security configuration to `kibana.yml`. ::::{note} There are [some cases](/deploy-manage/security/self-auto-setup.md#stack-skip-auto-configuration) where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled. diff --git a/deploy-manage/deploy/self-managed/install-elasticsearch-from-archive-on-linux-macos.md b/deploy-manage/deploy/self-managed/install-elasticsearch-from-archive-on-linux-macos.md index 71cfc5f0e4..e8ac231892 100644 --- a/deploy-manage/deploy/self-managed/install-elasticsearch-from-archive-on-linux-macos.md +++ b/deploy-manage/deploy/self-managed/install-elasticsearch-from-archive-on-linux-macos.md @@ -158,7 +158,7 @@ This is convenient because you don’t have to create any directories to start u | plugins | Plugin files location. Each plugin will be contained in a subdirectory. | `$ES_HOME/plugins` | | | repo | Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here. | Not configured | [`path.repo`](/deploy-manage/tools/snapshot-and-restore/shared-file-system-repository.md) | -### Security certificates and keys [security_certificates_and_keys] +### Security certificates and keys [stack-security-certificates] :::{include} _snippets/security-files.md ::: diff --git a/deploy-manage/deploy/self-managed/install-elasticsearch-with-debian-package.md b/deploy-manage/deploy/self-managed/install-elasticsearch-with-debian-package.md index 21437a4013..cc141d1359 100644 --- a/deploy-manage/deploy/self-managed/install-elasticsearch-with-debian-package.md +++ b/deploy-manage/deploy/self-managed/install-elasticsearch-with-debian-package.md @@ -183,7 +183,7 @@ The Debian package places config files, logs, and the data directory in the appr | plugins | Plugin files location. Each plugin will be contained in a subdirectory. | `/usr/share/elasticsearch/plugins` | | | repo | Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here. | Not configured | [`path.repo`](/deploy-manage/tools/snapshot-and-restore/shared-file-system-repository.md) | -### Security certificates and keys [_security_certificates_and_keys] +### Security certificates and keys [stack-security-certificates] :::{include} _snippets/security-files.md ::: diff --git a/deploy-manage/deploy/self-managed/install-elasticsearch-with-rpm.md b/deploy-manage/deploy/self-managed/install-elasticsearch-with-rpm.md index 8c906e46d2..4c530cb5da 100644 --- a/deploy-manage/deploy/self-managed/install-elasticsearch-with-rpm.md +++ b/deploy-manage/deploy/self-managed/install-elasticsearch-with-rpm.md @@ -174,7 +174,7 @@ The RPM places config files, logs, and the data directory in the appropriate loc | plugins | Plugin files location. Each plugin will be contained in a subdirectory. | `/usr/share/elasticsearch/plugins` | | | repo | Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here. | Not configured | [`path.repo`](/deploy-manage/tools/snapshot-and-restore/shared-file-system-repository.md) | -### Security certificates and keys [_security_certificates_and_keys] +### Security certificates and keys [stack-security-certificates] :::{include} _snippets/security-files.md ::: From ea7867b9c317bbbce6cd68bcb022b070748132d1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Mon, 31 Mar 2025 10:53:32 +0200 Subject: [PATCH 17/42] changes per review comments --- .../security/secure-cluster-communications.md | 14 +++++++++-- .../secure-your-cluster-deployment.md | 2 +- deploy-manage/security/self-auto-setup.md | 16 ++---------- deploy-manage/security/self-setup.md | 10 ++++---- deploy-manage/security/self-tls.md | 8 +++--- .../set-up-basic-security-plus-https.md | 5 ++-- .../security/set-up-basic-security.md | 25 +++++-------------- 7 files changed, 33 insertions(+), 47 deletions(-) diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index da7c3c3d40..4be46b7f2a 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -41,7 +41,7 @@ To ensure secure operation, it’s important to understand the communication cha ### Transport layer security [encrypt-internode-communication] -Securing {{es}} transport layer, also known as transport protocol, prevents unauthorized nodes from joining your cluster and protects internode traffic. +The transport layer relies on mutual TLS for both encryption and authentication of nodes. Correctly applying TLS ensures that a malicious node cannot join the cluster and exchange data with other nodes. While implementing username and password authentication at the HTTP layer is useful for securing external access, the security of communication between nodes requires TLS. The way that transport layer security is managed depends on your deployment type: @@ -65,11 +65,21 @@ The way that transport layer security is managed depends on your deployment type :::{tab-item} Self-managed :sync: self -{{es}} transport security can be [automatically configured](self-auto-setup.md), or manually set up by following the steps in [Set up basic security](set-up-basic-security.md). +{{es}} transport security can be [automatically configured](self-auto-setup.md), or manually set up by following the steps in [](set-up-basic-security.md). ::: :::: +::::{admonition} Understanding transport contexts +Transport Layer Security (TLS) is the name of an industry standard protocol for applying security controls (such as encryption) to network communications. TLS is the modern name for what used to be called Secure Sockets Layer (SSL). The {{es}} documentation uses the terms TLS and SSL interchangeably. + +Transport Protocol is the name of the protocol that {{es}} nodes use to communicate with one another. This name is specific to {{es}} and distinguishes the transport port (default `9300`) from the HTTP port (default `9200`). Nodes communicate with one another using the transport port, and REST clients communicate with {{es}} using the HTTP port. + +Although the word *transport* appears in both contexts, they mean different things. It’s possible to apply TLS to both the {{es}} transport port and the HTTP port. We know that these overlapping terms can be confusing, so to clarify, in this scenario we’re applying TLS to the {{es}} transport port. In [](./set-up-basic-security-plus-https.md), we’ll apply TLS to the {{es}} HTTP port. +:::: + + + ### HTTP layer security [encrypt-http-communication] The HTTP layer includes the service endpoints exposed by both {{es}} and {{kib}}, supporting communications such as REST API requests, browser access to {{kib}}, and {{kib}}’s own traffic to {{es}}. Securing these endpoints helps prevent unauthorized access and protects sensitive data in transit. diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index c999bc308f..f723448113 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -11,7 +11,7 @@ mapped_pages: # Secure your cluster or deployment -It's important to protect your {{es}} cluster and the data it contains. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. +It's important to protect your {{es}} cluster and the data it contains. Implementing an in-depth defense strategy provides multiple layers of security to help safeguard your system. :::{include} /deploy-manage/security/_snippets/complete-security.md ::: diff --git a/deploy-manage/security/self-auto-setup.md b/deploy-manage/security/self-auto-setup.md index 31d4d60058..d2128c2696 100644 --- a/deploy-manage/security/self-auto-setup.md +++ b/deploy-manage/security/self-auto-setup.md @@ -10,20 +10,8 @@ mapped_pages: % Original title: Start the Elastic Stack with security enabled automatically # Automatic security setup [configuring-stack-security] -When you start {{es}} for the first time, the following security configuration occurs automatically: - -* [Certificates and keys](../deploy/self-managed/installing-elasticsearch.md#stack-security-certificates) for TLS are generated for the transport and HTTP layers. -* The TLS configuration settings are written to `elasticsearch.yml`. -* A password is generated for the `elastic` user. -* An enrollment token is generated for {{kib}}. - -You can then start {{kib}} and enter the enrollment token, which is valid for 30 minutes. This token automatically applies the security settings from your {{es}} cluster, authenticates to {{es}} with the built-in `kibana` service account, and writes the security configuration to `kibana.yml`. - -::::{note} -There are [some cases](/deploy-manage/security/self-auto-setup.md#stack-skip-auto-configuration) where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled. -:::: - - +:::{include} /deploy-manage/deploy/self-managed/_snippets/auto-security-config.md +::: ## Prerequisites [_prerequisites_12] diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index 2c2b8f11a3..8b52d32d37 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -17,8 +17,8 @@ Since version 8.0, {{es}} automatically enables security features on first start The automatic configuration:: -* Generates TLS certificates for the transport and HTTP layers -* Applies security settings to `elasticsearch.yml` +* Generates TLS certificates for the [transport and HTTP layers](./secure-cluster-communications.md#communication-channels) +* Applies TLS configuration settings to `elasticsearch.yml` * Sets a password for the `elastic` superuser * Creates an enrollment token to securely connect {{kib}} to {{es}} @@ -34,11 +34,11 @@ Refer to [Automatic security setup](./self-auto-setup.md) for the complete proce If you’re securing an existing unsecured cluster, or prefer to use your own TLS certificates, follow the manual approach. It involves enabling different layers of protection in sequence, depending on your cluster architecture and security requirements. -* **Start with [minimal security](set-up-minimal-security.md)**: Enables password-based authentication for built-in users and configures {{kib}} to connect using credentials. Suitable for single-node clusters, but not sufficient for production or multi-node clusters. +1. **Start with [minimal security](set-up-minimal-security.md)**: Enables password-based authentication for built-in users and configures {{kib}} to connect using credentials. Suitable for single-node clusters, but not sufficient for production or multi-node clusters. -* **Then [configure transport TLS](./set-up-basic-security.md)**: Required for multi-node clusters running in [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode). Secures communication between nodes and prevents unauthorized nodes from joining the cluster. +2. **Then [configure transport TLS](./set-up-basic-security.md)**: Required for multi-node clusters running in [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode). Secures communication between nodes and prevents unauthorized nodes from joining the cluster. -* **Finally, [configure HTTP TLS](set-up-basic-security-plus-https.md)**: Secures all client communications over HTTPS, including traffic between {{kib}} and {{es}}, and between browsers and {{kib}}. Recommended for all clusters, even single-node setups. +3. **Finally, [configure HTTP TLS](set-up-basic-security-plus-https.md)**: Secures all client communications over HTTPS, including traffic between {{kib}} and {{es}}, and between browsers and {{kib}}. Recommended for all clusters, even single-node setups. Each step builds on the previous one. For production environments, it’s strongly recommended to complete all three. diff --git a/deploy-manage/security/self-tls.md b/deploy-manage/security/self-tls.md index 8e69f4e001..9af6f83c15 100644 --- a/deploy-manage/security/self-tls.md +++ b/deploy-manage/security/self-tls.md @@ -9,9 +9,11 @@ mapped_pages: # Manage TLS certificates in self-managed deployments -This section provides guides for manually configuring and maintaining the TLS certificates in self-managed deployments. For an overview of the endpoints that need securing in {{es}} and {{kib}}, refer to [Communication channels](./secure-cluster-communications.md#communication-channels). +This section provides guides for configuring TLS encryption in self-managed deployments. It covers how to create and manage TLS certificates, configure {{es}} and {{kib}} service endpoints to use them, and apply related security settings such as supported TLS versions and cipher suites. -Use the following guides to manage TLS certificates: +All procedures in this section focus on manual configuration. If you prefer an automated approach, consider using the [automatic security configuration](./self-auto-setup.md) feature, which sets up TLS certificates for {{es}} HTTP and transport endpoints during initial startup. + +For an overview of the endpoints that need securing in {{es}} and {{kib}}, refer to [Communication channels](./secure-cluster-communications.md#communication-channels). * [](./set-up-basic-security.md) (**required for multi-node clusters**): Create and configure a Certificate Authority (CA) and certificates to encrypt inter-node traffic. * [](./set-up-basic-security-plus-https.md) (**optional but recommended**): Create and configure certificates to encrypt traffic on {{es}} and {{kib}} HTTP endpoints. @@ -20,8 +22,6 @@ Use the following guides to manage TLS certificates: * [](./supported-ssltls-versions-by-jdk-version.md): Customize the list of supported SSL/TLS versions in your cluster. * [](./enabling-cipher-suites-for-stronger-encryption.md): Enable the use of additional cipher suites, so you can use different cipher suites for your TLS communications or communications with authentication providers. -As an alternative to the manual configuration, consider the [automatic security configuration](./self-auto-setup.md) procedure, which includes automatic generation of TLS certificates for {{es}} HTTP and transport endpoints. - ## Certificates lifecycle In self-managed deployments, you are responsible for certificate lifecycle management, including monitoring expiration dates, renewing certificates, and redeploying them as needed. If you used Elastic tools to generate your certificates, refer to [Update TLS certificates](./updating-certificates.md) for guidance on rotating or replacing them. diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 757996bb46..fd7e24c1eb 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -7,14 +7,15 @@ mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup-https.html --- - % Scope: HTTP certificates setup / manual configuration / multi or single node cluster % original title: Set up basic security for the Elastic Stack plus secured HTTPS traffic # Set up HTTP TLS [security-basic-setup-https] Enabling TLS on the HTTP layer ensures that all client communications with your cluster are encrypted, adding a critical layer of security. -This document provides guidance on how to: +This document focuses on the **manual configuration** of HTTPS for {{es}}. Use this approach if you want to provide your own TLS certificates, generate them with Elastic’s tools, or have full control over the configuration. Alternatively, {{es}} can [automatically generate and configure HTTPS certificates](./self-auto-setup.md). + +In this guide, you will learn how to: * [Generate and configure TLS certificates for the HTTP endpoints of your {{es}} nodes](#encrypt-http-communication). * [Configure {{kib}} to securely connect to {{es}} over HTTPS](#encrypt-kibana-elasticsearch) by trusting the Certificate Authority (CA) used by {{es}}. diff --git a/deploy-manage/security/set-up-basic-security.md b/deploy-manage/security/set-up-basic-security.md index 88e7c194c8..955e463f95 100644 --- a/deploy-manage/security/set-up-basic-security.md +++ b/deploy-manage/security/set-up-basic-security.md @@ -11,30 +11,18 @@ mapped_pages: % original title: Set up basic security for the Elastic Stack # Set up transport TLS [security-basic-setup] -If your cluster has multiple nodes, then you must configure TLS between {{es}} nodes. [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. This document focuses on the manual generation and configuration of the TLS certificates for the transport protocol in multi-node self-managed clusters. +Configuring TLS between nodes is the basic security setup to prevent unauthorized nodes from accessing to your {{es}} cluster, and it's required by multi-node clusters. [Production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. + +This document focuses on the **manual configuration** of TLS for [{{es}} transport protocol](./secure-cluster-communications.md#encrypt-internode-communication) in self-managed environments. Use this approach if you want to provide your own TLS certificates, generate them with Elastic’s tools, or have full control over the configuration. Alternatively, {{es}} can [automatically generate and configure HTTPS certificates](./self-auto-setup.md) for you. ::::{note} For other deployment types, such as {{ech}}, {{ece}}, or {{eck}}, refer to [](./secure-cluster-communications.md). :::: -When you start {{es}} for the first time, passwords are generated for the `elastic` user and TLS is [automatically configured](./self-auto-setup.md) for you. If you configure security [manually](./self-setup.md#manual-configuration) before starting your {{es}} nodes, the auto-configuration process will respect your security configuration. You can adjust your TLS configuration at any time, such as [updating node certificates](updating-certificates.md). - -## Transport protocol overview - -The {{es}} transport protocol, which listens in port `9300` by default, handles all inter-node communication within the cluster. - -It relies on mutual TLS for both encryption and authentication of nodes. Correctly applying TLS ensures that a malicious node cannot join the cluster and exchange data with other nodes. While implementing username and password authentication at the HTTP layer is useful for securing external access, the security of communication between nodes requires TLS. - -Configuring TLS between nodes is the basic security setup to prevent unauthorized nodes from accessing to your cluster. +In this guide, you will learn how to: -::::{admonition} Understanding transport contexts -Transport Layer Security (TLS) is the name of an industry standard protocol for applying security controls (such as encryption) to network communications. TLS is the modern name for what used to be called Secure Sockets Layer (SSL). The {{es}} documentation uses the terms TLS and SSL interchangeably. - -Transport Protocol is the name of the protocol that {{es}} nodes use to communicate with one another. This name is specific to {{es}} and distinguishes the transport port (default `9300`) from the HTTP port (default `9200`). Nodes communicate with one another using the transport port, and REST clients communicate with {{es}} using the HTTP port. - -Although the word *transport* appears in both contexts, they mean different things. It’s possible to apply TLS to both the {{es}} transport port and the HTTP port. We know that these overlapping terms can be confusing, so to clarify, in this scenario we’re applying TLS to the {{es}} transport port. In [](./set-up-basic-security-plus-https.md), we’ll apply TLS to the {{es}} HTTP port. - -:::: +* [Generate a Certificate Authority (CA) and a server certificate using the `elasticsearch-certutil` tool](#generate-certificates). +* [Configure your {{es}} nodes to use the generated certificate for the transport layer](#encrypt-internode-communication). ## Generate the certificate authority [generate-certificates] @@ -134,7 +122,6 @@ Complete the following steps **for each node in your cluster**. To join the same :::: - ## What’s next? [encrypting-internode-whatsnext] Congratulations! You’ve encrypted communications between the nodes in your cluster and can pass the [TLS bootstrap check](../deploy/self-managed/bootstrap-checks.md#bootstrap-checks-tls). From 7a7241d228576b3d0fadcb7480a7d24646398325 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Mon, 31 Mar 2025 11:05:39 +0200 Subject: [PATCH 18/42] removing badge in section --- deploy-manage/security/secure-your-cluster-deployment.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index f723448113..6f4ad3100e 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -28,10 +28,6 @@ You must secure [other {{stack}} components](/deploy-manage/security/secure-clie You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: ## Enable and set up security [manually-configure-security] -```{applies_to} -deployment: - self: all -``` :::{include} /deploy-manage/security/_snippets/enable-security.md ::: From c4fa41312b3ad18d3fbef076c6e3e2784690b9da Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Mon, 31 Mar 2025 11:18:17 +0200 Subject: [PATCH 19/42] fixing various links --- .../cloud-on-k8s/elasticsearch-deployment-quickstart.md | 2 +- deploy-manage/deploy/cloud-on-k8s/http-configuration.md | 8 ++++---- .../cloud-on-k8s/k8s-kibana-advanced-configuration.md | 2 +- deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md | 8 ++++---- .../deploy/cloud-on-k8s/kibana-instance-quickstart.md | 2 +- deploy-manage/deploy/self-managed/access-kibana.md | 2 +- 6 files changed, 12 insertions(+), 12 deletions(-) diff --git a/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md b/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md index e564a2cddc..860a645222 100644 --- a/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md +++ b/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md @@ -118,7 +118,7 @@ In order to make requests to the [{{es}} API](elasticsearch://reference/elastics PASSWORD=$(kubectl get secret quickstart-es-elastic-user -o go-template='{{.data.elastic | base64decode}}') ``` -2. Request the [{{es}} root API](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-info). You can do so from inside the Kubernetes cluster or from your local workstation. For demonstration purposes, certificate verification is disabled using the `-k` curl flag; however, this is not recommended outside of testing purposes. Refer to [Setup your own certificate](/deploy-manage/security/secure-cluster-communications.md#k8s-setting-up-your-own-certificate) for more information. +2. Request the [{{es}} root API](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-info). You can do so from inside the Kubernetes cluster or from your local workstation. For demonstration purposes, certificate verification is disabled using the `-k` curl flag; however, this is not recommended outside of testing purposes. Refer to [Setup your own certificate](/deploy-manage/security/k8s-https-settings.md#k8s-setting-up-your-own-certificate) for more information. * From inside the Kubernetes cluster: diff --git a/deploy-manage/deploy/cloud-on-k8s/http-configuration.md b/deploy-manage/deploy/cloud-on-k8s/http-configuration.md index 6c0aac6fc8..7eb60a8c6d 100644 --- a/deploy-manage/deploy/cloud-on-k8s/http-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/http-configuration.md @@ -6,7 +6,7 @@ mapped_pages: - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-maps-http-configuration.html --- -# HTTP configuration [k8s-maps-http-configuration] +# Elastic Maps HTTP configuration [k8s-maps-http-configuration] ::::{warning} This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. @@ -17,17 +17,17 @@ This functionality is in technical preview and may be changed or removed in a fu By default a `ClusterIP` [service](https://kubernetes.io/docs/concepts/services-networking/service/) is created and associated with the Elastic Maps Server deployment. If you want to expose maps externally with a [load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer), it is recommended to include a custom DNS name or IP in the self-generated certificate. -Refer to [Reserve static IP and custom domain](/deploy-manage/security/secure-cluster-communications.md#k8s-static-ip-custom-domain) for more details. +Refer to [Reserve static IP and custom domain](/deploy-manage/security/k8s-https-settings.md#k8s-static-ip-custom-domain) for more details. ## Provide your own certificate [k8s-maps-http-custom-tls] -If you want to use your own certificate, the required configuration is identical to Elasticsearch. Check [Custom HTTP certificate](../../security/secure-cluster-communications.md). +If you want to use your own certificate, the required configuration is identical to Elasticsearch. Check [Custom HTTP certificate](/deploy-manage/security/k8s-https-settings.md#k8s-setting-up-your-own-certificate). ## Disable TLS [k8s-maps-http-disable-tls] -You can disable the generation of the self-signed certificate and hence disable TLS. Check [Disable TLS](/deploy-manage/security/secure-cluster-communications.md#k8s-disable-tls). +You can disable the generation of the self-signed certificate and hence disable TLS. Check [Disable TLS](/deploy-manage/security/k8s-https-settings.md#k8s-disable-tls). ### Ingress and Kibana configuration [k8s-maps-ingress] diff --git a/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md b/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md index c3871c9d1b..969ff439a0 100644 --- a/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md @@ -12,7 +12,7 @@ If you already looked at the [Elasticsearch on ECK](elasticsearch-configuration. * [Customize the Pod configuration](#k8s-kibana-pod-configuration) * [Customize the product configuration](#k8s-kibana-configuration) -* [Manage HTTP settings](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-configuration) +* [Manage HTTP settings](/deploy-manage/security/k8s-https-settings.md#k8s-kibana-http-configuration) * [Use secure settings](../../security/k8s-secure-settings.md) * [Install {{kib}} plugins](k8s-kibana-plugins.md) diff --git a/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md b/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md index a40537d6bb..95ba94665d 100644 --- a/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md @@ -22,11 +22,11 @@ The following sections describe how to customize a {{kib}} deployment to suit yo * [Scaling out a {{kib}} deployment](k8s-kibana-advanced-configuration.md#k8s-kibana-scaling) * [Secure settings](../../security/k8s-secure-settings.md#k8s-kibana-secure-settings) -* [HTTP Configuration](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-configuration) +* [HTTP Configuration](/deploy-manage/security/k8s-https-settings.md#k8s-kibana-http-configuration) - * [Load balancer settings and TLS SANs](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-publish) - * [Provide your own certificate](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-custom-tls) - * [Disable TLS](/deploy-manage/security/secure-cluster-communications.md#k8s-kibana-http-disable-tls) + * [Load balancer settings and TLS SANs](/deploy-manage/security/k8s-https-settings.md#k8s-kibana-http-publish) + * [Provide your own certificate](/deploy-manage/security/k8s-https-settings.md#k8s-kibana-http-custom-tls) + * [Disable TLS](/deploy-manage/security/k8s-https-settings.md#k8s-disable-tls) * [Install {{kib}} plugins](k8s-kibana-plugins.md) * [Autoscaling stateless applications](../../autoscaling/autoscaling-in-eck.md#k8s-stateless-autoscaling): Use [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) for {{kib}} or other stateless applications. diff --git a/deploy-manage/deploy/cloud-on-k8s/kibana-instance-quickstart.md b/deploy-manage/deploy/cloud-on-k8s/kibana-instance-quickstart.md index a44ac031a7..2ac067dd71 100644 --- a/deploy-manage/deploy/cloud-on-k8s/kibana-instance-quickstart.md +++ b/deploy-manage/deploy/cloud-on-k8s/kibana-instance-quickstart.md @@ -57,7 +57,7 @@ To deploy a simple [{{kib}}](/get-started/the-stack.md#stack-components-kibana) kubectl port-forward service/quickstart-kb-http 5601 ``` - Open `https://localhost:5601` in your browser. Your browser will show a warning because the self-signed certificate configured by default is not verified by a known certificate authority and not trusted by your browser. You can temporarily acknowledge the warning for the purposes of this quick start but it is highly recommended that you [configure valid certificates](/deploy-manage/security/secure-cluster-communications.md#k8s-setting-up-your-own-certificate) for any production deployments. + Open `https://localhost:5601` in your browser. Your browser will show a warning because the self-signed certificate configured by default is not verified by a known certificate authority and not trusted by your browser. You can temporarily acknowledge the warning for the purposes of this quick start but it is highly recommended that you [configure valid certificates](/deploy-manage/security/k8s-https-settings.md#k8s-setting-up-your-own-certificate) for any production deployments. Login as the `elastic` user. The password can be obtained with the following command: diff --git a/deploy-manage/deploy/self-managed/access-kibana.md b/deploy-manage/deploy/self-managed/access-kibana.md index 4cb278cbbc..b4584ddb0c 100644 --- a/deploy-manage/deploy/self-managed/access-kibana.md +++ b/deploy-manage/deploy/self-managed/access-kibana.md @@ -15,7 +15,7 @@ Access {{kib}} through the web application on port 5601. To remotely connect to {{kib}}, set [`server.host`](kibana://reference/configuration-reference/general-settings.md#server-host) to a non-loopback address. :::{note} - For production deployments, you should always [secure {{kib}} with a certificate](/deploy-manage/security/secure-cluster-communications.md#encrypt-kibana-http) and access it over HTTPS. + For production deployments, you should always [secure {{kib}} with a certificate](/deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-kibana-http) and access it over HTTPS. ::: 2. Log on to your account. From 44ed1bf90409b38bd4b85f55a1b54d694723ea28 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Mon, 31 Mar 2025 11:38:53 +0200 Subject: [PATCH 20/42] kibana security doc reduced. finding home --- .../security/using-kibana-with-security.md | 64 +------------------ 1 file changed, 2 insertions(+), 62 deletions(-) diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index c452adc8e1..78dcd222ef 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -10,22 +10,16 @@ mapped_urls: % Kibana security had 2 original docs: % https://www.elastic.co/guide/en/kibana/current/using-kibana-with-security.html % https://www.elastic.co/guide/en/kibana/current/Security-production-considerations.html -% Scope: TBD # Configure security in {{kib}} [using-kibana-with-security] -% check and move part of this if needed - -When you start {{es}} for the first time, {{stack-security-features}} are enabled on your cluster and TLS is configured automatically. The security configuration process generates a password for the `elastic` user and an enrollment token for {{kib}}. [Start the {{stack}} with security enabled](/deploy-manage/security/self-auto-setup.md) and then enroll {{kib}} as part of the configuration process. - -You can then log in to {{kib}} as the `elastic` user to create additional roles and users. +For more information on granting access to {{kib}}, see [](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md). ::::{note} When a user is not authorized to view data in an index (such as an {{es}} index), the entire index will be inaccessible and not display in {{kib}}. :::: - -## Configure security settings [security-configure-settings] +## Configure encryption keys [security-configure-settings] Set an encryption key so that sessions are not invalidated. You can optionally configure additional security settings and authentication. @@ -41,61 +35,7 @@ Set an encryption key so that sessions are not invalidated. You can optionally c 3. Optional: [Configure {{kib}} to authenticate to {{es}} with a client certificate (mutual authentication)](/deploy-manage/security/kibana-es-mutual-tls.md). 4. Restart {{kib}}. - -## Create roles and users [security-create-roles] - -% ensure we have references to users and roles - -% check if part of this process should be merged with the other guides - -Configure roles for your {{kib}} users to control what data those users can access. - -1. Temporarily log in to {{kib}} using the built-in `elastic` superuser so you can create new users and assign roles. If you are running {{kib}} locally, go to `https://localhost:5601` to view the login page. - - ::::{note} - The password for the built-in `elastic` user is generated as part of the security configuration process on {{es}}. If you need to reset the password for the `elastic` user or other built-in users, run the [`elasticsearch-reset-password`](elasticsearch://reference/elasticsearch/command-line-tools/reset-password.md) tool. - :::: - -2. $$$kibana-roles$$$Create roles and users to grant access to {{kib}}. - - To manage privileges in {{kib}}, go to the **Roles** management page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). The built-in `kibana_admin` role will grant access to {{kib}} with administrator privileges. Alternatively, you can create additional roles that grant limited access to {{kib}}. - - If you’re using the default native realm with Basic Authentication, go to the **Users** management page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md) to create users and assign roles, or use the {{es}} [user management APIs](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-security). For example, the following creates a user named `jacknich` and assigns it the `kibana_admin` role: - - ```console - POST /_security/user/jacknich - { - "password" : "t0pS3cr3t", - "roles" : [ "kibana_admin" ] - } - ``` - - ::::{tip} - For more information on Basic Authentication and additional methods of authenticating {{kib}} users, see [Authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md). - :::: - -3. Grant users access to the indices that they will be working with in {{kib}}. - - ::::{tip} - You can define as many different roles for your {{kib}} users as you need. - :::: - - - For example, create roles that have `read` and `view_index_metadata` privileges on specific data views. For more information, see [User authorization](/deploy-manage/users-roles/cluster-or-deployment-auth/user-roles.md). - -4. Log out of {{kib}} and verify that you can log in as a normal user. If you are running {{kib}} locally, go to `https://localhost:5601` and enter the credentials for a user you’ve assigned a {{kib}} user role. For example, you could log in as the user `jacknich`. - - ::::{note} - This must be a user who has been assigned [Kibana privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md). {{kib}} server credentials (the built-in `kibana_system` user) should only be used internally by the {{kib}} server. - :::: - ## Additional Kibana security configurations [Security-production-considerations] -% deleting a lot here... - -% Important sentence to include!!! - -For more information on granting access to {{kib}}, see [](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md). - ### Use secure HTTP headers [configuring-security-headers] From 81833454f8b7c0cfc736306bfe43196b077b4dee Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Mon, 31 Mar 2025 16:41:34 +0200 Subject: [PATCH 21/42] comparison table updated --- .../security/_snippets/cluster-comparison.md | 87 +++++++++++-------- 1 file changed, 51 insertions(+), 36 deletions(-) diff --git a/deploy-manage/security/_snippets/cluster-comparison.md b/deploy-manage/security/_snippets/cluster-comparison.md index 1593c14cab..88201a47f3 100644 --- a/deploy-manage/security/_snippets/cluster-comparison.md +++ b/deploy-manage/security/_snippets/cluster-comparison.md @@ -2,7 +2,8 @@ Security feature availability varies by deployment type, with each feature havin | Status | Description | |--------|-------------| -| **Managed** | Handled automatically by Elastic with no user configuration needed | +| **Fully managed** | Handled automatically by Elastic with no user configuration needed | +| **Managed** | Handled automatically by Elastic, but certain configuration allowed | | **Configurable** | Built-in feature that needs your configuration (like IP filters or passwords) | | **Self-managed** | Infrastructure-level security you implement and maintain | | **N/A** | Not available for this deployment type | @@ -17,55 +18,70 @@ Select your deployment type below to see what's available and how implementation | Category | Security feature | Status | Description | |------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Managed | Automatically configured by Elastic | -| | TLS (Transport Layer) | Managed | Automatically configured by Elastic | -| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | -| | Private link | Configurable | Establish secure VPC connection | -| | Static IPs | Configurable | Enable fixed IP addresses | -| **Data** | Encryption at rest | Managed | Automatically encrypted by Elastic | -| | Bring your own encryption key | Configurable | Implement customer-provided keys | -| | Keystore security | Managed | Automatically protected by Elastic | -| | Saved object encryption | Managed | Automatically encrypted by Elastic | -| **User Session** | Kibana Sessions | Configurable | Customize session parameters | +| **Communication** | TLS (HTTP Layer) | Fully managed | Automatically configured by Elastic | +| | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | +| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | +| | Private link | Configurable | [Establish secure VPC connection](/deploy-manage/security/private-link-traffic-filters.md) | +| | Kubernetes Network Policies | N/A | | +| **Data** | Encryption at rest | Managed | You can [bring your own encryption key](/deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md) | +| | Secure settings | Configurable | Automatically protected by Elastic | +| | Saved object encryption | Fully managed | Automatically encrypted by Elastic | +| **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | ::: -:::{tab-item} {{serverless-full}} +:::{tab-item} Serverless :sync: serverless | Category| Security feature | Status | Description | |------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Managed | Automatically configured by Elastic | -| | TLS (Transport Layer) | Managed | Automatically configured by Elastic | -| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | +| **Communication** | TLS (HTTP Layer) | Fully managed | Automatically configured by Elastic | +| | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | +| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | | | Private link | N/A | X | -| | Static IPs | Configurable | Enable fixed IP addresses | -| **Data** | Encryption at rest | Managed | Automatically encrypted by Elastic | -| | Bring your own encryption key | N/A | X | -| | Keystore security | Managed | Automatically protected by Elastic | -| | Saved object encryption | Managed | Automatically encrypted by Elastic | +| | Kubernetes Network Policies | N/A | | +| **Data** | Encryption at rest | Fully managed | Automatically encrypted by Elastic | +| | Secure settings | Configurable | Automatically protected by Elastic | +| | Saved object encryption | Fully managed | Automatically encrypted by Elastic | | **User Session** | Kibana Sessions | Managed | Automatically configured by Elastic | ::: -:::{tab-item} ECE/ECK -:sync: ece-eck +:::{tab-item} ECE +:sync: ece | Category| Security feature | Status | Description | |------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Configurable | Configure custom certificates | -| | TLS (Transport Layer) | Managed | Automatically configured by Elastic | -| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | +| **Communication** | TLS (HTTP Layer) | Managed | You can [configure custom certificates](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) | +| | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | +| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | | | Private link | N/A | X | -| | Static IPs | N/A | X | +| | Kubernetes Network Policies | N/A | | | **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | -| | Bring your own encryption key | N/A | X | -| | Keystore security | Configurable | Configure secure settings storage | -| | Saved object encryption | Configurable | Enable encryption for saved objects | -| **User Session** | Kibana Sessions | Configurable | Customize session parameters | +| | Secure settings | Configurable | [Configure secure settings](/deploy-manage/security/secure-settings.md) | +| | Saved object encryption | Configurable | [Enable encryption for saved objects](/deploy-manage/security/secure-saved-objects.md) | +| **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | ::: +:::{tab-item} ECK +:sync: eck + +| Category| Security feature | Status | Description | +|------------------|------------|--------------|-------------| +| **Communication** | TLS (HTTP Layer) | Managed | [Multiple options](/deploy-manage/security/k8s-https-settings.md) | +| | TLS (Transport Layer) | Managed | [Multiple options](/deploy-manage/security/k8s-transport-settings.md) | +| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | +| | Private link | N/A | | +| | Kubernetes Network Policies | Configurable | [Apply network policies to your Pods](/deploy-manage/security/k8s-network-policies.md) | +| **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | +| | Secure settings | Configurable | [Configure secure settings](/deploy-manage/security/k8s-secure-settings.md) | +| | Saved object encryption | Configurable | [Enable encryption for saved objects](/deploy-manage/security/secure-saved-objects.md) | +| **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | + +::: + + :::{tab-item} Self-managed :sync: self-managed @@ -73,14 +89,13 @@ Select your deployment type below to see what's available and how implementation |------------------|------------|--------------|-------------| | **Communication** | TLS (HTTP Layer) | Self-managed | Implement and maintain certificates | | | TLS (Transport Layer) | Self-managed | Implement and maintain certificates | -| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | +| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | | | Private link | N/A | X | -| | Static IPs | N/A | X | +| | Kubernetes Network Policies | N/A | | | **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | -| | Bring your own encryption key | N/A | X | -| | Keystore security | Configurable | Configure secure settings storage | -| | Saved object encryption | Configurable | Enable encryption for saved objects | -| **User Session** | Kibana Sessions | Configurable | Customize session parameters | +| | Keystore security | Configurable | [Configure secure settings](/deploy-manage/security/secure-settings.md) storage | +| | Saved object encryption | Configurable | [Enable encryption for saved objects](/deploy-manage/security/secure-saved-objects.md) | +| **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | ::: :::: \ No newline at end of file From bd3cb740e92622fb326765f80734777586d99acc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Mon, 31 Mar 2025 22:11:18 +0200 Subject: [PATCH 22/42] getting closer --- deploy-manage/security.md | 2 +- .../security/secure-cluster-communications.md | 4 +++- .../security/secure-your-cluster-deployment.md | 2 +- deploy-manage/security/self-setup.md | 16 ++++++++++++++-- .../security/set-up-basic-security-plus-https.md | 12 ++++++------ deploy-manage/toc.yml | 6 +++--- 6 files changed, 28 insertions(+), 14 deletions(-) diff --git a/deploy-manage/security.md b/deploy-manage/security.md index ddd4869949..945596209b 100644 --- a/deploy-manage/security.md +++ b/deploy-manage/security.md @@ -77,7 +77,7 @@ deployment: You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: -### Enable and set up security +### Initial security setup :::{include} /deploy-manage/security/_snippets/enable-security.md ::: diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 4be46b7f2a..890e919323 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -41,7 +41,9 @@ To ensure secure operation, it’s important to understand the communication cha ### Transport layer security [encrypt-internode-communication] -The transport layer relies on mutual TLS for both encryption and authentication of nodes. Correctly applying TLS ensures that a malicious node cannot join the cluster and exchange data with other nodes. While implementing username and password authentication at the HTTP layer is useful for securing external access, the security of communication between nodes requires TLS. +The transport layer is used for communication between {{es}} nodes in a cluster. It relies on mutual TLS for both encryption and authentication of nodes. + +Securing this layer prevents unauthorized nodes from joining your cluster and protects internode data. While implementing username and password authentication at the HTTP layer is useful for securing external access, the security of communication between nodes requires TLS. The way that transport layer security is managed depends on your deployment type: diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index 6f4ad3100e..26b8633867 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -27,7 +27,7 @@ You must secure [other {{stack}} components](/deploy-manage/security/secure-clie You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: -## Enable and set up security [manually-configure-security] +## Initial security setup [manually-configure-security] :::{include} /deploy-manage/security/_snippets/enable-security.md ::: diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index 8b52d32d37..56e68fd870 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -9,7 +9,11 @@ mapped_pages: # Set up security in self-managed deployments -There are two approaches to configuring security in self-managed deployments of the {{stack}}: +This section explains how to perform the initial security setup for self-managed deployments, including configuring TLS certificates to secure {{es}} and {{kib}} endpoints, setting passwords for built-in users, and generating enrollment tokens to connect {{kib}} or additional {{es}} nodes to the cluster. + +Self-managed deployments support two approaches for the initial setup: automatic and manual. Note that securing {{kib}} always requires some manual configuration. + +For guidance on configuring additional security features, refer to [](./secure-your-cluster-deployment.md). ## Automatic configuration [automatic-configuration] @@ -28,7 +32,7 @@ This automatic setup is the quickest way to get started and ensures your cluster The automatic configuration does not enable TLS on the {{kib}} HTTP endpoint. To encrypt browser traffic to {{kib}}, follow the steps in [](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). :::: -Refer to [Automatic security setup](./self-auto-setup.md) for the complete procedure, including [cases where it may be skipped](./self-auto-setup.md#stack-skip-auto-configuration). +Refer to [Automatic security setup](./self-auto-setup.md) for details about the full procedure, including [cases where it may be skipped](./self-auto-setup.md#stack-skip-auto-configuration). ## Manual configuration [manual-configuration] @@ -42,4 +46,12 @@ If you’re securing an existing unsecured cluster, or prefer to use your own TL Each step builds on the previous one. For production environments, it’s strongly recommended to complete all three. +## Kibana security configuration + +Refer to [](./using-kibana-with-security.md) for detailed guidance on the following security topics: +* Set an encryption key for clients sessions +* Enable TLS on the HTTP service endpoint +* Enable mutual authentication between {{kib}} and {{es}} +* Use secure HTTP headers +* Require a Content Security Policy \ No newline at end of file diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index fd7e24c1eb..2cc2cedd9f 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -1,5 +1,5 @@ --- -navigation_title: "Set up HTTP TLS" +navigation_title: "Set up HTTPS" applies_to: deployment: self: ga @@ -9,11 +9,11 @@ mapped_pages: % Scope: HTTP certificates setup / manual configuration / multi or single node cluster % original title: Set up basic security for the Elastic Stack plus secured HTTPS traffic -# Set up HTTP TLS [security-basic-setup-https] +# Set up HTTPS [security-basic-setup-https] -Enabling TLS on the HTTP layer ensures that all client communications with your cluster are encrypted, adding a critical layer of security. +Enabling TLS on the HTTP layer, widely known as HTTPS, ensures that all client communications with your cluster are encrypted, adding a critical layer of security. -This document focuses on the **manual configuration** of HTTPS for {{es}}. Use this approach if you want to provide your own TLS certificates, generate them with Elastic’s tools, or have full control over the configuration. Alternatively, {{es}} can [automatically generate and configure HTTPS certificates](./self-auto-setup.md). +This document focuses on the **manual configuration** of HTTPS for {{es}} and {{kib}}. Use this approach if you want to provide your own TLS certificates, generate them with Elastic’s tools, or have full control over the configuration. Alternatively, {{es}} can [automatically generate and configure HTTPS certificates](./self-auto-setup.md). In this guide, you will learn how to: @@ -39,7 +39,7 @@ Both workflows are supported. Choose the one that best fits your infrastructure ## Prerequisites [basic-setup-https-prerequisites] -If security feature wasn't already enabled in your cluster, complete all steps in [Manual security setup](./set-up-minimal-security.md). +If security feature wasn't already enabled in your cluster, complete all steps in [](./set-up-minimal-security.md). For multi-node clusters, ensure you have completed the [transport TLS setup](./set-up-basic-security.md). As part of that process, you will have created a Certificate Authority (CA) that this guide reuses to issue HTTP certificates. @@ -120,7 +120,7 @@ Once TLS is enabled, all client communications with the cluster will be encrypte **Next**: [Encrypt HTTP client communications for {{kib}}](#encrypt-kibana-http) -## Encrypt HTTP client communications for {{kib}} [encrypt-kibana-http] +## Encrypt HTTP communications for {{kib}} [encrypt-kibana-http] {{kib}} handles two separate types of HTTP traffic that should be encrypted: * **Outgoing requests from {{kib}} to {{es}}**: {{kib}} acts as an HTTP client and must be configured to trust the TLS certificate used by {{es}}. diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 6dbc74c4ec..e9507fc261 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -460,13 +460,14 @@ toc: children: - file: security/self-auto-setup.md - file: security/set-up-minimal-security.md + - file: security/set-up-basic-security.md + - file: security/set-up-basic-security-plus-https.md + - file: security/using-kibana-with-security.md - file: security/install-stack-demo-secure.md - file: security/secure-cluster-communications.md children: - file: security/self-tls.md children: - - file: security/set-up-basic-security.md - - file: security/set-up-basic-security-plus-https.md - file: security/updating-certificates.md children: - file: security/same-ca.md @@ -510,7 +511,6 @@ toc: - file: security/logging-configuration/auditing-search-queries.md - file: security/logging-configuration/correlating-kibana-elasticsearch-audit-logs.md - file: security/fips-140-2.md - - file: security/using-kibana-with-security.md - file: security/secure-clients-integrations.md - file: security/httprest-clients-security.md - file: security/limitations.md From 87f634beee8322e9bf05eb1e8fefa5e9b719e4d4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 08:57:56 +0200 Subject: [PATCH 23/42] Update deploy-manage/security/self-setup.md Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com> --- deploy-manage/security/self-setup.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index 56e68fd870..dcd60ac9cd 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -19,7 +19,7 @@ For guidance on configuring additional security features, refer to [](./secure-y Since version 8.0, {{es}} automatically enables security features on first startup when the node is not part of an existing cluster and none of the [incompatible settings](./self-auto-setup.md#stack-existing-settings-detected) have been explicitly configured. -The automatic configuration:: +The automatic configuration: * Generates TLS certificates for the [transport and HTTP layers](./secure-cluster-communications.md#communication-channels) * Applies TLS configuration settings to `elasticsearch.yml` From 6833ffc3fd613486a1490484821954244358c461 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 10:45:41 +0200 Subject: [PATCH 24/42] refinement completed --- deploy-manage/security/self-auto-setup.md | 104 ++---------------- deploy-manage/security/self-setup.md | 9 +- deploy-manage/security/self-tls.md | 27 +++-- .../set-up-basic-security-plus-https.md | 10 +- .../security/set-up-basic-security.md | 3 + .../security/using-kibana-with-security.md | 36 +++--- 6 files changed, 65 insertions(+), 124 deletions(-) diff --git a/deploy-manage/security/self-auto-setup.md b/deploy-manage/security/self-auto-setup.md index d2128c2696..bf79df8ae6 100644 --- a/deploy-manage/security/self-auto-setup.md +++ b/deploy-manage/security/self-auto-setup.md @@ -75,82 +75,25 @@ mapped_pages: bin/kibana-setup --enrollment-token ``` - - ## Enroll additional nodes in your cluster [stack-enroll-nodes] -When {{es}} starts for the first time, the security auto-configuration process binds the HTTP layer to `0.0.0.0`, but only binds the transport layer to localhost. This intended behavior ensures that you can start a single-node cluster with security enabled by default without any additional configuration. - -Before enrolling a new node, additional actions such as binding to an address other than `localhost` or satisfying bootstrap checks are typically necessary in production clusters. During that time, an auto-generated enrollment token could expire, which is why enrollment tokens aren’t generated automatically. - -Additionally, only nodes on the same host can join the cluster without additional configuration. If you want nodes from another host to join your cluster, you need to set `transport.host` to a [supported value](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#network-interface-values) (such as uncommenting the suggested value of `0.0.0.0`), or an IP address that’s bound to an interface where other hosts can reach it. Refer to [transport settings](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#transport-settings) for more information. - -To enroll new nodes in your cluster, create an enrollment token with the `elasticsearch-create-enrollment-token` tool on any existing node in your cluster. You can then start a new node with the `--enrollment-token` parameter so that it joins an existing cluster. - -1. In a separate terminal from where {{es}} is running, navigate to the directory where you installed {{es}} and run the [`elasticsearch-create-enrollment-token`](elasticsearch://reference/elasticsearch/command-line-tools/create-enrollment-token.md) tool to generate an enrollment token for your new nodes. - - ```sh - bin/elasticsearch-create-enrollment-token -s node - ``` - - Copy the enrollment token, which you’ll use to enroll new nodes with your {{es}} cluster. - -2. From the installation directory of your new node, start {{es}} and pass the enrollment token with the `--enrollment-token` parameter. - - ```sh - bin/elasticsearch --enrollment-token - ``` - - {{es}} automatically generates certificates and keys in the following directory: - - ```sh - config/certs - ``` - -3. Repeat the previous step for any new nodes that you want to enroll. - +:::{include} /deploy-manage/deploy/self-managed/_snippets/enroll-nodes.md +::: ## Connect clients to {{es}} [_connect_clients_to_es_5] -When you start {{es}} for the first time, TLS is configured automatically for the HTTP layer. A CA certificate is generated and stored on disk at: - -```sh -/etc/elasticsearch/certs/http_ca.crt -``` - -The hex-encoded SHA-256 fingerprint of this certificate is also output to the terminal. Any clients that connect to {{es}}, such as the [{{es}} Clients](https://www.elastic.co/guide/en/elasticsearch/client/index.html), {{beats}}, standalone {{agent}}s, and {{ls}} must validate that they trust the certificate that {{es}} uses for HTTPS. {{fleet-server}} and {{fleet}}-managed {{agent}}s are automatically configured to trust the CA certificate. Other clients can establish trust by using either the fingerprint of the CA certificate or the CA certificate itself. - -If the auto-configuration process already completed, you can still obtain the fingerprint of the security certificate. You can also copy the CA certificate to your machine and configure your client to use it. - +:::{include} /deploy-manage/deploy/self-managed/_snippets/connect-clients.md +::: ### Use the CA fingerprint [_use_the_ca_fingerprint_5] -Copy the fingerprint value that’s output to your terminal when {{es}} starts, and configure your client to use this fingerprint to establish trust when it connects to {{es}}. - -If the auto-configuration process already completed, you can still obtain the fingerprint of the security certificate by running the following command. The path is to the auto-generated CA certificate for the HTTP layer. - -```sh -openssl x509 -fingerprint -sha256 -in config/certs/http_ca.crt -``` - -The command returns the security certificate, including the fingerprint. The `issuer` should be `{{es}} security auto-configuration HTTP CA`. - -```sh -issuer= /CN={{es}} security auto-configuration HTTP CA -SHA256 Fingerprint= -``` - +:::{include} /deploy-manage/deploy/self-managed/_snippets/ca-fingerprint.md +::: ### Use the CA certificate [_use_the_ca_certificate_5] -If your library doesn’t support a method of validating the fingerprint, the auto-generated CA certificate is created in the following directory on each {{es}} node: - -```sh -/etc/elasticsearch/certs/http_ca.crt -``` - -Copy the `http_ca.crt` file to your machine and configure your client to use this certificate to establish trust when it connects to {{es}}. - +:::{include} /deploy-manage/deploy/self-managed/_snippets/ca-cert.md +::: ## What’s next? [_whats_next] @@ -159,33 +102,8 @@ Congratulations! You’ve successfully started the {{stack}} with security enabl ## Security certificates and keys [stack-security-certificates] -When you install {{es}}, the following certificates and keys are generated in the {{es}} configuration directory, which are used to connect a {{kib}} instance to your secured {{es}} cluster and to encrypt internode communication. The files are listed here for reference. - -`http_ca.crt` -: The CA certificate that is used to sign the certificates for the HTTP layer of this {{es}} cluster. - -`http.p12` -: Keystore that contains the key and certificate for the HTTP layer for this node. - -`transport.p12` -: Keystore that contains the key and certificate for the transport layer for all the nodes in your cluster. - -`http.p12` and `transport.p12` are password-protected PKCS#12 keystores. {{es}} stores the passwords for these keystores as [secure settings](secure-settings.md). To retrieve the passwords so that you can inspect or change the keystore contents, use the [`bin/elasticsearch-keystore`](elasticsearch://reference/elasticsearch/command-line-tools/elasticsearch-keystore.md) tool. - -Use the following command to retrieve the password for `http.p12`: - -```sh -bin/elasticsearch-keystore show xpack.security.http.ssl.keystore.secure_password -``` - -Use the following command to retrieve the password for `transport.p12`: - -```sh -bin/elasticsearch-keystore show xpack.security.transport.ssl.keystore.secure_password -``` - -Additionally, when you use the enrollment token to connect {{kib}} to a secured {{es}} cluster, the HTTP layer CA certificate is retrieved from {{es}} and stored in the {{kib}} `/data` directory. This file establishes trust between {{kib}} and the {{es}} Certificate Authority (CA) for the HTTP layer. - +:::{include} /deploy-manage/deploy/self-managed/_snippets/security-files.md +::: ## Cases when security auto configuration is skipped [stack-skip-auto-configuration] @@ -201,8 +119,6 @@ If any of those checks fail, there’s a good indication that you manually confi If you redirect {{es}} output to a file, security autoconfiguration is skipped. Autoconfigured credentials can only be viewed on the terminal the first time you start {{es}}. If you need to redirect output to a file, start {{es}} without redirection the first time and use redirection on all subsequent starts. :::: - - ### Existing environment detected [stack-existing-environment-detected] If certain directories already exist, there’s a strong indication that the node was started previously. Similarly, if certain files *don’t* exist, or we can’t read or write to specific files or directories, then we’re likely not running as the user who installed {{es}} or an administrator imposed restrictions. If any of the following environment checks are true, security isn’t configured automatically. diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index dcd60ac9cd..210299467f 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -3,10 +3,9 @@ navigation_title: "Self-managed security setup" applies_to: deployment: self: ga -mapped_pages: - - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup-https.html --- +% scope: initial security setup in self-managed deployments, following the automatic or manual (minimal, basic, https) procedures # Set up security in self-managed deployments This section explains how to perform the initial security setup for self-managed deployments, including configuring TLS certificates to secure {{es}} and {{kib}} endpoints, setting passwords for built-in users, and generating enrollment tokens to connect {{kib}} or additional {{es}} nodes to the cluster. @@ -38,11 +37,11 @@ Refer to [Automatic security setup](./self-auto-setup.md) for details about the If you’re securing an existing unsecured cluster, or prefer to use your own TLS certificates, follow the manual approach. It involves enabling different layers of protection in sequence, depending on your cluster architecture and security requirements. -1. **Start with [minimal security](set-up-minimal-security.md)**: Enables password-based authentication for built-in users and configures {{kib}} to connect using credentials. Suitable for single-node clusters, but not sufficient for production or multi-node clusters. +1. **[Set up minimal security](set-up-minimal-security.md)**: Enables password-based authentication for built-in users and configures {{kib}} to connect using credentials. Suitable for single-node clusters, but not sufficient for production or multi-node clusters. -2. **Then [configure transport TLS](./set-up-basic-security.md)**: Required for multi-node clusters running in [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode). Secures communication between nodes and prevents unauthorized nodes from joining the cluster. +2. **[Configure transport TLS](./set-up-basic-security.md)**: Required for multi-node clusters running in [production mode](../deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode). Secures communication between nodes and prevents unauthorized nodes from joining the cluster. -3. **Finally, [configure HTTP TLS](set-up-basic-security-plus-https.md)**: Secures all client communications over HTTPS, including traffic between {{kib}} and {{es}}, and between browsers and {{kib}}. Recommended for all clusters, even single-node setups. +3. **[Configure HTTP TLS](set-up-basic-security-plus-https.md)**: Secures all client communications over HTTPS, including traffic between {{kib}} and {{es}}, and between browsers and {{kib}}. Recommended for all clusters, even single-node setups. Each step builds on the previous one. For production environments, it’s strongly recommended to complete all three. diff --git a/deploy-manage/security/self-tls.md b/deploy-manage/security/self-tls.md index 9af6f83c15..1fc2adfe4d 100644 --- a/deploy-manage/security/self-tls.md +++ b/deploy-manage/security/self-tls.md @@ -3,25 +3,32 @@ navigation_title: "Self-managed" applies_to: deployment: self: ga -mapped_pages: - - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup-https.html --- -# Manage TLS certificates in self-managed deployments +% scope: TLS encryption tasks and settings after the initial setup is completed. +# Manage TLS encryption in self-managed deployments -This section provides guides for configuring TLS encryption in self-managed deployments. It covers how to create and manage TLS certificates, configure {{es}} and {{kib}} service endpoints to use them, and apply related security settings such as supported TLS versions and cipher suites. +This section provides guidance on managing TLS certificates in self-managed deployments after the initial security setup. It covers tasks such as configuring mutual authentication, renewing certificates, and customizing supported TLS versions and cipher suites. -All procedures in this section focus on manual configuration. If you prefer an automated approach, consider using the [automatic security configuration](./self-auto-setup.md) feature, which sets up TLS certificates for {{es}} HTTP and transport endpoints during initial startup. +::::{note} +If you're looking to secure a new or existing cluster by setting up TLS for the first time, refer to [](./self-setup.md), which covers both the [automatic](./self-auto-setup.md) and [manual](./self-setup.md#manual-configuration) configuration procedures. +:::: -For an overview of the endpoints that need securing in {{es}} and {{kib}}, refer to [Communication channels](./secure-cluster-communications.md#communication-channels). +The topics in this section focus on post-setup tasks: -* [](./set-up-basic-security.md) (**required for multi-node clusters**): Create and configure a Certificate Authority (CA) and certificates to encrypt inter-node traffic. -* [](./set-up-basic-security-plus-https.md) (**optional but recommended**): Create and configure certificates to encrypt traffic on {{es}} and {{kib}} HTTP endpoints. -* [](./kibana-es-mutual-tls.md) (**optional**): Strengthen security by requiring {{kib}} to use an additional client certificate in the communication to {{es}}. +* [](./kibana-es-mutual-tls.md) (**optional**): Strengthen security by requiring {{kib}} to use a client certificate when connecting to {{es}}. * [](./updating-certificates.md): Renew or replace existing TLS certificates before they expire. * [](./supported-ssltls-versions-by-jdk-version.md): Customize the list of supported SSL/TLS versions in your cluster. -* [](./enabling-cipher-suites-for-stronger-encryption.md): Enable the use of additional cipher suites, so you can use different cipher suites for your TLS communications or communications with authentication providers. +* [](./enabling-cipher-suites-for-stronger-encryption.md): Enable additional cipher suites for TLS communications, including those used with authentication providers. + +For an overview of the endpoints that need securing in {{es}} and {{kib}}, refer to [Communication channels](./secure-cluster-communications.md#communication-channels). ## Certificates lifecycle In self-managed deployments, you are responsible for certificate lifecycle management, including monitoring expiration dates, renewing certificates, and redeploying them as needed. If you used Elastic tools to generate your certificates, refer to [Update TLS certificates](./updating-certificates.md) for guidance on rotating or replacing them. + +## Advanced configuration references + +Refer to [Transport TLS/SSL settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings) and [HTTP TLS/SSL settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#http-tls-ssl-settings) for the complete list of TLS-related settings in {{es}}. + +For {{kib}}, refer to [{{kib}} general settings](kibana://reference/configuration-reference/general-settings.md), and search for all `ssl`-related settings. TLS settings for the HTTPS server are under the `server.ssl` namespace, while settings for the connection to {{es}} are under `elasticsearch.ssl`. diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 2cc2cedd9f..6fe30c8b0f 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -21,6 +21,8 @@ In this guide, you will learn how to: * [Configure {{kib}} to securely connect to {{es}} over HTTPS](#encrypt-kibana-elasticsearch) by trusting the Certificate Authority (CA) used by {{es}}. * [Generate and configure TLS certificates for the {{kib}} HTTP interface to secure {{kib}} access](#encrypt-kibana-browser). +Refer to [HTTP TLS/SSL settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#http-tls-ssl-settings) for the complete list of available settings in {{es}}. + ::::{note} This guide uses the `elasticsearch-certutil` tool to generate Certificate Authorities (CAs) and TLS certificates. However, using this tool is not required. You can use publicly trusted certificates, your organization's internal certificate management system, or any other method that produces valid certificates. @@ -140,4 +142,10 @@ Once TLS is enabled, all client communications with the cluster will be encrypte :::{include} /deploy-manage/security/_snippets/kibana-https-setup.md ::: -**Next**: Configure any other client that interacts with {{es}} or {{kib}} to use HTTPS and trust the appropriate CA certificate. Refer to [Secure other {{stack}} components](/deploy-manage/security/secure-clients-integrations.md) and [Securing HTTP client applications](./httprest-clients-security.md) for more details. +## What’s next? [whats-next] + +After having enabled HTTPS, you should configure any other client that interacts with {{es}} or {{kib}} to use HTTPS and trust the appropriate CA certificate. Refer to [Secure other {{stack}} components](/deploy-manage/security/secure-clients-integrations.md) and [Securing HTTP client applications](./httprest-clients-security.md) for more details. + +For other tasks related with TLS encryption in self-managed deployments, refer to [](./self-tls.md). + +For other security features, refer to [](./secure-your-cluster-deployment.md). diff --git a/deploy-manage/security/set-up-basic-security.md b/deploy-manage/security/set-up-basic-security.md index 955e463f95..97c3aafcdb 100644 --- a/deploy-manage/security/set-up-basic-security.md +++ b/deploy-manage/security/set-up-basic-security.md @@ -24,6 +24,7 @@ In this guide, you will learn how to: * [Generate a Certificate Authority (CA) and a server certificate using the `elasticsearch-certutil` tool](#generate-certificates). * [Configure your {{es}} nodes to use the generated certificate for the transport layer](#encrypt-internode-communication). +Refer to [Transport TLS/SSL settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings) for the complete list of available settings in {{es}}. ## Generate the certificate authority [generate-certificates] @@ -127,3 +128,5 @@ Complete the following steps **for each node in your cluster**. To join the same Congratulations! You’ve encrypted communications between the nodes in your cluster and can pass the [TLS bootstrap check](../deploy/self-managed/bootstrap-checks.md#bootstrap-checks-tls). To add another layer of security, [set up HTTP TLS](./set-up-basic-security-plus-https.md) to encrypt client communications with both {{es}} and {{kib}}. + +For other tasks related with TLS encryption in self-managed deployments, refer to [](./self-tls.md). diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index 78dcd222ef..8fbc301630 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -7,22 +7,20 @@ mapped_urls: - https://www.elastic.co/guide/en/kibana/current/Security-production-considerations.html --- -% Kibana security had 2 original docs: -% https://www.elastic.co/guide/en/kibana/current/using-kibana-with-security.html -% https://www.elastic.co/guide/en/kibana/current/Security-production-considerations.html - # Configure security in {{kib}} [using-kibana-with-security] -For more information on granting access to {{kib}}, see [](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md). +This document describes security settings you may need to configure in self-managed deployments of {{kib}}. These settings help secure access, manage connections, and ensure consistent behavior across multiple instances. -::::{note} -When a user is not authorized to view data in an index (such as an {{es}} index), the entire index will be inaccessible and not display in {{kib}}. -:::: +Additional {{kib}} security features that apply to all deployment types — such as session management, saved objects encryption, and audit logging — are covered in a separate section [at the end of this document](#additional-security-topics). ## Configure encryption keys [security-configure-settings] Set an encryption key so that sessions are not invalidated. You can optionally configure additional security settings and authentication. +::::{important} +When {{kib}} traffic is balanced across multiple instances connected to the same deployment, it is critical to configure these settings with identical values across all instances. Refer to [](/deploy-manage/production-guidance/kibana-load-balance-traffic.md) for more information. +:::: + 1. 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. Refer to [`xpack.security.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-security-encryptionkey). ```yaml @@ -32,12 +30,9 @@ Set an encryption key so that sessions are not invalidated. You can optionally c {{kib}}'s reporting and saved objects features also have encryption key settings. Refer to [`xpack.reporting.encryptionKey`](kibana://reference/configuration-reference/reporting-settings.md#xpack-reporting-encryptionkey) and [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-encryptionkey) respectively. 2. Optional: [Configure {{kib}}'s session expiration settings](/deploy-manage/security/kibana-session-management.md). -3. Optional: [Configure {{kib}} to authenticate to {{es}} with a client certificate (mutual authentication)](/deploy-manage/security/kibana-es-mutual-tls.md). -4. Restart {{kib}}. - -## Additional Kibana security configurations [Security-production-considerations] +3. Restart {{kib}}. -### Use secure HTTP headers [configuring-security-headers] +## Use secure HTTP headers [configuring-security-headers] The {{kib}} server can instruct browsers to enable additional security controls using HTTP headers. @@ -61,7 +56,7 @@ The {{kib}} server can instruct browsers to enable additional security controls server.securityResponseHeaders.disableEmbedding: true ``` -### Require a Content Security Policy [csp-strict-mode] +## Require a Content Security Policy [csp-strict-mode] {{kib}} uses a Content Security Policy (CSP) to prevent the browser from allowing unsafe scripting, but older browsers will silently ignore this policy. If your organization does not need to support very old versions of our supported browsers, we recommend that you enable {{kib}}'s `strict` mode for the CSP. This will block access to {{kib}} for any browser that does not enforce even a rudimentary set of CSP protections. @@ -71,3 +66,16 @@ To do this, set `csp.strict` to `true` in your `kibana.yml`: csp.strict: true ``` +## Additional security topics [additional-security-topics] + +For guidance on managing user access to {{kib}}, refer to [](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md) and [](/deploy-manage/users-roles/cluster-or-deployment-auth.md). + +For TLS encryption configuration, refer to [](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). + +The following {{kib}} security features are not covered in this document because they apply to all deployment types, not just self-managed ones. However, they’re also important to consider: + +* [Session management](./kibana-session-management.md) +* [Saved objects encryption](./secure-saved-objects.md) +* [Security events audit logging](./logging-configuration/security-event-audit-logging.md) + +For more details, refer to [](./secure-your-cluster-deployment.md). From 1fe942ab9f290f0c0fe4c53b98bb150204f2d1ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 11:02:38 +0200 Subject: [PATCH 25/42] new redirects.yml added --- redirects.yml | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 redirects.yml diff --git a/redirects.yml b/redirects.yml new file mode 100644 index 0000000000..e371531007 --- /dev/null +++ b/redirects.yml @@ -0,0 +1,3 @@ +redirects: + 'deploy-manage/security/manually-configure-security-in-self-managed-cluster.md': '!deploy-manage/security/self-setup.md' + 'deploy-manage/security/security-certificates-keys.md': '!deploy-manage/security/self-auto-setup.md' From f82bfbdf0cd915014ffb41b2c1e19a1536110650 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 19:10:24 +0200 Subject: [PATCH 26/42] Apply suggestions from code review Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com> --- deploy-manage/security/_snippets/cluster-comparison.md | 6 +++--- deploy-manage/security/_snippets/enable-security.md | 2 +- deploy-manage/security/data-security.md | 2 +- deploy-manage/security/self-setup.md | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/deploy-manage/security/_snippets/cluster-comparison.md b/deploy-manage/security/_snippets/cluster-comparison.md index 88201a47f3..a6df3bd9de 100644 --- a/deploy-manage/security/_snippets/cluster-comparison.md +++ b/deploy-manage/security/_snippets/cluster-comparison.md @@ -16,17 +16,17 @@ Select your deployment type below to see what's available and how implementation :::{tab-item} {{ech}} :sync: cloud-hosted -| Category | Security feature | Status | Description | +| Category | Security feature | Status | Notes | |------------------|------------|--------------|-------------| | **Communication** | TLS (HTTP Layer) | Fully managed | Automatically configured by Elastic | | | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | | **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | -| | Private link | Configurable | [Establish secure VPC connection](/deploy-manage/security/private-link-traffic-filters.md) | +| | Private link | Configurable | [Establish a secure VPC connection](/deploy-manage/security/private-link-traffic-filters.md) | | | Kubernetes Network Policies | N/A | | | **Data** | Encryption at rest | Managed | You can [bring your own encryption key](/deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md) | | | Secure settings | Configurable | Automatically protected by Elastic | | | Saved object encryption | Fully managed | Automatically encrypted by Elastic | -| **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | +| **User session** | Kibana sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | ::: diff --git a/deploy-manage/security/_snippets/enable-security.md b/deploy-manage/security/_snippets/enable-security.md index 82d96e6c4c..8b83bd1f4b 100644 --- a/deploy-manage/security/_snippets/enable-security.md +++ b/deploy-manage/security/_snippets/enable-security.md @@ -6,4 +6,4 @@ For self-managed deployments, security features are automatically configured whe If you want to use your own TLS certificates, then you should manually configure security. ::: -Deployments managed by {{eck}}, {{ece}}, {{ech}}, and {{serverless-short}} automatically configure security by default. This includes setting the `elastic` user password, generating TLS certificates, and configuring {{kib}} to connect to {{es}} securely. Disabling security is not supported in these deployment types. \ No newline at end of file +Deployments managed by {{eck}}, {{ece}}, {{ech}}, as well as {{serverless-full}} projects, automatically configure security by default. This includes setting the `elastic` user password, generating TLS certificates, and configuring {{kib}} to connect to {{es}} securely. Disabling security is not supported in these deployment types. \ No newline at end of file diff --git a/deploy-manage/security/data-security.md b/deploy-manage/security/data-security.md index 75cd649767..570952cf99 100644 --- a/deploy-manage/security/data-security.md +++ b/deploy-manage/security/data-security.md @@ -15,7 +15,7 @@ For {{ech}} deployments, instead of the default, Elastic-managed encryption, you :::{note} -There is no encryption at rest out of the box for deployments orchestrated using [{{ece}}](secure-your-elastic-cloud-enterprise-installation.md) and [{{eck}}](secure-your-eck-installation.md), or for self-managed clusters. You must instead configure disk-level encryption on your hosts. +There is no encryption at rest out of the box for deployments orchestrated using {{ece}} and {{eck}}secure-your-eck-installation.md, or for self-managed clusters. You must instead configure disk-level encryption on your hosts. Configuring dm-crypt or similar technologies is outside the scope of the Elastic documentation, and issues related to disk encryption are outside the scope of support. ::: diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index 210299467f..e719a381b8 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -27,7 +27,7 @@ The automatic configuration: This automatic setup is the quickest way to get started and ensures your cluster is protected by default. -::::{note} +::::{warning} The automatic configuration does not enable TLS on the {{kib}} HTTP endpoint. To encrypt browser traffic to {{kib}}, follow the steps in [](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). :::: @@ -47,7 +47,7 @@ Each step builds on the previous one. For production environments, it’s strong ## Kibana security configuration -Refer to [](./using-kibana-with-security.md) for detailed guidance on the following security topics: +Refer to [](./using-kibana-with-security.md) to learn how to implement the following security best practices for {{kib}}: * Set an encryption key for clients sessions * Enable TLS on the HTTP service endpoint From d0b5df0d2d3f870372d342eb3941f3ac35766388 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 19:36:36 +0200 Subject: [PATCH 27/42] review in progress --- .../security/_snippets/cluster-comparison.md | 41 +++++++++---------- .../security/secure-cluster-communications.md | 22 ++++++---- .../secure-your-cluster-deployment.md | 2 - deploy-manage/security/self-setup.md | 2 + redirects.yml | 1 + 5 files changed, 36 insertions(+), 32 deletions(-) diff --git a/deploy-manage/security/_snippets/cluster-comparison.md b/deploy-manage/security/_snippets/cluster-comparison.md index a6df3bd9de..0dffde77d4 100644 --- a/deploy-manage/security/_snippets/cluster-comparison.md +++ b/deploy-manage/security/_snippets/cluster-comparison.md @@ -5,7 +5,6 @@ Security feature availability varies by deployment type, with each feature havin | **Fully managed** | Handled automatically by Elastic with no user configuration needed | | **Managed** | Handled automatically by Elastic, but certain configuration allowed | | **Configurable** | Built-in feature that needs your configuration (like IP filters or passwords) | -| **Self-managed** | Infrastructure-level security you implement and maintain | | **N/A** | Not available for this deployment type | Select your deployment type below to see what's available and how implementation responsibilities are distributed: @@ -20,7 +19,7 @@ Select your deployment type below to see what's available and how implementation |------------------|------------|--------------|-------------| | **Communication** | TLS (HTTP Layer) | Fully managed | Automatically configured by Elastic | | | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | -| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | +| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-filtering-cloud.md) | | | Private link | Configurable | [Establish a secure VPC connection](/deploy-manage/security/private-link-traffic-filters.md) | | | Kubernetes Network Policies | N/A | | | **Data** | Encryption at rest | Managed | You can [bring your own encryption key](/deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md) | @@ -33,31 +32,31 @@ Select your deployment type below to see what's available and how implementation :::{tab-item} Serverless :sync: serverless -| Category| Security feature | Status | Description | +| Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| | **Communication** | TLS (HTTP Layer) | Fully managed | Automatically configured by Elastic | | | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | -| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | -| | Private link | N/A | X | +| **Network** | IP traffic filtering | N/A | | +| | Private link | N/A | | | | Kubernetes Network Policies | N/A | | | **Data** | Encryption at rest | Fully managed | Automatically encrypted by Elastic | -| | Secure settings | Configurable | Automatically protected by Elastic | +| | Secure settings | N/A | | | | Saved object encryption | Fully managed | Automatically encrypted by Elastic | -| **User Session** | Kibana Sessions | Managed | Automatically configured by Elastic | +| **User Session** | Kibana Sessions | Fully managed | Automatically configured by Elastic | ::: :::{tab-item} ECE :sync: ece -| Category| Security feature | Status | Description | +| Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| | **Communication** | TLS (HTTP Layer) | Managed | You can [configure custom certificates](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) | | | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | -| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | -| | Private link | N/A | X | +| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-filtering-cloud.md) | +| | Private link | N/A | | | | Kubernetes Network Policies | N/A | | -| **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | +| **Data** | Encryption at rest | N/A | | | | Secure settings | Configurable | [Configure secure settings](/deploy-manage/security/secure-settings.md) | | | Saved object encryption | Configurable | [Enable encryption for saved objects](/deploy-manage/security/secure-saved-objects.md) | | **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | @@ -67,14 +66,14 @@ Select your deployment type below to see what's available and how implementation :::{tab-item} ECK :sync: eck -| Category| Security feature | Status | Description | +| Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| | **Communication** | TLS (HTTP Layer) | Managed | [Multiple options](/deploy-manage/security/k8s-https-settings.md) | | | TLS (Transport Layer) | Managed | [Multiple options](/deploy-manage/security/k8s-transport-settings.md) | -| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | +| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-filtering-basic.md) | | | Private link | N/A | | | | Kubernetes Network Policies | Configurable | [Apply network policies to your Pods](/deploy-manage/security/k8s-network-policies.md) | -| **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | +| **Data** | Encryption at rest | N/A | | | | Secure settings | Configurable | [Configure secure settings](/deploy-manage/security/k8s-secure-settings.md) | | | Saved object encryption | Configurable | [Enable encryption for saved objects](/deploy-manage/security/secure-saved-objects.md) | | **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | @@ -85,15 +84,15 @@ Select your deployment type below to see what's available and how implementation :::{tab-item} Self-managed :sync: self-managed -| Category| Security feature | Status | Description | +| Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Self-managed | Implement and maintain certificates | -| | TLS (Transport Layer) | Self-managed | Implement and maintain certificates | -| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-traffic-filtering.md) | -| | Private link | N/A | X | +| **Communication** | TLS (HTTP Layer) | Configurable | [Initial security setup](/deploy-manage/security/self-setup.md) | +| | TLS (Transport Layer) | Configurable | [Initial security setup](/deploy-manage/security/self-setup.md) | +| **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-filtering-basic.md) | +| | Private link | N/A | | | | Kubernetes Network Policies | N/A | | -| **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | -| | Keystore security | Configurable | [Configure secure settings](/deploy-manage/security/secure-settings.md) storage | +| **Data** | Encryption at rest | N/A | | +| | Keystore security | Configurable | [Configure secure settings](/deploy-manage/security/secure-settings.md) | | | Saved object encryption | Configurable | [Enable encryption for saved objects](/deploy-manage/security/secure-saved-objects.md) | | **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 890e919323..a6548912b9 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -92,17 +92,17 @@ While HTTP TLS encryption is optional in self-managed environments, it is strong The way that HTTP layer security is managed depends on your deployment type: -::::{tab-set} +:::::{tab-set} :group: deployments -:::{tab-item} ECH and Serverless +::::{tab-item} ECH and Serverless :sync: ech HTTP TLS for {{es}} and {{kib}} is fully managed by Elastic. No configuration is required. {{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. -::: +:::: -:::{tab-item} ECE +::::{tab-item} ECE :sync: ece HTTP TLS for deployments is managed at the platform proxy level. Refer to these guides for ECE-specific security customizations: @@ -111,28 +111,32 @@ HTTP TLS for deployments is managed at the platform proxy level. Refer to these * [Configure TLS version](./secure-your-elastic-cloud-enterprise-installation/configure-tls-version.md) {{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. -::: +:::: -:::{tab-item} ECK +::::{tab-item} ECK :sync: eck HTTP TLS is automatically enabled for {{es}} and {{kib}} using self-signed certificates, with [several options available for customization](./k8s-https-settings.md), including custom certificates and domain names. {{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. -::: +:::: -:::{tab-item} Self-managed +::::{tab-item} Self-managed :sync: self HTTP TLS certificates for {{es}} can be [automatically configured](self-auto-setup.md), or manually set up by following the steps in [Set up HTTP SSL](./set-up-basic-security-plus-https.md). {{kib}} acts as both an HTTP client to {{es}} and a server for browser access. It performs operations on behalf of users, so it must be properly configured to trust the {{es}} certificates, and to present its own TLS certificate for secure browser connections. These configurations must be performed manually in self-managed deployments. -For environments with stricter security requirements, refer to [Mutual TLS authentication between {{kib}} and {{es}}](./kibana-es-mutual-tls.md). +:::{note} +The automatic configuration does not enable TLS on the {{kib}} HTTP endpoint. To encrypt browser traffic to {{kib}}, follow the steps in [](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). ::: +For environments with stricter security requirements, refer to [Mutual TLS authentication between {{kib}} and {{es}}](./kibana-es-mutual-tls.md). :::: +::::: + ## Certificates lifecycle [generate-certificates] Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. Each deployment type provides different tools or responsibilities for managing certificates lifecycle. diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index 26b8633867..39fd4d9382 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -5,8 +5,6 @@ applies_to: eck: all ece: all ess: all -mapped_pages: - - https://www.elastic.co/guide/en/elasticsearch/reference/current/manually-configure-security.html --- # Secure your cluster or deployment diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index e719a381b8..1425f383e1 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -3,6 +3,8 @@ navigation_title: "Self-managed security setup" applies_to: deployment: self: ga +mapped_pages: + - https://www.elastic.co/guide/en/elasticsearch/reference/current/manually-configure-security.html --- % scope: initial security setup in self-managed deployments, following the automatic or manual (minimal, basic, https) procedures diff --git a/redirects.yml b/redirects.yml index d62c8dced2..16734b847d 100644 --- a/redirects.yml +++ b/redirects.yml @@ -1,4 +1,5 @@ redirects: + 'deploy-manage/security/secure-http-communications.md': '!deploy-manage/security/secure-cluster-communications.md' 'deploy-manage/security/manually-configure-security-in-self-managed-cluster.md': '!deploy-manage/security/self-setup.md' 'deploy-manage/security/security-certificates-keys.md': '!deploy-manage/security/self-auto-setup.md' 'deploy-manage/security/ece-traffic-filtering-through-the-api.md': 'deploy-manage/security/ec-traffic-filtering-through-the-api.md' From 2703f924db3fbb0e2a8b0bdbf6aefb1dcc515f1a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 20:41:37 +0200 Subject: [PATCH 28/42] Apply suggestions from code review Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com> --- .../security/_snippets/cluster-comparison.md | 32 +++++++++---------- deploy-manage/security/k8s-https-settings.md | 4 --- .../security/kibana-es-mutual-tls.md | 2 +- .../security/secure-cluster-communications.md | 12 +++---- deploy-manage/security/self-tls.md | 4 +-- .../security/using-kibana-with-security.md | 2 +- 6 files changed, 25 insertions(+), 31 deletions(-) diff --git a/deploy-manage/security/_snippets/cluster-comparison.md b/deploy-manage/security/_snippets/cluster-comparison.md index 0dffde77d4..15e9d27bc8 100644 --- a/deploy-manage/security/_snippets/cluster-comparison.md +++ b/deploy-manage/security/_snippets/cluster-comparison.md @@ -17,11 +17,11 @@ Select your deployment type below to see what's available and how implementation | Category | Security feature | Status | Notes | |------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Fully managed | Automatically configured by Elastic | -| | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | +| **Communication** | TLS (HTTP layer) | Fully managed | Automatically configured by Elastic | +| | TLS (Transport layer) | Fully managed | Automatically configured by Elastic | | **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-filtering-cloud.md) | | | Private link | Configurable | [Establish a secure VPC connection](/deploy-manage/security/private-link-traffic-filters.md) | -| | Kubernetes Network Policies | N/A | | +| | Kubernetes network policies | N/A | | | **Data** | Encryption at rest | Managed | You can [bring your own encryption key](/deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md) | | | Secure settings | Configurable | Automatically protected by Elastic | | | Saved object encryption | Fully managed | Automatically encrypted by Elastic | @@ -34,11 +34,11 @@ Select your deployment type below to see what's available and how implementation | Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Fully managed | Automatically configured by Elastic | -| | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | +| **Communication** | TLS (HTTP layer) | Fully managed | Automatically configured by Elastic | +| | TLS (Transport layer) | Fully managed | Automatically configured by Elastic | | **Network** | IP traffic filtering | N/A | | | | Private link | N/A | | -| | Kubernetes Network Policies | N/A | | +| | Kubernetes network policies | N/A | | | **Data** | Encryption at rest | Fully managed | Automatically encrypted by Elastic | | | Secure settings | N/A | | | | Saved object encryption | Fully managed | Automatically encrypted by Elastic | @@ -51,15 +51,15 @@ Select your deployment type below to see what's available and how implementation | Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Managed | You can [configure custom certificates](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) | -| | TLS (Transport Layer) | Fully managed | Automatically configured by Elastic | +| **Communication** | TLS (HTTP layer) | Managed | You can [configure custom certificates](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) | +| | TLS (Transport layer) | Fully managed | Automatically configured by Elastic | | **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-filtering-cloud.md) | | | Private link | N/A | | -| | Kubernetes Network Policies | N/A | | +| | Kubernetes network policies | N/A | | | **Data** | Encryption at rest | N/A | | | | Secure settings | Configurable | [Configure secure settings](/deploy-manage/security/secure-settings.md) | | | Saved object encryption | Configurable | [Enable encryption for saved objects](/deploy-manage/security/secure-saved-objects.md) | -| **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | +| **User session** | {{kib}} sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | ::: @@ -68,15 +68,15 @@ Select your deployment type below to see what's available and how implementation | Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Managed | [Multiple options](/deploy-manage/security/k8s-https-settings.md) | -| | TLS (Transport Layer) | Managed | [Multiple options](/deploy-manage/security/k8s-transport-settings.md) | +| **Communication** | TLS (HTTP layer) | Managed | [Multiple options](/deploy-manage/security/k8s-https-settings.md) for customization | +| | TLS (Transport layer) | Managed | [Multiple options](/deploy-manage/security/k8s-transport-settings.md) for customization | | **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-filtering-basic.md) | | | Private link | N/A | | -| | Kubernetes Network Policies | Configurable | [Apply network policies to your Pods](/deploy-manage/security/k8s-network-policies.md) | +| | Kubernetes network policies | Configurable | [Apply network policies to your Pods](/deploy-manage/security/k8s-network-policies.md) | | **Data** | Encryption at rest | N/A | | | | Secure settings | Configurable | [Configure secure settings](/deploy-manage/security/k8s-secure-settings.md) | | | Saved object encryption | Configurable | [Enable encryption for saved objects](/deploy-manage/security/secure-saved-objects.md) | -| **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | +| **User session** | {{kib}} sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | ::: @@ -90,11 +90,11 @@ Select your deployment type below to see what's available and how implementation | | TLS (Transport Layer) | Configurable | [Initial security setup](/deploy-manage/security/self-setup.md) | | **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-filtering-basic.md) | | | Private link | N/A | | -| | Kubernetes Network Policies | N/A | | +| | Kubernetes network policies | N/A | | | **Data** | Encryption at rest | N/A | | | | Keystore security | Configurable | [Configure secure settings](/deploy-manage/security/secure-settings.md) | | | Saved object encryption | Configurable | [Enable encryption for saved objects](/deploy-manage/security/secure-saved-objects.md) | -| **User Session** | Kibana Sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | +| **User session** | {{kib}} sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | ::: :::: \ No newline at end of file diff --git a/deploy-manage/security/k8s-https-settings.md b/deploy-manage/security/k8s-https-settings.md index 531e1c89f6..8a771aee91 100644 --- a/deploy-manage/security/k8s-https-settings.md +++ b/deploy-manage/security/k8s-https-settings.md @@ -12,10 +12,6 @@ mapped_urls: ## {{es}} certificates [k8s-tls-certificates] -```{applies_to} -deployment: - eck: all -``` :::{note} This section only covers TLS certificates for the HTTP layer. TLS certificates for the transport layer that are used for internal communications between Elasticsearch nodes are managed by ECK and cannot be changed. You can however set your own certificate authority for the [transport layer](/deploy-manage/security/k8s-transport-settings.md#k8s-transport-ca). diff --git a/deploy-manage/security/kibana-es-mutual-tls.md b/deploy-manage/security/kibana-es-mutual-tls.md index 2d7cad61a9..3ed3acda32 100644 --- a/deploy-manage/security/kibana-es-mutual-tls.md +++ b/deploy-manage/security/kibana-es-mutual-tls.md @@ -23,7 +23,7 @@ To [enroll {{kib}} with an {{es}} cluster](/deploy-manage/security/self-auto-set Using a PKI realm is a [subscription feature](https://www.elastic.co/subscriptions). :::: -#### Configure {{kib}} and {{es}} to use mutual TLS authentication [_configure_kib_and_es_to_use_mutual_tls_authentication] +## Configure {{kib}} and {{es}} to use mutual TLS authentication [_configure_kib_and_es_to_use_mutual_tls_authentication] If you haven’t already, start {{kib}} and connect it to {{es}} using the [enrollment token](/deploy-manage/security/self-auto-setup.md#stack-start-with-security). diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index a6548912b9..114a8b4bb6 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -13,21 +13,21 @@ mapped_urls: % Scope: landing page for manually handling TLS certificates, and for information about TLS in Elastic Stack in general. # TLS encryption for cluster communications -This page explains how to secure communications and setup TLS certificates between components in your {{stack}} deployment. +This page explains how to secure communications and set up TLS certificates between components in your {{stack}} deployment. -For {{ech}} and {{serverless-full}} deployments, communication security is fully managed by Elastic with no configuration required, including TLS certificates. +For {{ech}} deployments and {{serverless-full}} projects, communication security is [fully managed by Elastic](/deploy-manage/security.md#managed-security-in-elastic-cloud) with no configuration required, including TLS certificates. -For ECE, ECK, and self-managed deployments, this page provides specific configuration guidance to secure the various communication channels between components. +For ECE, ECK, and self-managed deployments, some of this process can be automated, with opportunities for manual configuration depending on your requirements. This page provides specific configuration guidance to secure the various communication channels between components. :::{tip} -For a complete comparison of security feature availability and responsibility by deployment type, see [Security features by deployment type](/deploy-manage/security.md#comparison-table). +For a complete comparison of security feature availability and responsibility by deployment type, refer to [Security features by deployment type](/deploy-manage/security.md#comparison-table). ::: ## Communication channels overview [communication-channels] Both {{es}} and {{kib}}, the core components of the {{stack}}, expose service endpoints that must be secured. {{es}} handles traffic at two levels: * The **transport layer** (defaults to port `9300`), used for internal communication between nodes in the cluster. -* The **HTTP layer** (defaults to port `9200`), used by external clients — including Kibana — to send requests via the REST API. +* The **HTTP layer** (defaults to port `9200`), used by external clients — including Kibana — to send requests using the REST API. Additionally, {{kib}} functions as a web server, exposing its own **HTTP endpoint** (defaults to port `5601`) to users, and also acts as a client when sending requests to {{es}}. @@ -77,7 +77,7 @@ Transport Layer Security (TLS) is the name of an industry standard protocol for Transport Protocol is the name of the protocol that {{es}} nodes use to communicate with one another. This name is specific to {{es}} and distinguishes the transport port (default `9300`) from the HTTP port (default `9200`). Nodes communicate with one another using the transport port, and REST clients communicate with {{es}} using the HTTP port. -Although the word *transport* appears in both contexts, they mean different things. It’s possible to apply TLS to both the {{es}} transport port and the HTTP port. We know that these overlapping terms can be confusing, so to clarify, in this scenario we’re applying TLS to the {{es}} transport port. In [](./set-up-basic-security-plus-https.md), we’ll apply TLS to the {{es}} HTTP port. +Although the word *transport* appears in both contexts, they mean different things. It’s possible to apply TLS to both the {{es}} transport port and the HTTP port. We know that these overlapping terms can be confusing, so to clarify, in this scenario we’re applying TLS to the {{es}} transport port. :::: diff --git a/deploy-manage/security/self-tls.md b/deploy-manage/security/self-tls.md index 1fc2adfe4d..6c27e7d007 100644 --- a/deploy-manage/security/self-tls.md +++ b/deploy-manage/security/self-tls.md @@ -10,9 +10,7 @@ applies_to: This section provides guidance on managing TLS certificates in self-managed deployments after the initial security setup. It covers tasks such as configuring mutual authentication, renewing certificates, and customizing supported TLS versions and cipher suites. -::::{note} If you're looking to secure a new or existing cluster by setting up TLS for the first time, refer to [](./self-setup.md), which covers both the [automatic](./self-auto-setup.md) and [manual](./self-setup.md#manual-configuration) configuration procedures. -:::: The topics in this section focus on post-setup tasks: @@ -21,7 +19,7 @@ The topics in this section focus on post-setup tasks: * [](./supported-ssltls-versions-by-jdk-version.md): Customize the list of supported SSL/TLS versions in your cluster. * [](./enabling-cipher-suites-for-stronger-encryption.md): Enable additional cipher suites for TLS communications, including those used with authentication providers. -For an overview of the endpoints that need securing in {{es}} and {{kib}}, refer to [Communication channels](./secure-cluster-communications.md#communication-channels). +For an overview of the endpoints that can be secured in {{es}} and {{kib}}, refer to [Communication channels](./secure-cluster-communications.md#communication-channels). ## Certificates lifecycle diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index 8fbc301630..42d3efd636 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -11,7 +11,7 @@ mapped_urls: This document describes security settings you may need to configure in self-managed deployments of {{kib}}. These settings help secure access, manage connections, and ensure consistent behavior across multiple instances. -Additional {{kib}} security features that apply to all deployment types — such as session management, saved objects encryption, and audit logging — are covered in a separate section [at the end of this document](#additional-security-topics). +Additional {{kib}} security features that apply to all deployment types, such as session management, saved objects encryption, and audit logging, are covered in a separate section [at the end of this document](#additional-security-topics). ## Configure encryption keys [security-configure-settings] From 23a9ae2c8873b97b5406ae37968908b04ce765d6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 20:47:21 +0200 Subject: [PATCH 29/42] Update deploy-manage/security/_snippets/cluster-comparison.md Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com> --- deploy-manage/security/_snippets/cluster-comparison.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/security/_snippets/cluster-comparison.md b/deploy-manage/security/_snippets/cluster-comparison.md index 15e9d27bc8..a6f8ffb548 100644 --- a/deploy-manage/security/_snippets/cluster-comparison.md +++ b/deploy-manage/security/_snippets/cluster-comparison.md @@ -25,7 +25,7 @@ Select your deployment type below to see what's available and how implementation | **Data** | Encryption at rest | Managed | You can [bring your own encryption key](/deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md) | | | Secure settings | Configurable | Automatically protected by Elastic | | | Saved object encryption | Fully managed | Automatically encrypted by Elastic | -| **User session** | Kibana sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | +| **User session** | {{kib}} sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | ::: From 7da7542b360bb165bbac3b23ec0c4e16b54f60ea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 20:47:30 +0200 Subject: [PATCH 30/42] Update deploy-manage/security/_snippets/cluster-comparison.md Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com> --- deploy-manage/security/_snippets/cluster-comparison.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deploy-manage/security/_snippets/cluster-comparison.md b/deploy-manage/security/_snippets/cluster-comparison.md index a6f8ffb548..0db6d4a263 100644 --- a/deploy-manage/security/_snippets/cluster-comparison.md +++ b/deploy-manage/security/_snippets/cluster-comparison.md @@ -42,7 +42,7 @@ Select your deployment type below to see what's available and how implementation | **Data** | Encryption at rest | Fully managed | Automatically encrypted by Elastic | | | Secure settings | N/A | | | | Saved object encryption | Fully managed | Automatically encrypted by Elastic | -| **User Session** | Kibana Sessions | Fully managed | Automatically configured by Elastic | +| **User session** | {{kib}} sessions | Fully managed | Automatically configured by Elastic | ::: From beca8539beac77039719159e42ab93836c781615 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 22:52:57 +0200 Subject: [PATCH 31/42] working on reviews --- deploy-manage/security/_snippets/eck-http.md | 3 ++ .../security/_snippets/eck-lifecycle.md | 5 +++ .../security/_snippets/eck-transport.md | 1 + deploy-manage/security/eck-tls.md | 15 +++----- .../security/install-stack-demo-secure.md | 3 +- deploy-manage/security/k8s-https-settings.md | 15 +++++--- .../security/secure-cluster-communications.md | 38 +++++++++---------- deploy-manage/security/self-auto-setup.md | 4 ++ deploy-manage/security/self-tls.md | 2 +- .../security/using-kibana-with-security.md | 5 ++- 10 files changed, 54 insertions(+), 37 deletions(-) create mode 100644 deploy-manage/security/_snippets/eck-http.md create mode 100644 deploy-manage/security/_snippets/eck-lifecycle.md create mode 100644 deploy-manage/security/_snippets/eck-transport.md diff --git a/deploy-manage/security/_snippets/eck-http.md b/deploy-manage/security/_snippets/eck-http.md new file mode 100644 index 0000000000..d8814e6da0 --- /dev/null +++ b/deploy-manage/security/_snippets/eck-http.md @@ -0,0 +1,3 @@ +HTTP TLS is automatically enabled for {{es}} and {{kib}} using self-signed certificates, with [several options available for customization](/deploy-manage/security/k8s-https-settings.md), including custom certificates and domain names. + +{{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. diff --git a/deploy-manage/security/_snippets/eck-lifecycle.md b/deploy-manage/security/_snippets/eck-lifecycle.md new file mode 100644 index 0000000000..97050460f4 --- /dev/null +++ b/deploy-manage/security/_snippets/eck-lifecycle.md @@ -0,0 +1,5 @@ +ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. + +ECK automatically rotates any certificates and CAs that were generated by the operator and are under its management. + +For certificate management configuration options, refer to [ECK configuration flags](cloud-on-k8s://reference/eck-configuration-flags.md). \ No newline at end of file diff --git a/deploy-manage/security/_snippets/eck-transport.md b/deploy-manage/security/_snippets/eck-transport.md new file mode 100644 index 0000000000..c357f30ce9 --- /dev/null +++ b/deploy-manage/security/_snippets/eck-transport.md @@ -0,0 +1 @@ +{{es}} transport security and TLS certificates are automatically configured by the operator, but you can still [customize its service and CA certificates](/deploy-manage/security/k8s-transport-settings.md). diff --git a/deploy-manage/security/eck-tls.md b/deploy-manage/security/eck-tls.md index d0d9d90359..cf0ff4619f 100644 --- a/deploy-manage/security/eck-tls.md +++ b/deploy-manage/security/eck-tls.md @@ -15,18 +15,15 @@ Refer to [Communication channels](./secure-cluster-communications.md#communicati ## {{es}} transport layer configuration -{{es}} transport security and TLS certificates are automatically configured by the operator, but you can still [customize its service and CA certificates](/deploy-manage/security/k8s-transport-settings.md). +:::{include} ./_snippets/eck-transport.md +::: ## {{es}} and {{kib}} HTTP configuration -HTTP TLS is automatically enabled for {{es}} and {{kib}} using self-signed certificates, with [several options available for customization](./k8s-https-settings.md), including custom certificates and domain names. - -{{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. +:::{include} ./_snippets/eck-http.md +::: ## Certificates lifecycle -ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. - -ECK automatically rotates any certificates and CAs that were generated by the operator and are under its management. - -For certificate management configuration options, refer to [ECK configuration flags](cloud-on-k8s://reference/eck-configuration-flags.md). \ No newline at end of file +:::{include} ./_snippets/eck-lifecycle.md +::: diff --git a/deploy-manage/security/install-stack-demo-secure.md b/deploy-manage/security/install-stack-demo-secure.md index af5f867350..67999b82b3 100644 --- a/deploy-manage/security/install-stack-demo-secure.md +++ b/deploy-manage/security/install-stack-demo-secure.md @@ -8,7 +8,8 @@ mapped_urls: # Tutorial: Securing a self-managed {{stack}} [install-stack-demo-secure] -TBD: This one feels duplicate (it comes from elastic-stack original book) +% This doc feels duplicate (it comes from elastic-stack original book), although it includes an end to end guidance and offers different examples for certificates generation +% we have to decide what to do with this at a later stage This tutorial is a follow-on to [installing a self-managed {{stack}}](/deploy-manage/deploy/self-managed.md) with a multi-node {{es}} cluster, {{kib}}, {{fleet-server}} and {{agent}}. In a production environment, it’s recommended after completing the {{kib}} setup to proceed directly to this tutorial to configure your SSL certificates. These steps guide you through that process, and then describe how to configure {{fleet-server}} and {{agent}} with the certificates in place. diff --git a/deploy-manage/security/k8s-https-settings.md b/deploy-manage/security/k8s-https-settings.md index 8a771aee91..5144701122 100644 --- a/deploy-manage/security/k8s-https-settings.md +++ b/deploy-manage/security/k8s-https-settings.md @@ -10,13 +10,14 @@ mapped_urls: # Manage HTTP certificates on ECK -## {{es}} certificates [k8s-tls-certificates] - +ECK offers several options for securing the HTTP endpoints of {{es}} and {{kib}}. By default, the operator generates a dedicated CA per deployment, and issues individual certificates for each instance. Alternatively, you can supply your own certificates or integrate with external solutions like `cert-manager`. :::{note} -This section only covers TLS certificates for the HTTP layer. TLS certificates for the transport layer that are used for internal communications between Elasticsearch nodes are managed by ECK and cannot be changed. You can however set your own certificate authority for the [transport layer](/deploy-manage/security/k8s-transport-settings.md#k8s-transport-ca). +This section only covers TLS certificates for the HTTP layer. TLS certificates for the transport layer that are used for internal communications between {{es}} nodes are managed by ECK and cannot be changed. You can however [set your own certificate authority for the transport layer](/deploy-manage/security/k8s-transport-settings.md#k8s-transport-ca). ::: +## {{es}} certificates [k8s-tls-certificates] + By default, the operator manages a self-signed certificate with a custom CA for each resource. The CA, the certificate and the private key are each stored in a separate `Secret`. ```sh @@ -198,9 +199,13 @@ spec: ## Kibana HTTP configuration in ECK [k8s-kibana-http-configuration] +By default, ECK creates a `ClusterIP` [Service](https://kubernetes.io/docs/concepts/services-networking/service/) and associates it with the {{kib}} deployment. + +If you need to expose {{kib}} externally or customize the service settings, ECK provides flexible options, including support for load balancers, custom DNS/IP SANs, and user-provided certificates. + ### Load balancer settings and TLS SANs [k8s-kibana-http-publish] -By default a `ClusterIP` [Service](https://kubernetes.io/docs/concepts/services-networking/service/) is created and associated with the {{kib}} deployment. If you want to expose {{kib}} externally with a [load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer), it is recommended to include a custom DNS name or IP in the self-generated certificate. +If you want to expose {{kib}} externally with a [load balancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer), it is recommended to include a custom DNS name or IP in the self-generated certificate. ```yaml apiVersion: kibana.k8s.elastic.co/v1 @@ -226,7 +231,7 @@ spec: ### Provide your own certificate [k8s-kibana-http-custom-tls] -If you want to use your own certificate, the required configuration is identical to {{es}}. Refer to [setup your own {{es}} certificate](#k8s-setting-up-your-own-certificate). +If you want to use your own certificate, the required configuration is identical to {{es}}. Refer to [setup your own {{es}} certificate](#k8s-setting-up-your-own-certificate) for more information. ## Disable TLS [k8s-disable-tls] diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 114a8b4bb6..e2bcbe976b 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -13,15 +13,22 @@ mapped_urls: % Scope: landing page for manually handling TLS certificates, and for information about TLS in Elastic Stack in general. # TLS encryption for cluster communications -This page explains how to secure communications and set up TLS certificates between components in your {{stack}} deployment. +This page explains how to secure communications and set up TLS certificates in your {{stack}} deployments. For {{ech}} deployments and {{serverless-full}} projects, communication security is [fully managed by Elastic](/deploy-manage/security.md#managed-security-in-elastic-cloud) with no configuration required, including TLS certificates. For ECE, ECK, and self-managed deployments, some of this process can be automated, with opportunities for manual configuration depending on your requirements. This page provides specific configuration guidance to secure the various communication channels between components. -:::{tip} For a complete comparison of security feature availability and responsibility by deployment type, refer to [Security features by deployment type](/deploy-manage/security.md#comparison-table). -::: + +::::{admonition} Understanding transport contexts +The term *transport* can be confusing in {{es}} because it's used in two different contexts: +- **Transport Layer Security (TLS)** is an industry-standard protocol that secures network communication. It's the modern name for SSL, and the Elastic documentation uses the terms TLS and SSL interchangeably. +- In {{es}}, the **transport layer** refers to internal node-to-node communication, which occurs over port 9300. This communication uses the [transport interface](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md), which implements a binary protocol specific to {{es}}. + +Keep this distinction in mind when configuring security settings. +:::: + ## Communication channels overview [communication-channels] @@ -37,7 +44,7 @@ To ensure secure operation, it’s important to understand the communication cha |-------------|-----------------|--------------------| | [{{es}} transport layer](#encrypt-internode-communication) | Communication between {{es}} nodes within a cluster | Mutual TLS/SSL required for multi-node clusters | | [{{es}} HTTP layer](#encrypt-http-communication) | Communication between external clients and {{es}} through the REST API | TLS/SSL optional (but recommended) | -| [{{kib}} HTTP layer](#encrypt-http-communication) | Communication between external browsers and {{kib}} through the REST API | TLS/SSL optional (but recommended) | +| [{{kib}} HTTP layer](#encrypt-http-communication) | Communication between external browsers or REST clients and {{kib}} | TLS/SSL optional (but recommended) | ### Transport layer security [encrypt-internode-communication] @@ -62,7 +69,10 @@ The way that transport layer security is managed depends on your deployment type :::{tab-item} ECK :sync: eck -{{es}} transport security and TLS certificates are automatically configured by the operator, but you can still [customize its service and CA certificates](/deploy-manage/security/k8s-transport-settings.md). + +:::{include} ./_snippets/eck-transport.md +::: + ::: :::{tab-item} Self-managed @@ -72,16 +82,6 @@ The way that transport layer security is managed depends on your deployment type :::: -::::{admonition} Understanding transport contexts -Transport Layer Security (TLS) is the name of an industry standard protocol for applying security controls (such as encryption) to network communications. TLS is the modern name for what used to be called Secure Sockets Layer (SSL). The {{es}} documentation uses the terms TLS and SSL interchangeably. - -Transport Protocol is the name of the protocol that {{es}} nodes use to communicate with one another. This name is specific to {{es}} and distinguishes the transport port (default `9300`) from the HTTP port (default `9200`). Nodes communicate with one another using the transport port, and REST clients communicate with {{es}} using the HTTP port. - -Although the word *transport* appears in both contexts, they mean different things. It’s possible to apply TLS to both the {{es}} transport port and the HTTP port. We know that these overlapping terms can be confusing, so to clarify, in this scenario we’re applying TLS to the {{es}} transport port. -:::: - - - ### HTTP layer security [encrypt-http-communication] The HTTP layer includes the service endpoints exposed by both {{es}} and {{kib}}, supporting communications such as REST API requests, browser access to {{kib}}, and {{kib}}’s own traffic to {{es}}. Securing these endpoints helps prevent unauthorized access and protects sensitive data in transit. @@ -116,9 +116,9 @@ HTTP TLS for deployments is managed at the platform proxy level. Refer to these ::::{tab-item} ECK :sync: eck -HTTP TLS is automatically enabled for {{es}} and {{kib}} using self-signed certificates, with [several options available for customization](./k8s-https-settings.md), including custom certificates and domain names. +:::{include} ./_snippets/eck-http.md +::: -{{kib}} instances are automatically configured to connect securely to {{es}}, without requiring manual setup. :::: ::::{tab-item} Self-managed @@ -159,9 +159,9 @@ In ECE, the platform automatically renews internal certificates. However, you mu :::{tab-item} ECK :sync: eck -ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. +:::{include} ./_snippets/eck-lifecycle.md +::: -TBD, add links to cert validity settings and cert configuration ::: :::{tab-item} Self-managed diff --git a/deploy-manage/security/self-auto-setup.md b/deploy-manage/security/self-auto-setup.md index bf79df8ae6..be7a4c656b 100644 --- a/deploy-manage/security/self-auto-setup.md +++ b/deploy-manage/security/self-auto-setup.md @@ -18,6 +18,10 @@ mapped_pages: * [Download](https://www.elastic.co/downloads/elasticsearch) and unpack the `elasticsearch` package distribution for your environment. * [Download](https://www.elastic.co/downloads/kibana) and unpack the `kibana` package distribution for your environment. +::::{note} +This guide assumes a `.tar.gz` installation of {{es}} and {{kib}} on Linux. +For instructions tailored to other installation packages (such as DEB, RPM, Docker, or macOS), refer to the [{{es}}](/deploy-manage/deploy/self-managed/installing-elasticsearch.md#elasticsearch-install-packages) and [{{kib}}](/deploy-manage/deploy/self-managed/install-kibana.md#install) installation guides. +:::: ## Start {{es}} and enroll {{kib}} with security enabled [stack-start-with-security] diff --git a/deploy-manage/security/self-tls.md b/deploy-manage/security/self-tls.md index 6c27e7d007..0690eac654 100644 --- a/deploy-manage/security/self-tls.md +++ b/deploy-manage/security/self-tls.md @@ -14,7 +14,7 @@ If you're looking to secure a new or existing cluster by setting up TLS for the The topics in this section focus on post-setup tasks: -* [](./kibana-es-mutual-tls.md) (**optional**): Strengthen security by requiring {{kib}} to use a client certificate when connecting to {{es}}. +* [](./kibana-es-mutual-tls.md): Strengthen security by requiring {{kib}} to use a client certificate when connecting to {{es}}. * [](./updating-certificates.md): Renew or replace existing TLS certificates before they expire. * [](./supported-ssltls-versions-by-jdk-version.md): Customize the list of supported SSL/TLS versions in your cluster. * [](./enabling-cipher-suites-for-stronger-encryption.md): Enable additional cipher suites for TLS communications, including those used with authentication providers. diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index 42d3efd636..40623b936a 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -36,9 +36,9 @@ When {{kib}} traffic is balanced across multiple instances connected to the same The {{kib}} server can instruct browsers to enable additional security controls using HTTP headers. -1. Enable HTTP Strict-Transport-Security. +1. Enable `HTTP Strict Transport Security (HSTS)`. - Use [`strictTransportSecurity`](https://www.elastic.co/guide/en/kibana/current/settings.html#server-securityResponseHeaders-strictTransportSecurity) to ensure that browsers will only attempt to access {{kib}} with SSL/TLS encryption. This is designed to prevent manipulator-in-the-middle attacks. To configure this with a lifetime of one year in your `kibana.yml`: + Use [`strictTransportSecurity`](https://www.elastic.co/guide/en/kibana/current/settings.html#server-securityResponseHeaders-strictTransportSecurity) to ensure that browsers will only attempt to access [{{kib}} with SSL/TLS encryption](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). This is designed to prevent manipulator-in-the-middle attacks. To configure this with a lifetime of one year in your `kibana.yml`: ```js server.securityResponseHeaders.strictTransportSecurity: "max-age=31536000" @@ -76,6 +76,7 @@ The following {{kib}} security features are not covered in this document because * [Session management](./kibana-session-management.md) * [Saved objects encryption](./secure-saved-objects.md) +* [Secure settings](./secure-settings.md) * [Security events audit logging](./logging-configuration/security-event-audit-logging.md) For more details, refer to [](./secure-your-cluster-deployment.md). From 8da916cdd01f1e41154b82578bb3da24e9703564 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 23:04:04 +0200 Subject: [PATCH 32/42] working on reviews --- deploy-manage/security/self-setup.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index 1425f383e1..cb9598ce0f 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -47,12 +47,12 @@ If you’re securing an existing unsecured cluster, or prefer to use your own TL Each step builds on the previous one. For production environments, it’s strongly recommended to complete all three. +For additional TLS configuration options, refer to [](./self-tls.md). + ## Kibana security configuration Refer to [](./using-kibana-with-security.md) to learn how to implement the following security best practices for {{kib}}: * Set an encryption key for clients sessions -* Enable TLS on the HTTP service endpoint -* Enable mutual authentication between {{kib}} and {{es}} * Use secure HTTP headers * Require a Content Security Policy \ No newline at end of file From 091d773c4bb88586d466441f32af0de8f130baf2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 23:14:14 +0200 Subject: [PATCH 33/42] working on reviews --- deploy-manage/security/_snippets/cluster-comparison.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/deploy-manage/security/_snippets/cluster-comparison.md b/deploy-manage/security/_snippets/cluster-comparison.md index 0db6d4a263..88d4cb3fa7 100644 --- a/deploy-manage/security/_snippets/cluster-comparison.md +++ b/deploy-manage/security/_snippets/cluster-comparison.md @@ -12,7 +12,7 @@ Select your deployment type below to see what's available and how implementation ::::{tab-set} :group: deployment-type -:::{tab-item} {{ech}} +:::{tab-item} ECH :sync: cloud-hosted | Category | Security feature | Status | Notes | @@ -86,8 +86,8 @@ Select your deployment type below to see what's available and how implementation | Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Configurable | [Initial security setup](/deploy-manage/security/self-setup.md) | -| | TLS (Transport Layer) | Configurable | [Initial security setup](/deploy-manage/security/self-setup.md) | +| **Communication** | TLS (HTTP layer) | Configurable | Can be automatically or manually configured. See [Initial security setup](/deploy-manage/security/self-setup.md) | +| | TLS (Transport layer) | Configurable | Can be automatically or manually configured. See [Initial security setup](/deploy-manage/security/self-setup.md) | | **Network** | IP traffic filtering | Configurable | [Configure IP-based access restrictions](/deploy-manage/security/ip-filtering-basic.md) | | | Private link | N/A | | | | Kubernetes network policies | N/A | | From 8c879405f8182b866dfe21013d0dd185114a89e2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 23:23:36 +0200 Subject: [PATCH 34/42] working on reviews --- deploy-manage/security/set-up-basic-security-plus-https.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 6fe30c8b0f..7af81585b7 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -13,7 +13,9 @@ mapped_pages: Enabling TLS on the HTTP layer, widely known as HTTPS, ensures that all client communications with your cluster are encrypted, adding a critical layer of security. -This document focuses on the **manual configuration** of HTTPS for {{es}} and {{kib}}. Use this approach if you want to provide your own TLS certificates, generate them with Elastic’s tools, or have full control over the configuration. Alternatively, {{es}} can [automatically generate and configure HTTPS certificates](./self-auto-setup.md). +This document focuses on the **manual configuration** of HTTPS for {{es}} and {{kib}}. Use this approach if you want to provide your own TLS certificates, generate them with Elastic’s tools, or have full control over the configuration. + +Note that HTTPS configuration for {{kib}} is always manual. Alternatively, {{es}} supports [automatic HTTPS setup](./self-auto-setup.md), which can simplify the process if full customization isn't required. In this guide, you will learn how to: From b9c737309e3784e217c3d6ffe1f18965ff12b9b6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 23:24:59 +0200 Subject: [PATCH 35/42] working on reviews --- deploy-manage/security/_snippets/kibana-client-https-setup.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/deploy-manage/security/_snippets/kibana-client-https-setup.md b/deploy-manage/security/_snippets/kibana-client-https-setup.md index cd11d2b906..82b69055a2 100644 --- a/deploy-manage/security/_snippets/kibana-client-https-setup.md +++ b/deploy-manage/security/_snippets/kibana-client-https-setup.md @@ -22,9 +22,7 @@ If you obtained the {{es}} certificates using a different method, you must provi :::::{admonition} Connect to a secure monitoring cluster If the Elastic monitoring features are enabled and you configured a separate {{es}} monitoring cluster, you can also configure {{kib}} to connect to the monitoring cluster through HTTPS. The steps are the same, but each setting is prefixed by `monitoring.ui`. For example, `monitoring.ui.elasticsearch.hosts` and `monitoring.ui.elasticsearch.ssl.certificateAuthorities`. -::::{note} If the monitoring cluster uses certificates signed by a different CA than the main cluster, you must provide a separate `elasticsearch-ca.pem` file that corresponds to the monitoring cluster's CA. -:::: ::::: From 9108fb229942211067c45140a3b0a624cc92240a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 23:38:22 +0200 Subject: [PATCH 36/42] working on reviews --- deploy-manage/security/secure-cluster-communications.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index e2bcbe976b..bc38ae8558 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -78,6 +78,8 @@ The way that transport layer security is managed depends on your deployment type :::{tab-item} Self-managed :sync: self {{es}} transport security can be [automatically configured](self-auto-setup.md), or manually set up by following the steps in [](set-up-basic-security.md). + +For additional TLS configuration options, refer to [](./self-tls.md). ::: :::: @@ -133,6 +135,8 @@ The automatic configuration does not enable TLS on the {{kib}} HTTP endpoint. To ::: For environments with stricter security requirements, refer to [Mutual TLS authentication between {{kib}} and {{es}}](./kibana-es-mutual-tls.md). + +For additional TLS configuration options, refer to [](./self-tls.md). :::: ::::: From 3b7e16f9d2c522f9059aa0b8d27a9b52fa34c427 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 23:50:56 +0200 Subject: [PATCH 37/42] applies_to and substitutions fixed --- .../enabling-cipher-suites-for-stronger-encryption.md | 3 +++ deploy-manage/security/httprest-clients-security.md | 6 ++++++ deploy-manage/security/limitations.md | 7 +++++++ deploy-manage/security/secure-clients-integrations.md | 6 ++++++ deploy-manage/security/self-auto-setup.md | 4 ++++ .../security/supported-ssltls-versions-by-jdk-version.md | 3 +++ 6 files changed, 29 insertions(+) diff --git a/deploy-manage/security/enabling-cipher-suites-for-stronger-encryption.md b/deploy-manage/security/enabling-cipher-suites-for-stronger-encryption.md index 6a25557775..3fbca5c63c 100644 --- a/deploy-manage/security/enabling-cipher-suites-for-stronger-encryption.md +++ b/deploy-manage/security/enabling-cipher-suites-for-stronger-encryption.md @@ -1,6 +1,9 @@ --- mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/ciphers.html +applies_to: + deployment: + self: all --- # Enabling cipher suites for stronger encryption [ciphers] diff --git a/deploy-manage/security/httprest-clients-security.md b/deploy-manage/security/httprest-clients-security.md index 9d472fe84e..5cd346bff8 100644 --- a/deploy-manage/security/httprest-clients-security.md +++ b/deploy-manage/security/httprest-clients-security.md @@ -1,6 +1,12 @@ --- mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/http-clients.html +applies_to: + deployment: + self: all + eck: all + ess: all + ece: all --- # Securing HTTP client applications diff --git a/deploy-manage/security/limitations.md b/deploy-manage/security/limitations.md index 451c03f1da..d9ace823bf 100644 --- a/deploy-manage/security/limitations.md +++ b/deploy-manage/security/limitations.md @@ -2,6 +2,13 @@ mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-limitations.html navigation_title: Limitations +applies_to: + deployment: + self: all + eck: all + ess: all + ece: all + --- # Security limitations [security-limitations] diff --git a/deploy-manage/security/secure-clients-integrations.md b/deploy-manage/security/secure-clients-integrations.md index b8054cf1f0..82819b6179 100644 --- a/deploy-manage/security/secure-clients-integrations.md +++ b/deploy-manage/security/secure-clients-integrations.md @@ -1,6 +1,12 @@ --- mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-clients-integrations.html +applies_to: + deployment: + self: all + eck: all + ess: all + ece: all --- # Secure other {{stack}} components diff --git a/deploy-manage/security/self-auto-setup.md b/deploy-manage/security/self-auto-setup.md index be7a4c656b..aae7064a55 100644 --- a/deploy-manage/security/self-auto-setup.md +++ b/deploy-manage/security/self-auto-setup.md @@ -2,6 +2,10 @@ navigation_title: Automatic security setup applies_to: self: ga +sub: + es-conf: "/etc/elasticsearch" + slash: "/" + escape: "\\" mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-stack-security.html --- diff --git a/deploy-manage/security/supported-ssltls-versions-by-jdk-version.md b/deploy-manage/security/supported-ssltls-versions-by-jdk-version.md index 4f024d3d3b..4dab9cd0cb 100644 --- a/deploy-manage/security/supported-ssltls-versions-by-jdk-version.md +++ b/deploy-manage/security/supported-ssltls-versions-by-jdk-version.md @@ -1,6 +1,9 @@ --- mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/jdk-tls-versions.html +applies_to: + deployment: + self: all --- # Supported SSL/TLS versions by JDK version [jdk-tls-versions] From 8044f4794e06a11af591e59ca21940453095ec3e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 23:56:31 +0200 Subject: [PATCH 38/42] Update deploy-manage/security/set-up-basic-security-plus-https.md Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com> --- deploy-manage/security/set-up-basic-security-plus-https.md | 1 - 1 file changed, 1 deletion(-) diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 7af81585b7..5a81207476 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -136,7 +136,6 @@ Once TLS is enabled, all client communications with the cluster will be encrypte :::{include} /deploy-manage/security/_snippets/kibana-client-https-setup.md ::: -**Next**: [Encrypt traffic between your browser and {{kib}}](#encrypt-kibana-browser) ### Encrypt traffic between your browser and {{kib}} [encrypt-kibana-browser] From 6bacccba46501a72ab271034eaf00854876b4f1a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Tue, 1 Apr 2025 23:57:37 +0200 Subject: [PATCH 39/42] Update deploy-manage/security/set-up-basic-security-plus-https.md Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com> --- deploy-manage/security/set-up-basic-security-plus-https.md | 1 - 1 file changed, 1 deletion(-) diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 5a81207476..93680e2b62 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -122,7 +122,6 @@ Once TLS is enabled, all client communications with the cluster will be encrypte 4. Start {{es}}. -**Next**: [Encrypt HTTP client communications for {{kib}}](#encrypt-kibana-http) ## Encrypt HTTP communications for {{kib}} [encrypt-kibana-http] From dc296f1cbc9bb5e3c5a12824b286bcca0725de2a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 2 Apr 2025 09:51:21 +0200 Subject: [PATCH 40/42] install stack demo secure moved to raw content --- deploy-manage/toc.yml | 1 - .../stack-docs/elastic-stack}/install-stack-demo-secure.md | 0 2 files changed, 1 deletion(-) rename {deploy-manage/security => raw-migrated-files/stack-docs/elastic-stack}/install-stack-demo-secure.md (100%) diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 8b8d6bca38..d24e9732fb 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -463,7 +463,6 @@ toc: - file: security/set-up-basic-security.md - file: security/set-up-basic-security-plus-https.md - file: security/using-kibana-with-security.md - - file: security/install-stack-demo-secure.md - file: security/secure-cluster-communications.md children: - file: security/self-tls.md diff --git a/deploy-manage/security/install-stack-demo-secure.md b/raw-migrated-files/stack-docs/elastic-stack/install-stack-demo-secure.md similarity index 100% rename from deploy-manage/security/install-stack-demo-secure.md rename to raw-migrated-files/stack-docs/elastic-stack/install-stack-demo-secure.md From 9a69becaadec746523b1b0d4d70bd3bc2b3aa4fd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 2 Apr 2025 09:54:07 +0200 Subject: [PATCH 41/42] removed empty line --- deploy-manage/security/limitations.md | 1 - 1 file changed, 1 deletion(-) diff --git a/deploy-manage/security/limitations.md b/deploy-manage/security/limitations.md index d9ace823bf..0a3cf857ed 100644 --- a/deploy-manage/security/limitations.md +++ b/deploy-manage/security/limitations.md @@ -8,7 +8,6 @@ applies_to: eck: all ess: all ece: all - --- # Security limitations [security-limitations] From 4a31e1d67abd9bdacff474b6c1f7f9eadfded9e8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?= <25320357+eedugon@users.noreply.github.com> Date: Wed, 2 Apr 2025 10:22:32 +0200 Subject: [PATCH 42/42] final refinement --- deploy-manage/security/self-setup.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index cb9598ce0f..d12f888c4f 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -53,6 +53,6 @@ For additional TLS configuration options, refer to [](./self-tls.md). Refer to [](./using-kibana-with-security.md) to learn how to implement the following security best practices for {{kib}}: -* Set an encryption key for clients sessions +* Set an encryption key for client sessions * Use secure HTTP headers -* Require a Content Security Policy \ No newline at end of file +* Require a Content Security Policy (CSP) \ No newline at end of file