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

Open
wants to merge 37 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
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
content/en/docs/security/hosting-best-practices.md Outdated Show resolved Hide resolved
content/en/docs/security/hosting-best-practices.md Outdated Show resolved Hide resolved
Co-authored-by: Juraci Paixão Kröhling <[email protected]>
@opentelemetrybot opentelemetrybot requested a review from a team September 23, 2024 22:52
content/en/docs/security/_index.md Show resolved Hide resolved
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
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
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
@tiffany76
Copy link
Contributor Author

tiffany76 commented Oct 18, 2024

Hi folks! I'm moving this PR out of draft. It's ready for review (finally)!

Just a couple thoughts:

  • I think I have addressed all the comments so far, but I did rewrite most of the content, so you might have trouble finding your comments in the changed files. I'm sorry about that.
  • I just reread @jpkrohling's comment about keeping these docs closer to the Collector getting started docs. I know there was some back and forth about it. I don't have a preference either way and will move the files to the Collector docs, if that's what everyone agrees on.
  • I will be AFK next week, so that will be a prime time for everyone to pile on the reviews. 😃

EDIT to add preview links:
Security landing page
Configuration best practices
Hosting best practices

@tiffany76 tiffany76 marked this pull request as ready for review October 18, 2024 04:00
@tiffany76 tiffany76 requested a review from a team as a code owner October 18, 2024 04:00
Copy link
Member

@svrnm svrnm left a comment

Choose a reason for hiding this comment

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

minor comment, but looks good to me overall, great work! 🎉

Comment on lines +6 to +8
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.
Copy link
Member

Choose a reason for hiding this comment

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

should we move that into the frontmatter description, it reads like one

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It might be a little long for the description. Let me take another shot at making the wording more intro-like.

content/en/docs/security/hosting-best-practices.md Outdated Show resolved Hide resolved
Comment on lines +30 to +33
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.
Copy link
Member

Choose a reason for hiding this comment

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

This section is worded differently from the others, I would rephrase it so that it more explicitly tells you what to do (use the least amount of privilege required).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch on the change in wording! I used the example that @jpkrohling gave in a comment that I can't find now. I will work on rephrasing it to match the other examples on the page.

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

5 participants