Variables for ACL prefix names

[Jard Leex]

Hello,

do the names a user can give for a prefix can contain variables? Are there some built-in variables available?

I'd like to restrict access to node or agent via the local machine name.

Right now I'd have to define one token + rules per server we have in the Consul cluster. Maintaining them would be a huge effort.

Like so:

node "" {
  policy = "read"
}
node "app1" {
  policy = "write"
}

What I'd like to do is this:

node "" {
  policy = "read"
}
node "$NODENAME" {
  policy = "write"
}

Right now we run on the default policy deny and had to grant write permissions for any node,agent and service via the anonymous token to ensure basic functions like cluster join or agent reload (triggered by local placed service definitions).

With the enhanced options from above I'd like to deploy a acl_token for each agent granting him only write permissions to his node and agent functions. 

The service policy may have to remain write globally as we can't predict service names may getting registered with consul.

Did somebody did something similar already?

Are there feature idea on the Consul roadmap for this?

Thanks

Jard

[Thomas]

I don’t know if I really understand your problem.

Where do deploy your policies? Why you cant use a script to generate the rules and deploy them via curl?

If you only want to have a prefix wildcard you can use your rule:

 

node "app1" {
   policy = "write"
 }




All nodes dedicated to “app1” have to use a nodename like “app1-nodename” and the acl token of this policy.

[Jard Leex]

We are deploying our policies with an Ansible role. The policies are defined in YAML. This way we have it always reproducible and can rebuild them even if the whole Consul cluster crashes.

We aim to have around 8 datacenter with around 1k hosts over all. So creating the policy upfront and maintaining them is no practical way for us.

So I came up with the idea to use variables in names for policies within the policy definition, if Consul supports that.

[Thomas]

Maybe I understand your intention still not yet.

But I think wildcards within a rule definition will make no sense.

 

Will all clients have different acl-tokens or the same?

If it is the same, it make no sense to use different policies and you can use a node prefix and a static YAML for your policies.

If you want to use a different acl token and you don’t know the client node name before it is created you have to create its rule after the node name is known. Here you can use the same ansible playbook to register the node with its credentials at the consul server.

 

If all client node names and tokens are static and known before the nodes are created, you can easily generate your YAML with bash and using the placeholder $NODENAME.

 

If your intention is a backup and restore of the acl policies you can use snapshot or save all policies via the API.

[Jard Leex]

My intention is to have one single acl_token for all Consul agents.

Having hundreds of ACLs (one per server) looks far to awkward for us.

This single token should grant each agent "write" permissions on "agent" and "node" to alter only things related to him. 

This way I want to block that an agent can manipulate other agents data/states like reloading the agent or telling others to leave the cluster.

My fear is that a single agent can dismantle a whole cluster with his acl_token if it is set to wide.

Thus I hoped that I can define one ACL like

node "$self" {
   policy = "write"
 }

where "$self" is interpreted as the node name on each ACL request. I assume the interpretation is then done on the leader.

For example:

Server app1.example.com can e.g. register/deregister content related to himself but not for app2.example.com and the other way around. 

[Thomas]

I think you will be sure that nodes don’t overwrite the same namespaces accidentally and not to be secure against hackers or sth. like that. If that is correct you can ensure by your node (nodename) configuration, that the different clients not overwriting their spaces.

 

node "webserver" {
   policy = "write"
 }

 

At the client node - config.json:

"node_name": "webserver-app1.example.com"

[James Phillips]

Hi,

Currently there's no variable substitution available in Consul ACL
policies, so you'd have to mint a token for each agent with its own
name, or have a more open name prefix but accept more risk of misdeeds
with a shared token. We've started some planning work on a template
system for ACLs, so this is something we can keep in mind for that.
With templates you'd be able to mint a token off of a predefined
policy (still a unique token per agent), and that might be a good
place to do some substitution.

-- James

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/consul/issues
> IRC: #consul on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Consul" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to consul-tool...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/consul-tool/1a8bfc4e-c6f9-4d0f-a59a-f2871396e122%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Jard Leex]

Hi James,

that's what I wanted to know, thank you.

I will keep my eyes open for this feature.

Best regrads

Jard