| dansmith | can anyone tell me.. if I have the member role on a project, and member implies reader, will my token (read: context) in a server project have X-Roles: reader,member ? | 15:44 |
|---|---|---|
| xek | redrobot, d34dh0r53, ^ maybe you know? | 15:48 |
| dansmith | I'm asking because we're supposed to have policy rules like "role:reader and project_id:$(project_id)s", which would also apply to member, but the servers themselves don't know that member should include reader | 15:49 |
| dansmith | so unless you add someone to a project as member *and* reader, I would think we'd be unable to apply the above rule to the people we expect to | 15:49 |
| d34dh0r53 | hmm, I do not know | 15:52 |
| dansmith | d34dh0r53: do you understand why I'm asking though? | 15:53 |
| d34dh0r53 | dansmith: yeah, that makes sense | 15:53 |
| dansmith | and I guess the corollary is: Do you expect to just add everyone as member *and* reader to a project? | 15:53 |
| d34dh0r53 | right, and does member imply reader | 15:54 |
| dansmith | at that point member is like the -w- bit and reader is like the r-- bit, but ..that seems less than ideal | 15:54 |
| d34dh0r53 | redrobot may have a better understanding as he's implementing this in barbican | 15:55 |
| dansmith | ack | 15:59 |
| redrobot | dansmith I am not sure what exact roles the response from validating a token contains. But, from a policy point of view, you only need "role:reader" in your policy. | 16:48 |
| redrobot | dansmith the policy engine that does the validation has the smarts to figure out that a token for "role:member" is allowed for a policy defined using only "role:reader" | 16:49 |
| redrobot | dansmith in barbican, we only use "role:reader" for apis that can be accessed by users with any of the roles (reader or member or admin) | 16:51 |
| redrobot | https://opendev.org/openstack/barbican/src/branch/master/barbican/common/policies/secretstores.py#L16 | 16:51 |
| dansmith | redrobot: how does it do that? the reader-member relationship is just convention, but actually defined in keystone, right? does the policy engine pull the roles from keystone to decide how inheritance works? | 17:13 |
| dansmith | redrobot: the reason I'm hitting this is because glance's tests provide raw http headers of "X-Roles: member" and those are failing role:reader policy checks, which I'm sure are running through oslo.policy itself | 17:14 |
| dansmith | if there's some keystone mock I need to make so that the policy lib thinks member and reader are related, then that would be cool, but so far I've just had to change those tests to use "X-Roles: reader,member" | 17:15 |
| *** ricolin_ is now known as ricolin | 17:49 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!