-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] resource "consul_node_token" #197
Comments
Thanks, I see what it does now. I think it may be complicated to accept a resource that does this thought: First the token is specific to each agent so I think the Also I think this would result in all secret tokens being saved in the Terraform state, which we are looking to avoid. For example the Does this seem correct? |
That is something I havent thought about. I work with a small cluster where I have access to all the nodes, so that is no problem for me. And you are right, you need a provider with alias for every node.
This souldn't be a problem. In my draft the resource only accepts accessor_id's. Of course, your provider token requires access to resolve the accessor_id to a secert_id. This way i can set the secert_id, without writing it to the state. (Same as "consul_acl_token_policy_attachment") |
While it won't be useful in many deployment, I understand that I can be very useful in some cases so I guess it's a legitimate resource.
Oh right, that's good news. You can set
I think you should be able to avoid this by adding an optional provider "consul" {
address = "consul-0.local"
}
resource "consul_acl_policy" "agent" {
name = "agent"
rules = <<-RULE
node_prefix "" {
policy = "write"
}
RULE
}
resource "consul_acl_token" "agent_token" {
description = "my test token"
policies = [consul_acl_policy.agent.name]
}
# Set the agent token of consul-0.local
resource "consul_node_token" "agent_token_0" {
type = "agent"
accessor_id = consul_acl_token.agent_token.accessor_id
}
# Set the agent token of consul-1.local
resource "consul_node_token" "agent_token_1" {
address = "consul-1.local"
type = "agent"
accessor_id = consul_acl_token.agent_token.accessor_id
} it would make it more flexible and a bit more useful. Regarding the name it seems to me that |
I have done some futher testing based on your suggestions and i like the result. Example: provider "consul" {
address = "localhost:8500"
}
data "consul_nodes" "all" {}
resource "consul_acl_policy" "agent_policies" {
count = length(data.consul_nodes.all.nodes)
name = "agent-token-${data.consul_nodes.all.nodes[count.index].name}"
rules = <<-RULE
node "${data.consul_nodes.all.nodes[count.index].name}" {
policy = "write"
}
RULE
}
resource "consul_acl_token" "agent_tokens" {
count = length(data.consul_nodes.all.nodes)
description = "node policy for ${data.consul_nodes.all.nodes[count.index].name}"
policies = [consul_acl_policy.agent_policies[count.index].name]
}
resource "consul_agent_token" "agent_tokens" {
count = length(data.consul_nodes.all.nodes)
type = "agent"
address = "${data.consul_nodes.all.nodes[count.index].address}:8500"
accessor_id = consul_acl_token.agent_tokens[count.index].accessor_id
}
I also thought about the problem you metioned, that every consul agent must be contacted by Terraform. After some research, i'm still not sure if consul can handle this with some changes. I will create a consul feature request to get some feedback, before continuing. |
I don't think you can support every use-cases here. Consul support sparse connectivity (https://www.consul.io/docs/enterprise/federation) for weird network topologies that will be complicated to support.
What do you have in mind? |
Maybe a bit too much. I thought about something like:
For Terraform, then the resource looks "global". Am i right ? |
Yes but how would you know who is |
As soon as a new agent starts (acl: enabled, no agent token configured), it will be register as new consul member (visible in server logs and ui).
Joining nodes is handled by Serf. And i think Serf is ACL indepentent ? Also note the As soon as the node knows a server, we can call
Am i right or do i miss something ? |
I was wrong, I just tried on a test cluster and even with the ACL to It looks like there is a lot of changes coming in this space in the next months, we should probably wait before merging anything. In the meantime you should probably be able to use the resource you wrote on your cluster without issue. If you want me to review it, please push it on the PR you already created and I will tell you if I see anything out of place :) |
I have updated the PR (tests are missing). I also added some docs just in case someone else want to use the provider until consul is ready to implement a better solution.
I totally agree. It also looks like |
It would be nice to have better ACL support for the bootstrap phase.
In #95, remilapeyre already pointed out the problem of
consul acl boostrap
.Apart from the problem of managing the acl bootstrap command, there is no way to set a terraform managed token, as agent default/agent/master token.
It is already possible to set agent tokens with
v1/agent/token/[default|agent|agent_master|replication]
but not to read them.So this feature depends on changes in consul itself.
@remilapeyre What do you think ? When you say the new resource would be useful, i will start to get the required changes into consul.
The text was updated successfully, but these errors were encountered: