Default ACLs and Consul Address security

I’m a bit stuck on the most “secure” way to implement ACLs. I currently am only making my Consul clients accessible on localhost. I have Nomad running alongside them, and Nomad currently is supplied with its own ACL token in its config file (previously, I was letting Nomad use the “default” ACL token set on the local Consul agent, but found that Connect-enabled Nomad jobs were not successfully using the Consul agent’s default ACL token - this appears to have been resolved in proxycfg: Use acl.tokens.default token as a default when there is no token in the registration by dnephin · Pull Request #10824 · hashicorp/consul · GitHub, so I may try using the Consul agent’s default ACL token once again).

However, I’ve recently enabled Consul telemetry on my clients for Prometheus to scrape. The problem is, if the Consul agent only listens on localhost, then Prometheus is unable to scrape them. The caveat there is that if I have the agent listen on a non-localhost network interface, then essentially anyone who has network access to my client can direct their Consul API requests against it, and be granted access to whichever API endpoints to which the client has access based on the given client’s default ACL token.

My question then becomes - is it secure/best practice to allow Consul clients to listen on a network interface other than localhost? I know that it is certainly possible to have it listen on multiple which I have previously implemented, but since then I limited access to only localhost for security purposes.

I updated my approach to set the Consul “agent” token and removed the “default” token while allowing access to my clients’ HTTP endpoint. The client refuses unauthenticated traffic and but the agent token allows it to still join the cluster.