-
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).
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 ---> |
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'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 |
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 also not sure where this is coming from: the only component that I know of spawning new processes is the jmx receiver.
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 comes directly from the security README. Should I remove it?
|
||
## Storing configuration information securely | ||
|
||
<!--- TODO: SHOULD ensure sensitive configuration information is stored securely. How? --> |
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.
Perhaps add a reference to the secrets management practices for Kubernetes?
Co-authored-by: Juraci Paixão Kröhling <juraci.github@kroehling.de>
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.