I don’t know of any kind of kernel LSM that provides this, but having some kind of proxy sit in between snaps and the snapd socket would enable finer access control to the snapd socket, i.e. in this case the interface would just allow sending GET’s on
/v2/snaps/[name]/conf, and all other requests would fail from your snap specifically, whereas other snaps that can actually perform other tasks would be able to send a POST to other endpoints, to install snaps, change configuration, etc.
This would probably involve not only adding a proxy that handles the HTTP access control, but also some form of per-snap authentication method, i.e. OAuth or something like that and finally a full backend to snapd to specify what HTTP control is granted to what interfaces.
For operations outside of the snap, access to the snapd socket would still be authenticated using traditional unix socket access permissions, but inside the snap’s mount namespace, the socket that is presented (i.e. currently
/run/snapd.socket) would not be the same socket, but instead a socket that the proxy listens on, and the proxy would then itself have access to the actual unix socket.
Anyways, this is all just a theoretical proposal. For the traefik snap currently to access snaps and their configuration you will need to plug
snapd-control, which will need store approval.