Re: [openstack-dev] [nova] locked instances and snaphot
On 06/18/2014 07:43 PM, Duncan Thomas wrote: Duncan Thomas On Jun 18, 2014 9:51 PM, "Jay Pipes" mailto:jaypi...@gmail.com>> wrote: > VMs should be cattle, not pets, but yes, a locked instance should be able to be snapshotted, for sure, IMO. Shooting all your cattle by accident is bad y'know, and you're a cattle farmer will probably put you out of business... You are missing the point on this Duncan :) The point of treating VMs as cattle and not pets is that you don't care about any particular VM... they can be killed and respun and the architecture of the application -- i.e. the way you handle state, load balancing, replication of block data, etc -- is designed to handle such failures. We should not be catering our roadmap to features designed to treat customers like little children that constantly need to be watched over, IMO. The effort you've put into raising them has a none-zero cost, and if you keep using them for target practice then some other farmer is going to be selling cheaper beef than you... Actually, raising them has a close-to-zero cost in a utility cloud model, which is the point of it all... Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On Jun 19, 2014, at 13:27, Michael Still wrote: > It might be a good idea to add a comment to the RPC layer for the > snapshot call explaining why we haven't implemented a lock check. That > would reduce future confusion as well. I think that's a good idea -- will do that. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
It might be a good idea to add a comment to the RPC layer for the snapshot call explaining why we haven't implemented a lock check. That would reduce future confusion as well. Cheers, Michael On Fri, Jun 20, 2014 at 5:06 AM, melanie witt wrote: > On Jun 17, 2014, at 13:34, Andrew Laski wrote: > >> It appears that locking was added in 2010 >> (8aea573bd2e44e152fb4ef1627640bab1818dede), at which time commit messages >> weren't nearly as clear and helpful as they now are so there's not much >> insight from that. But the lock checking methods added at that time have a >> docstring that includes "decorator used for preventing action against locked >> instances". So the original intent seems to be that API actions would not >> be allowed against locked instances. From that point of view snapshotting >> should be disallowed. > > That's what I was going on initially too. I was ignorant about what locking > instances is really for and didn't find documentation about it other than > some anecdotal things in ML archive. > >> Having said that, the main reason that I've heard for locks being used is to >> prevent accidental deletes. And I've heard requests for locks that only >> prevent deletes. So in my experience users want more granular locks, not >> more inclusive locking. So I wouldn't consider it a bug that snapshots are >> allowed while an instance is locked. > > That's interesting and good to know. > >> But getting back to the original issue, I'm not sure locking snapshots is >> going to help. The intent seems to be keeping users from gaining access to >> data that's within the instance. But locks don't keep a user from seeing >> what's on the instance, or doing something like an LVM snapshot of the data >> from within the instance. > > That's true and underscores why locking as a security measure doesn't make > much sense. There are too many ways to get around it that you end up with a > quite incomplete lockdown. > > I think we have consensus that instance locking to protect content isn't an > appropriate use of the feature and anyway isn't a complete solution to that > problem. Instance locking prevents accidental changes/deletion of an instance > by way of the api. And in Michael's example scenario of having to unlock (and > risk accidental change/delete) in order to take a snapshot of an important > instance, disabling snapshot of a locked instance would actively disrupt the > expected use case of instance locking. > > Thanks all for the discussion -- I learned a lot about this feature and I'll > be updating the lp bug (not a bug) and review. > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On Jun 17, 2014, at 13:34, Andrew Laski wrote: > It appears that locking was added in 2010 > (8aea573bd2e44e152fb4ef1627640bab1818dede), at which time commit messages > weren't nearly as clear and helpful as they now are so there's not much > insight from that. But the lock checking methods added at that time have a > docstring that includes "decorator used for preventing action against locked > instances". So the original intent seems to be that API actions would not be > allowed against locked instances. From that point of view snapshotting > should be disallowed. That's what I was going on initially too. I was ignorant about what locking instances is really for and didn't find documentation about it other than some anecdotal things in ML archive. > Having said that, the main reason that I've heard for locks being used is to > prevent accidental deletes. And I've heard requests for locks that only > prevent deletes. So in my experience users want more granular locks, not > more inclusive locking. So I wouldn't consider it a bug that snapshots are > allowed while an instance is locked. That's interesting and good to know. > But getting back to the original issue, I'm not sure locking snapshots is > going to help. The intent seems to be keeping users from gaining access to > data that's within the instance. But locks don't keep a user from seeing > what's on the instance, or doing something like an LVM snapshot of the data > from within the instance. That's true and underscores why locking as a security measure doesn't make much sense. There are too many ways to get around it that you end up with a quite incomplete lockdown. I think we have consensus that instance locking to protect content isn't an appropriate use of the feature and anyway isn't a complete solution to that problem. Instance locking prevents accidental changes/deletion of an instance by way of the api. And in Michael's example scenario of having to unlock (and risk accidental change/delete) in order to take a snapshot of an important instance, disabling snapshot of a locked instance would actively disrupt the expected use case of instance locking. Thanks all for the discussion -- I learned a lot about this feature and I'll be updating the lp bug (not a bug) and review. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
Duncan Thomas On Jun 18, 2014 9:51 PM, "Jay Pipes" wrote: > VMs should be cattle, not pets, but yes, a locked instance should be able to be snapshotted, for sure, IMO. Shooting all your cattle by accident is bad y'know, and you're a cattle farmer will probably put you out of business... The effort you've put into raising them has a none-zero cost, and if you keep using them for target practice then some other farmer is going to be selling cheaper beef than you... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On 06/18/2014 01:15 PM, Day, Phil wrote: -Original Message- From: Ahmed RAHAL [mailto:ara...@iweb.com] Sent: 18 June 2014 01:21 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] locked instances and snaphot Hi there, Le 2014-06-16 15:28, melanie witt a écrit : Hi all, [...] During the patch review, a reviewer raised a concern about the purpose of instance locking and whether prevention of snapshot while an instance is locked is appropriate. From what we understand, instance lock is meant to prevent unwanted modification of an instance. Is snapshotting considered a logical modification of an instance? That is, if an instance is locked to a user, they take a snapshot, create another instance using that snapshot, and modify the instance, have they essentially modified the original locked instance? I wanted to get input from the ML on whether it makes sense to disallow snapshot an instance is locked. Beyond 'preventing accidental change to the instance', locking could be seen as 'preventing any operation' to the instance. If I, as a user, lock an instance, it certainly only prevents me from accidentally deleting the VM. As I can unlock whenever I need to, there seems to be no other use case (chmod-like). It bocks any operation that would stop the instance from changing state: Delete, stop, start, reboot, rebuild, resize, shelve, pause, resume, etc In keeping with that I don't see why it should block a snapshot, and having to unlock it to take a snapshot doesn't feel good either. VMs should be cattle, not pets, but yes, a locked instance should be able to be snapshotted, for sure, IMO. If I, as an admin, lock an instance, I am preventing operations on a VM and am preventing an ordinary user from overriding the lock. The driver for doing this as an admin is slightly different - its to stop the user from changing the state of an instance rather than a protection. A couple of use cases: - if you want to migrate a VM and the user is running a continual sequence of say reboot commands at it putting an admin lock in place gives you a way to break into that cycle. - There are a few security cases where we need to take over control of an instance, and make sure it doesn't get deleted by the user But the user would still be able to SSH into their instance and do: shutdown -r now Best, -jay This is a form of authority enforcing that maybe should prevent even snapshots to be taken off that VM. The thing is that enforcing this beyond the limits of nova is AFAIK not there, so cloning/snapshotting cinder volumes will still be feasible. Enforcing it only in nova as a kind of 'security feature' may become misleading. The more I think about it, the more I get to think that locking is just there to avoid mistakes, not voluntary misbehaviour. -- Ahmed ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
> -Original Message- > From: Ahmed RAHAL [mailto:ara...@iweb.com] > Sent: 18 June 2014 01:21 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova] locked instances and snaphot > > Hi there, > > Le 2014-06-16 15:28, melanie witt a écrit : > > Hi all, > > > [...] > > > > During the patch review, a reviewer raised a concern about the purpose > > of instance locking and whether prevention of snapshot while an > > instance is locked is appropriate. From what we understand, instance > > lock is meant to prevent unwanted modification of an instance. Is > > snapshotting considered a logical modification of an instance? That > > is, if an instance is locked to a user, they take a snapshot, create > > another instance using that snapshot, and modify the instance, have > > they essentially modified the original locked instance? > > > > I wanted to get input from the ML on whether it makes sense to > > disallow snapshot an instance is locked. > > Beyond 'preventing accidental change to the instance', locking could be seen > as 'preventing any operation' to the instance. > If I, as a user, lock an instance, it certainly only prevents me from > accidentally > deleting the VM. As I can unlock whenever I need to, there seems to be no > other use case (chmod-like). It bocks any operation that would stop the instance from changing state: Delete, stop, start, reboot, rebuild, resize, shelve, pause, resume, etc In keeping with that I don't see why it should block a snapshot, and having to unlock it to take a snapshot doesn't feel good either. > If I, as an admin, lock an instance, I am preventing operations on a VM and > am preventing an ordinary user from overriding the lock. The driver for doing this as an admin is slightly different - its to stop the user from changing the state of an instance rather than a protection. A couple of use cases: - if you want to migrate a VM and the user is running a continual sequence of say reboot commands at it putting an admin lock in place gives you a way to break into that cycle. - There are a few security cases where we need to take over control of an instance, and make sure it doesn't get deleted by the user > > This is a form of authority enforcing that maybe should prevent even > snapshots to be taken off that VM. The thing is that enforcing this beyond > the limits of nova is AFAIK not there, so cloning/snapshotting cinder volumes > will still be feasible. > Enforcing it only in nova as a kind of 'security feature' may become > misleading. > > The more I think about it, the more I get to think that locking is just there > to > avoid mistakes, not voluntary misbehaviour. > > -- > > Ahmed > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On Wed, Jun 18, 2014 at 10:21 AM, Ahmed RAHAL wrote: > Le 2014-06-16 15:28, melanie witt a écrit : > The more I think about it, the more I get to think that locking is just > there to avoid mistakes, not voluntary misbehaviour. I agree. You have a really important instance, so you lock it to avoid it being accidentally deleted. Its so important you want to take a snapshot of it, but now with the proposed change you have to unlock it to do that (risking a delete in the process). Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
Hi there, Le 2014-06-16 15:28, melanie witt a écrit : Hi all, [...] During the patch review, a reviewer raised a concern about the purpose of instance locking and whether prevention of snapshot while an instance is locked is appropriate. From what we understand, instance lock is meant to prevent unwanted modification of an instance. Is snapshotting considered a logical modification of an instance? That is, if an instance is locked to a user, they take a snapshot, create another instance using that snapshot, and modify the instance, have they essentially modified the original locked instance? I wanted to get input from the ML on whether it makes sense to disallow snapshot an instance is locked. Beyond 'preventing accidental change to the instance', locking could be seen as 'preventing any operation' to the instance. If I, as a user, lock an instance, it certainly only prevents me from accidentally deleting the VM. As I can unlock whenever I need to, there seems to be no other use case (chmod-like). If I, as an admin, lock an instance, I am preventing operations on a VM and am preventing an ordinary user from overriding the lock. This is a form of authority enforcing that maybe should prevent even snapshots to be taken off that VM. The thing is that enforcing this beyond the limits of nova is AFAIK not there, so cloning/snapshotting cinder volumes will still be feasible. Enforcing it only in nova as a kind of 'security feature' may become misleading. The more I think about it, the more I get to think that locking is just there to avoid mistakes, not voluntary misbehaviour. -- Ahmed ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On 06/17/2014 03:03 PM, melanie witt wrote: On Jun 16, 2014, at 13:56, Michael Still wrote: It is certainly my belief that the lock functionality for instances is about avoiding accidental changes to the instance itself, not the contents of the instance. I personally think that snapshots aren't a change to the instance and therefore should be allowed, but I'd be interested in other people's thoughts on this. Thank you for sharing your view. I'm also interested in hearing other thoughts -- if the consensus is to allow snapshot of a locked instance, I can close the loop on the lp bug for the reporter. If anyone else has some input on snapshotting locked instances, please chime in! It appears that locking was added in 2010 (8aea573bd2e44e152fb4ef1627640bab1818dede), at which time commit messages weren't nearly as clear and helpful as they now are so there's not much insight from that. But the lock checking methods added at that time have a docstring that includes "decorator used for preventing action against locked instances". So the original intent seems to be that API actions would not be allowed against locked instances. From that point of view snapshotting should be disallowed. Having said that, the main reason that I've heard for locks being used is to prevent accidental deletes. And I've heard requests for locks that only prevent deletes. So in my experience users want more granular locks, not more inclusive locking. So I wouldn't consider it a bug that snapshots are allowed while an instance is locked. But getting back to the original issue, I'm not sure locking snapshots is going to help. The intent seems to be keeping users from gaining access to data that's within the instance. But locks don't keep a user from seeing what's on the instance, or doing something like an LVM snapshot of the data from within the instance. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On Jun 16, 2014, at 13:56, Michael Still wrote: > It is certainly my belief that the lock functionality for instances is > about avoiding accidental changes to the instance itself, not the > contents of the instance. I personally think that snapshots aren't a > change to the instance and therefore should be allowed, but I'd be > interested in other people's thoughts on this. Thank you for sharing your view. I'm also interested in hearing other thoughts -- if the consensus is to allow snapshot of a locked instance, I can close the loop on the lp bug for the reporter. If anyone else has some input on snapshotting locked instances, please chime in! signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] locked instances and snaphot
On Tue, Jun 17, 2014 at 5:28 AM, melanie witt wrote: > Hi all, > > Recently a nova bug [1] was opened where the user describes a scenario where > an instance that is locked is still able to be snapshotted (create image and > backup). In the case of Trove, instances are locked "...to ensure integrity > and protect secrets which are needed by the resident Trove Agent." However, > the end-user can still take a snapshot of the instance to create an image > while it's locked, and restore the image later. The end-user then has access > to the restored image. > > During the patch review, a reviewer raised a concern about the purpose of > instance locking and whether prevention of snapshot while an instance is > locked is appropriate. From what we understand, instance lock is meant to > prevent unwanted modification of an instance. Is snapshotting considered a > logical modification of an instance? That is, if an instance is locked to a > user, they take a snapshot, create another instance using that snapshot, and > modify the instance, have they essentially modified the original locked > instance? > > I wanted to get input from the ML on whether it makes sense to disallow > snapshot an instance is locked. Thanks for sending this email. It is certainly my belief that the lock functionality for instances is about avoiding accidental changes to the instance itself, not the contents of the instance. I personally think that snapshots aren't a change to the instance and therefore should be allowed, but I'd be interested in other people's thoughts on this. Michael > [1] https://bugs.launchpad.net/nova/+bug/1314741 -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] locked instances and snaphot
Hi all, Recently a nova bug [1] was opened where the user describes a scenario where an instance that is locked is still able to be snapshotted (create image and backup). In the case of Trove, instances are locked "...to ensure integrity and protect secrets which are needed by the resident Trove Agent." However, the end-user can still take a snapshot of the instance to create an image while it's locked, and restore the image later. The end-user then has access to the restored image. During the patch review, a reviewer raised a concern about the purpose of instance locking and whether prevention of snapshot while an instance is locked is appropriate. From what we understand, instance lock is meant to prevent unwanted modification of an instance. Is snapshotting considered a logical modification of an instance? That is, if an instance is locked to a user, they take a snapshot, create another instance using that snapshot, and modify the instance, have they essentially modified the original locked instance? I wanted to get input from the ML on whether it makes sense to disallow snapshot an instance is locked. Thanks, melanie [1] https://bugs.launchpad.net/nova/+bug/1314741 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
