-
-
Notifications
You must be signed in to change notification settings - Fork 313
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
what ACL rights required for consul_acl part to run? #373
Comments
So this isn't really a module issue, but to be clear, if you are enabling ACLs you shouldn't be using anonymous, as you are just letting any random system make said updates. Otherwise, you probably don't need configurationdata:deny, as your Default acl handles that. Honestly i don't see a major issue? |
Here's the thing though... looking at the code of the function, it appears that it is passing the acl_api_token variable, which i am specifying it to use the master token... when I am writing out the puppet to have it do ACLs, so I'm wondering whether there might be functions where it is not passing the variable? As for some of the existing rules... yes, I do need to change them.... I was originally designed as a blacklist so that I can transition from the acl_default_policy from allowed to deny... so I don't break any existing processes. As I mentioned, again... this code below, or any other consul_acl blocks... hangs when acl_default_policy is set as deny.....
|
So, it seems that, on the consul config, aside from have acl_master_token, I also need to have acl_token parameter set.... I bet that is the token that it somehow uses...... as it started working again after... |
So, i'm making steps to secure my consul setup with ACLs... and the most recent change is that I have changed the default policy to deny, via the following snippet.
"acl_default_policy":"deny","acl_down_policy":"extend-cache".
The anon token is given the following rights... mostly some kv stuff and that's it....
{"key":{"configurationdata":{"policy":"deny"},"endpoints":{"policy":"read"}},"event":{"":{"policy":"write"}},"service":{"":{"policy":"write"}},"keyring":"read","operator":"read"}
After the change, however, it seems that the part of my puppet config that add or checks existing ACLs stopped working... it would basically hang...
Looking at the debug log, it would appear that it is able to pass the master ACL to get existing ACLs, but it seems to hang after that....
Debug: prefetching for Anonymous Token Debug: found {:name=>"Anonymous Token", :type=>"client", :rules=>{"key"=>{"configurationdata"=>{"policy"=>"deny"}, "endpoints"=>{"policy"=>"read"}}, "event"=>{""=>{"policy"=>"write"}}, "service"=>{""=>{"policy"=>"write"}}, "keyring"=>"read", "operator"=>"read"}, :id=>"anonymous", :ensure=>:present} Notice: /Stage[main]/Hostclass::Consul_server/Consul_acl[kv-configuration-rw]/protocol: defined 'protocol' as 'http' Error: /Stage[main]/Hostclass::Consul_server/Consul_acl[kv-configuration-rw]: Could not evaluate: Net::ReadTimeout Notice: /Stage[main]/Hostclass::Consul_server/Consul_acl[kv-configuration-ro]/protocol: defined 'protocol' as 'http'
If acl_default_policy is set as allowed, this does not hang, which tells me, somewhere in the call, it is not using the master token, but using something else.....
I know it's some sort of config tweak that might be required.. but what should it be? A anon token with more rights? If so, what k/vs? Should I specify an acl_token, along with acl_master_token in config.json?
The text was updated successfully, but these errors were encountered: