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

Document high level security concerns #3227

Open
cartermp opened this issue Sep 5, 2023 · 4 comments
Open

Document high level security concerns #3227

cartermp opened this issue Sep 5, 2023 · 4 comments
Assignees

Comments

@cartermp
Copy link
Contributor

cartermp commented Sep 5, 2023

This was discussed in a comms SIG and floated by the security SIG prior with thumbs ups.

Proposal:

  • Top-level node in the docs called Security
  • Index page is a general overview
  • Page on HTTP operations and, in particular, things like being wary of capturing PII and looking into any config settings you have to set with instrumentation
  • Page on the collector that, in particular, covers the redactionprocessor

Relevant slack thread: https://cloud-native.slack.com/archives/C05A85QC281/p1692283776729499

@cartermp cartermp self-assigned this Sep 5, 2023
@martinjt
Copy link
Member

martinjt commented Sep 6, 2023

This should also include details on the approach to collector image security as that's something I hear a lot about.

@svrnm
Copy link
Member

svrnm commented Sep 8, 2023

There is a Security document in the collector repo, not sure if this belongs there or can be migrated into the docs:

https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md

cc @open-telemetry/collector-approvers

@mx-psi
Copy link
Member

mx-psi commented Sep 8, 2023

Some parts of this doc are for Collector end-users while others are for component developers. I think information for end-users makes sense to have under the OpenTelemetry docs, but information for component developers may be too niche

@svrnm
Copy link
Member

svrnm commented Sep 11, 2023

Splitting it into end-user material @ docs and keep the developer specific material in the repo makes sense to me. (and adding a back-reference from both documents to link them)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants