-
Notifications
You must be signed in to change notification settings - Fork 113
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
Allow adding/removing policies for the anonymous token (feature request) #125
Comments
Hi @randomswdev, thanks for opening a new issue. I understand your need, I think this could be added with a new resource: data "consul_acl_token" "anonymous" {
id = "00000000-0000-0000-0000-000000000002"
}
resource "consul_acl_policy" "test" {
name = "my_policy"
datacenters = ["dc1"]
rules = <<-RULE
node_prefix "" {
policy = "read"
}
RULE
}
resource "consul_acl_token_policy_attachement" "anonymous" {
token_id = "${data.consul_acl_token.anonymous.id}"
policy_id = "${consul_acl_policy.test.id}"
} a bit like I don't think we would be able to distinguish between resource "consul_acl_token" "test" {
description = "my test token"
policies = []
local = true
} and resource "consul_acl_token" "test" {
description = "my test token"
local = true
} though which would be an issue. In the first case, it should actively look at the policies attached to the token and removed them if there is some ; in the second, it should not take any action but let them be managed with CC-ing @pearkes for his opinion on this. |
Ok, I can work on this next week implementing a resource as the one you described: resource "consul_acl_token_policy_attachement" "anonymous" {
token_id = "${data.consul_acl_token.anonymous.id}"
policy_id = "${consul_acl_policy.test.id}"
} Regarding you concern related to differentiating between: resource "consul_acl_token" "test" {
description = "my test token"
policies = []
local = true
} and resource "consul_acl_token" "test" {
description = "my test token"
local = true
} I don't think we can differentiate between the two syntaxes, but I can investigate it. Let me know if this plan is ok for you. |
Thanks.
I will look into this too. We need to be able to differentiate between the two syntaxes or to come with another syntax as it would change the behavior of |
Terraform Version
Terraform v0.12.0
Expected Behavior
If multiple tenants manage the same Consul server, each of them could require adding policies to the anonymous token. While other tokens can be created/destroyed as needed (so every tenant can create its owns), the anonymous token is globally shared and cannot be replicated (Consul manages it in a specific way).
For this reason we would like to have the ability to add/remove policies to that token without impacting the policies added/managed by others.
Actual Behavior
In the above scenario, currently we can only import the anonymous token (issue #100) in each one of the tenant's terraform files. But as soon as a tenant adds policies, it overwrites the policies set by other tenants.
References
Issue #100 already discusses the possibility to add logic for updating token's policies. The solution proposed and implemented there does not satisfy our requirement of being able to manage the anonymous token independently across multiple tenants.
Proposed solution
We would like to define a new resource, for example consul_anonymous_token_policy. This resource will allow to add/remove a single policy from the anonymous token, preserving all the other policies (whoever added them).
If we agree on this design or a possible alternative that would address our need, we can develop a pull request implementing the design.
The text was updated successfully, but these errors were encountered: