Cannot delete resources in remote services once project is deleted

[Adam Young]

Steps to reproduce:

Create project

Assign non-admin role to user

As non-admin user Go to Glance and create image

As admin Delete project

As non-admin, cannot delete image

If policy requires as scoped token, even admin cannot delete the image.

This has the effect of forcing "admin somewhere is admin everywhere"

[Adam Young (ayoung)]

This is one reason we have not yet closed

https://bugs.launchpad.net/keystone/+bug/968696

[Adam Young (ayoung)]

Suggested solution: allow an admin user to create a proejct with the specified project id, assign a role, and go to the remote service to delete the image

[Dolph Mathews (dolph)]

It seems to me that the use case here should be included as part of other project's design considerations in their solutions to bug 968696, rather than a bug against keystone.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/203852

[Adam Young (ayoung)]

In order for the other projects to handle bug bug 968696 in a consistant manner, they need support for Keystone. The alternative is that each project has policy which can work on a project other than the one scoped to the resource. While this is acceptable for things that have no inherant scoping (administrative items at the super level) tokens which are meant for those operations should not be able to affect change in individual tenants projects; any one admin token stolen can than be used for any operation through out the cluster.

There are alternatives to "bringing a project back to life: such as making it possible to perform these actions via a separate endpoint that does not accept tokens and authenticated by strong crypto, like the X509 tokenless auth patch submitted for Keystone.

Probably the most significant aspect of this patch is that, once deleted, there is no differentiator for who can create a project with an ID specified and who has to use the existing mechanism. I would probably recommend that "with id" is reserved for a more specialized class of users. Those should have a different, more stringent, policy check; either in the API call, or a whole separate API to re-cerate a proejct.

Another alternative is to "soft delete" only a project, and maintain a record. An admin could then "re-animate" a project or even get tokens scoped to a deleted project in order to delete remote resources.

[Adam Young (ayoung)]

This is not a problem with current policy/approach. The approach to fix 968696 will also ensure this continues to work.

[OpenStack Infra (hudson-openstack)]

Change abandoned by ayoung (<email address hidden>) on branch: master
Review: https://review.openstack.org/203852