Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Collector security documentation #5209

Draft
wants to merge 31 commits into
base: main
Choose a base branch
from

Conversation

tiffany76
Copy link
Contributor

This PR moves end user security documentation from a README in the Collector core repository to the OTel docs website.

Based on decisions in previous issues and PRs, the following are assumed:

  • Security documentation intended for component developers will remain in the README, which will be amended in a follow-up PR.
  • Both documents will cross-reference the other.
  • The top-level Collector landing page and the Collector configuration page will link to the security documents.

Tracking issue: #3479
Related to: #3227

NOTE: Much of the work for this PR was done by @mjingle in #3652. With her permission, I am building on her efforts.

@tiffany76
Copy link
Contributor Author

Still lots to do. I'll let everyone know when it's in a state fit for reviewing. 👍

@mx-psi mx-psi self-requested a review September 17, 2024 07:49
@opentelemetrybot opentelemetrybot requested a review from a team September 19, 2024 22:24
## 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"one receiver and one exporter" seems very strict, what if the user wants to fork the data to two different targets? (e.g. are we suggesting that forking data is not recommended from security perspective?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @reyang -- where is this coming from?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, all! The content so far has been copied from an earlier draft of this documentation. I think this sentence was an edit of the following statement in the core respository's README:

The configuration drives the Collector's behavior and care should be taken to ensure the configuration only enables the minimum set of capabilities and as such exposes the minimum set of required ports.

I will remove the "one receiver and one exporter" restriction from this PR.

Copy link
Contributor Author

@tiffany76 tiffany76 Sep 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reworked the intro to this section (Receivers and exporters) based on the comments. Please let me know what you think. No rush. I still have lots to do. Thanks!

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resource exhaustion is a great topic, I feel the current description is a bit misleading - even if the settings are correct, OpenTelemetry Collector can still cause resource exhaustion - is this the current state or there is already a solid solution for resource governance?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @reyang, I removed the mention of resource exhaustion here. The topic is addressed in more detail in the Processors section. I'll let you know once I start work on it. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi again. I updated the resource utilization section in 8605abb.

otlp:
protocols:
grpc:
endpoint: localhost:4317
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't recall the exact details, would this bind to both IPv4 and IPv6, or the Collector has a recommendation regarding how to specify IPv4/v6 explicitly?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, "localhost" binds to both. In fact, localhost is the default today already, so this recommendation might need to be reworded, as it's probably reminiscent from the days where we bound to all IPs (0.0.0.0).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've rewritten the DOS safeguard section as well, with updated information about localhost.

Rather than provide an example of binding to a pod's IP, I linked to the README section. Unless you think that content (Docker, Kubernetes, etc.) is relevant to end users and belongs on the website? I was trying to draw a line between end user and developer content, but I'm happy to make changes.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure we have a guidance somewhere stating that people should not store PII in telemetry data. Perhaps we should reinforce it here, and add a link to that place? Something like: "help you protect telemetry that shouldn't, but might contain sensitive information, such ..."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still searching for the existing guidance, but I've updated the wording as suggested. I'll keep looking for the PII reference.

## 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @reyang -- where is this coming from?

content/en/docs/security/config-best-practices.md Outdated Show resolved Hide resolved
content/en/docs/security/config-best-practices.md Outdated Show resolved Hide resolved
otlp:
protocols:
grpc:
endpoint: localhost:4317
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, "localhost" binds to both. In fact, localhost is the default today already, so this recommendation might need to be reworded, as it's probably reminiscent from the days where we bound to all IPs (0.0.0.0).

content/en/docs/security/config-best-practices.md Outdated Show resolved Hide resolved
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 --->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's OK -- what we shouldn't be telling people is to run things as root or blindly disable security protections (like selinux).

### Subprocesses

Extensions can also be used to run subprocesses when the Collector can't
natively run the collection mechanisms (for example, FluentBit). Subprocesses
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also not sure where this is coming from: the only component that I know of spawning new processes is the jmx receiver.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section comes directly from the security README. Should I remove it?


## Storing configuration information securely

<!--- TODO: SHOULD ensure sensitive configuration information is stored securely. How? -->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps add a reference to the secrets management practices for Kubernetes?

content/en/docs/security/hosting-best-practices.md Outdated Show resolved Hide resolved
Co-authored-by: Juraci Paixão Kröhling <juraci.github@kroehling.de>
@opentelemetrybot opentelemetrybot requested a review from a team September 23, 2024 22:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

3 participants