On Wed, 20 Mar 2019 09:37:54 -0500, Matt Riedemann <mriedemos@gmail.com> wrote:
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 [1]. 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 [2]: 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 get(). 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 [4]. 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. Cheers, -melanie [1] https://bugzilla.redhat.com/show_bug.cgi?id=1663544 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1663544#c9