Open Stack

On Thu, May 25, 2017 at 2:36 PM, Marc Heckmann <marc.heckmann at ubisoft.com>
wrote:

> First of all @Lance, thanks for taking the time to write and summarize
> this for us. It's much appreciated.
>

Absolutely! it helps me think about it, too.


>
> While I'm not aware of all the nuances, based on my own testing, I feel
> that we are really close with option 1.
>
> That being said, as you already stated, option 2 is clearly more inline
> with the idea of having a "global" Cloud Admin role. So long term, #2 is
> more desirable.
>
> Given the two sentences above, I certainly would prefer option 3 so that
> we can have a usable solution quickly. I certainly will continue to test
> and provide feedback for the option 1 part.
>
>
It sounds like eventually migrating everything from the is_admin_project to
true global roles is a migration you're willing to make. This might be a
loaded question and it will vary across deployments, but how long would you
expect that migration to take for you're specific deployment(s)?


-m
>
>
>
>
> On Thu, 2017-05-25 at 10:42 +1200, Adrian Turjak wrote:
>
>
>
> On 25/05/17 07:47, Lance Bragstad wrote:
> <snip>
>
> *Option 2*
>
> Implement global role assignments in keystone.
>
> *How it works:*
>
> Role assignments in keystone can be scoped to global context. Users can
> then ask for a globally scoped token
>
> Pros:
> - This approach represents a more accurate long term vision for role
> assignments (at least how we understand it today)
> - Operators can create global roles and assign them as needed after the
> upgrade to give proper global scope to their users
> - It's easier to explain global scope using global role assignments
> instead of a special project
> - token.is_global = True and token.role = 'reader' is easier to understand
> than token.is_admin_project = True and token.role = 'reader'
> - A global token can't be associated to a project, making it harder for
> operations that require a project to consume a global token (i.e. I
> shouldn't be able to launch an instance with a globally scoped token)
>
> Cons:
> - We need to start from scratch implementing global scope in keystone,
> steps for this are detailed in the spec
>
> <snip>
>
>
> On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <lbragstad at gmail.com>
> wrote:
>
> Hey all,
>
> To date we have two proposed solutions for tackling the admin-ness issue
> we have across the services. One builds on the existing scope concepts by
> scoping to an admin project [0]. The other introduces global role
> assignments [1] as a way to denote elevated privileges.
>
> I'd like to get some feedback from operators, as well as developers from
> other projects, on each approach. Since work is required in keystone, it
> would be good to get consensus before spec freeze (June 9th). If you have
> specific questions on either approach, feel free to ping me or drop by the
> weekly policy meeting [2].
>
> Thanks!
>
>
> Please option 2. The concept of being an "admin" while you are only scoped
> to a project is stupid when that admin role gives you super user power yet
> you only have it when scoped to just that project. That concept never
> really made sense. Global scope makes so much more sense when that is the
> power the role gives.
>
> At same time, it kind of would be nice to make scope actually matter. As
> admin you have a role on Project X, yet you can now (while scoped to this
> project) pretty much do anything anywhere! I think global roles is a great
> step in the right direction, but beyond and after that we need to seriously
> start looking at making scope itself matter, so that giving someone 'admin'
> or some such on a project actually only gives them something akin to
> project_admin or some sort of admin-lite powers scoped to that project and
> sub-projects. That though falls into the policy work being done, but should
> be noted, as it is related.
>
> Still, at least global scope for roles make the superuser case make some
> actual sense, because (and I can't speak for other deployers), we have one
> project pretty much dedicated as an "admin_project" and it's just odd to
> actually need to give our service users roles in a project when that
> project is empty and a pointless construct for their purpose.
>
> Also thanks for pushing this! I've been watching your global roles spec
> review in hopes we'd go down that path. :)
>
> -Adrian
>
> _______________________________________________
> OpenStack-operators mailing listOpenStack-operators at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170525/d8e097d1/attachment.html>