diff --git a/deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md b/deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md index d224c4b883..ae5e9302c0 100644 --- a/deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md +++ b/deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md @@ -119,7 +119,7 @@ Currently you can’t use SSO to login directly from {{ecloud}} into Kibana endp Kibana does not currently support restoring a snapshot of their indices across Elastic Cloud deployments. -* [Kibana uses encryption keys](/deploy-manage/security/secure-your-cluster-deployment.md#security-configure-settings) in various places, ranging from encrypting data in some areas of reporting, alerts, actions, connector tokens, ingest outputs used in Fleet and Synthetics monitoring to user sessions. +* [Kibana uses encryption keys](/deploy-manage/security/secure-your-cluster-deployment.md) in various places, ranging from encrypting data in some areas of reporting, alerts, actions, connector tokens, ingest outputs used in Fleet and Synthetics monitoring to user sessions. * Currently, there is not a way to retrieve the values of Kibana encryption keys, or set them in the target deployment before restoring a snapshot. As a result, once a snapshot is restored, Kibana will not be able to decrypt the data required for some features to function properly in the target deployment. * If you have already restored a snapshot across deployments and now have broken Kibana saved objects in the target deployment, you will have to recreate all broken configurations and objects, or create a new setup in the target deployment instead of using snapshot restore. diff --git a/deploy-manage/security.md b/deploy-manage/security.md index a6bf5e004b..6f1bf34209 100644 --- a/deploy-manage/security.md +++ b/deploy-manage/security.md @@ -14,63 +14,16 @@ mapped_urls: - https://www.elastic.co/guide/en/cloud/current/ec-faq-technical.html --- -% SR: include this info somewhere in this section -% {{ech}} doesn't support custom SSL certificates, which means that a custom CNAME for an {{ech}} endpoint such as *mycluster.mycompanyname.com* also is not supported. -% -% In {{ech}}, IP sniffing is not supported by design and will not return the expected results. We prevent IP sniffing from returning the expected results to improve the security of our underlying {{ech}} infrastructure. -% -% encryption at rest (EAR) is enabled in {{ech}} by default. We support EAR for both the data stored in your clusters and the snapshots we take for backup, on all cloud platforms and across all regions. -% You can also bring your own key (BYOK) to encrypt your Elastic Cloud deployment data and snapshots. For more information, check [Encrypt your deployment with a customer-managed encryption key](../../../deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md). - -% Note that the encryption happens at the file system level. - -% We do provide [static IP ranges](../../../deploy-manage/security/elastic-cloud-static-ips.md), but they should be used with caution as noted in the documentation. IP addresses assigned to cloud resources can change without notice. This could be initiated by cloud providers with no knowledge to us. For this reason, we generally do not recommend that you use firewall rules to allow or restrict certain IP ranges. If you do wish to secure communication for deployment endpoints on {{ech}}, please use [Private Link](../../../deploy-manage/security/traffic-filtering.md). However, in situations where using Private Link services do not meet requirements (for example, secure traffic **from** Elastic Cloud), static IP ranges can be used. - -% What needs to be done: Refine - -% GitHub issue: https://github.com/elastic/docs-projects/issues/346 - -% Scope notes: this is just communication security - link to users + roles, spaces, monitoring, ++ - -$$$field-document-limitations$$$ - -$$$alias-limitations$$$ - -$$$preventing-unauthorized-access$$$ - -$$$preserving-data-integrity$$$ - -$$$maintaining-audit-trail$$$ - -:::{warning} -**This page is a work in progress.** -::: - - # Security An Elastic implementation comprises many moving parts: {{es}} nodes forming the cluster, {{kib}} instances, additional stack components such as Logstash and Beats, and various clients and integrations, all communicating with your cluster. To keep your data secured, Elastic offers security features that prevent bad actors from tampering with your data, and encrypt communications to, from, and within your cluster. Regardless of your deployment type, Elastic sets up certain security features for you automatically. -The documentation is organized into three main areas. - -* [Secure your orchestrator](security/secure-hosting-environment.md): Setup security in your [{{ece}}](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation.md) or [{{eck}}](/deploy-manage/security/secure-your-eck-installation.md) installations. -* [Secure your cluster or deployment](./security/secure-your-cluster-deployment.md): Learn about how to manage basic Elastic security features. You’ll also learn how to implement advanced security measures. -* [Secure your clients and integrations](security/secure-clients-integrations.md): Secure communications between your applications and the {{stack}}. - -::::{note} -As part of your overall security strategy, you can also do the following: - -* Prevent unauthorized access with [password protection and role-based access control](/deploy-manage/users-roles.md). -* Control access to dashboards and other saved objects in your UI using [Spaces](/deploy-manage/manage-spaces.md). -* Connect a local cluster to a [remote cluster](/deploy-manage/remote-clusters.md) to enable [cross-cluster replication](/deploy-manage/tools/cross-cluster-replication.md) and [cross-cluster search](/solutions/search/cross-cluster-search.md). -* Manage [API keys](/deploy-manage/api-keys.md) used for programmatic access to Elastic. -:::: - -The availability and configurability of security features vary by deployment type. On every page, you'll see deployment type indicators that show which content applies to specific deployment types. Focus on sections tagged with your deployment type and look for subsections specifically addressing your deployment model. +The availability and configurability of security features vary by deployment type. On every page, you'll see deployment type indicators that show which content applies to specific deployment types. Focus on sections tagged with your deployment type and look for subsections specifically addressing your deployment model. You can also review a [comparison table](#comparison-table) showing feature availability and configurability by deployment type. -At the end of this doc, there's also a [comparison table](#comparison-table) showing feature availability and configurability by deployment type. +:::{include} /deploy-manage/security/_snippets/complete-security.md +::: ## Managed security in Elastic Cloud ```yaml {applies_to} @@ -79,239 +32,92 @@ deployment: serverless: all ``` -Elastic Cloud has built-in security. For example, HTTPS communications between Elastic Cloud and the internet, as well as inter-node communications, are secured automatically, and cluster data is encrypted at rest. - -In {{ech}}, you can augment these security features in the following ways: -* Configure [traffic filtering](./security/traffic-filtering.md) to prevent unauthorized access to your deployments. -* Encrypt your deployment with a [customer-managed encryption key](./security/encrypt-deployment-with-customer-managed-encryption-key.md). -* [Secure your settings](./security/secure-settings.md) using {{es}} and {{kib}} keystores. -* Use the list of [Elastic Cloud static IPs](./security/elastic-cloud-static-ips.md) to allow or restrict communications in your infrastructure. - -::::{note} -Serverless projects are fully managed and secured by Elastic, and do not have any configurable security features at the project level. -:::: - -Refer to [Elastic Cloud security](https://www.elastic.co/cloud/security) for more details about Elastic security and privacy programs. - -## Cluster or deployment security features - -You can configure the following aspects of your Elastic implementation to maintain and enhance security: - -### Manage TLS certificates -```yaml {applies_to} -deployment: - ece: all - eck: all - self: all -``` - -TLS certificates apply security controls to network communications. TLS is the modern name for what used to be called Secure Sockets Layer (SSL). - -TLS certificates are used in two places: -* **The HTTP layer**: Used for communication between your cluster or deployment and the internet. -* **The transport layer**: Used mainly for inter-node communications, and in certain cases for cluster to cluster communication. +{{ecloud}} has built-in security. For example, HTTPS communications between {{ecloud}} and the internet, as well as inter-node communications, are secured automatically, and cluster data is encrypted at rest. -The way that TLS certificates are managed depends on your deployment type: +In {{ech}}, you can augment these Security features in the following ways: +* Configure [traffic filtering](/deploy-manage/security/traffic-filtering.md) to prevent unauthorized access to your deployments. +* Encrypt your deployment with a [customer-managed encryption key](/deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md). +* [Secure your settings](/deploy-manage/security/secure-settings.md) using {{es}} and {{kib}} keystores. +* Use the list of [{{ecloud}} static IPs](/deploy-manage/security/elastic-cloud-static-ips.md) to allow or restrict communications in your infrastructure. -* In self-managed {{es}} clusters, you [manage both of these certificates yourself](./security/secure-cluster-communications.md). You can also [Configure Kibana and Elasticsearch to use mutual TLS](./security/secure-http-communications.md#elasticsearch-mutual-tls). -* In {{ece}}, you can use one or more [proxy certificates](./security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) to secure the HTTP layer. These certificates are managed at the ECE installation level. Transport-level encryption is managed by ECE and certificates can’t be changed. -* In {{eck}}, you can [manage certificates for the HTTP layer](./security/secure-http-communications.md#k8s-custom-http-certificate). Certificates for the transport layer are managed by ECK and can’t be changed. However, you can set your own certificate authority, customize certificate contents, and provide your own certificate generation tools using [transport settings](./security/k8s-transport-settings.md). +{{ech}} doesn't support custom SSL certificates, which means that a custom CNAME for an {{ech}} endpoint such as *mycluster.mycompanyname.com* also is not supported. -::::{tip} -Elastic Cloud manages TLS certificates for you. +::::{note} +Serverless projects are fully managed and secured by Elastic, and do not have any configurable Security features at the project level. :::: -#### Enable cipher suites for stronger encryption +Refer to [{{ecloud}} security](https://www.elastic.co/cloud/security) for more details about Elastic security and privacy programs. -TBD - to refine -Refer to [](./security/enabling-cipher-suites-for-stronger-encryption.md) for more details. -(These cipher_suites settings are used for a bunch of different auth realms as well as http/transport layer) - -### Restrict connections using traffic filtering +## Securing your orchestrator ```yaml {applies_to} deployment: - ess: all ece: all eck: all - self: all ``` -[Traffic filtering](./security/traffic-filtering.md) allows you to limit how your deployments can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust. +When running {{stack}} applications on {{ece}} or {{eck}}, you must also secure the [orchestration layer](/deploy-manage/deploy.md#who-manages-the-infrastructure) responsible for deploying and managing your Elastic products. -* For all deployment types, you can configure [IP-based traffic filters](./security/ip-traffic-filtering.md). - -* For Elastic Cloud Hosted, you can also configure [private link traffic filters](./security/private-link-traffic-filters.md). - -* For {{eck}}, you can use [Kubernetes network policies](./security/k8s-network-policies.md). - -### Allow or deny Elastic Cloud IP ranges -```yaml {applies_to} -deployment: - ess: all -``` +Learn about securing the following components: -Elastic Cloud publishes a list of IP addresses used by its services for both incoming and outgoing traffic. Users can use these lists to configure their network firewalls as needed to allow or restrict traffic related to Elastic Cloud services. +* [An {{ece}} installation](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation.md) +* [An {{eck}} operator](/deploy-manage/security/secure-your-eck-installation.md) -[Learn more about Elastic Cloud static IPs](./security/elastic-cloud-static-ips.md). +:::{tip} +Elastic secures your [{{ecloud}}](/deploy-manage/deploy/elastic-cloud.md) orchestrator for you. +::: -### Manage Kibana sessions +## Cluster or deployment security features ```yaml {applies_to} deployment: - ess: all ece: all eck: all - self: all -``` - -Control the timeout and lifespan of logged-in sessions to Kibana, as well as the number of concurrent sessions each user can have. - -[Learn more about {{kib}} session management](./security/kibana-session-management.md). - -### Encryption at rest -```yaml {applies_to} -serverless: all -deployment: ess: all -``` - -By default, Elastic Cloud already encrypts your deployment data, project data, and snapshots at rest. - -If you’re using Elastic Cloud Hosted, then you can reinforce this mechanism by providing your own encryption key, also known as [Bring Your Own Key (BYOK)](./security/encrypt-deployment-with-customer-managed-encryption-key.md). - -::::{note} -Other deployment types don’t implement encryption at rest out of the box. For self-managed clusters, to implement encryption at rest, the hosts running the cluster must be configured with disk-level encryption, such as `dm-crypt`. In addition, snapshot targets must ensure that data is encrypted at rest as well. - -Configuring `dm-crypt` or similar technologies is outside the scope of this documentation, and issues related to disk encryption are outside the scope of support. -:::: - -### Secure your settings -```yaml {applies_to} -deployment: - ess: all - ece: all - eck: all self: all ``` -Some of the settings that you configure in Elasticsearch Service are sensitive, such as passwords, and relying on file system permissions to protect these settings is insufficient. Learn how to configure secure settings in the {{es}} keystore or {{kib}} keystore. +You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: -[Learn more about storing settings in a keystore](./security/secure-settings.md). +### Communication and network security +:::{include} /deploy-manage/security/_snippets/cluster-communication-network.md +::: -### Secure saved objects -```yaml {applies_to} -deployment: - ess: all - ece: all - eck: all - self: all -``` +### Data security -Kibana stores entities such as dashboards, visualizations, alerts, actions, and advanced settings as saved objects, which are kept in a dedicated, internal {{es}} index. If such an object includes sensitive information, for example a PagerDuty integration key or email server credentials used by the alert action, {{kib}} encrypts it and makes sure it cannot be accidentally leaked or tampered with. +:::{include} /deploy-manage/security/_snippets/cluster-data.md +::: + +### User session security -Encrypting sensitive information means that a malicious party with access to the Kibana internal indices won’t be able to extract that information without also knowing the encryption key. +:::{include} /deploy-manage/security/_snippets/cluster-user-session.md +::: -[Learn how to configure and rotate the saved object encryption key](./security/secure-saved-objects.md). +### Security event audit logging +:::{include} /deploy-manage/security/_snippets/audit-logging.md +::: -### Other topics -```yaml {applies_to} -deployment: - ess: all - ece: all - eck: all - self: all -``` -TBD / to determine if needed +% missing: fips mode, manual config % we need to refine this table, but the idea is awesome IMO -## Security features by deployment type [comparison-table] - -Security feature availability varies by deployment type, with each feature having one of the following statuses: - -| **Status** | **Description** | -|--------|-------------| -| **Managed** | Handled automatically by Elastic with no user configuration needed | -| **Configurable** | Built-in feature that needs your configuration (like IP filters or passwords) | -| **Self-managed** | Infrastructure-level security you implement and maintain | -| **N/A** | Not available for this deployment type | - -Select your deployment type below to see what's available and how implementation responsibilities are distributed: - -::::{tab-set} -:group: deployment-type - -:::{tab-item} Elastic Cloud Hosted -:sync: cloud-hosted - -| **Security Category** | **Security Feature** | **Status** | **Description** | -|------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Managed | Automatically configured by Elastic | -| | TLS (Transport Layer) | Managed | Automatically configured by Elastic | -| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | -| | Private link | Configurable | Establish secure VPC connection | -| | Static IPs | Configurable | Enable fixed IP addresses | -| **Data** | Encryption at rest | Managed | Automatically encrypted by Elastic | -| | Bring your own encryption key | Configurable | Implement customer-provided keys | -| | Keystore security | Managed | Automatically protected by Elastic | -| | Saved object encryption | Managed | Automatically encrypted by Elastic | -| **User Session** | Kibana Sessions | Configurable | Customize session parameters | +### Security features by deployment type [comparison-table] +:::{include} /deploy-manage/security/_snippets/cluster-comparison.md ::: -:::{tab-item} Serverless -:sync: serverless - -| **Security Category** | **Security Feature** | **Status** | **Description** | -|------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Managed | Automatically configured by Elastic | -| | TLS (Transport Layer) | Managed | Automatically configured by Elastic | -| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | -| | Private link | N/A | X | -| | Static IPs | Configurable | Enable fixed IP addresses | -| **Data** | Encryption at rest | Managed | Automatically encrypted by Elastic | -| | Bring your own encryption key | N/A | X | -| | Keystore security | Managed | Automatically protected by Elastic | -| | Saved object encryption | Managed | Automatically encrypted by Elastic | -| **User Session** | Kibana Sessions | Managed | Automatically configured by Elastic | +## Securing other {{stack}} components -::: +The {{es}} security features enable you to secure your {{es}} cluster. However, for a complete security strategy, you must secure other applications in the {{stack}}, as well as communications between {{es}} and other {{stack}} components. -:::{tab-item} ECE/ECK -:sync: ece-eck - -| **Security Category** | **Security Feature** | **Status** | **Description** | -|------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Configurable | Configure custom certificates | -| | TLS (Transport Layer) | Managed | Automatically configured by Elastic | -| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | -| | Private link | N/A | X | -| | Static IPs | N/A | X | -| **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | -| | Bring your own encryption key | N/A | X | -| | Keystore security | Configurable | Configure secure settings storage | -| | Saved object encryption | Configurable | Enable encryption for saved objects | -| **User Session** | Kibana Sessions | Configurable | Customize session parameters | +[Review security topics for other {{stack}} components](/deploy-manage/security/secure-clients-integrations.md). -::: +## Securing clients and integrations -:::{tab-item} Self-managed -:sync: self-managed - -| **Security Category** | **Security Feature** | **Status** | **Description** | -|------------------|------------|--------------|-------------| -| **Communication** | TLS (HTTP Layer) | Self-managed | Implement and maintain certificates | -| | TLS (Transport Layer) | Self-managed | Implement and maintain certificates | -| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | -| | Private link | N/A | X | -| | Static IPs | N/A | X | -| **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | -| | Bring your own encryption key | N/A | X | -| | Keystore security | Configurable | Configure secure settings storage | -| | Saved object encryption | Configurable | Enable encryption for saved objects | -| **User Session** | Kibana Sessions | Configurable | Customize session parameters | +If you use HTTP clients or integrations to communicate with {{es}}, then you also need to [secure communications between the clients or integrations and {{es}}](/deploy-manage/security/httprest-clients-security.md). -::: +## Security limitations -:::: +There are security limitations that apply to the usage of some {{es}} features or resources. Depending on your organization's security requirements, you might want to restrict, adjust, or find workaround or alternatives for some of these features and resources. + +[Review {{es}} security limitations](/deploy-manage/security/limitations.md). \ No newline at end of file diff --git a/deploy-manage/security/_snippets/audit-logging.md b/deploy-manage/security/_snippets/audit-logging.md new file mode 100644 index 0000000000..38d8c2a95b --- /dev/null +++ b/deploy-manage/security/_snippets/audit-logging.md @@ -0,0 +1,5 @@ +Audit logging is a powerful feature that helps you monitor and track security-related events within the {{stack}}. By enabling audit logs, you can gain visibility into authentication attempts, authorization decisions, and other system activity. + +Audit logging also provides forensic evidence in the event of an attack, and can be enabled independently for {{es}} and {{kib}}. + +[Learn how to enable audit logging](/deploy-manage/security/logging-configuration/security-event-audit-logging.md). diff --git a/deploy-manage/security/_snippets/cluster-communication-network.md b/deploy-manage/security/_snippets/cluster-communication-network.md new file mode 100644 index 0000000000..041a44aaf4 --- /dev/null +++ b/deploy-manage/security/_snippets/cluster-communication-network.md @@ -0,0 +1,7 @@ +* [Manage TLS certificates](/deploy-manage/security/secure-cluster-communications.md): TLS certificates apply security controls to network communications. Elastic uses TLS certificates to secure communications in two places: + * **The HTTP layer**: Used for communication between your cluster or deployment and the internet. + * **The transport layer**: Used mainly for inter-node communications, and in certain cases for cluster to cluster communication. + * In self-managed {{es}} clusters, you can also [Configure Kibana and Elasticsearch to use mutual TLS](/deploy-manage/security/secure-http-communications.md#elasticsearch-mutual-tls). +* [Enable cipher suites for stronger encryption](/deploy-manage/security/enabling-cipher-suites-for-stronger-encryption.md): The TLS and SSL protocols use a cipher suite that determines the strength of encryption used to protect the data. You may want to enable the use of additional cipher suites, so you can use different cipher suites for your TLS communications or communications with authentication providers. +* [Restrict connections using traffic filtering](/deploy-manage/security/traffic-filtering.md): Traffic filtering allows you to limit how your deployments can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust. Restrict access based on IP addresses or CIDR ranges, or secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. +* [Allow or deny {{ech}} IP ranges](/deploy-manage/security/elastic-cloud-static-ips.md): {{ecloud}} publishes a list of IP addresses used by its {{ech}} services for both incoming and outgoing traffic. Users can use these lists to configure their network firewalls as needed to allow or restrict traffic related to {{ech}} services. \ No newline at end of file diff --git a/deploy-manage/security/_snippets/cluster-comparison.md b/deploy-manage/security/_snippets/cluster-comparison.md new file mode 100644 index 0000000000..1593c14cab --- /dev/null +++ b/deploy-manage/security/_snippets/cluster-comparison.md @@ -0,0 +1,86 @@ +Security feature availability varies by deployment type, with each feature having one of the following statuses: + +| Status | Description | +|--------|-------------| +| **Managed** | Handled automatically by Elastic with no user configuration needed | +| **Configurable** | Built-in feature that needs your configuration (like IP filters or passwords) | +| **Self-managed** | Infrastructure-level security you implement and maintain | +| **N/A** | Not available for this deployment type | + +Select your deployment type below to see what's available and how implementation responsibilities are distributed: + +::::{tab-set} +:group: deployment-type + +:::{tab-item} {{ech}} +:sync: cloud-hosted + +| Category | Security feature | Status | Description | +|------------------|------------|--------------|-------------| +| **Communication** | TLS (HTTP Layer) | Managed | Automatically configured by Elastic | +| | TLS (Transport Layer) | Managed | Automatically configured by Elastic | +| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | +| | Private link | Configurable | Establish secure VPC connection | +| | Static IPs | Configurable | Enable fixed IP addresses | +| **Data** | Encryption at rest | Managed | Automatically encrypted by Elastic | +| | Bring your own encryption key | Configurable | Implement customer-provided keys | +| | Keystore security | Managed | Automatically protected by Elastic | +| | Saved object encryption | Managed | Automatically encrypted by Elastic | +| **User Session** | Kibana Sessions | Configurable | Customize session parameters | + +::: + +:::{tab-item} {{serverless-full}} +:sync: serverless + +| Category| Security feature | Status | Description | +|------------------|------------|--------------|-------------| +| **Communication** | TLS (HTTP Layer) | Managed | Automatically configured by Elastic | +| | TLS (Transport Layer) | Managed | Automatically configured by Elastic | +| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | +| | Private link | N/A | X | +| | Static IPs | Configurable | Enable fixed IP addresses | +| **Data** | Encryption at rest | Managed | Automatically encrypted by Elastic | +| | Bring your own encryption key | N/A | X | +| | Keystore security | Managed | Automatically protected by Elastic | +| | Saved object encryption | Managed | Automatically encrypted by Elastic | +| **User Session** | Kibana Sessions | Managed | Automatically configured by Elastic | + +::: + +:::{tab-item} ECE/ECK +:sync: ece-eck + +| Category| Security feature | Status | Description | +|------------------|------------|--------------|-------------| +| **Communication** | TLS (HTTP Layer) | Configurable | Configure custom certificates | +| | TLS (Transport Layer) | Managed | Automatically configured by Elastic | +| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | +| | Private link | N/A | X | +| | Static IPs | N/A | X | +| **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | +| | Bring your own encryption key | N/A | X | +| | Keystore security | Configurable | Configure secure settings storage | +| | Saved object encryption | Configurable | Enable encryption for saved objects | +| **User Session** | Kibana Sessions | Configurable | Customize session parameters | + +::: + +:::{tab-item} Self-managed +:sync: self-managed + +| Category| Security feature | Status | Description | +|------------------|------------|--------------|-------------| +| **Communication** | TLS (HTTP Layer) | Self-managed | Implement and maintain certificates | +| | TLS (Transport Layer) | Self-managed | Implement and maintain certificates | +| **Network** | IP traffic filtering | Configurable | Configure IP-based access restrictions | +| | Private link | N/A | X | +| | Static IPs | N/A | X | +| **Data** | Encryption at rest | Self-managed | Implement at infrastructure level | +| | Bring your own encryption key | N/A | X | +| | Keystore security | Configurable | Configure secure settings storage | +| | Saved object encryption | Configurable | Enable encryption for saved objects | +| **User Session** | Kibana Sessions | Configurable | Customize session parameters | + +::: +:::: \ No newline at end of file diff --git a/deploy-manage/security/_snippets/cluster-data.md b/deploy-manage/security/_snippets/cluster-data.md new file mode 100644 index 0000000000..bd265d9fbe --- /dev/null +++ b/deploy-manage/security/_snippets/cluster-data.md @@ -0,0 +1,9 @@ +* [Secure your settings](/deploy-manage/security/secure-settings.md): Some of the settings that you configure in Elastic are sensitive, such as passwords, and relying on file system permissions to protect these settings is insufficient. Learn how to configure secure settings in the {{es}} keystore or {{kib}} keystore. +* [Secure saved objects](/deploy-manage/security/secure-saved-objects.md): {{kib}} stores entities such as dashboards, visualizations, alerts, actions, and advanced settings as saved objects, which are kept in a dedicated, internal {{es}} index. If such an object includes sensitive information, for example a PagerDuty integration key or email server credentials used by the alert action, {{kib}} encrypts it and makes sure it cannot be accidentally leaked or tampered with. You can configure and rotate the saved object encryption key for additional security. +* [Encrypt data at rest](/deploy-manage/security/data-security.md): By default, {{ecloud}} already encrypts your {{ech}} deployment data, Serverless project data, and snapshots at rest. If you’re using ECH, then you can reinforce this mechanism by providing your own encryption key, also known as [Bring Your Own Key (BYOK)](/deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md). + + ::::{note} + Other deployment types don’t implement encryption at rest out of the box. For self-managed clusters, to implement encryption at rest, the hosts running the cluster must be configured with disk-level encryption, such as `dm-crypt`. In addition, snapshot targets must ensure that data is encrypted at rest as well. + + Configuring `dm-crypt` or similar technologies is outside the scope of this documentation, and issues related to disk encryption are outside the scope of support. + :::: \ No newline at end of file diff --git a/deploy-manage/security/_snippets/cluster-user-session.md b/deploy-manage/security/_snippets/cluster-user-session.md new file mode 100644 index 0000000000..193e8b878e --- /dev/null +++ b/deploy-manage/security/_snippets/cluster-user-session.md @@ -0,0 +1 @@ +[Manage {{kib}} sessions](/deploy-manage/security/kibana-session-management.md) to control the timeout and lifespan of logged-in sessions to {{kib}}, as well as the number of concurrent sessions each user can have. \ No newline at end of file diff --git a/deploy-manage/security/_snippets/complete-security.md b/deploy-manage/security/_snippets/complete-security.md new file mode 100644 index 0000000000..cbbcac8446 --- /dev/null +++ b/deploy-manage/security/_snippets/complete-security.md @@ -0,0 +1,8 @@ +::::{note} +As part of your overall security strategy, you can also do the following: + +* Prevent unauthorized access with [password protection and role-based access control](/deploy-manage/users-roles.md). +* Control access to dashboards and other saved objects in your UI using [Spaces](/deploy-manage/manage-spaces.md). +* Connect a local cluster to a [remote cluster](/deploy-manage/remote-clusters.md) to enable [cross-cluster replication](/deploy-manage/tools/cross-cluster-replication.md) and [cross-cluster search](/solutions/search/cross-cluster-search.md). +* Manage [API keys](/deploy-manage/api-keys.md) used for programmatic access to Elastic. +:::: \ No newline at end of file diff --git a/deploy-manage/security/data-security.md b/deploy-manage/security/data-security.md index fba16c6d90..1e199e9ed2 100644 --- a/deploy-manage/security/data-security.md +++ b/deploy-manage/security/data-security.md @@ -2,38 +2,28 @@ applies_to: deployment: ess: ga - ece: ga - eck: ga - self: ga serverless: ga --- # Encrypt your deployment data -(orphan now, we should put this content somewhere) +{{ech}} deployments and {{serverless-full}} projects are already encrypted at rest by default. This includes their data, objects, and settings. -Add another layer of security by defining custom encryption rules for your cluster's data, {{kib}} saved objects, and settings. +For {{serverless-full}} projects, security is fully-managed by Elastic. -**In {{ecloud}}**: +For {{ech}} deployments, instead of the default, Elastic-managed encryption, you can choose to use a [customer-managed encryption key](encrypt-deployment-with-customer-managed-encryption-key.md) to encrypt your {{ech}} deployments. -{{ech}} deployments and serverless projects are already encrypted at rest by default. This includes their data, objects, and settings. For serverless projects, security is fully-managed by Elastic. For {{ech}} deployments, some settings are available for you to customize the default security measures in place: - -- Instead of the default, Elastic-managed encryption, you can choose to use a [customer-managed encryption key](encrypt-deployment-with-customer-managed-encryption-key.md) from one of our supported providers' KMS to encrypt your {{ech}} deployments. -- Store sensitive settings using the [{{es}} keystore](secure-settings.md). - -**In {{ece}}, {{eck}} and self-managed installations**: - -There is no encryption at rest out of the box for deployments orchestrated using [{{ece}}](secure-your-elastic-cloud-enterprise-installation.md) and [{{eck}}](secure-your-eck-installation.md), and for [self-managed clusters](manually-configure-security-in-self-managed-cluster.md). You must instead configure disk-level encryption on your hosts. :::{note} +There is no encryption at rest out of the box for deployments orchestrated using [{{ece}}](secure-your-elastic-cloud-enterprise-installation.md) and [{{eck}}](secure-your-eck-installation.md), or for [self-managed clusters](manually-configure-security-in-self-managed-cluster.md). You must instead configure disk-level encryption on your hosts. + Configuring dm-crypt or similar technologies is outside the scope of the Elastic documentation, and issues related to disk encryption are outside the scope of support. ::: -However, some native features are available for you to protect sensitive data and objects: + +:::{tip} +As an alternative to or in addition to encryption at rest, you can also use the following features to encrypt sensitive data and objects: - Store sensitive settings using the [{{es}} or {{kib}} keystores](secure-settings.md). - Enable [encryption for {{kib}} saved objects](secure-saved-objects.md). -- Customize [{{kib}} session parameters](kibana-session-management.md). - - - +::: \ No newline at end of file diff --git a/deploy-manage/security/elastic-cloud-static-ips.md b/deploy-manage/security/elastic-cloud-static-ips.md index 44beeaf633..9b7a580ed0 100644 --- a/deploy-manage/security/elastic-cloud-static-ips.md +++ b/deploy-manage/security/elastic-cloud-static-ips.md @@ -8,10 +8,12 @@ mapped_pages: # {{ecloud}} Static IPs [ec-static-ips] -{{ecloud}} provides a range of static IP addresses that enable you to allow or deny IP ranges. There are two types of static IP addresses, [ingress](#ec-ingress) and [egress](#ec-egress), and they each have their own set of use cases. In general, static IPs can be used to introduce network controls (for example, firewall rules) for traffic that goes to and from {{ecloud}} deployments over the Internet. Use of static IPs is not applicable to private cloud service provider connections (for example, AWS/Azure PrivateLink, GCP Private Service Connect). It is important to note that static IP addresses are [subject to change](#ec-warning), and not all [cloud provider regions](#ec-regions) are currently fully supported for ingress and egress static IPs. +{{ecloud}} provides a range of static IP addresses that enable you to allow or deny IP ranges. There are two types of static IP addresses, [ingress](#ec-ingress) and [egress](#ec-egress), and they each have their own set of use cases. In general, static IPs can be used to introduce network controls (for example, firewall rules) for traffic that goes to and from {{ecloud}} deployments over the Internet. Use of static IPs is not applicable to private cloud service provider connections (for example, AWS/Azure PrivateLink, GCP Private Service Connect). +Static IP addresses are [subject to change](#ec-warning), and not all [cloud provider regions](#ec-regions) are currently fully supported for ingress and egress static IPs. For this reason, we generally do not recommend that you use firewall rules to allow or restrict certain IP ranges. Consider using [private link](/deploy-manage/security/private-link-traffic-filters.md) traffic filters for deployment endpoints on {{ech}}. However, in situations where using Private Link services do not meet requirements (for example, secure traffic **from** {{ecloud}}), static IP ranges can be used. -## Ingress Static IPs: Traffic To {{ecloud}} [ec-ingress] + +## Ingress Static IPs: Traffic to {{ecloud}} [ec-ingress] Suitable usage of ingress static IPs to introduce network controls: @@ -118,7 +120,7 @@ Not suitable usage of egress static IPs to introduce network controls: ::::{warning} :name: ec-warning -Static IP ranges are subject to change. You will need to update your firewall rules when they change to prevent service disruptions. We will announce changes at least 8 weeks in advance (see [example](https://status.elastic.co/incidents/1xs411x77wgh)). Please subscribe to the [{{ecloud}} Status Page](https://status.elastic.co/) to remain up to date with any changes to the Static IP ranges which you will need to update at your side. +Static IP ranges are subject to change. You will need to update your firewall rules when they change to prevent service disruptions. We will announce changes at least 8 weeks in advance (see [example](https://status.elastic.co/incidents/1xs411x77wgh)). Please subscribe to the [{{ecloud}} status page](https://status.elastic.co/) to remain up to date with any changes to the Static IP ranges which you will need to update at your side. :::: diff --git a/deploy-manage/security/limitations.md b/deploy-manage/security/limitations.md index 7546c2c497..451c03f1da 100644 --- a/deploy-manage/security/limitations.md +++ b/deploy-manage/security/limitations.md @@ -6,7 +6,7 @@ navigation_title: Limitations # Security limitations [security-limitations] - +Review the following {{es}} security limitations. Depending on your organization's security requirements, you might want to restrict, adjust, or find workaround or alternatives for some of these features and resources. ## Plugins [_plugins] @@ -20,12 +20,12 @@ navigation_title: Limitations ## Multi document APIs [_multi_document_apis] -Multi get and multi term vectors API throw IndexNotFoundException when trying to access non existing indices that the user is not authorized for. By doing that they leak information regarding the fact that the data stream or index doesn’t exist, while the user is not authorized to know anything about those data streams or indices. +Multi get and multi term vectors API throw `IndexNotFoundException` when trying to access non existing indices that the user is not authorized for. By doing that they leak information regarding the fact that the data stream or index doesn’t exist, while the user is not authorized to know anything about those data streams or indices. ## Filtered index aliases [_filtered_index_aliases] -Aliases containing filters are not a secure way to restrict access to individual documents, due to the limitations described in [Index and field names can be leaked when using aliases](/deploy-manage/security.md#alias-limitations). The {{stack-security-features}} provide a secure way to restrict access to documents through the [document-level security](/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md) feature. +Aliases containing filters are not a secure way to restrict access to individual documents, due to the limitations described in [Index and field names can be leaked when using aliases](#alias-limitations). The {{stack-security-features}} provide a secure way to restrict access to documents through the [document-level security](/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md) feature. ## Field and document level security limitations [field-document-limitations] diff --git a/deploy-manage/security/secure-clients-integrations.md b/deploy-manage/security/secure-clients-integrations.md index 6b6ed82527..b8054cf1f0 100644 --- a/deploy-manage/security/secure-clients-integrations.md +++ b/deploy-manage/security/secure-clients-integrations.md @@ -3,30 +3,17 @@ mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-clients-integrations.html --- -# Secure clients and integrations [security-clients-integrations] +# Secure other {{stack}} components -:::{warning} -**This page is a work in progress.** -::: - - -You will need to update the configuration for several [clients](httprest-clients-security.md) to work with a secured {{es}} cluster. - -The {{es}} {{security-features}} enable you to secure your {{es}} cluster. But {{es}} itself is only one product within the {{stack}}. It is often the case that other products in the {{stack}} are connected to the cluster and therefore need to be secured as well, or at least communicate with the cluster in a secured way: +The {{es}} {{security-features}} enable you to secure your {{es}} cluster. However, {{es}} itself is only one product within the {{stack}}. Other products in the {{stack}} are connected to the cluster and therefore need to be secured as well, or at least communicate with the cluster in a secured way. Review the guides for other {{es}} products: * [Apache Hadoop](elasticsearch-hadoop://reference/security.md) * [Auditbeat](beats://reference/auditbeat/securing-auditbeat.md) * [Filebeat](beats://reference/filebeat/securing-filebeat.md) * [{{fleet}} & {{agent}}](/reference/fleet/secure.md) * [Heartbeat](beats://reference/heartbeat/securing-heartbeat.md) -* [{{kib}}](../security.md) * [Logstash](logstash://reference/secure-connection.md) * [Metricbeat](beats://reference/metricbeat/securing-metricbeat.md) -* [Monitoring and security](../monitor.md) * [Packetbeat](beats://reference/packetbeat/securing-packetbeat.md) * [Reporting](../../explore-analyze/report-and-share.md) -* [Winlogbeat](beats://reference/winlogbeat/securing-winlogbeat.md) - - - - +* [Winlogbeat](beats://reference/winlogbeat/securing-winlogbeat.md) \ No newline at end of file diff --git a/deploy-manage/security/secure-cluster-communications.md b/deploy-manage/security/secure-cluster-communications.md index 8f08921831..084f647bb4 100644 --- a/deploy-manage/security/secure-cluster-communications.md +++ b/deploy-manage/security/secure-cluster-communications.md @@ -31,6 +31,7 @@ For ECE, ECK, and self-managed deployments, this page provides specific configur For a complete comparison of security feature availability and responsibility by deployment type, see [Security features by deployment type](/deploy-manage/security.md#comparison-table). ::: + ## Communication channels overview Your {{stack}} deployment includes several distinct communication channels that must be secured to protect your data and infrastructure. @@ -46,8 +47,9 @@ Your {{stack}} deployment includes several distinct communication channels that 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. +The way that transport layer security is managed depends on your deployment type: + +- **ECH, ECE, and Serverless**: Transport security is fully managed by Elastic. No configuration is required. - **ECK**: Transport security is automatically configured by the operator, but you can [customize its service and SSL certificates](/deploy-manage/security/k8s-transport-settings.md). - **Self-managed**: Transport security must be manually configured following the steps in [Set up basic security](set-up-basic-security.md). @@ -55,30 +57,32 @@ The transport layer is used for communication between {{es}} nodes in a cluster. 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. +The way that HTTP layer security is managed depends on your deployment type: + +- **ECH and Serverless**: HTTP security is fully managed by Elastic. No configuration is required. - **ECE**: HTTP security is automatically enforced at ECE proxies using self-signed certificates and a default [wildcard DNS record](/deploy-manage/deploy/cloud-enterprise/ece-wildcard-dns.md). However, it's recommended to [configure your own certificates](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). -- **ECK**: HTTP security is automatically configured with self-signed certificates. Custom certificates and domain names can be configured. -- **Self-managed**: HTTP security must be manually configured following [Secure HTTP communications](secure-http-communications.md). +- **ECK**: HTTP security is automatically configured with self-signed certificates. [Custom certificates and domain names can be configured](/deploy-manage/security/secure-http-communications.md#k8s-custom-http-certificate). +- **Self-managed**: HTTP security must be manually configured following [](secure-http-communications.md). ## {{kib}}-to-{{es}} communications {{kib}} connects to {{es}} as a client but requires special configuration as it performs operations on behalf of end users. -**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). +The way that {{kib}}-to-{{es}} communication security is managed depends on your deployment type: + +- **ECH and Serverless**: {{kib}}-{{es}} communication is fully managed using HTTPS and service tokens. +- **ECE and ECK**: {{kib}}-{{es}} communication is automatically secured with service tokens. +- **Self-managed**: {{kib}}-{{es}} communication must be manually secured. For mutual TLS configuration, refer to [Mutual TLS authentication between {{kib}} and {{es}}](secure-http-communications.md#elasticsearch-mutual-tls). ## Certificate management [generate-certificates] Managing certificates is critical for secure communications. Certificates have limited lifetimes and must be renewed before expiry to prevent service disruptions. -**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). +The way that you manage certificates depends on your deployment type: -**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. +- **ECH and Serverless**: Certificate management is fully automated by Elastic. +- **ECE**: ECE generates certificates for you. Refer to [](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md). +- **ECK**: ECK provides flexible options for managing SSL certificates in your deployments, including automatic certificate generation and rotation, integration with external tools like `cert-manager`, or using your own custom certificates. Custom HTTP certificates require manual management. - **Self-managed**: Certificate management is your responsibility. See [Security certificates and keys](security-certificates-keys.md). ## Next steps diff --git a/deploy-manage/security/secure-your-cluster-deployment.md b/deploy-manage/security/secure-your-cluster-deployment.md index 87d6ecb7fa..13926288d2 100644 --- a/deploy-manage/security/secure-your-cluster-deployment.md +++ b/deploy-manage/security/secure-your-cluster-deployment.md @@ -9,67 +9,61 @@ applies_to: # Secure your cluster or deployment -$$$install-stack-demo-secure-agent$$$ +It's important to protect your {{es}} cluster and the data it contains. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. -$$$install-stack-demo-secure-ca$$$ - -$$$install-stack-demo-secure-fleet$$$ - -$$$install-stack-demo-secure-http$$$ - -$$$install-stack-demo-secure-kib-es$$$ - -$$$install-stack-demo-secure-prereqs$$$ - -$$$install-stack-demo-secure-second-node$$$ - -$$$install-stack-demo-secure-transport$$$ - -$$$install-stack-demo-secure-view-data$$$ - -$$$security-configure-settings$$$ - - -Protecting your {{es}} cluster and the data it contains is of utmost importance. Implementing a defense in depth strategy provides multiple layers of security to help safeguard your system. +:::{include} /deploy-manage/security/_snippets/complete-security.md +::: :::{important} -Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. +* Never run an {{es}} cluster without security enabled. This principle cannot be overstated. Running {{es}} without security leaves your cluster exposed to anyone who can send network traffic to {{es}}, permitting these individuals to download, modify, or delete any data in your cluster. +* Never try to run {{es}} as the `root` user, which would invalidate any defense strategy and permit a malicious user to do **anything** on your server. You must create a dedicated, unprivileged user to run {{es}}. By default, the `rpm`, `deb`, `docker`, and Windows packages of {{es}} contain an `elasticsearch` user with this scope. ::: -To secure your clusters and deployments, consider the following: +:::{tip} +You must secure [other {{stack}} components](/deploy-manage/security/secure-clients-integrations.md), as well as [client and integration communications](/deploy-manage/security/httprest-clients-security.md), separately. +::: -## Network access +You can configure the following aspects of your Elastic cluster or deployment to maintain and enhance security: -Control which systems can access your Elastic deployments and clusters through traffic filtering and network controls: +## Communication and network security -- **IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges. -- **Private link filters**: Secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect. -- **Static IPs**: Use static IP addresses for predictable firewall rules. -- **Remote cluster access**: Secure cross-cluster operations. +:::{include} /deploy-manage/security/_snippets/cluster-communication-network.md +::: -Refer to [](traffic-filtering.md). +## Data security +:::{include} /deploy-manage/security/_snippets/cluster-data.md +::: + +## User session security -## Cluster communication +:::{include} /deploy-manage/security/_snippets/cluster-user-session.md +::: -- **HTTP and HTTPs** -- **TLS certificates and keys** +## Security event audit logging +:::{include} /deploy-manage/security/_snippets/audit-logging.md +::: -## Data, objects and settings security +## Configure security in a self-managed cluster -- **Bring your own encryption key**: Use your own encryption key instead of the default encryption at rest provided by Elastic. -- **{{es}} and {{kib}} keystores**: Secure sensitive settings using keystores -- **{{kib}} saved objects**: Customize the encryption for {{kib}} objects such as dashboards. -- **{{kib}} session management**: Customize {{kib}} session expiration settings. +Since {{es}} 8.0, security is enabled and configured by default. However, security auto configuration [might be skipped](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md#stack-skip-auto-configuration) in certain scenarios. In these cases, you can [manually configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md). -Refer to [](data-security.md). +## FIPS 140-2 compliant mode +```{applies_to} +deployment: + self: + eck: +``` -## User roles +The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB 140-2), titled "Security Requirements for Cryptographic Modules" is a U.S. government computer security standard used to approve cryptographic modules. You can run a self-managed cluster or {{eck}} cluster in FIPS-compliant mode: -[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. +* [Self-managed](/deploy-manage/security/fips-140-2.md) +* [ECK](/deploy-manage/deploy/cloud-on-k8s/deploy-fips-compatible-version-of-eck.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. -::: +% we need to refine this table, but the idea is awesome IMO + +## Security features by deployment type [comparison-table] +:::{include} /deploy-manage/security/_snippets/cluster-comparison.md +::: \ No newline at end of file diff --git a/deploy-manage/security/traffic-filtering.md b/deploy-manage/security/traffic-filtering.md index a14cf03fdd..97fba30f97 100644 --- a/deploy-manage/security/traffic-filtering.md +++ b/deploy-manage/security/traffic-filtering.md @@ -19,8 +19,9 @@ Traffic filtering allows you to limit how your deployments and clusters can be a Depending on your deployment type you can use different mechanisms to restrict traffic, such as [IP filters](./ip-traffic-filtering.md), [private links](./private-link-traffic-filters.md) provided by cloud platforms, or [Kubernetes network policies](./k8s-network-policies.md). + ::::{note} -This section covers traffic filtering at the deployment level. If you need the IP addresses used by Elastic Cloud to configure them in your network firewalls, refer to [](./elastic-cloud-static-ips.md). +This section covers traffic filtering at the deployment level. If you need the IP addresses used by {{ech}} to configure them in your network firewalls, refer to [](./elastic-cloud-static-ips.md). :::: :::::{tab-set} diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 5473733975..c13f5fcefc 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -508,8 +508,7 @@ toc: - file: security/install-stack-demo-secure.md - file: security/fips-140-2.md - file: security/secure-clients-integrations.md - children: - - file: security/httprest-clients-security.md + - file: security/httprest-clients-security.md - file: security/limitations.md - file: users-roles.md children: diff --git a/deploy-manage/tools/cross-cluster-replication.md b/deploy-manage/tools/cross-cluster-replication.md index dfc2445bd0..c62c86ad78 100644 --- a/deploy-manage/tools/cross-cluster-replication.md +++ b/deploy-manage/tools/cross-cluster-replication.md @@ -67,7 +67,7 @@ Use {{ccr}} to construct several multi-cluster architectures within the Elastic Watch the [{{ccr}} webinar](https://www.elastic.co/webinars/replicate-elasticsearch-data-with-cross-cluster-replication-ccr) to learn more about the following use cases. Then, [set up {{ccr}}](cross-cluster-replication/set-up-cross-cluster-replication.md) on your local machine and work through the demo from the webinar. ::::{important} -In all of these use cases, you must [configure security](../security/manually-configure-security-in-self-managed-cluster.md) independently on every cluster. The security configuration is not replicated when configuring {{ccr}} for disaster recovery. To ensure that the {{es}} `security` feature state is backed up, [take snapshots](snapshot-and-restore/create-snapshots.md#back-up-specific-feature-state) regularly. You can then restore the native users, roles, and tokens from your security configuration. +In all of these use cases, you must [configure security](/deploy-manage/security/manually-configure-security-in-self-managed-cluster.md) independently on every cluster. The security configuration is not replicated when configuring {{ccr}} for disaster recovery. To ensure that the {{es}} `security` feature state is backed up, [take snapshots](snapshot-and-restore/create-snapshots.md#back-up-specific-feature-state) regularly. You can then restore the native users, roles, and tokens from your security configuration. :::: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md b/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md index 20fe71fe98..c292e52632 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md @@ -52,7 +52,7 @@ The specified document query: * Expects the same format as if it was defined in the search request * Supports [templating a role query](#templating-role-query) that can access the details of the currently authenticated user * Accepts queries written as either string values or nested JSON -* Supports the majority of the {{es}} [Query DSL](/explore-analyze/query-filter/languages/querydsl.md), with [some limitations](../../../deploy-manage/security.md#field-document-limitations) for field and document level security +* Supports the majority of the {{es}} [Query DSL](/explore-analyze/query-filter/languages/querydsl.md), with [some limitations](/deploy-manage/security/limitations.md#field-document-limitations) for field and document level security ::::{important} Omitting the `query` parameter entirely disables document level security for the respective indices permission entry.