First, having a policy per node that grants write privileges for the node name is the ideal. This is the least privilege setup you can have. The not so nice part about this is that it requires setting up tons of policies.
In the future there could be better ways Consul could help from policy templating so it can fill in the node name for you and allow sharing a single template for all your consul nodes, or other concepts like a Node Identity similar to how we have Service Identities today. Neither of these things are on the roadmap.
If you do not require strict least-privilege level tokens for your Consul agents then you may be better off with a prefix matching rule for node names and using a common policy.
node_prefix "consul-node-" {
policy = "write"
}
Using that policy will allow tokens generated with that policy to perform write operations on any node whose name starts with “consul-node-”. For many users this level of restriction is enough, but you should carefully consider whether it meets your specific security requirements.
Your process certainly could work. But it would probably involve automatically creating more Vault roles as each role gets tied to a specific set of policies. So after your step 2 you would have to create a new Vault role that uses the policy that was just created. Whether this is a good idea again depends on your security requirements.
Today, it would seem the only way forward is probably to automate some of this yourself. I would recommend open a feature request to Consul and maybe Vault as well on GitHub with your use case. The Consul parts of needing templating, or identities or some other way to solve the issue of needing many policies to do least-privilege tokens has been on my mind since implementing the new ACLs in 1.4. Vault could, however make this process much easier by being able to create Consul policies itself for roles and then generating the tokens from a policy it manages. So instead of having to predefine all of them in Consul, Vault could do it for you. That is definitely not how the secret engine works today but seems like it would be a reasonable request.
One other note is that the Terraform Consul provider can generate policies and tokens. You might be able to use Terraform to do the policy creation and Vault management instead of having to automate something yourself (I haven’t experimented with the Vault provider for Terraform so I can’t say for sure it would do what you want but it might be worth a look). I am envisioning something where you you have terraform create the policy on Consul, then the role in vault instead of needing to write your own code to do this.