-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
base: main
Are you sure you want to change the base?
Conversation
Still lots to do. I'll let everyone know when it's in a state fit for reviewing. 👍 |
## 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 |
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
content/en/docs/security/_index.md
Outdated
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 |
There was a problem hiding this comment.
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 ..."
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
otlp: | ||
protocols: | ||
grpc: | ||
endpoint: localhost:4317 |
There was a problem hiding this comment.
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).
Co-authored-by: Juraci Paixão Kröhling <[email protected]>
Hi folks! I'm moving this PR out of draft. It's ready for review (finally)! Just a couple thoughts:
EDIT to add preview links: |
There was a problem hiding this 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! 🎉
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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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. |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
Co-authored-by: Pablo Baeyens <[email protected]>
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:
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.