[Forum] Feedback - Proposed Forum Schedule
gmann at ghanshyammann.com
Thu Mar 21 02:44:21 UTC 2019
---- On Wed, 20 Mar 2019 16:17:45 -0500 melanie witt <melwittt at gmail.com> wrote ----
> On Wed, 20 Mar 2019 09:37:54 -0500, Matt Riedemann <mriedemos at gmail.com>
> > On 3/18/2019 4:40 PM, melanie witt wrote:
> >> I wanted to run the idea by operators and users to get feedback.
> > Let me be frank and ask if we (nova) have specific operators and users
> > that are clamoring for these changes and if so, do they plan on not only
> > attending the session but engaging in the development of these pretty
> > massive shifts in how nova works? I know we've been talking about this
> > stuff for a long time, but the demand just doesn't feel like it's there
> > from the operators community, and as a development team we're already
> > spread thin.
> I have customers who have been configuring keystone roles and applying
> them to non-admin users, configuring their policy.json correctly, and
> then being unable to access the nova API in the way they wanted .
> Example: configured non-admin user access to live migration using
> role:MyRole and it doesn't work, they get 404 Instance Not Found if
> going across projects. Because of legacy stuff in nova, it only works
> correctly for role:admin.
> After learning more about our history around policy stuff and picking
> Lance's brain, I found that scope types are a way we could solve the
> problem. Alternatively, we could fix it legacy-style. But if we go the
> scope types route, we could use enablement of proper non-admin policy
> handling as a carrot for getting operators/users to begin using tokens
> with different scopes to access the API in the way they want.
> So, there are operators who want and need this, and based on what I
> learned from Lance, I think I can organize an effort around pushing this
> forward in Train. I outlined the steps we need :
> 1. Add test coverage for existing Nova default policy, to ensure we
> don't regress.
> 2. Add Keystone scopes to Nova APIs. For example, server APIs could
> allow scopes of 'project' and 'system'.
> 3. Add scope checks to Nova APIs and filter the compute_api.get()
> accordingly. The ability to filter would need to be added to the
> compute_api.get() method. If the token scope is 'project', filter the
> get() by project_id. If the token scope is 'system', do not filter the
> 4. Remove the hard-coding of 'project_only=True' in the database layer.
> 5. Educate users about how to request project-scoped vs system-scoped
> tokens from Keystone . They would need to use a system-scoped token
> in order to do a server action across projects, whereas a project-scoped
> token would allow a server action only within a project.
> And I will be able to spend time working on it, and my hope is that
> other people will want to help out too. The first two steps lend
> themselves especially well to being split up among many contributors and
> are quite mechanical. I plan to create an etherpad for organizing that
> work. I think the steps outlined above are not directly related to
> granular API policy and could be worked on in parallel, IIUC.
+1 for these improvements, these are very useful from the operators perspective.
First 3 are matching with what policy updates spec is proposing - https://review.openstack.org/#/c/547850/
I need to update that with review comments and PoC to see how those policies will look like.
I am working on those and then we can check if that match with all the requriements.
We need to make all policies granular otherwise we would not be able to add the suitable
default roles for example system_reader, system_admin etc. During my discussion with
John in Denver PTG I think, we thought of doing all these (scope_type, default roles, granular rule)
altogether so that there will be a single time policy transition for operator instead of multiple breaks.
>  https://bugzilla.redhat.com/show_bug.cgi?id=1663544
>  https://bugzilla.redhat.com/show_bug.cgi?id=1663544#c9
More information about the openstack-discuss