-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Description
Component(s)
receiver/statsd
Is your feature request related to a problem? Please describe.
We have some apps deployed in Kubernetes configured to send metrics to Datadog through the unix datagram socket managed by the Datadog agent in /var/run/datadog/dsd.socket. We're currently exploring a solution to deploy a drop-in replacement of the Datadog agent using a combination of statsdreceiver and datadogreceiver in the collector.
We have a PoC deployed and that works properly, but we have a little issue with the permissions of the socket bind by the statsdreceiver. If the application doesn't run with the same user than the collector, it won't be able to write to the socket because of the following permissions on the socket (default one I assume):
ls -l /var/run/
total 0
srwx-w--w- 1 root root 0 Feb 10 13:53 statsd-receiver.sockSo only owner of the socket is able to write (in that case, root). In comparison the Datadog agent socket has the following permissions:
ls -l /var/run/datadog
total 0
srwx-w--w- 1 root root 0 Jan 3 15:53 dsd.socketDescribe the solution you'd like
To solve the issue, I propose to call a chmod with 0622 right after the bind call to ensure permissions of the socket are managed by the receiver itself.
If needed, we can also introduce in the configuration a new attribute to allow customization of permissions, and make 0622 as default :
config:
receivers:
statsd:
transport: unixgram
endpoint: /path/to/statsd.socket
perms: 0622Describe alternatives you've considered
- Usage of
initContainersrunning as root to runchmod/chown: it works but if the collector restarts, permissions are reset when it binds again. - Usage of
fsGroup, not working
Additional context
I can propose a fix for this issue 👍