This is my first time asking for a store request, so bear with me if it is a bit lacking. I’m currently in the process of snapping the grafana-agent. This will later be used as a foundation for a machine charm, similar to the current k8s charm.
To allow for node_exporter, ebpf and similar integrations to work, it needs some bespoke permissions. While I could have opted for a classic snap, I really think it makes sense for the snap to not get more permissions than it actually needs.
The permissions I’m requesting are:
network-bind
time-control
hardware-observe
mount-observe
network-observe
system-observe
All of these are needed to be able to fetch all of the telemetry we need to make this useful, as made clear by prior art through the existing strictly confined node_exporter snap. In addition, some paths not available in the system-observe plug is needed, which resulted in a bespoke plug telemetry:
Likely this wasn’t the case back when the existing node_exporter charm was created, but as of now, node_exporter won’t be able to generate all metrics without it.
In addition to these permissions, I would like for the permissions to be auto-connected, as the software doesn’t make sense without them being present.
Regarding the requested system-files interface - can you be more specific? /var/log/ should be accessible via the log-observe inteface, and parts of /proc/sys/kernel/random are already in the base template for all snaps.
However, I don’t think either /proc/mdstat or /proc/schedstat are currently covered by any snapd interface - both of these seem like reasonable candidates to include in the existing system-observe interface so perhaps a PR to upstream snapd to includes these there would be a better option?
Makes total sense! I’ll switch to the log-observe one for /var/log. There were at least three /proc/sys/kernel/random ones I had issues with. I can try to narrow it down further. Published as revision 3.
+1 from me as well for auto-connect time-control, hardware-observe, mount-observe, network-observe, system-observe to grafana-agent since those are clearly required for the snap to properly operate. +2 votes for, 0 votes against, granting the requested auto-connections. This is now live.
network-bind is auto-connected by default, so no voting is needed ;).
I see this PR has been merged. Are you ok with waiting for the next snapd release to include it? Or is this needed asap?
We still need to build out the charm, so I guess we can wait. If anything I’m a bit worried that these changes won’t make it back to all of the deployments of all of the releases we need to support.
I see the required access is /etc/grafana-agent.yaml, can you please rename the iface reference to be etc-grafana-agent so it better represents the access granted? I am +1 for granting this access since grafana-agent is the clear owner of the directory. Can other @reviewers please vote?
Can you detail which other files perhaps the grafana-agent snap needs access to here since perhaps we can just add these to the base template in snapd instead of using system-files?
+2 votes for, 0 votes against. Granting auto-connect for plugging system-files with read access to /etc/grafana-agent.yaml using the interface reference etc-grafana-agent. This is now live.
Regarding the requested /proc/sys/kernel/random accesses:
Since those are not part of the base template yet, I am +1 to grant those as part of system-files in the meantime.
log-observe was missed during the voting process. +1 from me for auto-connect this iface to grafana-agent since this is clearly required to access files at /var/log