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 31c4e89b30..7c30d10c59 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](k8s-kibana-http-configuration.md) +* [Manage HTTP settings](/deploy-manage/security/secure-http-communications.md#k8s-kibana-http-configuration) * [Use secure settings](k8s-kibana-secure-settings.md) * [Install {{kib}} plugins](k8s-kibana-plugins.md) diff --git a/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-http-configuration.md b/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-http-configuration.md deleted file mode 100644 index 9335203faf..0000000000 --- a/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-http-configuration.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -applies_to: - deployment: - eck: all -mapped_pages: - - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-kibana-http-configuration.html ---- - -# HTTP configuration [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}}. Check [Custom HTTP certificate](../../security/secure-http-communications.md). - - -## 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 -``` - - diff --git a/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md b/deploy-manage/deploy/cloud-on-k8s/kibana-configuration.md index 3bab8364b1..9522281c7b 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](k8s-kibana-secure-settings.md) -* [HTTP Configuration](k8s-kibana-http-configuration.md) +* [HTTP Configuration](/deploy-manage/security/secure-http-communications.md#k8s-kibana-http-configuration) - * [Load balancer settings and TLS SANs](k8s-kibana-http-configuration.md#k8s-kibana-http-publish) - * [Provide your own certificate](k8s-kibana-http-configuration.md#k8s-kibana-http-custom-tls) - * [Disable TLS](k8s-kibana-http-configuration.md#k8s-kibana-http-disable-tls) + * [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) * [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/security/different-ca.md b/deploy-manage/security/different-ca.md index 1b935d4a28..a0397e6b67 100644 --- a/deploy-manage/security/different-ca.md +++ b/deploy-manage/security/different-ca.md @@ -1,11 +1,12 @@ --- +applies_to: + self: ga navigation_title: "With a different CA" mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/update-node-certs-different.html --- - # Different CA [update-node-certs-different] diff --git a/deploy-manage/security/install-stack-demo-secure.md b/deploy-manage/security/install-stack-demo-secure.md index 595f926254..bdbb7166db 100644 --- a/deploy-manage/security/install-stack-demo-secure.md +++ b/deploy-manage/security/install-stack-demo-secure.md @@ -2,6 +2,8 @@ applies_to: deployment: self: ga +mapped_urls: + - https://www.elastic.co/guide/en/elastic-stack/current/install-stack-demo-secure.html --- # Tutorial: Securing a self-managed {{stack}} [install-stack-demo-secure] @@ -14,15 +16,15 @@ Since {{stack}} 8.0, security is enabled by default, meaning that traffic betwee For traffic to be encrypted between {{es}} cluster nodes and between {{kib}} and {{es}}, SSL certificates must be created for the transport ({{es}} inter-node communication) and HTTP (for the {{es}} REST API) layers. Similarly, when setting up {{fleet-server}} you’ll generate and configure a new certificate bundle, and then {{elastic-agent}} uses the generated certificates to communicate with both {{fleet-server}} and {{es}}. The process to set things up is as follows: -* [Prerequisites and assumptions](secure-your-cluster-deployment.md#install-stack-demo-secure-prereqs) -* [Step 1: Generate a new self-signed CA certificate](secure-your-cluster-deployment.md#install-stack-demo-secure-ca) -* [Step 2: Generate a new certificate for the transport layer](secure-your-cluster-deployment.md#install-stack-demo-secure-transport) -* [Step 3: Generate new certificate(s) for the HTTP layer](secure-your-cluster-deployment.md#install-stack-demo-secure-http) -* [Step 4: Configure security on additional {{es}} nodes](secure-your-cluster-deployment.md#install-stack-demo-secure-second-node) -* [Step 5: Generate server-side and client-side certificates for {{kib}}](secure-your-cluster-deployment.md#install-stack-demo-secure-kib-es) -* [Step 6: Install {{fleet}} with SSL certificates configured](secure-your-cluster-deployment.md#install-stack-demo-secure-fleet) -* [Step 7: Install {{agent}}](secure-your-cluster-deployment.md#install-stack-demo-secure-agent) -* [Step 8: View your system data](secure-your-cluster-deployment.md#install-stack-demo-secure-view-data) +* [Prerequisites and assumptions](#install-stack-demo-secure-prereqs) +* [Step 1: Generate a new self-signed CA certificate](#install-stack-demo-secure-ca) +* [Step 2: Generate a new certificate for the transport layer](#install-stack-demo-secure-transport) +* [Step 3: Generate new certificate(s) for the HTTP layer](#install-stack-demo-secure-http) +* [Step 4: Configure security on additional {{es}} nodes](#install-stack-demo-secure-second-node) +* [Step 5: Generate server-side and client-side certificates for {{kib}}](#install-stack-demo-secure-kib-es) +* [Step 6: Install {{fleet}} with SSL certificates configured](#install-stack-demo-secure-fleet) +* [Step 7: Install {{agent}}](#install-stack-demo-secure-agent) +* [Step 8: View your system data](#install-stack-demo-secure-view-data) It should take between one and two hours to complete these steps. diff --git a/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md b/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md index ed414a24f7..0973505f6a 100644 --- a/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md +++ b/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md @@ -15,32 +15,40 @@ This page describes important aspects to consider and common end-to-end scenario 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. -If you want to enable security on an existing, unsecured cluster, use your own Certificate Authority (CA), or would rather manually configure security, the following scenarios provide steps for configuring TLS on the transport layer, plus securing HTTPS traffic if you want it. +## Security principles -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). +### Run {{es}} with security enabled [security-run-with-security] -:::{image} ../../images/elasticsearch-reference-elastic-security-overview.png -:alt: Elastic Security layers -::: +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. -## Common security scenarios +### 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. -While you absolutely shouldn’t expose {{es}} directly to the internet, you also shouldn’t expose {{es}} directly to users. Instead, use an intermediary application to make requests on behalf of users. This implementation allows you to track user behaviors, such as can submit requests, and to which specific nodes in the cluster. For example, you can implement an application that accepts a search term from a user and funnels it through a [`simple_query_string`](elasticsearch://reference/query-languages/query-dsl-simple-query-string-query.md) query. +### Implement role based access control [security-create-appropriate-users] -### Minimal security ({{es}} Development) [security-minimal-overview] +[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. -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}}. +## Common security scenarios + +:::{image} ../../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. @@ -49,7 +57,6 @@ Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but [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}}. @@ -58,13 +65,11 @@ This scenario builds on the one for basic security and secures all HTTP traffic 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: @@ -109,9 +114,3 @@ The following settings are incompatible with security auto configuration. If any Exceptions are when `discovery.type` is set to `single-node`, or when `cluster.initial_master_nodes` exists but contains only the name of the current node. :::: - - - - - - diff --git a/deploy-manage/security/same-ca.md b/deploy-manage/security/same-ca.md index dc1379320a..ea6e1b3a2e 100644 --- a/deploy-manage/security/same-ca.md +++ b/deploy-manage/security/same-ca.md @@ -1,4 +1,6 @@ --- +applies_to: + self: ga navigation_title: "With the same CA" mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/update-node-certs-same.html diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index b723939118..20f1d1ba92 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -1,33 +1,88 @@ --- +applies_to: + deployment: + self: + eck: + ece: mapped_urls: - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-security.html - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html - https://www.elastic.co/guide/en/kibana/current/elasticsearch-mutual-tls.html --- + +% TODO: what to do about this page that doesn't exist +% * [/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-security.md](/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-security.md) + +$$$encrypt-internode-communication$$$ +$$$generate-certificates$$$ + + # Secure cluster communications -% What needs to be done: Refine +This page explains how to secure communications between components in your {{stack}} deployment. -% GitHub issue: https://github.com/elastic/docs-projects/issues/346 +For {{ech}} and {{serverless-full}} deployments, communications security is fully managed by Elastic with no configuration required. -% Use migrated content from existing pages that map to this page: +For ECE, ECK, and self-managed deployments, this page provides specific configuration guidance to secure the various communication channels between components. -% - [ ] ./raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-security.md -% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup.md -% Notes: concepts -% - [ ] ./raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md +:::{tip} +For a complete comparison of security feature availability and responsibility by deployment type, see [Security features by deployment type](../security.md#security-features-by-deployment-type). +::: -% Internal links rely on the following IDs being on this page (e.g. as a heading ID, paragraph ID, etc): +## Communication channels overview -$$$generate-certificates$$$ +Your {{stack}} deployment includes several distinct communication channels that must be secured to protect your data and infrastructure. -$$$encrypt-internode-communication$$$ +| **Channel** | **Description** | **Security needs** | +|-------------|-----------------|--------------------| +| [Transport layer](#transport-layer-security) | Communication between {{es}} nodes within a cluster | - Mutual TLS (required)
- Node authentication
- Node role verification | +| [HTTP layer](#http-layer-security) | Communication between external clients and {{es}} through the REST API | - TLS encryption
- Authentication (basic auth, API keys, or token-based)
- Optional client certificate authentication | +| [{{kib}}-to-{{es}}](#kib-to-es-communications) | Communication from the {{kib}} server to {{es}} for user requests and queries | - TLS encryption
- Service authentication (API keys, service tokens, or mutual TLS) | -**This page is a work in progress.** The documentation team is working to combine content pulled from the following pages: -% 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) +## Transport layer security + +The transport layer is used for communication between {{es}} nodes in a cluster. Securing this layer prevents unauthorized nodes from joining your cluster and protects internode data. + +**Deployment type notes:** +- **Elastic Cloud, 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/deploy/cloud-on-k8s/transport-settings.md). +- **Self-managed**: Transport security must be manually configured following the steps in [Set up basic security](set-up-basic-security.md). + +## HTTP layer security + +The HTTP layer secures client communication with your {{es}} cluster via its REST API, preventing unauthorized access and protecting data in transit. + +**Deployment type notes:** +- **Elastic Cloud & 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. +- **Self-managed**: HTTP security must be manually configured following [Secure HTTP communications](secure-http-communications.md). + +## {{kib}}-to-{{es}} communications + +{{kib}} connects to {{es}} as a client but requires special configuration as it performs operations on behalf of end users. + +**Deployment type notes:** +- **Elastic Cloud & Serverless**: {{kib}}-{{es}} communication is fully managed using HTTPS and service tokens. +- **ECE/ECK**: {{kib}}-{{es}} communication is automatically secured with service tokens. +- **Self-managed**: {{kib}}-{{es}} communication must be manually secured. For mutual TLS configuration, see [Mutual TLS authentication between {{kib}} and {{es}}](secure-http-communications.md#elasticsearch-mutual-tls). + +## Certificate management [generate-certificates] + +Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. + +**Deployment type notes:** +- **Elastic Cloud & Serverless**: Certificate management is fully automated by Elastic. +- **ECE**: ECE generates certificates for you. Refer to [](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). + +**ECK**: ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. +- **Self-managed**: Certificate management is your responsibility. See [Security certificates and keys](security-certificates-keys.md). + +## Next steps -* [/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup.md](/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup.md) -* [/raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md](/raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md) \ No newline at end of file +- 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 index 629a8fa3d5..6ee868784b 100644 --- a/deploy-manage/security/secure-http-communications.md +++ b/deploy-manage/security/secure-http-communications.md @@ -1,61 +1,475 @@ --- +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 -% What needs to be done: Refine +## Overview -% GitHub issue: https://github.com/elastic/docs-projects/issues/346 +Securing HTTP communications is essential for protecting data transmitted between: -% Use migrated content from existing pages that map to this page: +- {{kib}} and {{es}} +- {{kib}} and web browsers +- External monitoring systems and {{es}} +- Any HTTP client and your {{stack}} deployment -% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup-https.md -% Notes: just the relevant section + concepts -% - [ ] ./raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-tls-certificates.md -% - [ ] ./raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-custom-http-certificate.md -% - [ ] ./raw-migrated-files/kibana/kibana/Security-production-considerations.md +Different deployment types have different requirements: -% 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. +| Deployment Type | HTTP Security Configuration | +|-----------------|----------------------------| +| {{ech}}/{{serverless-short}} | Automatically configured | +| Self-managed | Manual configuration required | +| {{eck}} | Configurable with defaults | +| {{ece}} | Manual configuration required | -% Internal links rely on the following IDs being on this page (e.g. as a heading ID, paragraph ID, etc): +## Self-managed deployments -$$$encrypt-kibana-browser$$$ +```{applies_to} +self: +``` -$$$encrypt-kibana-http$$$ +For self-managed deployments, you need to generate and configure certificates for secure HTTP communications. -$$$configure-beats-security$$$ +### Prerequisites -$$$configuring-tls-browser-kib$$$ +Complete all steps in: -$$$beats-setup-role$$$ +- [Set up basic security](/deploy-manage/security/set-up-basic-security.md) +- [](/deploy-manage/security/set-up-basic-security-plus-https.md) -$$$beats-monitoring-role$$$ +### Mutual TLS between {{kib}} and {{es}} [elasticsearch-mutual-tls] -$$$beats-writer-role$$$ +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. -$$$beats-reader-role$$$ +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. -$$$configure-metricbeat-tls$$$ +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. -$$$encrypt-http-communication$$$ +{{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](/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/deploy/cloud-on-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 +``` -$$$csp-strict-mode$$$ -$$$k8s-setting-up-your-own-certificate$$$ +#### Provide your own certificate [k8s-kibana-http-custom-tls] -$$$k8s-static-ip-custom-domain$$$ +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). -$$$k8s-disable-tls$$$ +#### Disable TLS [k8s-kibana-http-disable-tls] -**This page is a work in progress.** The documentation team is working to combine content pulled from the following pages: +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. -* [/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup-https.md](/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup-https.md) -* [/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-tls-certificates.md](/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-tls-certificates.md) -* [/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-custom-http-certificate.md](/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-custom-http-certificate.md) -* [/raw-migrated-files/kibana/kibana/Security-production-considerations.md](/raw-migrated-files/kibana/kibana/Security-production-considerations.md) \ No newline at end of file +```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 f4a8dae5b1..87d6ecb7fa 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -1,26 +1,14 @@ --- -mapped_urls: - - https://www.elastic.co/guide/en/elasticsearch/reference/current/es-security-principles.html - - https://www.elastic.co/guide/en/kibana/current/using-kibana-with-security.html - - https://www.elastic.co/guide/en/elastic-stack/current/install-stack-demo-secure.html +applies_to: + deployment: + self: ga + eck: all + ece: all + ess: all --- # Secure your cluster or deployment -% What needs to be done: Refine - -% GitHub issue: https://github.com/elastic/docs-projects/issues/346 - -% Scope notes: consider keeping the mapped tutorial as a quickstart at some level - -% Use migrated content from existing pages that map to this page: - -% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/es-security-principles.md -% - [ ] ./raw-migrated-files/kibana/kibana/using-kibana-with-security.md -% - [ ] ./raw-migrated-files/stack-docs/elastic-stack/install-stack-demo-secure.md - -% Internal links rely on the following IDs being on this page (e.g. as a heading ID, paragraph ID, etc): - $$$install-stack-demo-secure-agent$$$ $$$install-stack-demo-secure-ca$$$ @@ -41,11 +29,6 @@ $$$install-stack-demo-secure-view-data$$$ $$$security-configure-settings$$$ -**This page is a work in progress.** The documentation team is working to combine content pulled from the following pages: - -* [/raw-migrated-files/elasticsearch/elasticsearch-reference/es-security-principles.md](/raw-migrated-files/elasticsearch/elasticsearch-reference/es-security-principles.md) -* [/raw-migrated-files/kibana/kibana/using-kibana-with-security.md](/raw-migrated-files/kibana/kibana/using-kibana-with-security.md) -* [/raw-migrated-files/stack-docs/elastic-stack/install-stack-demo-secure.md](/deploy-manage/security/install-stack-demo-secure.md) Protecting your {{es}} cluster and the data it contains is of utmost importance. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. @@ -66,6 +49,7 @@ Control which systems can access your Elastic deployments and clusters through t Refer to [](traffic-filtering.md). + ## Cluster communication - **HTTP and HTTPs** @@ -88,3 +72,4 @@ Refer to [](data-security.md). :::{important} Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. ::: + diff --git a/deploy-manage/security/security-certificates-keys.md b/deploy-manage/security/security-certificates-keys.md index d5db60bc2c..d4dbae761d 100644 --- a/deploy-manage/security/security-certificates-keys.md +++ b/deploy-manage/security/security-certificates-keys.md @@ -1,9 +1,11 @@ --- +applies_to: + self: ga mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-stack-security.html --- -# Security certificates and keys [configuring-stack-security] +# Self-managed certificates and keys [configuring-stack-security] When you start {{es}} for the first time, the following security configuration occurs automatically: @@ -161,7 +163,7 @@ Copy the `http_ca.crt` file to your machine and configure your client to use thi ## 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}}](secure-http-communications.md#encrypt-kibana-browser). +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] 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 92b92a4e77..fed1f4dc7d 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -103,7 +103,7 @@ Complete all steps in [Set up basic security for the Elastic Stack](secure-clust 4. Start {{es}}. -**Next**: [Encrypt HTTP client communications for {{kib}}](secure-http-communications.md#encrypt-kibana-http) +**Next**: [Encrypt HTTP client communications for {{kib}}](#encrypt-kibana-http) ## Encrypt HTTP client communications for {{kib}} [encrypt-kibana-http] @@ -140,7 +140,7 @@ You must create a separate `elasticsearch-ca.pem` security file for the monitori ::::: -**Next**: [Encrypt traffic between your browser and {{kib}}](secure-http-communications.md#encrypt-kibana-browser) +**Next**: [Encrypt traffic between your browser and {{kib}}](#encrypt-kibana-browser) ### Encrypt traffic between your browser and {{kib}} [encrypt-kibana-browser] @@ -198,7 +198,7 @@ After making these changes, you must always access {{kib}} via HTTPS. For exampl :::: -**Next**: [Configure {{beats}} security](secure-http-communications.md#configure-beats-security) +**Next**: [Configure {{beats}} security](#configure-beats-security) @@ -232,7 +232,7 @@ These instructions assume that you are using the default name for {{metricbeat}} To create users and roles from Stack Management in {{kib}}, select **Roles** or **Users** from the side navigation. -**Next**: [Create a setup role](secure-http-communications.md#beats-setup-role) +**Next**: [Create a setup role](#beats-setup-role) ##### Create a setup role and user [beats-setup-role] @@ -263,7 +263,7 @@ Setting up {{metricbeat}} is an admin-level task that requires extra privileges. | `ingest_admin` | Set up index templates and, if available, ingest pipelines | -**Next**: [Create a monitoring role](secure-http-communications.md#beats-monitoring-role) +**Next**: [Create a monitoring role](#beats-monitoring-role) ##### Create a monitoring role and user [beats-monitoring-role] @@ -302,12 +302,12 @@ You can use the built-in `beats_system` user, if it’s available in your enviro | `monitoring_user` | Use Stack Monitoring in {{kib}} to monitor {{metricbeat}} | -**Next**: [Create a writer role](secure-http-communications.md#beats-writer-role) +**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](secure-http-communications.md#beats-setup-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. @@ -325,7 +325,7 @@ Users who publish events to {{es}} need to create and write to {{metricbeat}} in | `remote_monitoring_agent` | Send monitoring data to the monitoring cluster | -**Next**: [Create a reader role](secure-http-communications.md#beats-reader-role) +**Next**: [Create a reader role](#beats-reader-role) ##### Create a reader role and user [beats-reader-role] @@ -352,7 +352,7 @@ Users who publish events to {{es}} need to create and write to {{metricbeat}} in | `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](secure-http-communications.md#configure-metricbeat-tls) +**Next**: [Configure {{metricbeat}} to use TLS](#configure-metricbeat-tls) #### Configure {{metricbeat}} to use TLS [configure-metricbeat-tls] @@ -368,7 +368,7 @@ In production environments, we strongly recommend using a separate cluster (refe :::: -1. On the node where you [generated certificates for the HTTP layer](secure-http-communications.md#encrypt-http-communication), navigate to the `/kibana` directory. +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}}. diff --git a/raw-migrated-files/kibana/kibana/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md similarity index 51% rename from raw-migrated-files/kibana/kibana/using-kibana-with-security.md rename to deploy-manage/security/using-kibana-with-security.md index cd97320ad8..58c2b5d3ab 100644 --- a/raw-migrated-files/kibana/kibana/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -1,9 +1,14 @@ --- -navigation_title: "Configure security" +applies_to: + deployment: + self: ga +mapped_urls: + - https://www.elastic.co/guide/en/kibana/current/using-kibana-with-security.html --- -# Configure security in {{kib}} [using-kibana-with-security] +$$$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. @@ -14,7 +19,6 @@ When a user is not authorized to view data in an index (such as an {{es}} index) :::: - ## Configure security settings [security-configure-settings] Set an encryption key so that sessions are not invalidated. You can optionally configure additional security settings and authentication. @@ -27,8 +31,8 @@ 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). +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}}. @@ -57,7 +61,7 @@ Configure roles for your {{kib}} users to control what data those users can acce ``` ::::{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). + 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}}. @@ -67,18 +71,68 @@ Configure roles for your {{kib}} users to control what data those users can acce :::: - 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). + 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. + 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] + +The {{kib}} server can instruct browsers to enable additional security controls using HTTP headers. + +1. Enable HTTP Strict-Transport-Security. + + 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`: + + ```js + server.securityResponseHeaders.strictTransportSecurity: "max-age=31536000" + ``` + + ::::{warning} + This header will block unencrypted connections for the entire domain. If you host more than one web application on the same domain using different ports or paths, all of them will be affected. :::: +2. Disable embedding. + Use [`disableEmbedding`](https://www.elastic.co/guide/en/kibana/current/settings.html#server-securityResponseHeaders-disableEmbedding) to ensure that {{kib}} cannot be embedded in other websites. To configure this in your `kibana.yml`: + ```js + server.securityResponseHeaders.disableEmbedding: true + ``` +### 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. +To do this, set `csp.strict` to `true` in your `kibana.yml`: +```js +csp.strict: true +``` diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 03a7c98155..65f0dc2b1f 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -239,7 +239,6 @@ toc: - file: deploy/cloud-on-k8s/k8s-kibana-es.md - file: deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md - file: deploy/cloud-on-k8s/k8s-kibana-secure-settings.md - - file: deploy/cloud-on-k8s/k8s-kibana-http-configuration.md - file: deploy/cloud-on-k8s/k8s-kibana-plugins.md - file: deploy/cloud-on-k8s/customize-pods.md - file: deploy/cloud-on-k8s/manage-compute-resources.md @@ -477,6 +476,7 @@ toc: - file: security/set-up-minimal-security.md - file: security/set-up-basic-security.md - file: security/set-up-basic-security-plus-https.md + - file: security/using-kibana-with-security.md - file: security/install-stack-demo-secure.md - file: security/secure-your-cluster-deployment.md children: @@ -494,6 +494,7 @@ toc: - file: security/secure-cluster-communications.md children: - file: security/secure-http-communications.md + - file: security/enabling-cipher-suites-for-stronger-encryption.md - file: security/security-certificates-keys.md children: - file: security/updating-certificates.md diff --git a/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-custom-http-certificate.md b/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-custom-http-certificate.md deleted file mode 100644 index 22cc1df264..0000000000 --- a/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-custom-http-certificate.md +++ /dev/null @@ -1,105 +0,0 @@ -# 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 -``` - - diff --git a/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-tls-certificates.md b/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-tls-certificates.md deleted file mode 100644 index 871f230190..0000000000 --- a/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-tls-certificates.md +++ /dev/null @@ -1,99 +0,0 @@ -# TLS certificates [k8s-tls-certificates] - -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/deploy/cloud-on-k8s/transport-settings.md#k8s-transport-ca). - -## Default self-signed certificate [k8s-default-self-signed-certificate] - -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----- -``` - -### Reserve static IP and custom domain [k8s-static-ip-custom-domain] - -To use a custom domain name with the self-signed certificate, you can reserve a static IP and/or use an Ingress instead of a `LoadBalancer` `Service`. Whatever you use, your DNS must be added to the certificate SAN in the `spec.http.tls.selfSignedCertificate.subjectAltNames` section of your Elastic resource manifest. - -```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](../../../deploy-manage/security/secure-http-communications.md#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 -``` - - diff --git a/raw-migrated-files/elasticsearch/elasticsearch-reference/es-security-principles.md b/raw-migrated-files/elasticsearch/elasticsearch-reference/es-security-principles.md deleted file mode 100644 index a3021a75ba..0000000000 --- a/raw-migrated-files/elasticsearch/elasticsearch-reference/es-security-principles.md +++ /dev/null @@ -1,26 +0,0 @@ -# {{es}} security principles [es-security-principles] - -Protecting your {{es}} cluster and the data it contains is of utmost importance. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. The following principles provide a foundation for running {{es}} in a secure manner that helps to mitigate attacks on your system at multiple levels. - - -## 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. - -While you absolutely shouldn’t expose {{es}} directly to the internet, you also shouldn’t expose {{es}} directly to users. Instead, use an intermediary application to make requests on behalf of users. This implementation allows you to track user behaviors, such as can submit requests, and to which specific nodes in the cluster. For example, you can implement an application that accepts a search term from a user and funnels it through a [`simple_query_string`](elasticsearch://reference/query-languages/query-dsl-simple-query-string-query.md) query. - - -## 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. - diff --git a/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup-https.md b/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup-https.md deleted file mode 100644 index bfd20a800f..0000000000 --- a/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup-https.md +++ /dev/null @@ -1,468 +0,0 @@ ---- -navigation_title: "Set up basic security plus HTTPS" ---- - -# Set up basic security for the Elastic Stack plus secured HTTPS traffic [security-basic-setup-https] - - -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. - -When you run the `elasticsearch-certutil` tool in `http` mode, the tool asks several questions about how you want to generate certificates. While there are numerous options, the following choices result in certificates that should work for most environments. - -::::{admonition} Signing certificates -:name: signing-certificates - -The first question that the `elasticsearch-certutil` tool prompts you with is whether you want to generate a Certificate Signing Request (CSR). Answer `n` if you want to sign your own certificates, or `y` if you want to sign certificates with a central CA. - - -#### Sign your own certificates [_sign_your_own_certificates] - -If you want to use the CA that you created when [Generating the certificate authority](../../../deploy-manage/security/set-up-basic-security.md#generate-certificates) answer `n` when asked if you want to generate a CSR. You then specify the location of your CA, which the tool uses to sign and generate a `.p12` certificate. The steps in this procedure follow this workflow. - - -#### Sign certificates with a central CA [_sign_certificates_with_a_central_ca] - -If you work in an environment with a central security team, they can likely generate a certificate for you. Infrastructure within your organization might already be configured to trust an existing CA, so it may be easier for clients to connect to {{es}} if you use a CSR and send that request to the team that controls your CA. To use a central CA, answer `y` to the first question. - -:::: - - -## Prerequisites [basic-setup-https-prerequisites] - -Complete all steps in [Set up basic security for the Elastic Stack](../../../deploy-manage/security/set-up-basic-security.md). - - -## Encrypt HTTP client communications for {{es}} [encrypt-http-communication] - -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). - - ```shell - ./bin/elasticsearch-certutil http - ``` - - This command generates a `.zip` file that contains certificates and keys to use with {{es}} and {{kib}}. Each folder contains a `README.txt` explaining how to use these files. - - 1. When asked if you want to generate a CSR, enter `n`. - 2. When asked if you want to use an existing CA, enter `y`. - 3. Enter the path to your CA. This is the absolute path to the `elastic-stack-ca.p12` file that you generated for your cluster. - 4. Enter the password for your CA. - 5. Enter an expiration value for your certificate. You can enter the validity period in years, months, or days. For example, enter `90D` for 90 days. - 6. When asked if you want to generate one certificate per node, enter `y`. - - 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](../../../deploy-manage/security/set-up-basic-security.md#generate-certificates). - 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. - - 9. Enter the IP addresses that clients can use to connect to your node. - 10. Repeat these steps for each additional node in your cluster. - -3. After generating a certificate for each of your nodes, enter a password for your private key when prompted. -4. Unzip the generated `elasticsearch-ssl-http.zip` file. This compressed file contains one directory for both {{es}} and {{kib}}. - - ```txt - /elasticsearch - |_ README.txt - |_ http.p12 - |_ sample-elasticsearch.yml - ``` - - ```txt - /kibana - |_ README.txt - |_ elasticsearch-ca.pem - |_ sample-kibana.yml - ``` - -5. On **every** node in your cluster, complete the following steps: - - 1. Copy the relevant `http.p12` certificate to the `$ES_PATH_CONF` directory. - 2. Edit the `elasticsearch.yml` file to enable HTTPS security and specify the location of the `http.p12` security certificate. - - ```yaml - xpack.security.http.ssl.enabled: true - xpack.security.http.ssl.keystore.path: http.p12 - ``` - - 3. Add the password for your private key to the secure settings in {{es}}. - - ```shell - ./bin/elasticsearch-keystore add xpack.security.http.ssl.keystore.secure_password - ``` - - 4. Start {{es}}. - - -**Next**: [Encrypt HTTP client communications for {{kib}}](../../../deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-kibana-http) - - -## Encrypt HTTP client communications for {{kib}} [encrypt-kibana-http] - -Browsers send traffic to {{kib}} and {{kib}} sends traffic to {{es}}. These communication channels are configured separately to use TLS. You encrypt traffic between {{kib}} and {{es}}, and then encrypt traffic between your browser and {{kib}}. - -### Encrypt traffic between {{kib}} and {{es}} [encrypt-kibana-elasticsearch] - -When you ran the `elasticsearch-certutil` tool with the `http` option, it created a `/kibana` directory containing an `elasticsearch-ca.pem` file. You use this file to configure {{kib}} to trust the {{es}} CA for the HTTP layer. - -1. Copy the `elasticsearch-ca.pem` file to the {{kib}} configuration directory, as defined by the `$KBN_PATH_CONF` path. -2. Open `kibana.yml` and add the following line to specify the location of the security certificate for the HTTP layer. - - ```yaml - elasticsearch.ssl.certificateAuthorities: $KBN_PATH_CONF/elasticsearch-ca.pem - ``` - -3. Add the following line to specify the HTTPS URL for your {{es}} cluster. - - ```yaml - elasticsearch.hosts: https://:9200 - ``` - -4. Restart {{kib}}. - -:::::{admonition} Connect to a secure monitoring cluster -If the Elastic monitoring features are enabled and you configured a separate {{es}} monitoring cluster, you can also configure {{kib}} to connect to the monitoring cluster via HTTPS. The steps are the same, but each setting is prefixed by `monitoring`. For example, `monitoring.ui.elasticsearch.hosts` and `monitoring.ui.elasticsearch.ssl.truststore.path`. - -::::{note} -You must create a separate `elasticsearch-ca.pem` security file for the monitoring cluster. -:::: - - -::::: - - -**Next**: [Encrypt traffic between your browser and {{kib}}](../../../deploy-manage/security/set-up-basic-security-plus-https.md#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](../../../deploy-manage/security/set-up-basic-security-plus-https.md#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](asciidocalypse://docs/beats/docs/reference/index.md) you want to configure security for. - -### Prerequisites [_prerequisites_13] - -[Install {{metricbeat}}](asciidocalypse://docs/beats/docs/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 Kibana 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](../../../deploy-manage/security/set-up-basic-security-plus-https.md#beats-setup-role) - - -##### Create a setup role and user [beats-setup-role] - -Administrators who set up {{metricbeat}} typically need to load mappings, dashboards, and other objects used to index data into {{es}} and visualize it in {{kib}}. - -::::{warning} -Setting up {{metricbeat}} is an admin-level task that requires extra privileges. As a best practice, grant the setup role to administrators only, and use a more restrictive role for event publishing. -:::: - - -1. Create the setup role: -2. Enter **metricbeat_setup** as the role name. -3. Choose the **monitor** and **manage_ilm** cluster privileges. -4. On the **metricbeat-\** indices, choose the ***manage** and **write** privileges. - - If the **metricbeat-\*** indices aren’t listed, enter that pattern into the list of indices. - -5. Create the setup user: -6. Enter **metricbeat_setup** as the user name. -7. Enter the username, password, and other user details. -8. Assign the following roles to the **metricbeat_setup** user: - - | Role | Purpose | - | --- | --- | - | `metricbeat_setup` | Set up {{metricbeat}}. | - | `kibana_admin` | Load dependencies, such as example dashboards, if available, into {{kib}} | - | `ingest_admin` | Set up index templates and, if available, ingest pipelines | - - -**Next**: [Create a monitoring role](../../../deploy-manage/security/set-up-basic-security-plus-https.md#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](../../../deploy-manage/security/set-up-basic-security-plus-https.md#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](../../../deploy-manage/security/set-up-basic-security-plus-https.md#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](../../../deploy-manage/security/set-up-basic-security-plus-https.md#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 **Kibana**, click **Add Kibana 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](../../../deploy-manage/security/set-up-basic-security-plus-https.md#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](../../../deploy-manage/security/set-up-basic-security-plus-https.md#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}}](asciidocalypse://docs/beats/docs/reference/metricbeat/configuration-ssl.md).`hosts` - : Specifies the host where your {{es}} cluster is running. Ensure that you include `https` in the URL. - - `username` - : Name of the user with privileges to collect metric data. The built-in `monitoring_user` user has these privileges. Alternatively, you can create a user and assign it the `monitoring_user` role. - - `password` - : Password for the indicated `username`. - - `certificate_authorities` - : Indicates the path to the local `.pem` file that contains your CA’s certificate. - -7. If you want to use the predefined assets for parsing, indexing, and visualizing your data, run the following command to load these assets: - - ```shell - ./metricbeat setup -e - ``` - -8. Start {{es}}, and then start {{metricbeat}}. - - ```shell - ./metricbeat -e - ``` - - `-e` is optional and sends output to standard error instead of the configured log output. - -9. Log in to {{kib}}, open the main menu, and click **Stack Monitoring**. - - You’ll see cluster alerts that require your attention and a summary of the available monitoring metrics for {{es}}. Click any of the header links on the available cards to view additional information. diff --git a/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup.md b/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup.md deleted file mode 100644 index 2151d00016..0000000000 --- a/raw-migrated-files/elasticsearch/elasticsearch-reference/security-basic-setup.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -navigation_title: "Set up basic security" ---- - -# Set up basic security for the Elastic Stack [security-basic-setup] - - -When you start {{es}} for the first time, passwords are generated for the `elastic` user and TLS is automatically configured for you. If you configure security manually *before* starting your {{es}} nodes, the auto-configuration process will respect your security configuration. You can adjust your TLS configuration at any time, such as [updating node certificates](../../../deploy-manage/security/updating-certificates.md). - -::::{important} -If your cluster has multiple nodes, then you must configure TLS between nodes. [Production mode](/deploy-manage/deploy/self-managed/bootstrap-checks.md#dev-vs-prod-mode) clusters will not start if you do not enable TLS. -:::: - - -The transport layer relies on mutual TLS for both encryption and authentication of nodes. Correctly applying TLS ensures that a malicious node cannot join the cluster and exchange data with other nodes. While implementing username and password authentication at the HTTP layer is useful for securing a local cluster, the security of communication between nodes requires TLS. - -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 [the next scenario](security-basic-setup-https.md), we’ll apply TLS to the {{es}} HTTP port. - -:::: - - -## Generate the certificate authority [generate-certificates] - -You can add as many nodes as you want in a cluster but they must be able to communicate with each other. The communication between nodes in a cluster is handled by the transport module. To secure your cluster, you must ensure that internode communications are encrypted and verified, which is achieved with mutual TLS. - -In a secured cluster, {{es}} nodes use certificates to identify themselves when communicating with other nodes. - -The cluster must validate the authenticity of these certificates. The recommended approach is to trust a specific certificate authority (CA). When nodes are added to your cluster they must use a certificate signed by the same CA. - -For the transport layer, we recommend using a separate, dedicated CA instead of an existing, possibly shared CA so that node membership is tightly controlled. Use the `elasticsearch-certutil` tool to generate a CA for your cluster. - -1. Before starting {{es}}, use the `elasticsearch-certutil` tool on any single node to generate a CA for your cluster. - - ```shell - ./bin/elasticsearch-certutil ca - ``` - - 1. When prompted, accept the default file name, which is `elastic-stack-ca.p12`. This file contains the public certificate for your CA and the private key used to sign certificates for each node. - 2. Enter a password for your CA. You can choose to leave the password blank if you’re not deploying to a production environment. - -2. On any single node, generate a certificate and private key for the nodes in your cluster. You include the `elastic-stack-ca.p12` output file that you generated in the previous step. - - ```shell - ./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 - ``` - - `--ca ` - : Name of the CA file used to sign your certificates. The default file name from the `elasticsearch-certutil` tool is `elastic-stack-ca.p12`. - - 1. Enter the password for your CA, or press **Enter** if you did not configure one in the previous step. - 2. Create a password for the certificate and accept the default file name. - - The output file is a keystore named `elastic-certificates.p12`. This file contains a node certificate, node key, and CA certificate. - -3. On **every** node in your cluster, copy the `elastic-certificates.p12` file to the `$ES_PATH_CONF` directory. - - -## Encrypt internode communications with TLS [encrypt-internode-communication] - -The transport networking layer is used for internal communication between nodes in a cluster. When security features are enabled, you must use TLS to ensure that communication between the nodes is encrypted. - -Now that you’ve generated a certificate authority and certificates, you’ll update your cluster to use these files. - -::::{note} -{{es}} monitors all files such as certificates, keys, keystores, or truststores that are configured as values of TLS-related node settings. If you update any of these files, such as when your hostnames change or your certificates are due to expire, {{es}} reloads them. The files are polled for changes at a frequency determined by the global {{es}} `resource.reload.interval.high` setting, which defaults to 5 seconds. -:::: - - -Complete the following steps **for each node in your cluster**. To join the same cluster, all nodes must share the same `cluster.name` value. - -1. Open the `$ES_PATH_CONF/elasticsearch.yml` file and make the following changes: - - 1. Add the [`cluster-name`](elasticsearch://reference/elasticsearch/configuration-reference/miscellaneous-cluster-settings.md#cluster-name) setting and enter a name for your cluster: - - ```yaml - cluster.name: my-cluster - ``` - - 2. Add the [`node.name`](../../../deploy-manage/deploy/self-managed/important-settings-configuration.md#node-name) setting and enter a name for the node. The node name defaults to the hostname of the machine when {{es}} starts. - - ```yaml - node.name: node-1 - ``` - - 3. Add the following settings to enable internode communication and provide access to the node’s certificate. - - Because you are using the same `elastic-certificates.p12` file on every node in your cluster, set the verification mode to `certificate`: - - ```yaml - xpack.security.transport.ssl.enabled: true - xpack.security.transport.ssl.verification_mode: certificate <1> - xpack.security.transport.ssl.client_authentication: required - xpack.security.transport.ssl.keystore.path: elastic-certificates.p12 - xpack.security.transport.ssl.truststore.path: elastic-certificates.p12 - ``` - - 1. If you want to use hostname verification, set the verification mode to `full`. You should generate a different certificate for each host that matches the DNS or IP address. See the `xpack.security.transport.ssl.verification_mode` parameter in [TLS settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings). - -2. If you entered a password when creating the node certificate, run the following commands to store the password in the {{es}} keystore: - - ```shell - ./bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password - ``` - - ```shell - ./bin/elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password - ``` - -3. Complete the previous steps for each node in your cluster. -4. On **every** node in your cluster, start {{es}}. The method for [starting and stopping](../../../deploy-manage/maintenance/start-stop-services/start-stop-elasticsearch.md) {{es}} varies depending on how you installed it. - - For example, if you installed {{es}} with an archive distribution (`tar.gz` or `.zip`), you can enter `Ctrl+C` on the command line to stop {{es}}. - - ::::{warning} - You must perform a full cluster restart. Nodes that are configured to use TLS for transport cannot communicate with nodes that use unencrypted transport connection (and vice-versa). - :::: - - - -## 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-manage/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](security-basic-setup-https.md). In addition to configuring TLS on the transport interface of your {{es}} cluster, you configure TLS on the HTTP interface for both {{es}} and {{kib}}. - - diff --git a/raw-migrated-files/kibana/kibana/Security-production-considerations.md b/raw-migrated-files/kibana/kibana/Security-production-considerations.md deleted file mode 100644 index 7af43c0f56..0000000000 --- a/raw-migrated-files/kibana/kibana/Security-production-considerations.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -navigation_title: "Security" ---- - -# Security production considerations [Security-production-considerations] - - -To secure your {{kib}} installation in production, consider these high-priority topics to ensure that only authorized users can access {{kib}}. For more information on {{kib}}'s security controls, see [Configure security](using-kibana-with-security.md). - - -## 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). - -encrypt-kibana-http - - -## 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] - -The {{kib}} server can instruct browsers to enable additional security controls using HTTP headers. - -1. Enable HTTP Strict-Transport-Security. - - Use [`strictTransportSecurity`](kibana://reference/configuration-reference/general-settings.md##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`: - - ```js - server.securityResponseHeaders.strictTransportSecurity: "max-age=31536000" - ``` - - ::::{warning} - This header will block unencrypted connections for the entire domain. If you host more than one web application on the same domain using different ports or paths, all of them will be affected. - :::: - -2. Disable embedding. - - Use [`disableEmbedding`](https://www.elastic.co/guide/en/kibana/master/settings.html#server-securityResponseHeaders-disableEmbedding) to ensure that {{kib}} cannot be embedded in other websites. To configure this in your `kibana.yml`: - - ```js - server.securityResponseHeaders.disableEmbedding: true - ``` - - - -## 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. - -To do this, set `csp.strict` to `true` in your `kibana.yml`: - -```js -csp.strict: true -``` - diff --git a/raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md b/raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md deleted file mode 100644 index 06b5c93247..0000000000 --- a/raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -navigation_title: "Mutual TLS with {{es}}" ---- - -# Mutual TLS authentication between {{kib}} and {{es}} [elasticsearch-mutual-tls] - - -Secure Sockets Layer (SSL) and Transport Layer Security (TLS) provide encryption for data-in-transit. While these terms are often used interchangeably, {{kib}} supports only TLS, which supersedes the old SSL protocols. - -TLS requires X.509 certificates to authenticate the communicating parties and perform encryption of data-in-transit. Each certificate contains a public key and has and an associated — but separate — private key; these keys are used for cryptographic operations. {{kib}} supports certificates and private keys in PEM or PKCS#12 format. - -In a standard TLS configuration, the server presents a signed certificate to authenticate itself to the client. In a mutual TLS configuration, the client also presents a signed certificate to authenticate itself to the server. - -{{es}} {{security-features}} are enabled on your cluster by default, so each request that {{kib}} (the client) makes to {{es}} (the server) is authenticated. Most requests made by end users through {{kib}} to {{es}} are authenticated by using the credentials of the logged-in user. - -To [enroll {{kib}} with an {{es}} cluster](/deploy-manage/security/security-certificates-keys.md#stack-start-with-security), you pass a generated enrollment token. This token configures {{kib}} to authenticate with {{es}} using a [service account token](../../../deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#service-accounts-tokens). {{kib}} also supports mutual TLS authentication with {{es}} via a [Public Key Infrastructure (PKI) realm](../../../deploy-manage/users-roles/cluster-or-deployment-auth/pki.md). With this setup, {{es}} needs to verify the signature on the {{kib}} client certificate, and it also needs to map the client certificate’s distinguished name (DN) to the appropriate `kibana_system` role. - -::::{note} -Using a PKI realm is a [subscription feature](https://www.elastic.co/subscriptions). -:::: - - - -## Configure {{kib}} and {{es}} to use mutual TLS authentication [_configure_kib_and_es_to_use_mutual_tls_authentication] - -If you haven’t already, start {{kib}} and connect it to {{es}} using the [enrollment token](/deploy-manage/security/security-certificates-keys.md#stack-start-with-security). - -1. Obtain a client certificate and private key for {{kib}}. - - {{kib}} uses the client certificate and corresponding private key when connecting to {{es}}. - - ::::{note} - This is not the same as the [server certificate](../../../deploy-manage/security/secure-http-communications.md#configuring-tls-browser-kib) 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](../../../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](/deploy-manage/security/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](/deploy-manage/security/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/raw-migrated-files/toc.yml b/raw-migrated-files/toc.yml index c5090e46cf..40e99ee287 100644 --- a/raw-migrated-files/toc.yml +++ b/raw-migrated-files/toc.yml @@ -13,9 +13,7 @@ toc: - file: apm-agent-ruby/apm-agent-ruby/release-notes-4.x.md - file: cloud-on-k8s/cloud-on-k8s/index.md children: - - file: cloud-on-k8s/cloud-on-k8s/k8s-custom-http-certificate.md - file: cloud-on-k8s/cloud-on-k8s/k8s-securing-stack.md - - file: cloud-on-k8s/cloud-on-k8s/k8s-tls-certificates.md - file: cloud-on-k8s/cloud-on-k8s/k8s-upgrading-stack.md - file: cloud/cloud-enterprise/index.md children: @@ -136,7 +134,6 @@ toc: - file: elasticsearch/elasticsearch-reference/index.md children: - file: elasticsearch/elasticsearch-reference/documents-indices.md - - file: elasticsearch/elasticsearch-reference/es-security-principles.md - file: elasticsearch/elasticsearch-reference/esql-using.md - file: elasticsearch/elasticsearch-reference/how-monitoring-works.md - file: elasticsearch/elasticsearch-reference/index-modules-allocation.md @@ -150,8 +147,6 @@ toc: - file: elasticsearch/elasticsearch-reference/search-with-synonyms.md - file: elasticsearch/elasticsearch-reference/secure-cluster.md - file: elasticsearch/elasticsearch-reference/secure-monitoring.md - - file: elasticsearch/elasticsearch-reference/security-basic-setup-https.md - - file: elasticsearch/elasticsearch-reference/security-basic-setup.md - file: elasticsearch/elasticsearch-reference/security-files.md - file: elasticsearch/elasticsearch-reference/security-limitations.md - file: elasticsearch/elasticsearch-reference/semantic-search-inference.md @@ -162,14 +157,11 @@ toc: - file: kibana/kibana/index.md children: - file: kibana/kibana/apm-settings-kb.md - - file: kibana/kibana/elasticsearch-mutual-tls.md - file: kibana/kibana/logging-settings.md - file: kibana/kibana/reporting-production-considerations.md - file: kibana/kibana/secure-reporting.md - - file: kibana/kibana/Security-production-considerations.md - file: kibana/kibana/upgrade-migrations-rolling-back.md - - file: kibana/kibana/upgrade.md - - file: kibana/kibana/using-kibana-with-security.md + - file: kibana/kibana/upgrade.md - file: kibana/kibana/xpack-security.md - file: logstash/logstash/index.md children: diff --git a/redirects.yml b/redirects.yml index 0f8272b336..3e272bb8c7 100644 --- a/redirects.yml +++ b/redirects.yml @@ -18,6 +18,7 @@ redirects: anchors: 'spaces-control-feature-visibility': 'deploy-manage/deploy/cloud-enterprise/deploy-large-installation-cloud.md': '!deploy-manage/deploy/cloud-enterprise/deploy-large-installation.md' + 'deploy-manage/deploy/cloud-on-k8s/k8s-kibana-http-configuration.md': '!deploy-manage/security/secure-http-communications.md' 'deploy-manage/deploy/self-managed/install-with-docker.md': '!deploy-manage/deploy/self-managed/install-kibana-with-docker.md' 'deploy-manage/deploy/self-managed/deploy-cluster.md': '!deploy-manage/deploy/self-managed/installing-elasticsearch.md' 'deploy-manage/deploy/self-managed/configure.md': '!deploy-manage/deploy/self-managed/configure-kibana.md' @@ -30,6 +31,9 @@ redirects: 'deploy-manage/monitor/logging-configuration/auditing-search-queries.md': 'deploy-manage/security/logging-configuration/auditing-search-queries.md' 'deploy-manage/monitor/logging-configuration/logfile-audit-output.md': 'deploy-manage/security/logging-configuration/logfile-audit-output.md' + ## temporary hack due to moved anchors + 'deploy-manage/security/secure-http-communications.md': '!deploy-manage/security/secure-http-communications.md' + ## explore-analyze 'explore-analyze/machine-learning/nlp/ml-nlp-auto-scale.md': '!deploy-manage/autoscaling/trained-model-autoscaling.md'