| *** mhen_ is now known as mhen | 01:21 | |
| *** ralonsoh_ is now known as ralonsoh | 10:19 | |
| *** haleyb|out is now known as haleyb | 12:57 | |
| skraynev | hello. I am trying to tune oslo policies config in neutron for my local deployment and stuck with the following questions: is it possible to limit access to some endpoint only "domain" scoped tokens? In the code it has setup "scope_types=['project']", however, when I patch it to "domain", nothing changes. | 14:12 |
|---|---|---|
| skraynev | and another question: is it possible to restrict access by validation special value in attribute? f.e. I have tag "my-resource" for port and what to block update resource with such tag. the tricky part, that it could be several other tags on this resource. | 14:14 |
| gtema | skraynev - actually both scope_types and the the check itself matters. They are considered as different checks. technically speaking scope_type=domain is not different to having a check_str "project_id:None and not domain_id: None" So if you set the scope_type to domain but the check str will still try to ensure the project_id - it would be rejected pretty much always. Important thing to know - there is no way to override scope_types | 15:36 |
| gtema | through configuration file - it can be only set by the code | 15:36 |
| gtema | on the other hand - domain scope on neutron makes absolutely no sense and it will not work - Neutron code requires project scope since it goes directly into the DB queries | 15:37 |
| gtema | for second question - it depends on the service. Typically services check the policy first and then perform action. That typically means you cant evaluate existing attribute of the resource you are trying to modify. Neutron is doing things again differently and for GET operations it first fetches results and then filters them using policy, for modification operations it still evaluates the policy first | 15:39 |
| fungi | https://governance.openstack.org/tc/reference/projects/oslo.html says damani[m] is the security liaison for oslo, is there a reason he's not one of the oslo security reviewers in https://launchpad.net/~oslo-coresec/+members ? | 16:19 |
| hberaud[m] | fungi: I suppose this is just a forgot | 16:22 |
| fungi | maybe it's a good time to clean up the list in that case, i see a few folks there who haven't been around oslo for a while now | 16:22 |
| fungi | and perhaps there are some maintainers who aren't listed but have an interest in helping with oslo vulnerability reports | 16:23 |
| hberaud[m] | IMO we can at least remove Mosés, Vipin, and Sean | 16:25 |
| hberaud[m] | *Moisés | 16:25 |
| fungi | bnemec too? | 16:25 |
| hberaud[m] | yeah | 16:25 |
| hberaud[m] | Ben is not active since years now, so | 16:26 |
| fungi | looks like i'm the only other admin besides him, and i'd rather not be, i think this was supposed to be a transitory state while we updated the list | 16:26 |
| fungi | so if damani[m] can confirm wanting to be part of oslo-coresec on lp, i'll add him as an admin, remove myself, and then let him add/remove others on behalf of oslo | 16:27 |
| fungi | i guess at the moment the only active oslo-coresec folks (not counting my temporary inclusion) with visibility into oslo vulnerability reports are johnsom and stephenfin | 16:29 |
| hberaud[m] | I'm not part of the DPL volunteer so I do not think this is a good idea having me as an administrator of this board, but maybe Takashi, Stephen, or Daniel will want to become granted as an admin there | 16:29 |
| hberaud[m] | ack | 16:30 |
| fungi | yeah, having multiple admins (none of whom are me) would be a good idea. with damani[m] being the security liaison for oslo, i'd prefer to leave that decision to him though | 16:30 |
| hberaud[m] | ack | 16:31 |
| fungi | i can make recommendations, and minimally act at his direction (or that of the tc) as needed | 16:32 |
| johnsom | fungi: I am still willing to participate as a member | 16:45 |
| fungi | i had assumed so, but i'd also prefer not to be the one to make that call | 16:46 |
| johnsom | I am on an island in the pacific this week though, so if there is an open issue my response will be delayed | 16:47 |
| fungi | no worries, that's the reason for having an updated list consisting of multiple people | 16:47 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!