You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should document that. We'll need to be clear that routing to an index like this means that you're on your own as far as index templates / mappings go.
*arbitrary so long as they start with "logs", "metrics-", or "traces-"
Just some context, we saw this post in the security labs blog on how to get Claude Code and Claude Cowork logs using OTEL and decided to implement it.
Since we use Elastic Cloud we used the Managed OTLP endpoint to receive this data, before going into production we decided to validate the risks and was discovered that the API Key used for the Managed OTLP have write permissions on logs-*, metrics-* and traces-* and not just on the otel data streams.
Since this API Key will be set as an Environment variable, the users would have access to it and therefore would be able to ingest data into any index.
If this information were present in the documentation we would start with a self-hosted EDOT collector and not used the Managed OTLP.
This issue is to make more clear that the Managed OTLP API Key has full write permissions on logs-*, metrics-* and traces-* depending on the attributes sent to the endpoint.
Hi @hilt86! This issue tracks the docs update. There's now a PR open for it: elastic/opentelemetry#686. It documents the key's actual write scope (anything under logs-, metrics-, traces-) and the elasticsearch.index routing behavior, so the tradeoff is at least visible upfront.
As for the product change, it's something the team is aware of and has discussed, but there's no public tracker or timeline I can point you to.
In the meantime, the way to get least privilege is to send data through a self-managed collector in Gateway mode with an API key scoped to specific indices, and point your apps at that instead of the managed endpoint.
Activity
eddxavier-elastic commentedon Jun 18, 2026
@elastic/elastic-security-labs hey team, can you take a look on this?
leandrojmp commentedon Jun 18, 2026
Just some context, we saw this post in the security labs blog on how to get Claude Code and Claude Cowork logs using OTEL and decided to implement it.
Since we use Elastic Cloud we used the Managed OTLP endpoint to receive this data, before going into production we decided to validate the risks and was discovered that the API Key used for the Managed OTLP have write permissions on
logs-*,metrics-*andtraces-*and not just on theoteldata streams.Since this API Key will be set as an Environment variable, the users would have access to it and therefore would be able to ingest data into any index.
If this information were present in the documentation we would start with a self-hosted EDOT collector and not used the Managed OTLP.
This issue is to make more clear that the Managed OTLP API Key has full write permissions on
logs-*,metrics-*andtraces-*depending on the attributes sent to the endpoint.hilt86 commentedon Aug 27, 2026
Can anyone from Elastic bump this issue please? An api key with write to all indices for the OTLP / Claude use case is not cool
hilt86 commentedon Oct 26, 2026
Any update on least privileges for this please?
alexandra5000 commentedon Oct 26, 2026
Hi @hilt86! This issue tracks the docs update. There's now a PR open for it: elastic/opentelemetry#686. It documents the key's actual write scope (anything under logs-, metrics-, traces-) and the
elasticsearch.indexrouting behavior, so the tradeoff is at least visible upfront.As for the product change, it's something the team is aware of and has discussed, but there's no public tracker or timeline I can point you to.
In the meantime, the way to get least privilege is to send data through a self-managed collector in Gateway mode with an API key scoped to specific indices, and point your apps at that instead of the managed endpoint.