[openstack-dev] [tc][appcat] The future of the App Catalog

John Garbutt john at johngarbutt.com
Wed Mar 15 12:36:52 UTC 2017


On 13 March 2017 at 21:10, Zane Bitter <zbitter at redhat.com> wrote:
> Yes. this is a problem with the default policy - if you have *any* role in a
> project then you get write access to everything in that project. I don't
> know how I can even call this role-based, since everybody has access to
> everything regardless of their roles.
>
> Keystone folks are working on a new global default policy. The new policy
> will require specific reader/writer roles on a project to access any of that
> project's data (I attended the design session and insisted on it). That will
> free up services to create their own limited-scope roles without the
> consequence of opening up full access to every other OpenStack API. e.g.
> it's easy to imagine a magnum-tenant role that has permissions to move
> Neutron ports around but nothing else.
>
> We ultimately need finer-grained authorisation than that - we'll want users
> to be able to specify permissions for particular resources, and since most
> users are not OpenStack projects we'll need them to be able to do it for
> roles (or specific user accounts) that are not predefined in policy.json.
> With the other stuff in place that's at least do-able in individual projects
> though, and if a few projects can agree on a common approach then it could
> easily turn into e.g. an Oslo library, even if it never turns into a
> centralised authorisation service.

I would love feedback on these three Nova specs currently reworking
our default policy:
https://review.openstack.org/#/c/427872/

It clearly doesn't get us all the way there, but I think it lays the
foundations to build what you suggest.

In a related note, there is this old idea I am trying to write up for
Trove/Magnum concerns (now we have proper service token support in
keystoneauth and keystone middleware):
https://review.openstack.org/#/c/438134/

Thanks,
johnthetubaguy



More information about the OpenStack-dev mailing list