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..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-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/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 44a0534f0b..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-http-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-http-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-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/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 4cb6ba81a4..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-http-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 11fd37da76..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-http-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-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/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 a90c7c5e60..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-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/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/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/_snippets/auto-security-config.md b/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md index 6f9c39948d..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,12 +1,12 @@ -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/security-certificates-keys.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/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/deploy/self-managed/access-kibana.md b/deploy-manage/deploy/self-managed/access-kibana.md index f53b4afd3b..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-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/set-up-basic-security-plus-https.md#encrypt-kibana-http) and access it over HTTPS. ::: 2. Log on to your account. 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/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 ::: 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 6f1bf34209..945596209b 100644 --- a/deploy-manage/security.md +++ b/deploy-manage/security.md @@ -77,6 +77,11 @@ deployment: You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: +### Initial security setup + +:::{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..d4751d1f58 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. +* [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/cluster-comparison.md b/deploy-manage/security/_snippets/cluster-comparison.md index 1593c14cab..88d4cb3fa7 100644 --- a/deploy-manage/security/_snippets/cluster-comparison.md +++ b/deploy-manage/security/_snippets/cluster-comparison.md @@ -2,9 +2,9 @@ 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 | Select your deployment type below to see what's available and how implementation responsibilities are distributed: @@ -12,75 +12,89 @@ 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 | Description | +| Category | Security feature | Status | Notes | |------------------|------------|--------------|-------------| -| **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-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) | +| | Secure settings | Configurable | Automatically protected by Elastic | +| | Saved object encryption | Fully managed | Automatically encrypted by Elastic | +| **User session** | {{kib}} 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 | +| Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| -| **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 | 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 | -| **User Session** | Kibana Sessions | 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 | | +| **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** | {{kib}} sessions | Fully managed | Automatically configured by Elastic | ::: -:::{tab-item} ECE/ECK -:sync: ece-eck +:::{tab-item} ECE +:sync: ece -| Category| Security feature | Status | Description | +| Category| Security feature | Status | Notes | |------------------|------------|--------------|-------------| -| **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 | -| | Private link | N/A | X | -| | Static IPs | N/A | X | -| **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 | +| **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 | | +| **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** | {{kib}} sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | ::: +:::{tab-item} ECK +:sync: eck + +| Category| Security feature | Status | Notes | +|------------------|------------|--------------|-------------| +| **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) | +| **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** | {{kib}} sessions | Configurable | [Customize session parameters](/deploy-manage/security/kibana-session-management.md) | + +::: + + :::{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 | -| | Private link | N/A | X | -| | Static IPs | N/A | X | -| **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 | +| **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 | | +| **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** | {{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/_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/_snippets/enable-security.md b/deploy-manage/security/_snippets/enable-security.md new file mode 100644 index 0000000000..8b83bd1f4b --- /dev/null +++ b/deploy-manage/security/_snippets/enable-security.md @@ -0,0 +1,9 @@ +{{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. + +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). + +:::{tip} +If you want to use your own TLS certificates, then you should manually configure security. +::: + +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/_snippets/kibana-client-https-setup.md b/deploy-manage/security/_snippets/kibana-client-https-setup.md new file mode 100644 index 0000000000..82b69055a2 --- /dev/null +++ b/deploy-manage/security/_snippets/kibana-client-https-setup.md @@ -0,0 +1,28 @@ +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. + + ```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.ui`. For example, `monitoring.ui.elasticsearch.hosts` and `monitoring.ui.elasticsearch.ssl.certificateAuthorities`. + +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 new file mode 100644 index 0000000000..cf8d06282b --- /dev/null +++ b/deploy-manage/security/_snippets/kibana-https-setup.md @@ -0,0 +1,46 @@ +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. + +::::{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 CSR 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. 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 + 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 HTTPS for incoming connections. + + ```yaml + server.ssl.enabled: true + ``` + +6. Start {{kib}}. + + After making these changes, you must always access {{kib}} through HTTPS. For example, `https://.com:5601`. diff --git a/deploy-manage/security/data-security.md b/deploy-manage/security/data-security.md index 1e199e9ed2..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](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}} 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 new file mode 100644 index 0000000000..cf0ff4619f --- /dev/null +++ b/deploy-manage/security/eck-tls.md @@ -0,0 +1,29 @@ +--- +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. + +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 + +:::{include} ./_snippets/eck-transport.md +::: + +## {{es}} and {{kib}} HTTP configuration + +:::{include} ./_snippets/eck-http.md +::: + +## Certificates lifecycle + +:::{include} ./_snippets/eck-lifecycle.md +::: 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 5764ac124f..5cd346bff8 100644 --- a/deploy-manage/security/httprest-clients-security.md +++ b/deploy-manage/security/httprest-clients-security.md @@ -1,9 +1,25 @@ --- 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 --- -# 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 +33,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 +60,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 +79,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/k8s-https-settings.md b/deploy-manage/security/k8s-https-settings.md new file mode 100644 index 0000000000..5144701122 --- /dev/null +++ b/deploy-manage/security/k8s-https-settings.md @@ -0,0 +1,252 @@ +--- +applies_to: + deployment: + eck: +mapped_urls: + - 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/cloud-on-k8s/current/k8s-kibana-http-configuration.html +--- + +# Manage HTTP certificates on ECK + +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 {{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 +> kubectl get secret | grep es-http +hulk-es-http-ca-internal Opaque 2 28m +hulk-es-http-certs-internal Opaque 2 28m +hulk-es-http-certs-public Opaque 1 28m +``` + +The public certificate is stored in a secret named `-[es|kb|apm|ent|agent]-http-certs-public`. + +```sh +> kubectl get secret hulk-es-http-certs-public -o go-template='{{index .data "tls.crt" | base64decode }}' +-----BEGIN CERTIFICATE----- +MIIDQDCCAiigAwIBAgIQHC4O/RWX15a3/P3upsm3djANBgkqhkiG9w0BAQsFADA6 +... +QLYL4zLEby3vRxq65+xofVBJAaM= +-----END CERTIFICATE----- +``` + +### Custom HTTP certificate [k8s-custom-http-certificate] + +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](./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] + +This example illustrates how to create your own self-signed certificate for the [quickstart Elasticsearch cluster](/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md) using the OpenSSL command line utility. Note the subject alternative name (SAN) entry for `quickstart-es-http.default.svc`. + +```sh +$ openssl req -x509 -sha256 -nodes -newkey rsa:4096 -days 365 -subj "/CN=quickstart-es-http" -addext "subjectAltName=DNS:quickstart-es-http.default.svc" -keyout tls.key -out tls.crt +$ kubectl create secret generic quickstart-es-cert --from-file=ca.crt=tls.crt --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key +``` + +#### Custom self-signed certificate using cert-manager [k8s_custom_self_signed_certificate_using_cert_manager] + +This example illustrates how to issue a self-signed certificate for the [quickstart Elasticsearch cluster](/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md) using a [cert-manager](https://cert-manager.io) self-signed issuer. + +```yaml +--- +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: selfsigned-issuer +spec: + selfSigned: {} +--- +apiVersion: cert-manager.io/v1 +kind: Certificate +metadata: + name: quickstart-es-cert +spec: + isCA: true + dnsNames: + - quickstart-es-http + - quickstart-es-http.default.svc + - quickstart-es-http.default.svc.cluster.local + issuerRef: + kind: Issuer + name: selfsigned-issuer + secretName: quickstart-es-cert + subject: + organizations: + - quickstart +``` + +Here is how to issue multiple Elasticsearch certificates from a single self-signed CA. This is useful for example for [Remote clusters](/deploy-manage/remote-clusters/eck-remote-clusters.md) which need to trust each other’s CA, in order to avoid mounting N CAs when a cluster is connected to N other clusters. + +```yaml +apiVersion: cert-manager.io/v1 +kind: ClusterIssuer +metadata: + name: selfsigned-issuer +spec: + selfSigned: {} +--- +apiVersion: cert-manager.io/v1 +kind: Certificate +metadata: + name: selfsigned-ca +spec: + isCA: true + commonName: selfsigned-ca + secretName: root-ca-secret + privateKey: + algorithm: ECDSA + size: 256 + issuerRef: + kind: ClusterIssuer + name: selfsigned-issuer +--- +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: ca-issuer +spec: + ca: + secretName: root-ca-secret +--- +apiVersion: cert-manager.io/v1 +kind: Certificate +metadata: + name: quickstart-es-cert +spec: + isCA: false + dnsNames: + - quickstart-es-http + - quickstart-es-http.default.svc + - quickstart-es-http.default.svc.cluster.local + subject: + organizations: + - quickstart + privateKey: + algorithm: RSA + encoding: PKCS1 + size: 2048 + issuerRef: + kind: Issuer + name: ca-issuer + secretName: quickstart-es-cert +``` + +### Reserve static IP and custom domain [k8s-static-ip-custom-domain] + +To use a custom domain with a self-signed certificate: + +```yaml +spec: + http: + service: + spec: + type: LoadBalancer + tls: + selfSignedCertificate: + subjectAltNames: + - ip: 160.46.176.15 + - dns: hulk.example.com +``` + +### 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. + +Create a Kubernetes secret with: + +* `ca.crt`: CA certificate (optional if `tls.crt` was issued by a well-known CA). +* `tls.crt`: The certificate. +* `tls.key`: The private key to the first certificate in the certificate chain. + +::::{warning} +If your `tls.crt` is signed by an intermediate CA you may need both the Root CA and the intermediate CA combined within the `ca.crt` file depending on whether the Root CA is globally trusted. +:::: + +```sh +kubectl create secret generic my-cert --from-file=ca.crt --from-file=tls.crt --from-file=tls.key +``` + +Alternatively you can also bring your own CA certificate including a private key and let ECK issue certificates with it. Any certificate SANs you have configured as decribed in [Reserve static IP and custom domain](#k8s-static-ip-custom-domain) will also be respected when issuing certificates with this CA certificate. + +Create a Kubernetes secret with: + +* `ca.crt`: CA certificate. +* `ca.key`: The private key to the CA certificate. + +```sh +kubectl create secret generic my-cert --from-file=ca.crt --from-file=ca.key +``` + +In both cases, you have to reference the secret name in the `http.tls.certificate` section of the resource manifest. + +```yaml +spec: + http: + tls: + certificate: + secretName: my-cert +``` + +## 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] + +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 +kind: Kibana +metadata: + name: kibana-sample +spec: + version: 8.16.1 + count: 1 + elasticsearchRef: + name: "elasticsearch-sample" + http: + service: + spec: + type: LoadBalancer # default is ClusterIP + tls: + selfSignedCertificate: + subjectAltNames: + - ip: 1.2.3.4 + - dns: kibana.example.com +``` + + +### 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) for more information. + +## Disable TLS [k8s-disable-tls] + +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 +spec: + http: + tls: + selfSignedCertificate: + disabled: true +``` diff --git a/deploy-manage/security/k8s-transport-settings.md b/deploy-manage/security/k8s-transport-settings.md index 621b028993..ec22d23ad8 100644 --- a/deploy-manage/security/k8s-transport-settings.md +++ b/deploy-manage/security/k8s-transport-settings.md @@ -6,9 +6,9 @@ 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). +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/kibana-es-mutual-tls.md b/deploy-manage/security/kibana-es-mutual-tls.md new file mode 100644 index 0000000000..3ed3acda32 --- /dev/null +++ b/deploy-manage/security/kibana-es-mutual-tls.md @@ -0,0 +1,130 @@ +--- +navigation_title: Mutual authentication +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/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). +:::: + +## 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). + +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/limitations.md b/deploy-manage/security/limitations.md index 451c03f1da..0a3cf857ed 100644 --- a/deploy-manage/security/limitations.md +++ b/deploy-manage/security/limitations.md @@ -2,6 +2,12 @@ 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/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 a79552ddc3..0000000000 --- a/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md +++ /dev/null @@ -1,116 +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) - - -## 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-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/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 084f647bb4..bc38ae8558 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -1,93 +1,177 @@ --- -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 set up TLS certificates in your {{stack}} deployments. -$$$encrypt-internode-communication$$$ -$$$generate-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, 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. -# Manage TLS certificates +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). -This page explains how to secure communications between components in your {{stack}} deployment. +::::{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}}. -For {{ech}} and {{serverless-full}} deployments, communications security is fully managed by Elastic with no configuration required. +Keep this distinction in mind when configuring security settings. +:::: -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 [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 using the REST API. -## Communication channels overview +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}}. -Your {{stack}} deployment includes several distinct communication channels that must be secured to protect your data and infrastructure. +To ensure secure operation, it’s important to understand the communication channels and their specific security requirements. -| **Channel** | **Description** | **Security needs** | +| **Channel** | **Description** | **TLS requirements** | |-------------|-----------------|--------------------| -| [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) | +| [{{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 or REST clients and {{kib}} | TLS/SSL optional (but recommended) | +### Transport layer security [encrypt-internode-communication] -## Transport layer security +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. -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. +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: -- **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} +: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 + +:::{include} ./_snippets/eck-transport.md +::: + +::: + +:::{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). +::: + +:::: + +### HTTP layer security [encrypt-http-communication] -## HTTP layer security +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. -The HTTP layer secures client communication with your {{es}} cluster via its REST API, preventing unauthorized access and protecting 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} +: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) +* [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. +:::: -## {{kib}}-to-{{es}} communications +::::{tab-item} ECK +:sync: eck -{{kib}} connects to {{es}} as a client but requires special configuration as it performs operations on behalf of end users. +:::{include} ./_snippets/eck-http.md +::: + +:::: + +::::{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. + +:::{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). + +For additional TLS configuration options, refer to [](./self-tls.md). +:::: + +::::: -The way that {{kib}}-to-{{es}} communication security is managed depends on your deployment type: +## Certificates lifecycle [generate-certificates] -- **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). +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. -## Certificate management [generate-certificates] +::::{tab-set} +:group: deployments -Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. +:::{tab-item} ECH and Serverless +:sync: ech -The way that you manage certificates depends on your deployment type: +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 -- **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). +:::{include} ./_snippets/eck-lifecycle.md +::: + +::: -## Next steps +:::{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. +::: -- 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-http-communications.md b/deploy-manage/security/secure-http-communications.md deleted file mode 100644 index 5787ae2701..0000000000 --- a/deploy-manage/security/secure-http-communications.md +++ /dev/null @@ -1,475 +0,0 @@ ---- -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. - -% 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 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). - - -## 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] - -```{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). -::: - -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 -> kubectl get secret | grep es-http -hulk-es-http-ca-internal Opaque 2 28m -hulk-es-http-certs-internal Opaque 2 28m -hulk-es-http-certs-public Opaque 1 28m -``` - -The public certificate is stored in a secret named `-[es|kb|apm|ent|agent]-http-certs-public`. - -```sh -> kubectl get secret hulk-es-http-certs-public -o go-template='{{index .data "tls.crt" | base64decode }}' ------BEGIN CERTIFICATE----- -MIIDQDCCAiigAwIBAgIQHC4O/RWX15a3/P3upsm3djANBgkqhkiG9w0BAQsFADA6 -... -QLYL4zLEby3vRxq65+xofVBJAaM= ------END CERTIFICATE----- -``` - -### Custom HTTP certificate [k8s-custom-http-certificate] - -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. - -#### Custom self-signed certificate using OpenSSL [k8s_custom_self_signed_certificate_using_openssl] - -This example illustrates how to create your own self-signed certificate for the [quickstart Elasticsearch cluster](/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md) using the OpenSSL command line utility. Note the subject alternative name (SAN) entry for `quickstart-es-http.default.svc`. - -```sh -$ openssl req -x509 -sha256 -nodes -newkey rsa:4096 -days 365 -subj "/CN=quickstart-es-http" -addext "subjectAltName=DNS:quickstart-es-http.default.svc" -keyout tls.key -out tls.crt -$ kubectl create secret generic quickstart-es-cert --from-file=ca.crt=tls.crt --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key -``` - -#### Custom self-signed certificate using cert-manager [k8s_custom_self_signed_certificate_using_cert_manager] - -This example illustrates how to issue a self-signed certificate for the [quickstart Elasticsearch cluster](/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md) using a [cert-manager](https://cert-manager.io) self-signed issuer. - -```yaml ---- -apiVersion: cert-manager.io/v1 -kind: Issuer -metadata: - name: selfsigned-issuer -spec: - selfSigned: {} ---- -apiVersion: cert-manager.io/v1 -kind: Certificate -metadata: - name: quickstart-es-cert -spec: - isCA: true - dnsNames: - - quickstart-es-http - - quickstart-es-http.default.svc - - quickstart-es-http.default.svc.cluster.local - issuerRef: - kind: Issuer - name: selfsigned-issuer - secretName: quickstart-es-cert - subject: - organizations: - - quickstart -``` - -Here is how to issue multiple Elasticsearch certificates from a single self-signed CA. This is useful for example for [Remote clusters](/deploy-manage/remote-clusters/eck-remote-clusters.md) which need to trust each other’s CA, in order to avoid mounting N CAs when a cluster is connected to N other clusters. - -```yaml -apiVersion: cert-manager.io/v1 -kind: ClusterIssuer -metadata: - name: selfsigned-issuer -spec: - selfSigned: {} ---- -apiVersion: cert-manager.io/v1 -kind: Certificate -metadata: - name: selfsigned-ca -spec: - isCA: true - commonName: selfsigned-ca - secretName: root-ca-secret - privateKey: - algorithm: ECDSA - size: 256 - issuerRef: - kind: ClusterIssuer - name: selfsigned-issuer ---- -apiVersion: cert-manager.io/v1 -kind: Issuer -metadata: - name: ca-issuer -spec: - ca: - secretName: root-ca-secret ---- -apiVersion: cert-manager.io/v1 -kind: Certificate -metadata: - name: quickstart-es-cert -spec: - isCA: false - dnsNames: - - quickstart-es-http - - quickstart-es-http.default.svc - - quickstart-es-http.default.svc.cluster.local - subject: - organizations: - - quickstart - privateKey: - algorithm: RSA - encoding: PKCS1 - size: 2048 - issuerRef: - kind: Issuer - name: ca-issuer - secretName: quickstart-es-cert -``` - -### Reserve static IP and custom domain [k8s-static-ip-custom-domain] - -To use a custom domain with a self-signed certificate: - -```yaml -spec: - http: - service: - spec: - type: LoadBalancer - tls: - selfSignedCertificate: - subjectAltNames: - - ip: 160.46.176.15 - - dns: hulk.example.com -``` - -### Setup 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. - -Create a Kubernetes secret with: - -* `ca.crt`: CA certificate (optional if `tls.crt` was issued by a well-known CA). -* `tls.crt`: The certificate. -* `tls.key`: The private key to the first certificate in the certificate chain. - -::::{warning} -If your `tls.crt` is signed by an intermediate CA you may need both the Root CA and the intermediate CA combined within the `ca.crt` file depending on whether the Root CA is globally trusted. -:::: - -```sh -kubectl create secret generic my-cert --from-file=ca.crt --from-file=tls.crt --from-file=tls.key -``` - -Alternatively you can also bring your own CA certificate including a private key and let ECK issue certificates with it. Any certificate SANs you have configured as decribed in [Reserve static IP and custom domain](#k8s-static-ip-custom-domain) will also be respected when issuing certificates with this CA certificate. - -Create a Kubernetes secret with: - -* `ca.crt`: CA certificate. -* `ca.key`: The private key to the CA certificate. - -```sh -kubectl create secret generic my-cert --from-file=ca.crt --from-file=ca.key -``` - -In both cases, you have to reference the secret name in the `http.tls.certificate` section of the resource manifest. - -```yaml -spec: - http: - tls: - certificate: - secretName: my-cert -``` - -### Disable TLS [k8s-disable-tls] - -You can explicitly disable TLS for Kibana, APM Server, and the HTTP layer of Elasticsearch. - -```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] - -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. - -```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: - service: - spec: - type: LoadBalancer # default is ClusterIP - tls: - selfSignedCertificate: - subjectAltNames: - - ip: 1.2.3.4 - - dns: kibana.example.com -``` - - -#### 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). - -#### Disable TLS [k8s-kibana-http-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. - -```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/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index 13926288d2..39fd4d9382 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -9,7 +9,7 @@ applies_to: # 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 ::: @@ -25,6 +25,11 @@ 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: +## Initial security setup [manually-configure-security] + +:::{include} /deploy-manage/security/_snippets/enable-security.md +::: + ## Communication and network security :::{include} /deploy-manage/security/_snippets/cluster-communication-network.md @@ -45,10 +50,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: @@ -66,4 +67,4 @@ 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 +::: diff --git a/deploy-manage/security/security-certificates-keys.md b/deploy-manage/security/security-certificates-keys.md deleted file mode 100644 index d4dbae761d..0000000000 --- a/deploy-manage/security/security-certificates-keys.md +++ /dev/null @@ -1,244 +0,0 @@ ---- -applies_to: - self: ga -mapped_pages: - - https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-stack-security.html ---- - -# Self-managed certificates and keys [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/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. -:::: - - - -## Prerequisites [_prerequisites_12] - -* [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. - - -## Start {{es}} and enroll {{kib}} with security enabled [stack-start-with-security] - -1. From the installation directory, start {{es}}. - - ```shell - bin/elasticsearch - ``` - - The command prints the `elastic` user password and an enrollment token for {{kib}}. - -2. Copy the generated `elastic` password and enrollment token. These credentials are only shown when you start {{es}} for the first time. - - ::::{note} - 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. To generate new enrollment tokens for {{kib}} or {{es}} nodes, run the [`elasticsearch-create-enrollment-token`](elasticsearch://reference/elasticsearch/command-line-tools/create-enrollment-token.md) tool. These tools are available in the {{es}} `bin` directory. - - :::: - - - We recommend storing the `elastic` password as an environment variable in your shell. Example: - - ```sh - export ELASTIC_PASSWORD="your_password" - ``` - -3. (Optional) Open a new terminal and verify that you can connect to your {{es}} cluster by making an authenticated call. - - ```shell - curl --cacert config/certs/http_ca.crt -u elastic:$ELASTIC_PASSWORD https://localhost:9200 - ``` - -4. From the directory where you installed {{kib}}, start {{kib}}. - - ```shell - bin/kibana - ``` - -5. Enroll {{kib}} using either interactive or detached mode. - - * **Interactive mode** (browser) - - 1. In your terminal, click the generated link to open {{kib}} in your browser. - 2. In your browser, paste the enrollment token that you copied and click the button to connect your {{kib}} instance with {{es}}. - - ::::{note} - {{kib}} won’t enter interactive mode if it detects existing credentials for {{es}} (`elasticsearch.username` and `elasticsearch.password`) or an existing URL for `elasticsearch.hosts`. - - :::: - - * **Detached mode** (non-browser) - - Run the `kibana-setup` tool and pass the generated enrollment token with the `--enrollment-token` parameter. - - ```sh - 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. - - -## 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. - - -### 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= -``` - - -### 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}}. - - -## What’s next? [_whats_next] - -Congratulations! You’ve successfully started the {{stack}} with security enabled. {{es}} and {{kib}} are secured with TLS on the HTTP layer, and internode communication is encrypted. If you want to enable HTTPS for web traffic, you can [encrypt traffic between your browser and {{kib}}](set-up-basic-security-plus-https.md#encrypt-kibana-browser). - - -## 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. - - -## 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](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. - -::::{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/self-auto-setup.md b/deploy-manage/security/self-auto-setup.md new file mode 100644 index 0000000000..aae7064a55 --- /dev/null +++ b/deploy-manage/security/self-auto-setup.md @@ -0,0 +1,157 @@ +--- +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 +--- + +% Scope: Automatic setup +% Original title: Start the Elastic Stack with security enabled automatically +# Automatic security setup [configuring-stack-security] + +:::{include} /deploy-manage/deploy/self-managed/_snippets/auto-security-config.md +::: + +## Prerequisites [_prerequisites_12] + +* [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] + +1. From the installation directory, start {{es}}. + + ```shell + bin/elasticsearch + ``` + + The command prints the `elastic` user password and an enrollment token for {{kib}}. + +2. Copy the generated `elastic` password and enrollment token. These credentials are only shown when you start {{es}} for the first time. + + ::::{note} + 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. To generate new enrollment tokens for {{kib}} or {{es}} nodes, run the [`elasticsearch-create-enrollment-token`](elasticsearch://reference/elasticsearch/command-line-tools/create-enrollment-token.md) tool. These tools are available in the {{es}} `bin` directory. + + :::: + + + We recommend storing the `elastic` password as an environment variable in your shell. Example: + + ```sh + export ELASTIC_PASSWORD="your_password" + ``` + +3. (Optional) Open a new terminal and verify that you can connect to your {{es}} cluster by making an authenticated call. + + ```shell + curl --cacert config/certs/http_ca.crt -u elastic:$ELASTIC_PASSWORD https://localhost:9200 + ``` + +4. From the directory where you installed {{kib}}, start {{kib}}. + + ```shell + bin/kibana + ``` + +5. Enroll {{kib}} using either interactive or detached mode. + + * **Interactive mode** (browser) + + 1. In your terminal, click the generated link to open {{kib}} in your browser. + 2. In your browser, paste the enrollment token that you copied and click the button to connect your {{kib}} instance with {{es}}. + + ::::{note} + {{kib}} won’t enter interactive mode if it detects existing credentials for {{es}} (`elasticsearch.username` and `elasticsearch.password`) or an existing URL for `elasticsearch.hosts`. + + :::: + + * **Detached mode** (non-browser) + + Run the `kibana-setup` tool and pass the generated enrollment token with the `--enrollment-token` parameter. + + ```sh + bin/kibana-setup --enrollment-token + ``` + +## Enroll additional nodes in your cluster [stack-enroll-nodes] + +:::{include} /deploy-manage/deploy/self-managed/_snippets/enroll-nodes.md +::: + +## Connect clients to {{es}} [_connect_clients_to_es_5] + +:::{include} /deploy-manage/deploy/self-managed/_snippets/connect-clients.md +::: + +### Use the CA fingerprint [_use_the_ca_fingerprint_5] + +:::{include} /deploy-manage/deploy/self-managed/_snippets/ca-fingerprint.md +::: + +### Use the CA certificate [_use_the_ca_certificate_5] + +:::{include} /deploy-manage/deploy/self-managed/_snippets/ca-cert.md +::: + +## What’s next? [_whats_next] + +Congratulations! You’ve successfully started the {{stack}} with security enabled. {{es}} and {{kib}} are secured with TLS on the HTTP layer, and internode communication is encrypted. If you want to enable HTTPS for web traffic, you can [encrypt traffic between your browser and {{kib}}](set-up-basic-security-plus-https.md#encrypt-kibana-browser). + + +## Security certificates and keys [stack-security-certificates] + +:::{include} /deploy-manage/deploy/self-managed/_snippets/security-files.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/self-setup.md b/deploy-manage/security/self-setup.md new file mode 100644 index 0000000000..d12f888c4f --- /dev/null +++ b/deploy-manage/security/self-setup.md @@ -0,0 +1,58 @@ +--- +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 +# 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. + +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] + +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: + +* 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}} + +This automatic setup is the quickest way to get started and ensures your cluster is protected by default. + +::::{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). +:::: + +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] + +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. **[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. **[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. **[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. + +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 client sessions +* Use secure HTTP headers +* Require a Content Security Policy (CSP) \ No newline at end of file diff --git a/deploy-manage/security/self-tls.md b/deploy-manage/security/self-tls.md new file mode 100644 index 0000000000..0690eac654 --- /dev/null +++ b/deploy-manage/security/self-tls.md @@ -0,0 +1,32 @@ +--- +navigation_title: "Self-managed" +applies_to: + deployment: + self: ga +--- + +% scope: TLS encryption tasks and settings after the initial setup is completed. +# Manage TLS encryption in self-managed deployments + +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. + +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: + +* [](./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. + +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 + +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 259c1fc75d..93680e2b62 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: "Set up HTTPS" applies_to: deployment: self: ga @@ -7,42 +7,61 @@ 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 HTTPS [security-basic-setup-https] +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. -# Set up basic security plus HTTPS [security-basic-setup-https] +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. -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. +In this guide, you will learn how to: -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. +* [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). -::::{admonition} Signing certificates -:name: signing-certificates +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}}. -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. +::::{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. +:::: -#### Sign your own certificates [_sign_your_own_certificates] +::::{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). -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. +* 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. +:::: -#### 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. +## Prerequisites [basic-setup-https-prerequisites] -:::: +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. -## Prerequisites [basic-setup-https-prerequisites] +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 +``` -Complete all steps in [Set up basic security for the Elastic Stack](secure-cluster-communications.md). +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}} -## Encrypt HTTP client communications for {{es}} [encrypt-http-communication] +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 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 @@ -59,7 +78,7 @@ Complete all steps in [Set up basic security for the Elastic Stack](secure-clust 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. @@ -94,7 +113,7 @@ Complete all steps in [Set up basic security for the Elastic Stack](secure-clust 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 @@ -103,373 +122,30 @@ Complete all steps in [Set up basic security for the Elastic Stack](secure-clust 4. Start {{es}}. -**Next**: [Encrypt HTTP client communications for {{kib}}](#encrypt-kibana-http) +## Encrypt HTTP communications for {{kib}} [encrypt-kibana-http] -## Encrypt HTTP client 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}}. +* **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. -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. -:::: - - -::::: +:::{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`. -:::: - - -**Next**: [Configure {{beats}} security](#configure-beats-security) - - - -## 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 | +:::{include} /deploy-manage/security/_snippets/kibana-https-setup.md +::: +## What’s next? [whats-next] -**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. +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. -9. Log in to {{kib}}, open the main menu, and click **Stack Monitoring**. +For other tasks related with TLS encryption in self-managed deployments, refer to [](./self-tls.md). - 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. +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 53ed3b8424..97c3aafcdb 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: "Set up transport TLS" applies_to: deployment: self: ga @@ -7,31 +7,24 @@ 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 transport TLS [security-basic-setup] +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. -# Set up basic security [security-basic-setup] +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. - -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. +::::{note} +For other deployment types, such as {{ech}}, {{ece}}, or {{eck}}, refer to [](./secure-cluster-communications.md). :::: +In this guide, you will learn how to: -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. - -Configuring TLS between nodes is the basic security setup to prevent unauthorized nodes from accessing to your cluster. - -::::{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 [](secure-http-communications.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). +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] @@ -130,11 +123,10 @@ 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). -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 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/set-up-minimal-security.md b/deploy-manage/security/set-up-minimal-security.md index 856bebdb1e..b4a0f122d3 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: "Minimal security setup" applies_to: deployment: self: ga @@ -7,22 +7,20 @@ mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-minimal-setup.html --- - - -# Set up minimal security [security-minimal-setup] - +% 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] ::::{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](./self-auto-setup.md) when you start {{es}} for the first time. -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. +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 +45,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 +55,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 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. ```shell @@ -89,6 +84,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 +102,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,10 +129,8 @@ 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. - -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. - -[Set up basic security for the {{stack}}](secure-cluster-communications.md) to secure all internal communication between nodes in your cluster. +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. +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/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] 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 58c2b5d3ab..40623b936a 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -4,25 +4,23 @@ 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-roles$$$ - # 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. - -You can then log in to {{kib}} as the `elastic` user to create additional roles and users. - -::::{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}}. -:::: +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). -## 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. +::::{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,83 +30,15 @@ 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). -4. Restart {{kib}}. - - -## Create roles and users [security-create-roles] - -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. - :::: +3. Restart {{kib}}. - - 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] - -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 [](/deploy-manage/security/secure-http-communications.md#elasticsearch-mutual-tls) 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. - -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] +## Use secure HTTP headers [configuring-security-headers] 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" @@ -126,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. @@ -136,3 +66,17 @@ 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) +* [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). diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index a7b62bf02c..d24e9732fb 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -456,18 +456,28 @@ toc: - file: security/secure-your-eck-installation.md - file: security/secure-your-cluster-deployment.md children: + - file: security/self-setup.md + 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/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/self-tls.md children: - file: security/updating-certificates.md children: - file: security/same-ca.md - file: security/different-ca.md - - file: security/supported-ssltls-versions-by-jdk-version.md - - file: security/enabling-cipher-suites-for-stronger-encryption.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/traffic-filtering.md children: - file: security/ip-traffic-filtering.md @@ -501,13 +511,6 @@ 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/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 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: 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 99% rename from deploy-manage/security/install-stack-demo-secure.md rename to raw-migrated-files/stack-docs/elastic-stack/install-stack-demo-secure.md index c486865bb4..67999b82b3 100644 --- a/deploy-manage/security/install-stack-demo-secure.md +++ b/raw-migrated-files/stack-docs/elastic-stack/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. @@ -516,7 +517,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/redirects.yml b/redirects.yml index fd000d6b15..16734b847d 100644 --- a/redirects.yml +++ b/redirects.yml @@ -1,2 +1,5 @@ redirects: - 'deploy-manage/security/ece-traffic-filtering-through-the-api.md': 'deploy-manage/security/ec-traffic-filtering-through-the-api.md' \ No newline at end of file + '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'