Cannot see values in UI with nested ACL

[ashald]

With Consul 0.6.3 and the latest UI bundle (due to #1071) let's assume following KV hierarchy:

/foo
     alpha
     beta
     gamma
/bar

With ACLs enabled and default policy set to deny if ACL for token set to:

key "bar/" {
  policy = "read"
}

then in UI you will see bar and all its content. But if ACL is set to

key "foo/alpha/" {
  policy = "read"
}

you won't be able to see foo in the UI. In order to get access to alpha you will need to manually put foo into your URL.

Expected behavior: with ACL as mentioned above you should be able to use UI to navigate up to the target dir.

[slackpad]

Hi @ashald this is a function of the longest prefix match behavior of ACLs (see https://groups.google.com/d/msgid/consul-tool/e1e286f7-f091-420f-93ee-3939268a23e9%40googlegroups.com?utm_medium=email&utm_source=footer). I think we'd need a special-case "list" permission to change this behavior. Consul KV doesn't really have knowledge of folders, though, so we'd need to see how this would look.

[ashald]

But how does that work with

key "bar/" {
  policy = "read"
}

?

I assume when you hit on K/V button UI makes a call to get contents of /, root record, but still displays bar.

[slackpad]

Yeah - it will list / and pass in the delimiter / so it will see bar/ and foo/ but there won't be an ACL that lets it see foo/ since the foo/alpha/ ACL is a more specific prefix, so that will be filtered out when looking at the top level.

[ashald]

Ah, I see - it will compare exact key names with ACLs, right?

It'd be so nice to have simple fnmatch-alike wildcards though...

[slackpad]

Correct - it finds the longest prefix match against the ACLs and uses that. Wildcards are a good suggestion for this!

[ashald]

@slackpad can you please take a look at #1738 ? I believe it also might be an issue related to ACL resolution.

[intelradoux]

I'm also interested by this enhancement.

From the example

/foo
  alpha
  beta
  gamma
/bar

I was thinking of ACL like (default set to deny):

key "foo" {  policy = "read" }
key "foo/*" {  policy = "deny" }
key "foo/beta/" {  policy = "write" }

we can also think of rule like :

key "foo/**/password" {  policy = "deny" }  
key "bar/*/password" {  policy = "deny" }

"**" meaning any number of level
"*" meaning only one level.

in order to hide some stuff for specific people.

If I got some time I will look source to check if I can do that

[ghost]

I agree that support for wildcards would be of great benefit to us. We have configuration data stored under different namespaces each ACL'ed off to the team that owns that namespace. Right now that involves explicitly denying every other namespace in every ACL. 40 teams = 1600 ACL rules and adding a rule to all 40 ACLs any time a new team is created :( . Being able to reduce that down to what @intelradoux suggested would be awesome.

@slackpack is there any update on possibly getting this support added?

[slackpad]

Closing this against #3025 which captures the wildcard portion of this.