You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An Elastic implementation comprises many moving parts. There are the Elasticsearch nodes that form the cluster, Kibana instances, additional stack components such as Logstash and Beats, and clients and integrations all communicating with your cluster.
61
+
62
+
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.
63
+
64
+
In this section, you’ll learn about how to manage basic Elastic security features. You’ll also learn how to implement advanced security measures.
65
+
66
+
As part of your overall security strategy, you can also do the following:
67
+
68
+
- Prevent unauthorized access with [password protection and role-based access control].
69
+
- Maintain an [audit trail] for security-related events.
70
+
- Control access to dashboards and other saved objects in your UI using [Spaces].
71
+
- Connect a local cluster to a [remote cluster] to enable cross-cluster replication and search.
72
+
- Manage [API keys] used for programmatic access to Elastic.
73
+
74
+
75
+
76
+
Keeping your Elastic installation and data safe generally means:
77
+
78
+
- Securing the hosting environment where your Elastic products are deployed.
79
+
- self-managed
80
+
- TLS certificates
81
+
- HTTPS
82
+
- ECE
83
+
- TLS certificates
84
+
- Cloud RBAC
85
+
- ECH and Serverless
86
+
- SSO
87
+
- Role-based access control
88
+
- Securing the deployments and clusters within that environment.
89
+
- Authentication and access
90
+
-`elastic` power user, built-in and system user passwords
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}}.
22
27
@@ -28,7 +33,7 @@ The minimal security scenario is not sufficient for [production mode](../deploy/
28
33
[Set up minimal security](set-up-minimal-security.md)
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.
34
39
@@ -37,7 +42,7 @@ Your external HTTP traffic between {{es}} and {{kib}} won’t be encrypted, but
37
42
[Set up basic security](secure-cluster-communications.md)
38
43
39
44
40
-
## Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview]
45
+
###Basic security plus secured HTTPS traffic ({{stack}}) [security-basic-https-overview]
41
46
42
47
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}}.
43
48
@@ -50,6 +55,24 @@ You then configure {{kib}} and Beats to communicate with {{es}} using TLS so tha
50
55
51
56
[Set up basic security plus HTTPS traffic](secure-http-communications.md)
52
57
58
+
## Considerations
59
+
60
+
### TLS certificate management
61
+
62
+
TLS certificates apply security controls to network communications. They encrypt data in transit, verify the identity of connecting parties, and help prevent man-in-the-middle attacks.
63
+
64
+
On **self-managed** installations, you manage certificates for both HTTP and transport layers.
65
+
66
+
### Network security
67
+
68
+
Control which systems can access your Elastic deployment through traffic filtering and network controls:
69
+
70
+
-**IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges.
71
+
72
+
## Next step: secure your deployments and clusters
73
+
74
+
This section covered security principles and options at the environment level. You can take further measures individually for each deployment or cluster that you're running on your installation. Refer to [](secure-your-cluster-deployment.md).
Whether you're running Elastic on {{ecloud}}, through an {{ece}} or {{eck}} orchestrator, or self-managed on your own premises, it is critical that you secure the layer responsible for deploying and hosting your Elastic products.
10
+
11
+
This section covers security measures specific to:
# Secure your {{eck}} installation [eck-securing-considerations]
9
+
10
+
**This page is a work in progress.**
11
+
12
+
## TLS certificate management
13
+
14
+
TLS certificates apply security controls to network communications. They encrypt data in transit, verify the identity of connecting parties, and help prevent man-in-the-middle attacks.
15
+
16
+
With **{{eck}}**, you manage HTTP layer certificates. The transport layer is managed by ECK.
17
+
18
+
## Network security
19
+
20
+
Control which systems can access your Elastic deployment through traffic filtering and network controls:
21
+
22
+
-**IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges.
23
+
24
+
## Next step: secure your deployments and clusters
25
+
26
+
This section covered security principles and options at the environment level. You can take further measures individually for each deployment or cluster that you're running on your installation. Refer to [](secure-your-cluster-deployment.md).
# Secure your Elastic Cloud Enterprise installation [ece-securing-considerations]
7
11
8
-
Elastic Cloud Enterprise can run on shared and less secure environments, but you should be aware of some limitations when deploying our product.
12
+
**This page is a work in progress.**
9
13
14
+
When securing your {{ece}} installation, consider the following:
10
15
11
-
### Users with admin privileges [ece_users_with_admin_privileges]
16
+
##TLS certificate management
12
17
13
-
In Elastic Cloud Enterprise 3.8.1, every user who can manage your installation through the Cloud UI or the RESTful API is a user with admin privileges. This includes both the `admin` user and the `readonly` user that get created when you install ECE on your first host. Initially, only the `admin` user has the required privileges to make changes to resources on ECE.
18
+
TLS certificates apply security controls to network communications. They encrypt data in transit, verify the identity of connecting parties, and help prevent man-in-the-middle attacks.
14
19
15
-
[Role-based access control](../users-roles/cloud-enterprise-orchestrator/manage-users-roles.md) for Elastic Cloud Enterprise allows you to connect multiple users or user groups to the platform.
20
+
With {{ece}}, you manage proxy certificates for the HTTP layer. The transport layer is managed by ECE. Refer to [](secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md).
16
21
17
-
All Elasticsearch clusters come with X-Pack security features and support role-based access control. To learn more, check [Secure Your Clusters](../users-roles/cluster-or-deployment-auth.md).
22
+
## Network security
23
+
24
+
Control which systems can access your Elastic deployment through traffic filtering and network controls:
18
25
26
+
-**IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges.
27
+
-**Trust for cross-cluster operations**. Define which environments your {{ece}} installation can connect to and receive connections from. For more details on cross-cluster operations and the required settings, refer to [](/deploy-manage/remote-clusters.md).
19
28
20
-
### Clusters share the same resources [ece_clusters_share_the_same_resources]
29
+
$$$ece_clusters_share_the_same_resources$$$
30
+
:::{note}
31
+
Clusters share the same resources
21
32
22
33
The Elasticsearch clusters you create on Elastic Cloud Enterprise share the same resources. It is currently not possible to run a specific cluster on entirely dedicated hardware not shared by other clusters.
34
+
:::
35
+
36
+
## Users with admin privileges [ece_users_with_admin_privileges]
37
+
38
+
In Elastic Cloud Enterprise, every user who can manage your installation through the Cloud UI or the RESTful API is a user with admin privileges. This includes both the `admin` user and the `readonly` user that get created when you install ECE on your first host. Initially, only the `admin` user has the required privileges to make changes to resources on ECE.
39
+
40
+
[Role-based access control](../users-roles/cloud-enterprise-orchestrator/manage-users-roles.md) for Elastic Cloud Enterprise allows you to connect multiple users or user groups to the platform.
41
+
42
+
All Elasticsearch clusters come with X-Pack security features and support role-based access control. To learn more, check [Secure Your Clusters](../users-roles/cluster-or-deployment-auth.md).
23
43
24
44
25
-
###Encryption [ece_encryption]
45
+
## Encryption [ece_encryption]
26
46
27
47
Elastic Cloud Enterprise does not implement encryption at rest out of the box. To ensure encryption at rest for all data managed by Elastic Cloud Enterprise, the hosts running Elastic Cloud Enterprise 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.
28
48
29
49
Configuring dm-crypt or similar technologies is outside the scope of the Elastic Cloud Enterprise documentation, and issues related to disk encryption are outside the scope of support.
30
50
31
-
Elastic Cloud Enterprise provides full encryption of all network traffic by default when using Elasticsearch 6.0 or higher.
51
+
Elastic Cloud Enterprise provides full encryption of all network traffic by default.
32
52
33
-
TLS is supported when interacting with the RESTful API of Elastic Cloud Enterprise and for the proxy layer that routes user requests to clusters of all versions. Internally, our administrative services also ensure transport-level encryption.
34
-
35
-
In Elasticsearch versions lower than 6.0, traffic between nodes in a cluster and between proxies and the clusters is *not* encrypted.
53
+
TLS is supported when interacting with the [RESTful API of Elastic Cloud Enterprise](https://www.elastic.co/docs/api/doc/cloud-enterprise/) and for the proxy layer that routes user requests to clusters of all versions. Internally, our administrative services also ensure transport-level encryption.
36
54
37
55
38
56
## Attack vectors versus separation of roles [ece-securing-vectors]
@@ -45,3 +63,7 @@ Elastic Cloud Enterprise is designed to ensure that an allocator has access only
45
63
46
64
Security comes in layers, and running separate services on separate infrastructure is the last layer of defense, on top of other security features like the JVM security manager, system call filtering, and running nodes in isolated containers with no shared secrets.
47
65
66
+
## Next step: secure your deployments and clusters
67
+
68
+
This section covered security principles and options at the environment level. You can take further measures individually for each deployment or cluster that you're running on your installation. Refer to [](secure-your-cluster-deployment.md).
# Secure your Elastic Cloud organization [ec-securing-considerations]
10
+
11
+
**This page is a work in progress.**
12
+
13
+
## TLS certificate management
14
+
15
+
TLS certificates apply security controls to network communications. They encrypt data in transit, verify the identity of connecting parties, and help prevent man-in-the-middle attacks.
16
+
17
+
For your **{{ech}}** deployments and serverless projects hosted on {{ecloud}}, TLS certificates are managed automatically.
18
+
19
+
## Network security
20
+
21
+
Control which systems can access your Elastic deployment through traffic filtering and network controls:
22
+
23
+
-**IP traffic filtering**: Restrict access based on IP addresses or CIDR ranges.
24
+
-**Private link filters**: Secure connectivity through AWS PrivateLink, Azure Private Link, or GCP Private Service Connect.
25
+
-**Static IPs**: Use static IP addresses for predictable firewall rules.
26
+
27
+
28
+
## Next step: secure your deployments and clusters
29
+
30
+
This section covered security principles and options at the environment level. You can take further measures individually for each deployment or cluster that you're running on your installation. Refer to [](secure-your-cluster-deployment.md).
0 commit comments