18:01:39 <gmann> #startmeeting policy
18:01:39 <opendevmeet> 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 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:39 <opendevmeet> The meeting name has been set to 'policy'
18:01:59 <rdopiera> Hi, I just added my point to the agenda on the etherpad
18:02:20 <gmann> sure checking
18:02:58 <rdopiera> I can elaborate
18:03:03 <gmann> sure
18:04:23 <rdopiera> 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 <gmann> yeah, and that is for services right like nova etc?
18:05:15 <gmann> not just keystone
18:05:19 <rdopiera> most of the problematic pages are in nova
18:05:25 <gmann> :) yeah
18:05:33 <gmann> 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 <rdopiera> what I can tell is that some of the calls we need to make on them are allowed, but some not
18:06:10 <gmann> 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 <gmann> this is #link BP https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
18:07:04 <rdopiera> I also wanted to clarify how it should work in Horizon from the user interface point of view
18:07:30 <gmann> yeah that will be very helpful and we can see how user going to use it
18:07:35 <rdopiera> 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 <rdopiera> 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 <rdopiera> any user*
18:08:50 <gmann> other scope entry will not be visible at all right?
18:09:20 <rdopiera> you only see the entries in the menu that are allowed by the policy with your current token
18:09:31 <gmann> +1
18:09:41 <rdopiera> I have two doubts about this.
18:10:43 <rdopiera> 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 <rdopiera> 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 <gmann> 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 <rdopiera> currently a user who doesn't have a project can't log into horizon
18:13:14 <gmann> yes that is my expectation.
18:13:54 <gmann> 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 <rdopiera> thanks, then I will add an RFE for handling this case
18:14:27 <gmann> horizon should allow them to login even they are not associated with any project
18:15:08 <gmann> and once they login to horizon they can switch to other scope if they are allowed by keystone
18:15:45 <gmann> we are very much separating the system scope users to perform any project level resource operation
18:15:54 <rdopiera> 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 <gmann> yeah, this is good question.
18:17:01 <gmann> 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 <gmann> 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 <rdopiera> 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 <gmann> and that time there will be less policy with both scope
18:18:34 <gmann> for services, I horizon needs to wait until they are ready
18:19:18 <rdopiera> so we should basically pause work on this?
18:20:41 <gmann> rdopiera: not pause but do only for keystone panel and for other yes hold until Yoga cycle
18:21:18 <gmann> 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 <rdopiera> we use the policies provided to decide which panels to display, we can't use system scope just for some panels
18:21:34 <gmann> so considering services other than keystone will be good for Z cycle
18:22:33 <gmann> 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 <gmann> does that work?
18:22:48 <rdopiera> no
18:22:51 <gmann> ohk
18:23:00 <rdopiera> the switch is global, like switching projects
18:23:52 <gmann> i see
18:24:14 <rdopiera> we can add code to some of the panels that will hide them in system_scope explicitly
18:24:20 <rdopiera> ignoring the policies
18:24:29 <gmann> so in global switch, if we say either system or project scope nova panel will be shown same ?
18:24:47 <gmann> yeah kind of ignoring
18:24:58 <gmann> ignoring new policy
18:25:02 <rdopiera> right now you will see anything that the policy allows
18:25:10 <rdopiera> it's entirely driven by policy checks
18:25:47 <rdopiera> we can add additional checks, but to do that, we need to know what should be displayed in which scope
18:26:24 <rdopiera> that patch I linked does something like that
18:26:51 <rdopiera> it hides the identity panel when not in the syste_scope, when the ENFORCE_SYSTEM_SCOPE option is set
18:27:01 <gmann> so for say nove panel if we ust ignore the scope switching ?
18:27:24 <gmann> rdopiera: ohk, so ENFORCE_SYSTEM_SCOPE  is global one not per service?
18:27:31 <rdopiera> I can hide nova panels when you are switched to system scope
18:27:42 <gmann> ah hide is not good
18:27:46 <rdopiera> I can make it per service
18:28:05 <gmann> yeah, beacuse in actual we have enforce_scope per service so that operator can enable/disable per services
18:28:06 <rdopiera> I can show you how it works on video?
18:28:22 <rdopiera> I quick meet call?
18:28:28 <gmann> sure. meetpad not working currently
18:28:37 <gmann> but google meet ok for me
18:28:49 <rdopiera> https://meet.google.com/juc-fuho-iic
18:29:06 <gmann> joining, 1 min
18:45:39 <gmann> I am adding note in etherpad for discussion on horizon plan.
18:45:51 <gmann> thanks again rdopiera for joining
18:46:14 <gmann> we will cancel next meeting which is on 30th Dec and will meet on 13th Jan
18:46:19 <gmann> #endmeeting