18:01:39 #startmeeting policy 18:01:39 Meeting started Thu Dec 16 18:01:39 2021 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:39 The meeting name has been set to 'policy' 18:01:59 Hi, I just added my point to the agenda on the etherpad 18:02:20 sure checking 18:02:58 I can elaborate 18:03:03 sure 18:04:23 we started work on the phase two, for the system admin support, in horizon, and for that we added the ability to switch from a project scope to the system scope, and it mostly all works as expected, however, in the system scope we are disallowed to make many calls that are used on a lot of admin pages 18:05:06 yeah, and that is for services right like nova etc? 18:05:15 not just keystone 18:05:19 most of the problematic pages are in nova 18:05:25 :) yeah 18:05:33 As per the new schedule keystone system/domain scope policies are ready means their system scope panel in horizon can be implemented 18:05:42 what I can tell is that some of the calls we need to make on them are allowed, but some not 18:06:10 and nova is going to modify the policy in Yoga cycle where we are modifying many policy from system to project scoped etc 18:07:03 this is #link BP https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2 18:07:04 I also wanted to clarify how it should work in Horizon from the user interface point of view 18:07:30 yeah that will be very helpful and we can see how user going to use it 18:07:35 so far we based our implementation on the PTG discussion, and basically just added an entry to the project scope switching menu, that says "system scope" 18:08:06 any use who has access to the system scope has that option, and can switch to this scope, at which point they will only see the menu entries appropriate for that scope 18:08:18 any user* 18:08:50 other scope entry will not be visible at all right? 18:09:20 you only see the entries in the menu that are allowed by the policy with your current token 18:09:31 +1 18:09:41 I have two doubts about this. 18:10:43 First, from the SRBAC high-level descriptions it seems that there is going to be a special, separate user, that has access to the system scope, and has no access to anything else, and that is going to be the only user who has access to the system scope 18:11:48 If that is the case, we will need a mechanism that allows users who have no access to any project to log into Horizon -- currently if you try that, horizon will not let you to log in. And then you will start in the system scope right from the beginning -- is that right? 18:12:16 yeah so with the new design we finalized in goal is system and project scope users are very much isolated in term of access control (except few cases where few API will be accessible to both) 18:13:07 currently a user who doesn't have a project can't log into horizon 18:13:14 yes that is my expectation. 18:13:54 system users will not have any project_id in their token and can perform only operation allowed to system level which is nothing but the one does not need projetc id like GET hypervisors etc 18:14:18 thanks, then I will add an RFE for handling this case 18:14:27 horizon should allow them to login even they are not associated with any project 18:15:08 and once they login to horizon they can switch to other scope if they are allowed by keystone 18:15:45 we are very much separating the system scope users to perform any project level resource operation 18:15:54 Second doubt I have, currently a lot of API calls are available by policy both in system scope and in project scope -- so the user has access to the same "admin" and "identity" menus as in system scope -- my question is should we explicitly hide them in horizon with some option, or will that be handled by new and updated set of policies? 18:16:19 yeah, this is good question. 18:17:01 for keystone, I think policy are ready and they will not be changed much, In Yoga cycle release we are hoping operator will use the new policy. so it is safe to migrate them in Horizon also 18:17:32 but for service policy like Nova, cinder etc we are re-modifying the policies in Yoga and they should be ready after Yoga 18:17:34 for example, I have a WIP patch for an "ENFORCE_SCOPE" option in horizon that wold hide some menu entries: https://review.opendev.org/c/openstack/horizon/+/818763 18:17:54 and that time there will be less policy with both scope 18:18:34 for services, I horizon needs to wait until they are ready 18:19:18 so we should basically pause work on this? 18:20:41 rdopiera: not pause but do only for keystone panel and for other yes hold until Yoga cycle 18:21:18 Yoga cycle release or whenever services are ready. for example If I can implement for nova in Yoga m-3 or so then you can see but that is still late 18:21:21 we use the policies provided to decide which panels to display, we can't use system scope just for some panels 18:21:34 so considering services other than keystone will be good for Z cycle 18:22:33 rdopiera: i mean if you switch for keystone panel and for other services shows everything what it is currently with message that NO SCOPE SWITCH FOR THIS SERVICE YET 18:22:37 does that work? 18:22:48 no 18:22:51 ohk 18:23:00 the switch is global, like switching projects 18:23:52 i see 18:24:14 we can add code to some of the panels that will hide them in system_scope explicitly 18:24:20 ignoring the policies 18:24:29 so in global switch, if we say either system or project scope nova panel will be shown same ? 18:24:47 yeah kind of ignoring 18:24:58 ignoring new policy 18:25:02 right now you will see anything that the policy allows 18:25:10 it's entirely driven by policy checks 18:25:47 we can add additional checks, but to do that, we need to know what should be displayed in which scope 18:26:24 that patch I linked does something like that 18:26:51 it hides the identity panel when not in the syste_scope, when the ENFORCE_SYSTEM_SCOPE option is set 18:27:01 so for say nove panel if we ust ignore the scope switching ? 18:27:24 rdopiera: ohk, so ENFORCE_SYSTEM_SCOPE is global one not per service? 18:27:31 I can hide nova panels when you are switched to system scope 18:27:42 ah hide is not good 18:27:46 I can make it per service 18:28:05 yeah, beacuse in actual we have enforce_scope per service so that operator can enable/disable per services 18:28:06 I can show you how it works on video? 18:28:22 I quick meet call? 18:28:28 sure. meetpad not working currently 18:28:37 but google meet ok for me 18:28:49 https://meet.google.com/juc-fuho-iic 18:29:06 joining, 1 min 18:45:39 I am adding note in etherpad for discussion on horizon plan. 18:45:51 thanks again rdopiera for joining 18:46:14 we will cancel next meeting which is on 30th Dec and will meet on 13th Jan 18:46:19 #endmeeting