From 631930de011ce3da4b998c230d6f4a1d141a2784 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 16 Sep 2024 17:52:04 -0700
Subject: [PATCH 01/30] Edit security index.md

---
 content/en/docs/security/_index.md | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md
index 85c229f08e23..c93493f075c4 100644
--- a/content/en/docs/security/_index.md
+++ b/content/en/docs/security/_index.md
@@ -1,4 +1,27 @@
 ---
-title: Security
-weight: 970
+title: Security in OpenTelemetry
+description: Security in OpenTelemetry
+weight: 10
 ---
+
+When setting up the OpenTelemetry (OTel) Collector, consider implementing
+security best practices in both your hosting infrastructure and your OTel
+Collector configuration. Running a secure Collector can help you
+
+- Protect telemetry that might contain sensitive information, such as personally
+  identifiable information (PII), application-specific data, or network traffic
+  patterns.
+- Prevent data tampering that makes telemetry unreliable and disrupts incident
+  responses.
+- Comply with data privacy and security regulations.
+- Defend against denial of service (DoS) attacks.
+
+See [Hosting best pracices](/security/otel-collector-hosting-best-practices) to
+learn how to secure your Collector's infrastructure.
+
+See
+[Configuration best practices](/security/otel-collector-configuration-best-practices)
+to learn how to securely configure your Collector.
+
+For Collector component developers, see
+[Security best practices](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md).

From 2dc2e17830d75e9720d9f0cb63c435b6e306e3c5 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 16 Sep 2024 17:53:21 -0700
Subject: [PATCH 02/30] Copy content into config-best-practices.md

---
 .../en/docs/security/config-best-practices.md | 152 ++++++++++++++++++
 1 file changed, 152 insertions(+)
 create mode 100644 content/en/docs/security/config-best-practices.md

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
new file mode 100644
index 000000000000..0d726395eb43
--- /dev/null
+++ b/content/en/docs/security/config-best-practices.md
@@ -0,0 +1,152 @@
+---
+title: Collector configuration best practices
+linkTitle: Collector config
+description: Best practices to securely configure OpenTelemetry Collector.
+weight: 20
+---
+
+When configuring the OpenTelemetry (OTel) Collector, consider the following
+practices to better secure your Collector instance.
+
+## Receivers and exporters
+
+We recommend enabling only the minimum required components for a Collector
+configuration: one receiver and one exporter. Configuring only the minimum set
+of components exposes a minimum set of required ports.
+
+- Receivers and exporters can be either push- or pull-based. In either case, the
+  connection established should be over a secure and authenticated channel.
+- Unused receivers and exporters should be disabled to minimize the attack
+  vector of the Collector.
+- Receivers and exporters might expose buffer, queue, payload, and worker
+  settings using configuration parameters. If these settings are available, you
+  should proceed with caution before modifying the default configuration values.
+  Improperly setting these values might expose the OpenTelemetry Collector to
+  additional attack vectors including resource exhaustion.
+
+### Safeguards against denial of service attacks
+
+Bind receivers' servers to addresses that limit connections to authorized users,
+so that your Collectors aren't exposed to the public internet or to wider
+networks than necessary.
+
+For example, if the OTLP receiver OTLP/gRPC server has only local clients, bind
+the `endpoint` setting to `localhost`:
+
+```yaml
+receivers:
+  otlp:
+    protocols:
+      grpc:
+        endpoint: localhost:4317
+```
+
+Use `localhost`-like addresses instead of `0.0.0.0`. For more information, see
+[CWE-1327: Binding to an Unrestricted IP Address](https://cwe.mitre.org/data/definitions/1327.html).
+
+To change the default endpoint to be `localhost`-bound in all components, enable
+the `component.UseLocalHostAsDefaultHost` feature gate. This feature gate will
+be enabled by default in the Collector in a future release.
+
+### Encryption and authentication
+
+Your OTel Collector configuration should include encryption and authentication.
+
+- For communication encryption, see
+  [Configuring certificates](/collector/configuration/#setting-up-certificates).
+- For authentication, use the OTel Collector's authentication mechanism, as
+  described in [Authentication](/collector/configuration/#authentication).
+
+## Processors
+
+Processors sit between receivers and exporters. They are responsible for
+processing telemetry before it's analyzed. From a security perspective,
+processors are useful in a few ways.
+
+### Recommended processors
+
+<!--- TODO: SHOULD configure recommended processors. If so, what are they? -->
+
+    redactionprocessor (never tried myself)
+    transformprocessor (great for redacting PIIs and such)
+
+### Scrubbing sensitive data
+
+You can use the OpenTelemetry Collector to scrub sensitive data before exporting
+it to a back end. Configure the Collector to obfuscate or scrub sensitive data
+before exporting.
+
+<!--- TODO: SHOULD configure obfuscation/scrubbing of sensitive metadata. How? Give more details and/or link to an existing document -->
+
+Use OpenTelemetry Collector's `redaction` processor to scrub sensitive data.
+
+<!--- TODO: Give example config for the redaction processor or remove this line. --->
+
+### Safeguarding resource utilization
+
+Processors also offer safeguards for resource utilization. After implementing
+[safeguards resource utilization in your hosting infrastructure](/security/hosting-best-practices/),
+make sure your OpenTelemetry Collector configuration uses these safeguards.
+
+<!-- start same page content in hosting-best-practices -->
+
+The `batch` processor helps ensure the OpenTelemetry Collector is resource
+efficient and does not run out of memory when overloaded.
+
+For more information on recommended processors and order, refer to the
+[OpenTelemetry Collector Processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor)
+documentation.
+
+<!-- /end same page content in hosting-best-practices -->
+
+## Extensions
+
+While receivers, processors, and exporters handle telemetry directly, extensions
+serve different needs.
+
+<!--- TODO: Extensions SHOULD NOT expose sensitive health or telemetry data. How? What can you do? -->
+
+### Health and telemetry
+
+Extensions are available for health check information, Collector metrics and
+traces, and generating and collecting profiling data. When enabled with their
+default settings, all of these extensions, except the health check extension,
+are accessible only locally to the OpenTelemetry Collector. Take care to protect
+sensitive information when configuring these extensions for remote access, as
+they might expose it accidentally.
+
+### Forwarding
+
+A forwarding extension is used when you need to collect telemetry that's not
+natively supported by the Collector. For example, the `http_forwarder` extension
+can receive and forward HTTP payloads. Forwarding extensions are similar to
+receivers and exporters so the same security considerations apply.
+
+### Collector's internal telemetry
+
+<!--- INSERT RECOMMENDATIONS HERE. For example:
+
+1. Remove zPages.
+1. Remove configuration endpoints.
+-->
+
+### Observers
+
+An observer is a component that discovers services in endpoints. Other
+components of the OpenTelemetry Collector, such as receivers, can subscribe to
+these extensions to be notified of endpoints coming or going.
+
+Observers might require certain permissions in order to discover services. For
+example, the `k8s_observer` requires certain RBAC permissions in Kubernetes,
+while the `host_observer` requires the OpenTelemetry Collector to run in
+privileged mode.
+
+<!--- But what about Juraci's comment here: https://github.com/open-telemetry/opentelemetry.io/pull/3652/files?diff=unified&w=0#r1417409370 --->
+
+### Subprocesses
+
+Extensions can also be used to run subprocesses when the Collector can't
+natively run the collection mechanisms (for example, FluentBit). Subprocesses
+expose a completely separate attack vector that depends on the subprocess
+itself. In general, take care before running any subprocesses alongside the
+Collector.

From 135fc1df1b4386117c9334301b1b707e63a8dd4b Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 19 Sep 2024 15:41:02 -0700
Subject: [PATCH 03/30] Fix spelling issues

---
 content/en/docs/security/_index.md                | 2 +-
 content/en/docs/security/config-best-practices.md | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md
index c93493f075c4..de8eeb43848c 100644
--- a/content/en/docs/security/_index.md
+++ b/content/en/docs/security/_index.md
@@ -16,7 +16,7 @@ Collector configuration. Running a secure Collector can help you
 - Comply with data privacy and security regulations.
 - Defend against denial of service (DoS) attacks.
 
-See [Hosting best pracices](/security/otel-collector-hosting-best-practices) to
+See [Hosting best practices](/security/otel-collector-hosting-best-practices) to
 learn how to secure your Collector's infrastructure.
 
 See
diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 0d726395eb43..a1106133b3d8 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -67,8 +67,8 @@ processors are useful in a few ways.
 
 <!--- TODO: SHOULD configure recommended processors. If so, what are they? -->
 
-    redactionprocessor (never tried myself)
-    transformprocessor (great for redacting PIIs and such)
+    redaction processor (never tried myself)
+    transform processor (great for redacting PIIs and such)
 
 ### Scrubbing sensitive data
 

From 6063b77a448d9c5455a4bc3b743081ecfed12a86 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 19 Sep 2024 15:43:41 -0700
Subject: [PATCH 04/30] Make linter fixes

---
 content/en/docs/security/config-best-practices.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index a1106133b3d8..8781ddebfb17 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -65,15 +65,15 @@ processors are useful in a few ways.
 
 ### Recommended processors
 
-<!--- TODO: SHOULD configure recommended processors. If so, what are they? -->
+<!--- TODO: SHOULD configure recommended processors. If so, what are they? 
 
-    redaction processor (never tried myself)
-    transform processor (great for redacting PIIs and such)
+redaction processor (never tried myself)
+transform processor (great for redacting PIIs and such) -->
 
 ### Scrubbing sensitive data
 
 You can use the OpenTelemetry Collector to scrub sensitive data before exporting
-it to a back end. Configure the Collector to obfuscate or scrub sensitive data
+it to a backend. Configure the Collector to obfuscate or scrub sensitive data
 before exporting.
 
 <!--- TODO: SHOULD configure obfuscation/scrubbing of sensitive metadata. How? Give more details and/or link to an existing document -->

From 2de00e2018e37c7b2d27646025f94a96629baad9 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 19 Sep 2024 15:46:53 -0700
Subject: [PATCH 05/30] Update links on index.md

---
 content/en/docs/security/_index.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md
index de8eeb43848c..20b3a5024752 100644
--- a/content/en/docs/security/_index.md
+++ b/content/en/docs/security/_index.md
@@ -16,11 +16,11 @@ Collector configuration. Running a secure Collector can help you
 - Comply with data privacy and security regulations.
 - Defend against denial of service (DoS) attacks.
 
-See [Hosting best practices](/security/otel-collector-hosting-best-practices) to
+See [Hosting best practices](/security/hosting-best-practices) to
 learn how to secure your Collector's infrastructure.
 
 See
-[Configuration best practices](/security/otel-collector-configuration-best-practices)
+[Configuration best practices](/security/config-best-practices)
 to learn how to securely configure your Collector.
 
 For Collector component developers, see

From 7cbbcf6ad296d2f38be8bbc5ed8e9599c0939faf Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 19 Sep 2024 15:51:19 -0700
Subject: [PATCH 06/30] Copy content into hosting-best-practices.md

---
 .../docs/security/hosting-best-practices.md   | 64 +++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 content/en/docs/security/hosting-best-practices.md

diff --git a/content/en/docs/security/hosting-best-practices.md b/content/en/docs/security/hosting-best-practices.md
new file mode 100644
index 000000000000..3f2f1b06760c
--- /dev/null
+++ b/content/en/docs/security/hosting-best-practices.md
@@ -0,0 +1,64 @@
+---
+title: Collector hosting best practices
+linkTitle: Collector hosting
+description: Follow best practices to securely host OpenTelemetry Collector.
+weight: 10
+---
+
+When setting up hosting for OpenTelemetry (OTel) Collector, consider the
+following practices to better secure your hosting instance.
+
+## Storing configuration information securely
+
+<!--- TODO: SHOULD ensure sensitive configuration information is stored securely. How? -->
+
+## Permissions
+
+<!--- TODO: SHOULD not run the OpenTelemetry Collector as root/admin user. Why? (Give the reader motivation.) How do you do that?
+- NOTE: MAY require privileged access for some components 
+
+The Collector SHOULD NOT require privileged access, except where the data it's obtaining is in a privileged location. For instance, in order to get pod logs by mounting a node volume, the Collector daemonset needs enough privileges to get that data.
+
+The rule of least privilege applies here. --->
+
+## Receivers and exporters
+
+To limit the exposure of servers to authorized users:
+
+- Enable authentication, using bearer token authentication extensions and basic
+  authentication extensions.
+- Restrict the IPs that the OTel Collector runs on.
+
+## Processors
+
+Processors sit between receivers and exporters. They are responsible for
+processing the data in some way. From a security perspective, they are useful in
+a few ways.
+
+### Safeguarding around resource utilization
+
+In addition, processors offer safeguards around resource utilization.
+
+<!-- start same page content in otel-collector-configuration-best-practices -->
+
+The `batch` and especially `memory_limiter` processor help ensure that the
+OpenTelemetry Collector is resource efficient and does not run when overloaded.
+At least these two processors SHOULD be enabled on every defined pipeline.
+
+For more information on recommended processors and order, refer to the
+[OpenTelemetry Collector Processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor)
+documentation.
+
+<!-- /end same page content in otel-collector-configuration-best-practices -->
+
+After installing resource utilization safeguards in your hosting, ensure your
+OpenTelemetry Collector configuration uses those
+[safeguards in its configuration](/security/otel-collector-configuration-best-practices/).
+
+### Another example
+
+<!--- TODO: INSERT ADDITIONAL EXAMPLES HERE. -->
+
+## Extensions
+
+<!--- TODO: Extensions SHOULD NOT expose sensitive health or telemetry data. How? What can you do? -->

From b4987c35883629700c13f34eb6727d08d571f93b Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 19 Sep 2024 15:52:29 -0700
Subject: [PATCH 07/30] Add TODO

---
 content/en/docs/security/_index.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md
index 20b3a5024752..3c94a062f755 100644
--- a/content/en/docs/security/_index.md
+++ b/content/en/docs/security/_index.md
@@ -4,6 +4,8 @@ description: Security in OpenTelemetry
 weight: 10
 ---
 
+<!--- TODO: Add content to introduce CVE and security response docs --->
+
 When setting up the OpenTelemetry (OTel) Collector, consider implementing
 security best practices in both your hosting infrastructure and your OTel
 Collector configuration. Running a secure Collector can help you

From 79688ecdb84fec0d5e02fdcaafdff2b1f2c59a11 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 19 Sep 2024 16:23:58 -0700
Subject: [PATCH 08/30] Edits to config and hosting best practices

---
 .../en/docs/security/config-best-practices.md | 23 ++++++------
 .../docs/security/hosting-best-practices.md   | 35 +++++++++----------
 2 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 8781ddebfb17..a3bd669140f7 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -59,13 +59,13 @@ Your OTel Collector configuration should include encryption and authentication.
 
 ## Processors
 
-Processors sit between receivers and exporters. They are responsible for
-processing telemetry before it's analyzed. From a security perspective,
-processors are useful in a few ways.
+[Processors](/collector/configuration/#processors) sit between receivers and
+exporters. They are responsible for processing telemetry before it's analyzed.
+From a security perspective, processors are useful in a few ways.
 
 ### Recommended processors
 
-<!--- TODO: SHOULD configure recommended processors. If so, what are they? 
+<!--- TODO: SHOULD configure recommended processors. If so, what are they?
 
 redaction processor (never tried myself)
 transform processor (great for redacting PIIs and such) -->
@@ -85,16 +85,19 @@ Use OpenTelemetry Collector's `redaction` processor to scrub sensitive data.
 ### Safeguarding resource utilization
 
 Processors also offer safeguards for resource utilization. After implementing
-[safeguards resource utilization in your hosting infrastructure](/security/hosting-best-practices/),
-make sure your OpenTelemetry Collector configuration uses these safeguards.
+safeguards for resource utilization in your
+[hosting infrastructure](/security/hosting-best-practices/), make sure your
+OpenTelemetry Collector configuration uses these safeguards.
 
 <!-- start same page content in hosting-best-practices -->
 
-The `batch` processor helps ensure the OpenTelemetry Collector is resource
-efficient and does not run out of memory when overloaded.
+The `batch` and `memory_limiter` processors help ensure the OpenTelemetry
+Collector is resource efficient and does not run out of memory when overloaded.
+These two processors should be enabled on every defined pipeline.
 
-For more information on recommended processors and order, refer to the
-[OpenTelemetry Collector Processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor)
+For more information on recommended processors and how to order them in your
+configuration, see the
+[Collector processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor)
 documentation.
 
 <!-- /end same page content in hosting-best-practices -->
diff --git a/content/en/docs/security/hosting-best-practices.md b/content/en/docs/security/hosting-best-practices.md
index 3f2f1b06760c..f9fd25aa2d64 100644
--- a/content/en/docs/security/hosting-best-practices.md
+++ b/content/en/docs/security/hosting-best-practices.md
@@ -2,7 +2,7 @@
 title: Collector hosting best practices
 linkTitle: Collector hosting
 description: Follow best practices to securely host OpenTelemetry Collector.
-weight: 10
+weight: 15
 ---
 
 When setting up hosting for OpenTelemetry (OTel) Collector, consider the
@@ -15,7 +15,7 @@ following practices to better secure your hosting instance.
 ## Permissions
 
 <!--- TODO: SHOULD not run the OpenTelemetry Collector as root/admin user. Why? (Give the reader motivation.) How do you do that?
-- NOTE: MAY require privileged access for some components 
+- NOTE: MAY require privileged access for some components
 
 The Collector SHOULD NOT require privileged access, except where the data it's obtaining is in a privileged location. For instance, in order to get pod logs by mounting a node volume, the Collector daemonset needs enough privileges to get that data.
 
@@ -27,33 +27,30 @@ To limit the exposure of servers to authorized users:
 
 - Enable authentication, using bearer token authentication extensions and basic
   authentication extensions.
-- Restrict the IPs that the OTel Collector runs on.
+- Restrict the IPs that OTel Collector runs on.
 
 ## Processors
 
-Processors sit between receivers and exporters. They are responsible for
-processing the data in some way. From a security perspective, they are useful in
-a few ways.
+[Processors](/collector/configuration/#processors) sit between receivers and
+exporters. They are responsible for processing telemetry before it's analyzed.
+From a security perspective, processors are useful in a few ways.
 
-### Safeguarding around resource utilization
+### Safeguarding resource utilization
 
 In addition, processors offer safeguards around resource utilization.
 
-<!-- start same page content in otel-collector-configuration-best-practices -->
+The `batch` and `memory_limiter` processors help ensure that the OpenTelemetry
+Collector is resource efficient and does not run out memory when overloaded.
+These two processors should be enabled on every defined pipeline.
 
-The `batch` and especially `memory_limiter` processor help ensure that the
-OpenTelemetry Collector is resource efficient and does not run when overloaded.
-At least these two processors SHOULD be enabled on every defined pipeline.
-
-For more information on recommended processors and order, refer to the
-[OpenTelemetry Collector Processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor)
+For more information on recommended processors and how to order them in your
+configuration, see the
+[Collector processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor)
 documentation.
 
-<!-- /end same page content in otel-collector-configuration-best-practices -->
-
-After installing resource utilization safeguards in your hosting, ensure your
-OpenTelemetry Collector configuration uses those
-[safeguards in its configuration](/security/otel-collector-configuration-best-practices/).
+After installing resource utilization safeguards in your hosting, make sure your
+Collector configuration uses those
+[safeguards in its configuration](/security/config-best-practices/).
 
 ### Another example
 

From be0d8eef63f371a3e8029763a24cc6f5abcd9781 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 19 Sep 2024 16:26:02 -0700
Subject: [PATCH 09/30] Make Prettier fix

---
 content/en/docs/security/_index.md | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md
index 3c94a062f755..3b0d93052fb2 100644
--- a/content/en/docs/security/_index.md
+++ b/content/en/docs/security/_index.md
@@ -18,12 +18,11 @@ Collector configuration. Running a secure Collector can help you
 - Comply with data privacy and security regulations.
 - Defend against denial of service (DoS) attacks.
 
-See [Hosting best practices](/security/hosting-best-practices) to
-learn how to secure your Collector's infrastructure.
+See [Hosting best practices](/security/hosting-best-practices) to learn how to
+secure your Collector's infrastructure.
 
-See
-[Configuration best practices](/security/config-best-practices)
-to learn how to securely configure your Collector.
+See [Configuration best practices](/security/config-best-practices) to learn how
+to securely configure your Collector.
 
 For Collector component developers, see
 [Security best practices](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md).

From 3e7c3c967fea6a54c5b7158b57fc66b75f37be13 Mon Sep 17 00:00:00 2001
From: Tiffany Hrabusa <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 23 Sep 2024 15:52:31 -0700
Subject: [PATCH 10/30] Apply suggestions from Juraci
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Juraci Paixão Kröhling <juraci.github@kroehling.de>
---
 content/en/docs/security/config-best-practices.md  | 4 ++--
 content/en/docs/security/hosting-best-practices.md | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index a3bd669140f7..e7d647e00e98 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -15,7 +15,7 @@ configuration: one receiver and one exporter. Configuring only the minimum set
 of components exposes a minimum set of required ports.
 
 - Receivers and exporters can be either push- or pull-based. In either case, the
-  connection established should be over a secure and authenticated channel.
+  connection established should at least be over a secure channel, potentially authenticated as well.
 - Unused receivers and exporters should be disabled to minimize the attack
   vector of the Collector.
 - Receivers and exporters might expose buffer, queue, payload, and worker
@@ -41,7 +41,7 @@ receivers:
         endpoint: localhost:4317
 ```
 
-Use `localhost`-like addresses instead of `0.0.0.0`. For more information, see
+Try to always use specific interfaces, such as the pod's IP, or `localhost` instead of `0.0.0.0`. For more information, see
 [CWE-1327: Binding to an Unrestricted IP Address](https://cwe.mitre.org/data/definitions/1327.html).
 
 To change the default endpoint to be `localhost`-bound in all components, enable
diff --git a/content/en/docs/security/hosting-best-practices.md b/content/en/docs/security/hosting-best-practices.md
index f9fd25aa2d64..7e7a8a26aef8 100644
--- a/content/en/docs/security/hosting-best-practices.md
+++ b/content/en/docs/security/hosting-best-practices.md
@@ -25,7 +25,7 @@ The rule of least privilege applies here. --->
 
 To limit the exposure of servers to authorized users:
 
-- Enable authentication, using bearer token authentication extensions and basic
+- Enable authentication, for instance by using bearer token authentication extensions and basic
   authentication extensions.
 - Restrict the IPs that OTel Collector runs on.
 

From a1427f299fe71c6229d97d68fe59d827eee67142 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 23 Sep 2024 16:17:30 -0700
Subject: [PATCH 11/30] Update index.md with PII no-no

---
 content/en/docs/security/_index.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md
index 3b0d93052fb2..c19755260106 100644
--- a/content/en/docs/security/_index.md
+++ b/content/en/docs/security/_index.md
@@ -10,9 +10,9 @@ When setting up the OpenTelemetry (OTel) Collector, consider implementing
 security best practices in both your hosting infrastructure and your OTel
 Collector configuration. Running a secure Collector can help you
 
-- Protect telemetry that might contain sensitive information, such as personally
-  identifiable information (PII), application-specific data, or network traffic
-  patterns.
+- Protect telemetry that shouldn't but might contain sensitive information, such
+  as personally identifiable information (PII), application-specific data, or
+  network traffic patterns.
 - Prevent data tampering that makes telemetry unreliable and disrupts incident
   responses.
 - Comply with data privacy and security regulations.

From cc131a85f772a86beed8a9b2321d275c5dc1eb8e Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 23 Sep 2024 16:31:24 -0700
Subject: [PATCH 12/30] Add headings for child pages to index.md

---
 content/en/docs/security/_index.md | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md
index c19755260106..3ef931214856 100644
--- a/content/en/docs/security/_index.md
+++ b/content/en/docs/security/_index.md
@@ -1,10 +1,21 @@
 ---
-title: Security in OpenTelemetry
+title: Security
 description: Security in OpenTelemetry
 weight: 10
 ---
 
-<!--- TODO: Add content to introduce CVE and security response docs --->
+## Common Vulnerabilities and Exposures (CVEs)
+
+For CVEs across all repositories, see
+[Common Vulnerabilities and Exposures](/security/cve).
+
+## Security incident response
+
+Learn how to report a vulnerability or find out how incident responses are
+handled in
+[Community incident response guidelines](/security/security-response).
+
+## Collector security
 
 When setting up the OpenTelemetry (OTel) Collector, consider implementing
 security best practices in both your hosting infrastructure and your OTel

From cbf67a9a37d2a791e2d8bf9a8fb37d65e0882f92 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 23 Sep 2024 17:53:23 -0700
Subject: [PATCH 13/30] Update config receivers and exporters section

---
 .../en/docs/security/config-best-practices.md | 24 +++++++++++--------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index e7d647e00e98..b51a4bb85f68 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -10,19 +10,22 @@ practices to better secure your Collector instance.
 
 ## Receivers and exporters
 
-We recommend enabling only the minimum required components for a Collector
-configuration: one receiver and one exporter. Configuring only the minimum set
-of components exposes a minimum set of required ports.
-
-- Receivers and exporters can be either push- or pull-based. In either case, the
-  connection established should at least be over a secure channel, potentially authenticated as well.
-- Unused receivers and exporters should be disabled to minimize the attack
-  vector of the Collector.
+We recommend enabling a limited set of components in your Collector
+configuration. Minimizing the number of components you use minimizes the attack
+surface exposed.
+
+- Use the [OpenTelemetry Collector Builder (`ocb`)](/collector/custom-collector)
+  to create a Collector distribution that uses only the components you need.
+- If you find that you have unused receivers and exporters, remove them from
+  your configuration.
+- Receivers and exporters can be push- or pull-based. In either case, you should
+  establish the connection at least over a secure channel, potentially
+  authenticated as well.
 - Receivers and exporters might expose buffer, queue, payload, and worker
   settings using configuration parameters. If these settings are available, you
   should proceed with caution before modifying the default configuration values.
   Improperly setting these values might expose the OpenTelemetry Collector to
-  additional attack vectors including resource exhaustion.
+  additional attack vectors.
 
 ### Safeguards against denial of service attacks
 
@@ -41,7 +44,8 @@ receivers:
         endpoint: localhost:4317
 ```
 
-Try to always use specific interfaces, such as the pod's IP, or `localhost` instead of `0.0.0.0`. For more information, see
+Try to always use specific interfaces, such as the pod's IP, or `localhost`
+instead of `0.0.0.0`. For more information, see
 [CWE-1327: Binding to an Unrestricted IP Address](https://cwe.mitre.org/data/definitions/1327.html).
 
 To change the default endpoint to be `localhost`-bound in all components, enable

From 02d09442057e8efc98c1a3fdc6a92daa2eff45aa Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 23 Sep 2024 17:55:48 -0700
Subject: [PATCH 14/30] Make link and linter fixes

---
 content/en/docs/security/_index.md              | 12 ++++++------
 .../en/docs/security/config-best-practices.md   | 17 +++++++++--------
 .../en/docs/security/hosting-best-practices.md  | 12 ++++++------
 3 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md
index 3ef931214856..1eb840c731a4 100644
--- a/content/en/docs/security/_index.md
+++ b/content/en/docs/security/_index.md
@@ -7,13 +7,13 @@ weight: 10
 ## Common Vulnerabilities and Exposures (CVEs)
 
 For CVEs across all repositories, see
-[Common Vulnerabilities and Exposures](/security/cve).
+[Common Vulnerabilities and Exposures](/docs/security/cve).
 
 ## Security incident response
 
 Learn how to report a vulnerability or find out how incident responses are
 handled in
-[Community incident response guidelines](/security/security-response).
+[Community incident response guidelines](/docs/security/security-response).
 
 ## Collector security
 
@@ -29,11 +29,11 @@ Collector configuration. Running a secure Collector can help you
 - Comply with data privacy and security regulations.
 - Defend against denial of service (DoS) attacks.
 
-See [Hosting best practices](/security/hosting-best-practices) to learn how to
-secure your Collector's infrastructure.
+See [Hosting best practices](/docs/security/hosting-best-practices) to learn how
+to secure your Collector's infrastructure.
 
-See [Configuration best practices](/security/config-best-practices) to learn how
-to securely configure your Collector.
+See [Configuration best practices](/docs/security/config-best-practices) to
+learn how to securely configure your Collector.
 
 For Collector component developers, see
 [Security best practices](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md).
diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index b51a4bb85f68..15db3da069c6 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -14,8 +14,9 @@ We recommend enabling a limited set of components in your Collector
 configuration. Minimizing the number of components you use minimizes the attack
 surface exposed.
 
-- Use the [OpenTelemetry Collector Builder (`ocb`)](/collector/custom-collector)
-  to create a Collector distribution that uses only the components you need.
+- Use the
+  [OpenTelemetry Collector Builder (`ocb`)](/docs/collector/custom-collector) to
+  create a Collector distribution that uses only the components you need.
 - If you find that you have unused receivers and exporters, remove them from
   your configuration.
 - Receivers and exporters can be push- or pull-based. In either case, you should
@@ -57,15 +58,15 @@ be enabled by default in the Collector in a future release.
 Your OTel Collector configuration should include encryption and authentication.
 
 - For communication encryption, see
-  [Configuring certificates](/collector/configuration/#setting-up-certificates).
+  [Configuring certificates](/docs/collector/configuration/#setting-up-certificates).
 - For authentication, use the OTel Collector's authentication mechanism, as
-  described in [Authentication](/collector/configuration/#authentication).
+  described in [Authentication](/docs/collector/configuration/#authentication).
 
 ## Processors
 
-[Processors](/collector/configuration/#processors) sit between receivers and
-exporters. They are responsible for processing telemetry before it's analyzed.
-From a security perspective, processors are useful in a few ways.
+[Processors](/docs/collector/configuration/#processors) sit between receivers
+and exporters. They are responsible for processing telemetry before it's
+analyzed. From a security perspective, processors are useful in a few ways.
 
 ### Recommended processors
 
@@ -90,7 +91,7 @@ Use OpenTelemetry Collector's `redaction` processor to scrub sensitive data.
 
 Processors also offer safeguards for resource utilization. After implementing
 safeguards for resource utilization in your
-[hosting infrastructure](/security/hosting-best-practices/), make sure your
+[hosting infrastructure](/docs/security/hosting-best-practices/), make sure your
 OpenTelemetry Collector configuration uses these safeguards.
 
 <!-- start same page content in hosting-best-practices -->
diff --git a/content/en/docs/security/hosting-best-practices.md b/content/en/docs/security/hosting-best-practices.md
index 7e7a8a26aef8..514d217e19e2 100644
--- a/content/en/docs/security/hosting-best-practices.md
+++ b/content/en/docs/security/hosting-best-practices.md
@@ -25,15 +25,15 @@ The rule of least privilege applies here. --->
 
 To limit the exposure of servers to authorized users:
 
-- Enable authentication, for instance by using bearer token authentication extensions and basic
-  authentication extensions.
+- Enable authentication, for instance by using bearer token authentication
+  extensions and basic authentication extensions.
 - Restrict the IPs that OTel Collector runs on.
 
 ## Processors
 
-[Processors](/collector/configuration/#processors) sit between receivers and
-exporters. They are responsible for processing telemetry before it's analyzed.
-From a security perspective, processors are useful in a few ways.
+[Processors](/docs/collector/configuration/#processors) sit between receivers
+and exporters. They are responsible for processing telemetry before it's
+analyzed. From a security perspective, processors are useful in a few ways.
 
 ### Safeguarding resource utilization
 
@@ -50,7 +50,7 @@ documentation.
 
 After installing resource utilization safeguards in your hosting, make sure your
 Collector configuration uses those
-[safeguards in its configuration](/security/config-best-practices/).
+[safeguards in its configuration](/docs/security/config-best-practices/).
 
 ### Another example
 

From 500d33100e01652e5f88b853daddd46a9a7f80be Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Tue, 24 Sep 2024 15:55:55 -0700
Subject: [PATCH 15/30] Update DOS safeguard section

---
 .../en/docs/security/config-best-practices.md | 38 ++++++++++++-------
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 15db3da069c6..d627cb15b7ed 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -30,28 +30,40 @@ surface exposed.
 
 ### Safeguards against denial of service attacks
 
-Bind receivers' servers to addresses that limit connections to authorized users,
-so that your Collectors aren't exposed to the public internet or to wider
-networks than necessary.
+For server-like receivers and extensions, you can protect your Collector from
+exposure to the public internet or to wider networks than necessary by binding
+these components' endpoints to addresses that limit connections to authorized
+users. Try to always use specific interfaces, such as a pod's IP, or `localhost`
+instead of `0.0.0.0`. For more information, see
+[CWE-1327: Binding to an Unrestricted IP Address](https://cwe.mitre.org/data/definitions/1327.html).
+
+From Collector v0.110.0, the default endpoints for all servers in Collector
+components are set to `localhost:4317` for `gRPC` ports or `localhost:4318` for
+`http` ports. For earlier versions of the Collector, change the default endpoint
+from `0.0.0.0` to `localhost` in all components by enabling the
+`component.UseLocalHostAsDefaultHost` feature gate.
+
+If `localhost` resolves to a different IP due to your DNS settings, then
+explicitly use the loopback IP instead: `127.0.0.1` for IPv4 or `::1` for IPv6.
+In IPv6 setups, make sure your system supports both IPv4 and IPv6 loopback
+addresses.
 
-For example, if the OTLP receiver OTLP/gRPC server has only local clients, bind
-the `endpoint` setting to `localhost`:
+For example, you can override the `localhost` default address and configure an
+OTLP receiver's gRPC server to `127.0.0.1`:
 
 ```yaml
 receivers:
   otlp:
     protocols:
       grpc:
-        endpoint: localhost:4317
+        endpoint: 127.0.0.1:4317
 ```
 
-Try to always use specific interfaces, such as the pod's IP, or `localhost`
-instead of `0.0.0.0`. For more information, see
-[CWE-1327: Binding to an Unrestricted IP Address](https://cwe.mitre.org/data/definitions/1327.html).
-
-To change the default endpoint to be `localhost`-bound in all components, enable
-the `component.UseLocalHostAsDefaultHost` feature gate. This feature gate will
-be enabled by default in the Collector in a future release.
+If you are working in environments that have nonstandard networking setups, such
+as Docker or Kubernetes, see the
+[example configurations](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks)
+in our component developer documentation for ideas on how to bind your component
+endpoints.
 
 ### Encryption and authentication
 

From 0a05a95396995a3cb3bd511db0e68a5bac42db23 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Tue, 24 Sep 2024 15:56:48 -0700
Subject: [PATCH 16/30] Adjust info architecture of all pages

---
 content/en/docs/security/_index.md                 | 9 ++++++---
 content/en/docs/security/config-best-practices.md  | 7 +++----
 content/en/docs/security/cve.md                    | 2 +-
 content/en/docs/security/hosting-best-practices.md | 7 +++----
 content/en/docs/security/security-response.md      | 2 +-
 5 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/content/en/docs/security/_index.md b/content/en/docs/security/_index.md
index 1eb840c731a4..56fae923b9fe 100644
--- a/content/en/docs/security/_index.md
+++ b/content/en/docs/security/_index.md
@@ -1,15 +1,18 @@
 ---
 title: Security
-description: Security in OpenTelemetry
-weight: 10
+weight: 970
 ---
 
+Learn how the OpenTelemetry project discloses vulnerabilities and responds to
+incidents. Find out how to ensure your observability data is collected and
+transmitted in a secure manner.
+
 ## Common Vulnerabilities and Exposures (CVEs)
 
 For CVEs across all repositories, see
 [Common Vulnerabilities and Exposures](/docs/security/cve).
 
-## Security incident response
+## Incident response
 
 Learn how to report a vulnerability or find out how incident responses are
 handled in
diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index d627cb15b7ed..3cd04e5a2445 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -1,11 +1,10 @@
 ---
 title: Collector configuration best practices
-linkTitle: Collector config
-description: Best practices to securely configure OpenTelemetry Collector.
-weight: 20
+linkTitle: Collector configuration
+weight: 112
 ---
 
-When configuring the OpenTelemetry (OTel) Collector, consider the following
+When configuring the OpenTelemetry (OTel) Collector, consider these best
 practices to better secure your Collector instance.
 
 ## Receivers and exporters
diff --git a/content/en/docs/security/cve.md b/content/en/docs/security/cve.md
index 3c6b8fb18730..208406d36109 100644
--- a/content/en/docs/security/cve.md
+++ b/content/en/docs/security/cve.md
@@ -1,6 +1,6 @@
 ---
 title: Common Vulnerabilities and Exposures
-weight: 102
+weight: 100
 ---
 
 This is a list of reported Common Vulnerabilities and Exposures (CVEs) across
diff --git a/content/en/docs/security/hosting-best-practices.md b/content/en/docs/security/hosting-best-practices.md
index 514d217e19e2..ba746ef8eba5 100644
--- a/content/en/docs/security/hosting-best-practices.md
+++ b/content/en/docs/security/hosting-best-practices.md
@@ -1,12 +1,11 @@
 ---
 title: Collector hosting best practices
 linkTitle: Collector hosting
-description: Follow best practices to securely host OpenTelemetry Collector.
-weight: 15
+weight: 115
 ---
 
-When setting up hosting for OpenTelemetry (OTel) Collector, consider the
-following practices to better secure your hosting instance.
+When setting up hosting for OpenTelemetry (OTel) Collector, consider these best
+practices to better secure your hosting instance.
 
 ## Storing configuration information securely
 
diff --git a/content/en/docs/security/security-response.md b/content/en/docs/security/security-response.md
index a20ba04cfcfe..39adb1d12017 100644
--- a/content/en/docs/security/security-response.md
+++ b/content/en/docs/security/security-response.md
@@ -1,5 +1,5 @@
 ---
-title: Community Incident Response Guidelines
+title: Community incident response guidelines
 weight: 102
 ---
 

From 18283d5197544639c66efe31e60c2275d8ab54ff Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 26 Sep 2024 17:23:27 -0700
Subject: [PATCH 17/30] Edit protocol section

---
 content/en/docs/security/config-best-practices.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 3cd04e5a2445..5809487c6210 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -44,11 +44,7 @@ from `0.0.0.0` to `localhost` in all components by enabling the
 
 If `localhost` resolves to a different IP due to your DNS settings, then
 explicitly use the loopback IP instead: `127.0.0.1` for IPv4 or `::1` for IPv6.
-In IPv6 setups, make sure your system supports both IPv4 and IPv6 loopback
-addresses.
-
-For example, you can override the `localhost` default address and configure an
-OTLP receiver's gRPC server to `127.0.0.1`:
+For example, here's an IPv4 configuration using a `gRPC` port:
 
 ```yaml
 receivers:
@@ -58,6 +54,10 @@ receivers:
         endpoint: 127.0.0.1:4317
 ```
 
+In IPv6 setups, make sure your system supports both IPv4 and IPv6 loopback
+addresses so the network functions properly in dual-stack environments and
+applications, where both protocol versions are used.
+
 If you are working in environments that have nonstandard networking setups, such
 as Docker or Kubernetes, see the
 [example configurations](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks)

From bb8852f978755f9bcc14be1139eb69965638a972 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 26 Sep 2024 17:51:55 -0700
Subject: [PATCH 18/30] Change headings and info arch

---
 .../en/docs/security/config-best-practices.md | 35 +++++++------------
 1 file changed, 13 insertions(+), 22 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 5809487c6210..dc822fe02050 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -7,7 +7,7 @@ weight: 112
 When configuring the OpenTelemetry (OTel) Collector, consider these best
 practices to better secure your Collector instance.
 
-## Receivers and exporters
+## Minimize your configuration
 
 We recommend enabling a limited set of components in your Collector
 configuration. Minimizing the number of components you use minimizes the attack
@@ -27,7 +27,16 @@ surface exposed.
   Improperly setting these values might expose the OpenTelemetry Collector to
   additional attack vectors.
 
-### Safeguards against denial of service attacks
+## Use encryption and authentication
+
+Your OTel Collector configuration should include encryption and authentication.
+
+- For communication encryption, see
+  [Configuring certificates](/docs/collector/configuration/#setting-up-certificates).
+- For authentication, use the OTel Collector's authentication mechanism, as
+  described in [Authentication](/docs/collector/configuration/#authentication).
+
+## Protect against denial of service attacks
 
 For server-like receivers and extensions, you can protect your Collector from
 exposure to the public internet or to wider networks than necessary by binding
@@ -64,30 +73,12 @@ as Docker or Kubernetes, see the
 in our component developer documentation for ideas on how to bind your component
 endpoints.
 
-### Encryption and authentication
-
-Your OTel Collector configuration should include encryption and authentication.
-
-- For communication encryption, see
-  [Configuring certificates](/docs/collector/configuration/#setting-up-certificates).
-- For authentication, use the OTel Collector's authentication mechanism, as
-  described in [Authentication](/docs/collector/configuration/#authentication).
-
-## Processors
+## Scrub sensitive data
 
 [Processors](/docs/collector/configuration/#processors) sit between receivers
 and exporters. They are responsible for processing telemetry before it's
 analyzed. From a security perspective, processors are useful in a few ways.
 
-### Recommended processors
-
-<!--- TODO: SHOULD configure recommended processors. If so, what are they?
-
-redaction processor (never tried myself)
-transform processor (great for redacting PIIs and such) -->
-
-### Scrubbing sensitive data
-
 You can use the OpenTelemetry Collector to scrub sensitive data before exporting
 it to a backend. Configure the Collector to obfuscate or scrub sensitive data
 before exporting.
@@ -98,7 +89,7 @@ Use OpenTelemetry Collector's `redaction` processor to scrub sensitive data.
 
 <!--- TODO: Give example config for the redaction processor or remove this line. --->
 
-### Safeguarding resource utilization
+## Safeguard resource utilization
 
 Processors also offer safeguards for resource utilization. After implementing
 safeguards for resource utilization in your

From 0532e0265fe1a3585d9f68b000f38f117412d5b8 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 26 Sep 2024 18:15:45 -0700
Subject: [PATCH 19/30] Edit scrubbing sensitive data section

---
 .../en/docs/security/config-best-practices.md | 46 ++++++++++++++-----
 1 file changed, 35 insertions(+), 11 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index dc822fe02050..e18039917b2b 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -75,19 +75,43 @@ endpoints.
 
 ## Scrub sensitive data
 
-[Processors](/docs/collector/configuration/#processors) sit between receivers
-and exporters. They are responsible for processing telemetry before it's
-analyzed. From a security perspective, processors are useful in a few ways.
+[Processors](/docs/collector/configuration/#processors) are the Collector
+components that sit between receivers and exporters. They are responsible for
+processing telemetry before it's analyzed. You can use the OpenTelemetry
+Collector's `redaction` processor to obfuscate or scrub sensitive data before
+exporting it to a backend.
+
+The
+[`redaction` processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor)
+deletes span, log, and metric datapoint attributes that don't match a list of
+allowed attributes. It also masks attribute values that match a blocked value
+list. Attributes that aren't on the allowed list are removed before any value
+checks are done.
+
+For example, here is a configuration that masks values containing credit card
+numbers:
 
-You can use the OpenTelemetry Collector to scrub sensitive data before exporting
-it to a backend. Configure the Collector to obfuscate or scrub sensitive data
-before exporting.
-
-<!--- TODO: SHOULD configure obfuscation/scrubbing of sensitive metadata. How? Give more details and/or link to an existing document -->
-
-Use OpenTelemetry Collector's `redaction` processor to scrub sensitive data.
+```yaml
+processors:
+  redaction:
+    allow_all_keys: false
+    allowed_keys:
+      - description
+      - group
+      - id
+      - name
+    ignored_keys:
+      - safe_attribute
+    blocked_values: # Regular expressions for blocking values of allowed span attributes
+      - '4[0-9]{12}(?:[0-9]{3})?' # Visa credit card number
+      - '(5[1-5][0-9]{14})' # MasterCard number
+    summary: debug
+```
 
-<!--- TODO: Give example config for the redaction processor or remove this line. --->
+See the
+[README](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor)
+for more details on adding the `redaction` processor to your Collector
+configuration.
 
 ## Safeguard resource utilization
 

From 36d55c13b67dc198cbc360f4f83f03b88b80f02d Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Sun, 6 Oct 2024 11:58:05 -0700
Subject: [PATCH 20/30] Create new top level section and rework content

---
 .../en/docs/security/config-best-practices.md | 47 ++++++++++++++-----
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index e18039917b2b..ae4602fbeaaf 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -7,17 +7,47 @@ weight: 112
 When configuring the OpenTelemetry (OTel) Collector, consider these best
 practices to better secure your Collector instance.
 
-## Minimize your configuration
+## Create secure pipelines
 
-We recommend enabling a limited set of components in your Collector
-configuration. Minimizing the number of components you use minimizes the attack
-surface exposed.
+Follow these guidelines to secure your Collector's configuration pipelines.
+
+### Store your configuration securely
+
+The Collector's configuration might contain sensitive information including:
+
+- Authentication information such as API tokens.
+- TLS certificates including private keys.
+
+You should store sensitive information securely such as on an encrypted
+filesystem or secret store. You can use environment variables to handle
+sensitive and non-sensitive data as the Collector supports
+[environment variable expansion](/docs/collector/configuration/#environment-variables).
+
+### Use encryption and authentication
+
+Your OTel Collector configuration should include encryption and authentication.
+
+- For communication encryption, see
+  [Configuring certificates](/docs/collector/configuration/#setting-up-certificates).
+- For authentication, use the OTel Collector's authentication mechanism, as
+  described in [Authentication](/docs/collector/configuration/#authentication).
+
+### Minimize the components in your configuration
+
+We recommend limiting the set of components in your Collector configuration to
+only those you need. Minimizing the number of components you use minimizes the
+attack surface exposed.
 
 - Use the
   [OpenTelemetry Collector Builder (`ocb`)](/docs/collector/custom-collector) to
   create a Collector distribution that uses only the components you need.
 - If you find that you have unused receivers and exporters, remove them from
   your configuration.
+
+### Configure with care
+
+Some components can increase the security risk of your Collector pipelines.
+
 - Receivers and exporters can be push- or pull-based. In either case, you should
   establish the connection at least over a secure channel, potentially
   authenticated as well.
@@ -27,15 +57,6 @@ surface exposed.
   Improperly setting these values might expose the OpenTelemetry Collector to
   additional attack vectors.
 
-## Use encryption and authentication
-
-Your OTel Collector configuration should include encryption and authentication.
-
-- For communication encryption, see
-  [Configuring certificates](/docs/collector/configuration/#setting-up-certificates).
-- For authentication, use the OTel Collector's authentication mechanism, as
-  described in [Authentication](/docs/collector/configuration/#authentication).
-
 ## Protect against denial of service attacks
 
 For server-like receivers and extensions, you can protect your Collector from

From c95ba0c41e9307a9cffc26956056dafe3b15e2c5 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Sun, 6 Oct 2024 12:12:11 -0700
Subject: [PATCH 21/30] Create 'specific risk' section

---
 content/en/docs/security/config-best-practices.md | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index ae4602fbeaaf..692416ee604e 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -7,9 +7,10 @@ weight: 112
 When configuring the OpenTelemetry (OTel) Collector, consider these best
 practices to better secure your Collector instance.
 
-## Create secure pipelines
+## Create secure configurations
 
-Follow these guidelines to secure your Collector's configuration pipelines.
+Follow these guidelines to secure your Collector's configuration and its
+pipelines.
 
 ### Store your configuration securely
 
@@ -57,7 +58,11 @@ Some components can increase the security risk of your Collector pipelines.
   Improperly setting these values might expose the OpenTelemetry Collector to
   additional attack vectors.
 
-## Protect against denial of service attacks
+## Manage specific security risks
+
+Configure your Collector to block these threats to security.
+
+### Protect against denial of service attacks
 
 For server-like receivers and extensions, you can protect your Collector from
 exposure to the public internet or to wider networks than necessary by binding
@@ -94,7 +99,7 @@ as Docker or Kubernetes, see the
 in our component developer documentation for ideas on how to bind your component
 endpoints.
 
-## Scrub sensitive data
+### Scrub sensitive data
 
 [Processors](/docs/collector/configuration/#processors) are the Collector
 components that sit between receivers and exporters. They are responsible for
@@ -134,7 +139,7 @@ See the
 for more details on adding the `redaction` processor to your Collector
 configuration.
 
-## Safeguard resource utilization
+### Safeguard resource utilization
 
 Processors also offer safeguards for resource utilization. After implementing
 safeguards for resource utilization in your

From dbfd1b6207dd67ab5a618d94ff86c803e794afac Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Sun, 6 Oct 2024 12:25:01 -0700
Subject: [PATCH 22/30] Remove forwarding section

---
 content/en/docs/security/config-best-practices.md | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 692416ee604e..fe61d08121d1 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -175,13 +175,6 @@ are accessible only locally to the OpenTelemetry Collector. Take care to protect
 sensitive information when configuring these extensions for remote access, as
 they might expose it accidentally.
 
-### Forwarding
-
-A forwarding extension is used when you need to collect telemetry that's not
-natively supported by the Collector. For example, the `http_forwarder` extension
-can receive and forward HTTP payloads. Forwarding extensions are similar to
-receivers and exporters so the same security considerations apply.
-
 ### Collector's internal telemetry
 
 <!--- INSERT RECOMMENDATIONS HERE. For example:

From 8605abbdfa9e1c1fb95a16f005d956a98f0efd9f Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 14 Oct 2024 16:57:03 -0700
Subject: [PATCH 23/30] Edit resource utlization section

---
 .../en/docs/security/config-best-practices.md | 57 ++++++++++++++-----
 1 file changed, 43 insertions(+), 14 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index fe61d08121d1..159730e4da59 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -75,7 +75,8 @@ From Collector v0.110.0, the default endpoints for all servers in Collector
 components are set to `localhost:4317` for `gRPC` ports or `localhost:4318` for
 `http` ports. For earlier versions of the Collector, change the default endpoint
 from `0.0.0.0` to `localhost` in all components by enabling the
-`component.UseLocalHostAsDefaultHost` feature gate.
+`component.UseLocalHostAsDefaultHost`
+[feature gate](https://github.com/open-telemetry/opentelemetry-collector/tree/main/featuregate).
 
 If `localhost` resolves to a different IP due to your DNS settings, then
 explicitly use the loopback IP instead: `127.0.0.1` for IPv4 or `::1` for IPv6.
@@ -141,23 +142,51 @@ configuration.
 
 ### Safeguard resource utilization
 
-Processors also offer safeguards for resource utilization. After implementing
-safeguards for resource utilization in your
-[hosting infrastructure](/docs/security/hosting-best-practices/), make sure your
-OpenTelemetry Collector configuration uses these safeguards.
+After implementing safeguards for resource utilization in your
+[hosting infrastructure](/docs/security/hosting-best-practices/), consider
+adding these safeguards to your OpenTelemetry Collector configuration.
 
-<!-- start same page content in hosting-best-practices -->
+Batching your telemetry and limiting the memory available to your Collector can
+prevent out-of-memory errors and usage spikes. You can also handle traffic
+spikes by adjusting queue sizes to manage memory usage while avoiding data loss.
+For example, use the
+[`exporterhelper`](https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/exporterhelper/README.md)
+to manage queue size for your `otlp` exporter:
 
-The `batch` and `memory_limiter` processors help ensure the OpenTelemetry
-Collector is resource efficient and does not run out of memory when overloaded.
-These two processors should be enabled on every defined pipeline.
+```yaml
+exporters:
+  otlp:
+    endpoint: <ENDPOINT>
+    sending_queue:
+      queue_size: 800
+```
+
+Filtering unwanted telemetry is another way you can protect your Collector's
+resources. Not only does filtering protect your Collector instance, but it also
+reduces the load on your backend. You can use the
+[`filter` processor](/docs/collector/transforming-telemetry/#basic-filtering) to
+drop logs, metrics, and spans you don't need. For example, here's a
+configuration that drops non-HTTP spans:
+
+```yaml
+processors:
+  filter:
+    error_mode: ignore
+    traces:
+      span:
+        - attributes["http.request.method"] == nil
+```
 
-For more information on recommended processors and how to order them in your
-configuration, see the
-[Collector processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor)
-documentation.
+You can also configure your components with appropriate timeout and retry
+limits. These limits should allow your Collector to handle failures without
+accumulating too much data in memory. See the
+[`exporterhelper` documentation](https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/exporterhelper/README.md)
+for more information.
 
-<!-- /end same page content in hosting-best-practices -->
+Finally, consider using compression with your exporters to reduce the send size
+of your data and conserve network and CPU resources. By default, the
+[`otlp` exporter](https://github.com/open-telemetry/opentelemetry-collector/tree/main/exporter/otlpexporter)
+uses `gzip` compression.
 
 ## Extensions
 

From 44ae838fe7f3fc0614d66b94e15bd2a3e3edbe16 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 14 Oct 2024 17:17:32 -0700
Subject: [PATCH 24/30] Minor edits

---
 content/en/docs/security/config-best-practices.md | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 159730e4da59..5631b30591ac 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -33,7 +33,7 @@ Your OTel Collector configuration should include encryption and authentication.
 - For authentication, use the OTel Collector's authentication mechanism, as
   described in [Authentication](/docs/collector/configuration/#authentication).
 
-### Minimize the components in your configuration
+### Minimize the number of components
 
 We recommend limiting the set of components in your Collector configuration to
 only those you need. Minimizing the number of components you use minimizes the
@@ -60,7 +60,7 @@ Some components can increase the security risk of your Collector pipelines.
 
 ## Manage specific security risks
 
-Configure your Collector to block these threats to security.
+Configure your Collector to block these security threats.
 
 ### Protect against denial of service attacks
 
@@ -136,14 +136,13 @@ processors:
 ```
 
 See the
-[README](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor)
-for more details on adding the `redaction` processor to your Collector
-configuration.
+[documentation](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/redactionprocessor)
+to learn how to add the `redaction` processor to your Collector configuration.
 
 ### Safeguard resource utilization
 
 After implementing safeguards for resource utilization in your
-[hosting infrastructure](/docs/security/hosting-best-practices/), consider
+[hosting infrastructure](/docs/security/hosting-best-practices/), consider also
 adding these safeguards to your OpenTelemetry Collector configuration.
 
 Batching your telemetry and limiting the memory available to your Collector can

From 2e606e20b4ab334365983683382d2cd91273e93f Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Mon, 14 Oct 2024 17:37:54 -0700
Subject: [PATCH 25/30] Make cSpell happy

---
 content/en/docs/security/config-best-practices.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 5631b30591ac..14061f5fc7ac 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -2,6 +2,7 @@
 title: Collector configuration best practices
 linkTitle: Collector configuration
 weight: 112
+cSpell:ignore: exporterhelper
 ---
 
 When configuring the OpenTelemetry (OTel) Collector, consider these best

From fb566d1379e42b62f29350b61248857ebedeec5f Mon Sep 17 00:00:00 2001
From: Tiffany Hrabusa <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 17 Oct 2024 18:00:56 -0700
Subject: [PATCH 26/30] Apply suggestions from Pablo's review

Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
---
 content/en/docs/security/config-best-practices.md | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 14061f5fc7ac..199c303e61ea 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -43,15 +43,14 @@ attack surface exposed.
 - Use the
   [OpenTelemetry Collector Builder (`ocb`)](/docs/collector/custom-collector) to
   create a Collector distribution that uses only the components you need.
-- If you find that you have unused receivers and exporters, remove them from
-  your configuration.
+- Remove unused components from your configuration.
 
 ### Configure with care
 
 Some components can increase the security risk of your Collector pipelines.
 
-- Receivers and exporters can be push- or pull-based. In either case, you should
-  establish the connection at least over a secure channel, potentially
+- Receivers, exporters and other components should establish
+  network connections over a secure channel, potentially
   authenticated as well.
 - Receivers and exporters might expose buffer, queue, payload, and worker
   settings using configuration parameters. If these settings are available, you
@@ -72,9 +71,8 @@ users. Try to always use specific interfaces, such as a pod's IP, or `localhost`
 instead of `0.0.0.0`. For more information, see
 [CWE-1327: Binding to an Unrestricted IP Address](https://cwe.mitre.org/data/definitions/1327.html).
 
-From Collector v0.110.0, the default endpoints for all servers in Collector
-components are set to `localhost:4317` for `gRPC` ports or `localhost:4318` for
-`http` ports. For earlier versions of the Collector, change the default endpoint
+From Collector v0.110.0, the default host for all servers in Collector components is `localhost`. 
+For earlier versions of the Collector, change the default endpoint
 from `0.0.0.0` to `localhost` in all components by enabling the
 `component.UseLocalHostAsDefaultHost`
 [feature gate](https://github.com/open-telemetry/opentelemetry-collector/tree/main/featuregate).

From 961ac4706d42e13b465724f02e9efaed90734038 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 17 Oct 2024 18:13:06 -0700
Subject: [PATCH 27/30] Fix formatting and remove sections

---
 .../en/docs/security/config-best-practices.md | 36 +++----------------
 1 file changed, 5 insertions(+), 31 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index 199c303e61ea..b066f459572c 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -49,9 +49,8 @@ attack surface exposed.
 
 Some components can increase the security risk of your Collector pipelines.
 
-- Receivers, exporters and other components should establish
-  network connections over a secure channel, potentially
-  authenticated as well.
+- Receivers, exporters, and other components should establish network
+  connections over a secure channel, potentially authenticated as well.
 - Receivers and exporters might expose buffer, queue, payload, and worker
   settings using configuration parameters. If these settings are available, you
   should proceed with caution before modifying the default configuration values.
@@ -71,9 +70,9 @@ users. Try to always use specific interfaces, such as a pod's IP, or `localhost`
 instead of `0.0.0.0`. For more information, see
 [CWE-1327: Binding to an Unrestricted IP Address](https://cwe.mitre.org/data/definitions/1327.html).
 
-From Collector v0.110.0, the default host for all servers in Collector components is `localhost`. 
-For earlier versions of the Collector, change the default endpoint
-from `0.0.0.0` to `localhost` in all components by enabling the
+From Collector v0.110.0, the default host for all servers in Collector
+components is `localhost`. For earlier versions of the Collector, change the
+default endpoint from `0.0.0.0` to `localhost` in all components by enabling the
 `component.UseLocalHostAsDefaultHost`
 [feature gate](https://github.com/open-telemetry/opentelemetry-collector/tree/main/featuregate).
 
@@ -193,23 +192,6 @@ serve different needs.
 
 <!--- TODO: Extensions SHOULD NOT expose sensitive health or telemetry data. How? What can you do? -->
 
-### Health and telemetry
-
-Extensions are available for health check information, Collector metrics and
-traces, and generating and collecting profiling data. When enabled with their
-default settings, all of these extensions, except the health check extension,
-are accessible only locally to the OpenTelemetry Collector. Take care to protect
-sensitive information when configuring these extensions for remote access, as
-they might expose it accidentally.
-
-### Collector's internal telemetry
-
-<!--- INSERT RECOMMENDATIONS HERE. For example:
-
-1. Remove zPages.
-1. Remove configuration endpoints.
--->
-
 ### Observers
 
 An observer is a component that discovers services in endpoints. Other
@@ -222,11 +204,3 @@ while the `host_observer` requires the OpenTelemetry Collector to run in
 privileged mode.
 
 <!--- But what about Juraci's comment here: https://github.com/open-telemetry/opentelemetry.io/pull/3652/files?diff=unified&w=0#r1417409370 --->
-
-### Subprocesses
-
-Extensions can also be used to run subprocesses when the Collector can't
-natively run the collection mechanisms (for example, FluentBit). Subprocesses
-expose a completely separate attack vector that depends on the subprocess
-itself. In general, take care before running any subprocesses alongside the
-Collector.

From af957412a239da7bd6129bcb42cbc6ab9015264e Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 17 Oct 2024 18:56:29 -0700
Subject: [PATCH 28/30] Rewrite and move observers section

---
 .../en/docs/security/config-best-practices.md | 42 ++++++++++---------
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/content/en/docs/security/config-best-practices.md b/content/en/docs/security/config-best-practices.md
index b066f459572c..d08ce52b2c3f 100644
--- a/content/en/docs/security/config-best-practices.md
+++ b/content/en/docs/security/config-best-practices.md
@@ -57,6 +57,28 @@ Some components can increase the security risk of your Collector pipelines.
   Improperly setting these values might expose the OpenTelemetry Collector to
   additional attack vectors.
 
+## Set permissions carefully
+
+Avoid running the Collector as a root user. Some components might require
+special permissions, however. In those cases, follow the principle of least
+privilege and make sure your components only have the access they need to do
+their job.
+
+### Observers
+
+Observers are implemented as extensions. Extensions are a type of component that
+adds capabilities on top of the primary functions of the Collector. Extensions
+don't require direct access to telemetry and aren't part of pipelines, but they
+can still pose security risks if they require special permissions.
+
+An observer discovers networked endpoints such as a Kubernetes pod, Docker
+container, or local listening port on behalf of the
+[receiver creator](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/receivercreator/README.md).
+In order to discover services, observers might require greater access. For
+example, the `k8s_observer` requires
+[role-based access control (RBAC) permissions](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/observer/k8sobserver#setting-up-rbac-permissions)
+in Kubernetes.
+
 ## Manage specific security risks
 
 Configure your Collector to block these security threats.
@@ -184,23 +206,3 @@ Finally, consider using compression with your exporters to reduce the send size
 of your data and conserve network and CPU resources. By default, the
 [`otlp` exporter](https://github.com/open-telemetry/opentelemetry-collector/tree/main/exporter/otlpexporter)
 uses `gzip` compression.
-
-## Extensions
-
-While receivers, processors, and exporters handle telemetry directly, extensions
-serve different needs.
-
-<!--- TODO: Extensions SHOULD NOT expose sensitive health or telemetry data. How? What can you do? -->
-
-### Observers
-
-An observer is a component that discovers services in endpoints. Other
-components of the OpenTelemetry Collector, such as receivers, can subscribe to
-these extensions to be notified of endpoints coming or going.
-
-Observers might require certain permissions in order to discover services. For
-example, the `k8s_observer` requires certain RBAC permissions in Kubernetes,
-while the `host_observer` requires the OpenTelemetry Collector to run in
-privileged mode.
-
-<!--- But what about Juraci's comment here: https://github.com/open-telemetry/opentelemetry.io/pull/3652/files?diff=unified&w=0#r1417409370 --->

From 73f4c38a930bee5062dee797fae7e0799606b5c8 Mon Sep 17 00:00:00 2001
From: tiffany76 <30397949+tiffany76@users.noreply.github.com>
Date: Thu, 17 Oct 2024 20:46:35 -0700
Subject: [PATCH 29/30] Rewrite hosting best practices

---
 .../docs/security/hosting-best-practices.md   | 74 +++++++++----------
 static/refcache.json                          |  8 ++
 2 files changed, 44 insertions(+), 38 deletions(-)

diff --git a/content/en/docs/security/hosting-best-practices.md b/content/en/docs/security/hosting-best-practices.md
index ba746ef8eba5..bb5ec3faa719 100644
--- a/content/en/docs/security/hosting-best-practices.md
+++ b/content/en/docs/security/hosting-best-practices.md
@@ -7,54 +7,52 @@ weight: 115
 When setting up hosting for OpenTelemetry (OTel) Collector, consider these best
 practices to better secure your hosting instance.
 
-## Storing configuration information securely
+## Store data securely
 
-<!--- TODO: SHOULD ensure sensitive configuration information is stored securely. How? -->
+Your Collector configuration file might contain sensitive data, including
+authentication tokens or TLS certificates. See the best practices for
+[securing your configuration](/docs/security/config-best-practices/#create-secure-configurations).
 
-## Permissions
+If you are storing telemetry for processing, make sure to restrict access to
+those directories to prevent tampering with raw data.
 
-<!--- TODO: SHOULD not run the OpenTelemetry Collector as root/admin user. Why? (Give the reader motivation.) How do you do that?
-- NOTE: MAY require privileged access for some components
+## Keep your secrets secret
 
-The Collector SHOULD NOT require privileged access, except where the data it's obtaining is in a privileged location. For instance, in order to get pod logs by mounting a node volume, the Collector daemonset needs enough privileges to get that data.
+Kubernetes [secrets](https://kubernetes.io/docs/concepts/configuration/secret/)
+are credentials that hold confidential data. They authenticate and authorize
+privileged access. If you're using a Kubernetes deployment for your Collector,
+make sure to follow these
+[recommended practices](https://kubernetes.io/docs/concepts/security/secrets-good-practices/)
+to improve security for your clusters.
 
-The rule of least privilege applies here. --->
+## Apply the rule of least privilege
 
-## Receivers and exporters
+The Collector should not require privileged access, except where the data it's
+collecting is in a privileged location. For example, in order to get pod logs by
+mounting a node volume, the Collector daemonset needs enough privileges to get
+that data.
 
-To limit the exposure of servers to authorized users:
+## Control access to server-like components
 
-- Enable authentication, for instance by using bearer token authentication
-  extensions and basic authentication extensions.
-- Restrict the IPs that OTel Collector runs on.
+Some Collector components such as receivers and exporters can function like
+servers. To limit access to authorized users, you should
 
-## Processors
+- Enable authentication by using bearer token authentication extensions and
+  basic authentication extensions, for example.
+- Restrict the IPs that your Collector runs on.
 
-[Processors](/docs/collector/configuration/#processors) sit between receivers
-and exporters. They are responsible for processing telemetry before it's
-analyzed. From a security perspective, processors are useful in a few ways.
+## Safeguard resource utilization
 
-### Safeguarding resource utilization
+Use the Collector's own
+[internal telemetry](/docs/collector/internal-telemetry/) to monitor its
+performance. Scrape metrics from the Collector about its CPU, memory, and
+throughput usage and set alerts for resource exhaustion.
 
-In addition, processors offer safeguards around resource utilization.
+If resource limits are reached, consider horizontally
+[scaling the Collector](/docs/collector/scaling/) by deploying multiple
+instances in a load-balanced configuration. Scaling your Collector distributes
+the resource demands and prevents bottlenecks.
 
-The `batch` and `memory_limiter` processors help ensure that the OpenTelemetry
-Collector is resource efficient and does not run out memory when overloaded.
-These two processors should be enabled on every defined pipeline.
-
-For more information on recommended processors and how to order them in your
-configuration, see the
-[Collector processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor)
-documentation.
-
-After installing resource utilization safeguards in your hosting, make sure your
-Collector configuration uses those
-[safeguards in its configuration](/docs/security/config-best-practices/).
-
-### Another example
-
-<!--- TODO: INSERT ADDITIONAL EXAMPLES HERE. -->
-
-## Extensions
-
-<!--- TODO: Extensions SHOULD NOT expose sensitive health or telemetry data. How? What can you do? -->
+Once you secure resource utilization in your deployment, make sure your
+Collector instance also uses
+[safeguards in its configuration](/docs/security/config-best-practices/#safeguard-resource-utilization).
diff --git a/static/refcache.json b/static/refcache.json
index d7639447eba3..627d20e9c7c0 100644
--- a/static/refcache.json
+++ b/static/refcache.json
@@ -8667,6 +8667,10 @@
     "StatusCode": 206,
     "LastSeen": "2024-08-09T10:44:30.895853-04:00"
   },
+  "https://kubernetes.io/docs/concepts/configuration/secret/": {
+    "StatusCode": 206,
+    "LastSeen": "2024-10-17T20:41:39.419625448-07:00"
+  },
   "https://kubernetes.io/docs/concepts/configuration/secret/#using-a-secret": {
     "StatusCode": 206,
     "LastSeen": "2024-04-25T00:01:05.630302-04:00"
@@ -8695,6 +8699,10 @@
     "StatusCode": 206,
     "LastSeen": "2024-08-09T10:45:22.265624-04:00"
   },
+  "https://kubernetes.io/docs/concepts/security/secrets-good-practices/": {
+    "StatusCode": 206,
+    "LastSeen": "2024-10-17T20:41:39.602462106-07:00"
+  },
   "https://kubernetes.io/docs/concepts/services-networking/service/": {
     "StatusCode": 206,
     "LastSeen": "2024-01-30T06:06:10.439014-05:00"

From 3f856e9dfd0aad83b195727bff6ef78fb01407fe Mon Sep 17 00:00:00 2001
From: Tiffany Hrabusa <30397949+tiffany76@users.noreply.github.com>
Date: Fri, 18 Oct 2024 18:04:31 -0700
Subject: [PATCH 30/30] Apply suggestions from Pablo's second review

Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
---
 content/en/docs/security/hosting-best-practices.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/content/en/docs/security/hosting-best-practices.md b/content/en/docs/security/hosting-best-practices.md
index bb5ec3faa719..5eea494cbe78 100644
--- a/content/en/docs/security/hosting-best-practices.md
+++ b/content/en/docs/security/hosting-best-practices.md
@@ -16,7 +16,7 @@ authentication tokens or TLS certificates. See the best practices for
 If you are storing telemetry for processing, make sure to restrict access to
 those directories to prevent tampering with raw data.
 
-## Keep your secrets secret
+## Keep your secrets safe
 
 Kubernetes [secrets](https://kubernetes.io/docs/concepts/configuration/secret/)
 are credentials that hold confidential data. They authenticate and authorize
@@ -45,7 +45,7 @@ servers. To limit access to authorized users, you should
 
 Use the Collector's own
 [internal telemetry](/docs/collector/internal-telemetry/) to monitor its
-performance. Scrape metrics from the Collector about its CPU, memory, and
+performance. Collect metrics from the Collector about its CPU, memory, and
 throughput usage and set alerts for resource exhaustion.
 
 If resource limits are reached, consider horizontally