Clean up

Author: leemthompo

deploy-manage/security/manually-configure-security-in-self-managed-cluster.md

@@ -15,32 +15,32 @@ 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
 
-::::{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.
-::::
+### Minimal security ({{es}} Development) [security-minimal-overview]
 
+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,25 +49,14 @@ 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}}.
 
-::::{note}
 If you need mutual (bidirectional) TLS on the HTTP layer, then you’ll need to configure mutual authenticated encryption.
-::::
-
-
-You then configure {{kib}} and Beats to communicate with {{es}} using TLS so that all communications are encrypted. This level of security is strong, and ensures that any communications in and out of your cluster are secure.
 
 [Set up basic security plus HTTPS traffic](secure-http-communications.md)
 
-
-
-
-
-
-
-
-
+:::{image} ../../images/elasticsearch-reference-elastic-security-overview.png
+:alt: Elastic Security layers
+:::

deploy-manage/security/secure-your-cluster-deployment.md

@@ -1,24 +1,14 @@
 ---
-mapped_urls:
-  - https://www.elastic.co/guide/en/elasticsearch/reference/current/es-security-principles.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
-
-
-**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)
 
 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.
 

raw-migrated-files/elasticsearch/elasticsearch-reference/es-security-principles.md

@@ -156,7 +156,6 @@ toc:
       - file: elasticsearch/elasticsearch-reference/change-passwords-native-users.md
       - file: elasticsearch/elasticsearch-reference/configuring-stack-security.md
       - 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/fips-140-compliance.md
       - file: elasticsearch/elasticsearch-reference/how-monitoring-works.md