18:02:33 #startmeeting policy_popup 18:02:34 Meeting started Thu Jan 21 18:02:33 2021 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:37 The meeting name has been set to 'policy_popup' 18:02:48 o/ 18:04:13 seems two of us, let's quickly discuss the things 18:04:17 #link https://etherpad.opendev.org/p/default-policy-meeting-agenda 18:04:22 today agenda 18:04:48 we had few action item from previous meeting 18:05:01 gmann to check with abhishekk on glance point in meeting agenda 18:05:24 I am not sure i did it so continuing this 18:05:29 #action gmann to check with abhishekk on glance point in meeting agenda 18:05:46 gmann to push common persona on oslo policy and release 3.6.1 and lbragstad to review that 18:05:56 lbragstad: i think you pushed this 18:05:59 we had a little debate on that in review 18:06:09 yeah - and we weren't quite sure what to do with scope_types 18:06:55 #link https://review.opendev.org/c/openstack/oslo.policy/+/766536 18:07:01 for example, if we set scope_types on personas in oslo.policy, do we expect projects to override them in the actual implementation? 18:07:17 that wasn't really clear and we weren't sure what the best approach was 18:07:20 so it fizzled out 18:08:12 yeah having system_scope:all in check_str and not scope_type seems little conflicting 18:08:26 and i can see how that causes confusion 18:09:11 i don't really care for duplicated check string in each service, but i think i'd rather have that than push something through without thinking about how best to handle it 18:09:45 and we can leave scope_type for service side rule to take care of? 18:10:26 like done in nova 18:10:35 we could - but we need to ensure nested DocumentedDefaultRules work as expected with scope checking 18:11:40 i see your point. i think it work fine as in nova 18:11:48 but we can add test in oslo.policy side too 18:11:51 i don't think i've seen a case where we nest them 18:12:04 ah you mean keeping in both? 18:12:16 common rule as well as in specific rule too 18:12:40 well - a lot of the services will use the composite rules in their services specific policies, right? 18:13:14 with check_str=rule:system_admin -> which is ultimately imported as a DocumentedRuleDefault instance from oslo.policy 18:13:51 but is common rule going to be registered as registered rule in oslo policy? 18:14:04 because oslo policy only checks scope type from register rules https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L1026 18:14:37 anyways i was thinking to remove the scope_type from common rules and let service side to define that in their policy 18:14:55 correct - but the additional recommendation was to use DocumentedDefaultRule for each common persona (check string) so that the definitions for system-admin, system-reader, etc... are all consistent 18:15:00 across the implementations in services 18:15:03 otherwise it is confusing in both way 1. if not checked in oslo policy or 2. checked and erorr 18:16:11 yeah DocumentedRuleDefault rule does not force scope_type 18:16:19 https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L1256 18:16:21 right 18:16:24 it's optional 18:16:48 because it landed in oslo.policy prior to the scope work in keystone and related libraries 18:17:25 but we cannot make it mandatory until we remove the old/existing policy completely 18:17:50 so - the approach i proposed was to implement the common persona check strings as instances of DocumentedRuleDefault because we thought it would be nice to have the same definition/help text for each common personas 18:17:56 that time we can pass some special case for common rules and ignore those in actrual checking ? 18:18:08 +1 fo that 18:18:10 for 18:18:22 otherwise - we could just do something SYSTEM_ADMIN = 'role:admin and system_scope:all' 18:18:39 if the common bits are just strings, then we shouldn't have any problems putting them in oslo.policy as constants 18:19:10 otherwise - it was going to be SYSTEM_ADMIN = policy.DocumentedRuleDefault(name='rule:system_admin', check_str='role:admin and system_scope:all') 18:19:36 and the second case was causing some confusion 18:20:00 other problem with having it DocumentedRuleDefault is about deprecation https://review.opendev.org/c/openstack/oslo.policy/+/766536/1/oslo_policy/personas.py#97 18:20:35 right 18:20:46 and for that services need to define other common rule there side even we make oslo policy common as constant or DocumentedRuleDefault 18:21:50 or we can provide set method on DocumentedRuleDefault to set the deprecated rule info 18:23:29 ok - so are we saying we should or shouldn't move forward with the common personas as DocumentedRuleDefaults in oslo.policy? 18:25:29 humm, i would like to have in DocumentedRuleDefaults but from current challenges it seems difficult and going with constant seems easy 18:25:50 at least it can be helpful when we remove the 'system:all' special string 18:26:02 i need more time to think about it and the ramifications of how it's going to work and test it 18:26:11 ok, 18:26:31 I will also try to consume it on nova side and see how it work/look 18:26:47 #action lbragstad to continue on common persona on oslo policy 18:26:50 for the most part, i've proposed audits for each api and almost all the new check strings are consistent (even if they are duplicated) 18:27:20 ok. 18:28:35 one more challenge i see in common persona is how to change them 'remove system:all' all together for all projects or one by one. 18:28:40 but need to think more on this 18:28:45 ++ 18:28:57 anyways let's continue brainstorming on this. 18:29:02 next Action item is 18:29:04 lbragstad to finish placement as first 18:29:27 I started review the placement patches and I think i should be able to do tomorrow 18:29:39 #link https://review.opendev.org/q/topic:%2522secure-rbac%2522+(status:open+OR+status:merged)+project:openstack/placement 18:29:43 stephen is already +2 on most of them i think 18:29:44 so - i think placement is pretty much done 18:29:54 cool, thanks for that. 18:30:05 i'm working on cinder and ironic now - and we're trying to work through testing strategies with ddt 18:30:19 ok 18:30:20 ironic has a pretty good start 18:30:29 with unit tests? 18:30:33 they're testing everything that's supported by the legacy RBAC approach 18:30:48 they're using functional API tests with ddt 18:30:49 oh they do not use policy fixture? 18:31:13 i mean testing on actual default policy? 18:31:36 yeah - they're testing all the default policies that exist today without any of the secure rbac changes 18:31:45 great 18:31:57 so - they want protection testing for project-admin and project-member use cases 18:32:02 as a starting point 18:32:11 i see. 18:32:17 and then as they implement the various personas, they're going to add new tests for the additional personas 18:32:47 (each class will inherit a different setup that sets the oslo-policy config options that opt them into the new world of enforcement) 18:32:56 +1, that is nice. 18:33:31 i'm attempting to do the same thing with cinder right now 18:33:48 but there you have to write all these new tests like done in nova 18:33:48 i'm not sure how far i'm going to get in two weeks - but i'd like to have enough of a start for others to start jumping in 18:34:12 I can take care of glance after checking with glance team which is fist AI 18:34:33 my JSON->YAML work is almost done, need to debug some failure thoguh 18:35:06 ++ 18:35:08 sounds good 18:35:14 let's move next 18:35:45 last action item is raildo to update https://review.opendev.org/#/c/743318/ 18:36:06 he updated that seems. 18:36:41 I think we also covered the agenda topics also as part of action item. 18:36:49 lbragstad: anything else you have to discuss? 18:36:59 have/want 18:37:00 i posted this to the openstack-discuss mailing list 18:37:03 http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019916.html 18:37:08 gmann, yo, yeah, I have updated the docs suggestions, but I believe that would be nice to create some spec for the "visibility" function discussed on the previous patch set 18:37:09 ah i see 18:37:28 just clarifying some points that have been brought regarding and important distinction between reader and auditor usecases 18:37:55 an important* 18:37:59 #link https://review.opendev.org/c/openstack/glance/+/742810/3/doc/source/admin/interoperable-image-import.rst 18:38:17 lbragstad: +1, that was really nice info. should we add that in some doc in keystone side or so? 18:39:20 already done 18:39:22 #link https://review.opendev.org/c/openstack/keystone/+/771509 18:39:30 raildo: yeah, that case we can cover. 18:39:44 lbragstad: ah nice :) thanks 18:40:04 if you want to review it 18:40:22 yeah sure, I will check. 18:40:25 so raildo point for 'visibility' is in many places in neutron side i think 18:40:33 https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_527/771509/1/check/openstack-tox-docs/5276478/docs/admin/service-api-protection.html#reader 18:40:59 yeah, it might want to discuss about this on the next PTG-ish? 18:42:12 raildo: ok and merge the current version of 743318/ for now or you want to hold it? 18:43:16 gmann, I would that we can merge it, I already adding a note saying that we'll discuss the visibility in a future 18:43:27 I would say* 18:44:07 +1 from me. 18:44:38 I will review the latest version. 18:44:39 thanks 18:44:54 anything else to discuss? 18:44:58 i'm good 18:45:06 nope 18:45:15 thanks lbragstad raildo . 18:45:17 thanks gmann 18:45:23 #endmeeting