Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1362121 - [Doc][RFE] Disassociate permissions of Upload Images and Create Snapshots
Summary: [Doc][RFE] Disassociate permissions of Upload Images and Create Snapshots
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: Upstream M2
: ---
Assignee: RHOS Documentation Team
QA Contact: Mike Abrams
Don Domingo
URL:
Whiteboard:
Depends On:
Blocks: 1381612
TreeView+ depends on / blocked
 
Reported: 2016-08-01 10:31 UTC by David Sanz
Modified: 2017-11-23 15:16 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-23 15:16:26 UTC


Attachments (Terms of Use)

Description David Sanz 2016-08-01 10:31:00 UTC
At this moment, permission of upload images to openstack and to create instance snapshots are linked.
Customer wants to allow user to create their own instance snapshots but not to upload new images to openstack, because they want to control that only images controlled by the security team are deployed in the infrastructure.

Use Case:

Customer want to control that only approved images are uploaded to Openstack, and they will control from the admin view versions and patching but they want to allow users to create snapshots of their running vms and use that snapshots to create new vms.
If the user want to create an image from that snapshot, they will have to ask the admin guys to create it Customer knows that it is ok for them.

Comment 3 Flavio Percoco 2016-08-02 09:42:54 UTC
Hi David,

Help me understand this a bit better:

What would be the point of allowing users to create snapshots of their instances if they won't be able to upload them in Glance and/or use them?

That being said, this would likely be something that should be requested to Nova as snapshots are created there and it's nova itself that uploads those images to Glance.

Comment 5 David Sanz 2016-08-05 12:23:25 UTC
Hello Flavio,

Customer wants to audit the images uploaded to Glance, and they want to restrict users to upload new images (even if they are private) modifying the policy.json file of glance.

The problem is that if you modify the policy.json of glance to only allow admin to create images, the snapshot creating fails.

Customer wants to allow users to create snapshots from a running instance, and use them to create new servers, using it as backup for rolling back or whatever, because they are being created from an approved image, but not to direct upload new images to openstack, because they cannot control how those images has been created.

Comment 6 Flavio Percoco 2016-08-08 11:59:49 UTC
(In reply to David Sanz from comment #5)
> Hello Flavio,
> 
> Customer wants to audit the images uploaded to Glance, and they want to
> restrict users to upload new images (even if they are private) modifying the
> policy.json file of glance.
> 
> The problem is that if you modify the policy.json of glance to only allow
> admin to create images, the snapshot creating fails.
> 
> Customer wants to allow users to create snapshots from a running instance,
> and use them to create new servers, using it as backup for rolling back or
> whatever, because they are being created from an approved image, but not to
> direct upload new images to openstack, because they cannot control how those
> images has been created.


A-ha! This does clarify things. So, there's no "built-in" way to do this right now. The policies management does not differentiate from "service tokens" and "users tokens". The recommended way for doing this is having a "private" glance-api node that is used *only* by nova. This node should allow for images to be created by anyone. All other, public facing, glance-api nodes should be protected.

Does this help? If it does, I'd probably close this BZ as "UPSTREAM" since there's no really point for us to track this here.

Comment 8 David Sanz 2016-08-17 10:12:51 UTC
Created blueprint for this RFE

https://blueprints.launchpad.net/glance/+spec/disassociate-glance-snapshots-permissions

Comment 10 Paul Grist 2016-10-14 01:44:35 UTC
This did not make Newton and is an upstream blueprint. Marking the bug as an RFE and moving to Pike. If for some reason this is active and has a chance to make it we can bring it back.

Comment 11 Erno Kuvaja 2016-10-19 13:43:25 UTC
Glance community does not follow any blueprints filed against the project. Please see http://docs.openstack.org/developer/glance/contributing/blueprints.html for more details.

Also for Glance snapshot is just an image. There is no differentiation as long as Glance is concerned. As Flavio mentioned earlier the way to address this is to provide internal Glance nodes for Nova and limit Image creation on public facing nodes by policies.

I do not see this changing at least before service tokens are widely supported in OpenStack.

Comment 12 Cyril Roelandt 2017-03-10 14:56:43 UTC
@David: Is this still an issue? If so we should push a lite spec instead of a blueprint, following Erno's comment.

Comment 13 Mikel Olasagasti 2017-04-07 08:14:21 UTC
David answered in the case:

Created By: David Sanz  (24/03/2017 11:29)
Hello Cyril,

Yes, customer is very interested in this feature, they don't allow users to upload images, and this makes OSP admin teams to create all the snapshots required by all the users

Comment 15 Cyril Roelandt 2017-05-15 20:29:21 UTC
Hello Mikel.

The way I see it, we have two options:
- follow Erno's suggestion (see comment #11 "Also for Glance snapshot is just an image. There is no differentiation as long as Glance is concerned. As Flavio mentioned earlier the way to address this is to provide internal Glance nodes for Nova and limit Image creation on public facing nodes by policies.");
- push a lite spec upstream and hope the upstream devs are interested, but Erno did not sound that confident to me.

Comment 17 Cyril Roelandt 2017-11-23 15:16:26 UTC
No news on this bug for a while. As I said in #15, I'd suggest following Erno and Flavio's recommendations. I'm closing this bug since their workaround should work.


Note You need to log in before you can comment on or make changes to this bug.