DNS resolution issue after enabling Consul ACL

Consul
,
1

Good day!

Sorry for my English!

After configuring the Consul ACL, there was a problem: at the request of the security service, I need to restrict anonymous access to the Web API and UI. To do this, I configured the following rules: node_prefix “” {policy = “deny”} service_prefix “” {policy = “deny”}. It worked and now nothing can be done without the token. But there was a problem with our services:
0. On the host with service containers, an agent with maximum privileges is configured

  1. The consul agent is launched inside the container and registers the service through the agent on the host
  2. But after applying the policies for the anonymous user, the service stops receiving domain names from the consul server (vault.service.consul, etc).
  3. If you configure anonymous policies like this: node_prefix “” {policy = “read”} service_prefix “” {policy = “read”}, then the service can see domain names and access them, but this goes against the security policy.
    How can I restrict access to everything for an anonymous user and at the same time allow services to refer to the domain names of the consul?

Please, help. For more than a week I have not been able to find the answer.

Consul ver. 1.9.0

2

Hi @vladimirgibadulin,

Welcome to the Forums!

When you say the service stops receiving domain names from Consul, does that mean services aren’t getting registered, or is it that nslookup/dig commands do not return results?

If it’s the latter, I think the best option for you is to have dedicated consul nodes for serving DNS queries and create and set default token with the necessary policy. Also make sure that from a network security level, only expose the DNS port to the rest of the world.

Ref: Secure Consul with Access Control Lists (ACLs) | Consul - HashiCorp Learn

1 Like
3

Thanks for the answer.

Services are registered. DIG works, doesn’t work in containers. I also forgot to say that this is only needed for the consul-template, which takes KV from the Vault repository.

Can I get domain names through agents?

4

Do you have some minimal examples/errors that you can share? Are you trying to render service names and their attributes from consul-template? Are you using a token for consul template?

5

I can only show the list of policies that are set by default for the agent and the policy for the anonymous user. A token is used by default for policies. When the container goes up, the service inside it registers itself through the agent on the host.

Agent Policies:

acl = "write"
keyring = "write"
operator = "write"
node_prefix "" { policy = "write" }
service_prefix "" { policy = "write" }
query_prefix "" { policy = "write" }
agent_prefix "" { policy = "write" }
session_prefix "" { policy = "write" }
key_prefix "" { policy = "write" }
event_prefix "" { policy = "write" }

consul acl policy create   -name agent   -rules @agent.hcl
consul acl token create -description "Token for Agent" -policy-name agent
consul acl set-agent-token default "<token>"

Anonymous policies:

node_prefix "" { policy = "read" }
service_prefix "" { policy = "read" }
#session_prefix "" { policy = "read" }
#agent_prefix "" { policy = "read" }

If I set node “” {policy = “read”} in the anonymous policy, this will block anonymous users from viewing the list of Nodes, but also block access to domain names of services. But if you leave node_prefix instead of node, then domain names can be pinged inside the container

6

Thanks for the help. It seems I was able to set up getting the domain name through the agent using firewalld. I disabled full access for the anonymous user and now, if I configured everything correctly, the security service can sleep peacefully))

Tell me more, please. Why does curl http://12.34.56.789:8500/v1/agent/members -v return code 200 and empty square brackets [ ] when node_prefix “” {policy = “deny”}? Shouldn’t there be some other code like 404 or something similar?

7

Just a suggestion from a security standpoint. Your agent policy seems to be too open. You should definitely try to tweak it to have the least privileges required.

Someone gaining access to this host will be able to modify the ACL rules and all the hardening you are trying to do will turn out to be of no use.

1 Like
8

Yes, I understand that. Thanks for the advice. I will definitely tune in. I just needed it for observation.