You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Erik Weber <te...@gmail.com> on 2014/08/26 22:34:44 UTC
[DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
If I understand correctly, we currently deploy a web server on port 8080 on
the VR and send a specially crafted request to retrieve the password.
This requires special made scripts or software on the guest vms to execute
the password reset.
At the same time cloud-init has become the de facto standard of pushing
configuration to guest vms.
cloud-init does support password resets out of the box, through the usage
of user-data.
There are a couple of issues with this that I can think of, and there are
probably more that I currently cannot think of, but hopefully someone else
might :-)
- we cannot change/update user-data (yet) in acs (i think?)
- if the vm has an existing user-data, we have to modify it. how to handle
custom scripts as user-data?
- should we clean up the user-data after some time? how to pick up that
the cloud-init has run?
If you want to test how this works you can deploy a machine with cloud-init
installed.
I used this[1] from Lucian as source for its configuration.
After that, you have to manually log on to the VR, go to
/var/www/html/userdata/<vm ip>/ and modify the user-data file. Example
content is here[2].
Then on your test machine, issue: rm -rf /var/lib/cloud/ && cloud-init init
&& cloud-init modules --mode config && cloud-init modules --mode final
If you chose to use the random password generator it will display on the
screen.
This is most likely beyond my programming skills, so I cannot say what
amount of effort it would take to accomplish.
[1] http://dl.openvm.eu/cloudstack/centos/ks/vanilla/7/post_cloudstack.ks
[2] https://gist.github.com/terbolous/e0ab09afaa6be2a5f3bb
--
Erik
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by Marcus <sh...@gmail.com>.
Yeah, that would be low hanging fruit as far as features go, since the API
is already in place to set VM public keys.
On Tue, Aug 26, 2014 at 4:33 PM, Carlos Reategui <ca...@reategui.com>
wrote:
> On Tue, Aug 26, 2014 at 3:04 PM, Marcus <sh...@gmail.com> wrote:
>
> > I'm wondering how you keep the root password secure. Right now, it works
> > similarly to userdata and metadata, in that the instance queries its
> router
> > as it boots, but then the password is wiped once queried. If this didn't
> > happen, non-root users could query for the root password all day. Do you
> > suggest this be special userdata that is handled like this after first
> > access? Or is there another way this is normally handled?
> >
>
> For that reason I prefer to set the meta-data/public-keys and not allow
> password authentication. Cloud-init supports this. It would be nice if
> the UI had a means to manage keys and an option to set the public-key for
> an instance.
>
>
> >
> > Is the push for cloud-init just that it is easier to install than
> > cloud-set-guest-password?
> >
> >
> >
> > On Tue, Aug 26, 2014 at 4:00 PM, Erik Weber <te...@gmail.com> wrote:
> >
> > > On Tue, Aug 26, 2014 at 11:44 PM, Nux! <nu...@li.nux.ro> wrote:
> > >
> > > > Hi Erik and thanks for your effort. Using user data is a nice idea.
> > > > Let's see what more experienced programmers have to say on this.
> > > >
> > > >
> > > Sure thing
> > >
> > > One thing that I noticed; though it might have been OK in your
> particular
> > > > case, "rm -rf /var/lib/cloud/" is a bad idea as it can include
> various
> > > > useful scripts along that path. As you noticed I copy the
> > > > cloudstack-set-password script in /var/lib/cloud/scripts/per-boot, so
> > > > that's one example. :-)
> > > >
> > >
> > >
> > > Guess I should note that this was on a test vm, to force refreshing the
> > > user-data. It can probably be done with in a less harmful way.
> > >
> > > DO NOT DO THIS ON ANYTHING IN PRODUCTION :-)
> > >
> > > --
> > > Erik
> > >
> >
>
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by Carlos Reategui <ca...@reategui.com>.
On Tue, Aug 26, 2014 at 3:04 PM, Marcus <sh...@gmail.com> wrote:
> I'm wondering how you keep the root password secure. Right now, it works
> similarly to userdata and metadata, in that the instance queries its router
> as it boots, but then the password is wiped once queried. If this didn't
> happen, non-root users could query for the root password all day. Do you
> suggest this be special userdata that is handled like this after first
> access? Or is there another way this is normally handled?
>
For that reason I prefer to set the meta-data/public-keys and not allow
password authentication. Cloud-init supports this. It would be nice if
the UI had a means to manage keys and an option to set the public-key for
an instance.
>
> Is the push for cloud-init just that it is easier to install than
> cloud-set-guest-password?
>
>
>
> On Tue, Aug 26, 2014 at 4:00 PM, Erik Weber <te...@gmail.com> wrote:
>
> > On Tue, Aug 26, 2014 at 11:44 PM, Nux! <nu...@li.nux.ro> wrote:
> >
> > > Hi Erik and thanks for your effort. Using user data is a nice idea.
> > > Let's see what more experienced programmers have to say on this.
> > >
> > >
> > Sure thing
> >
> > One thing that I noticed; though it might have been OK in your particular
> > > case, "rm -rf /var/lib/cloud/" is a bad idea as it can include various
> > > useful scripts along that path. As you noticed I copy the
> > > cloudstack-set-password script in /var/lib/cloud/scripts/per-boot, so
> > > that's one example. :-)
> > >
> >
> >
> > Guess I should note that this was on a test vm, to force refreshing the
> > user-data. It can probably be done with in a less harmful way.
> >
> > DO NOT DO THIS ON ANYTHING IN PRODUCTION :-)
> >
> > --
> > Erik
> >
>
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by Marcus <sh...@gmail.com>.
I'm wondering how you keep the root password secure. Right now, it works
similarly to userdata and metadata, in that the instance queries its router
as it boots, but then the password is wiped once queried. If this didn't
happen, non-root users could query for the root password all day. Do you
suggest this be special userdata that is handled like this after first
access? Or is there another way this is normally handled?
Is the push for cloud-init just that it is easier to install than
cloud-set-guest-password?
On Tue, Aug 26, 2014 at 4:00 PM, Erik Weber <te...@gmail.com> wrote:
> On Tue, Aug 26, 2014 at 11:44 PM, Nux! <nu...@li.nux.ro> wrote:
>
> > Hi Erik and thanks for your effort. Using user data is a nice idea.
> > Let's see what more experienced programmers have to say on this.
> >
> >
> Sure thing
>
> One thing that I noticed; though it might have been OK in your particular
> > case, "rm -rf /var/lib/cloud/" is a bad idea as it can include various
> > useful scripts along that path. As you noticed I copy the
> > cloudstack-set-password script in /var/lib/cloud/scripts/per-boot, so
> > that's one example. :-)
> >
>
>
> Guess I should note that this was on a test vm, to force refreshing the
> user-data. It can probably be done with in a less harmful way.
>
> DO NOT DO THIS ON ANYTHING IN PRODUCTION :-)
>
> --
> Erik
>
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by Erik Weber <te...@gmail.com>.
On Tue, Aug 26, 2014 at 11:44 PM, Nux! <nu...@li.nux.ro> wrote:
> Hi Erik and thanks for your effort. Using user data is a nice idea.
> Let's see what more experienced programmers have to say on this.
>
>
Sure thing
One thing that I noticed; though it might have been OK in your particular
> case, "rm -rf /var/lib/cloud/" is a bad idea as it can include various
> useful scripts along that path. As you noticed I copy the
> cloudstack-set-password script in /var/lib/cloud/scripts/per-boot, so
> that's one example. :-)
>
Guess I should note that this was on a test vm, to force refreshing the
user-data. It can probably be done with in a less harmful way.
DO NOT DO THIS ON ANYTHING IN PRODUCTION :-)
--
Erik
Re: [DISCUSS] Changing the way password reset works, or allowing
the cloud-init way
Posted by Nux! <nu...@li.nux.ro>.
Hi Erik and thanks for your effort. Using user data is a nice idea.
Let's see what more experienced programmers have to say on this.
One thing that I noticed; though it might have been OK in your particular case, "rm -rf /var/lib/cloud/" is a bad idea as it can include various useful scripts along that path. As you noticed I copy the cloudstack-set-password script in /var/lib/cloud/scripts/per-boot, so that's one example. :-)
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
----- Original Message -----
> From: "Erik Weber" <te...@gmail.com>
> To: "dev" <de...@cloudstack.apache.org>
> Sent: Tuesday, 26 August, 2014 9:34:44 PM
> Subject: [DISCUSS] Changing the way password reset works, or allowing the cloud-init way
>
> If I understand correctly, we currently deploy a web server on port 8080 on
> the VR and send a specially crafted request to retrieve the password.
>
> This requires special made scripts or software on the guest vms to execute
> the password reset.
>
> At the same time cloud-init has become the de facto standard of pushing
> configuration to guest vms.
>
> cloud-init does support password resets out of the box, through the usage
> of user-data.
>
> There are a couple of issues with this that I can think of, and there are
> probably more that I currently cannot think of, but hopefully someone else
> might :-)
> - we cannot change/update user-data (yet) in acs (i think?)
> - if the vm has an existing user-data, we have to modify it. how to handle
> custom scripts as user-data?
> - should we clean up the user-data after some time? how to pick up that
> the cloud-init has run?
>
> If you want to test how this works you can deploy a machine with cloud-init
> installed.
> I used this[1] from Lucian as source for its configuration.
>
> After that, you have to manually log on to the VR, go to
> /var/www/html/userdata/<vm ip>/ and modify the user-data file. Example
> content is here[2].
>
> Then on your test machine, issue: rm -rf /var/lib/cloud/ && cloud-init init
> && cloud-init modules --mode config && cloud-init modules --mode final
>
> If you chose to use the random password generator it will display on the
> screen.
>
> This is most likely beyond my programming skills, so I cannot say what
> amount of effort it would take to accomplish.
>
>
> [1] http://dl.openvm.eu/cloudstack/centos/ks/vanilla/7/post_cloudstack.ks
> [2] https://gist.github.com/terbolous/e0ab09afaa6be2a5f3bb
>
> --
> Erik
>
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by Erik Weber <te...@gmail.com>.
On Wed, Aug 27, 2014 at 1:04 AM, John Kinsella <jl...@stratosec.co> wrote:
>
> On Aug 26, 2014, at 1:34 PM, Erik Weber <te...@gmail.com> wrote:
> > If I understand correctly, we currently deploy a web server on port 8080
> on
>
> Slight correction: A processes on the VR listens on port 8080, and hands
> any connections to a UNIX script. Calling it a "web server" is way too kind.
>
>
Thanks for the clarification :-)
> Also, you’re just looking at the unix use-case. The Windows agent is close
> sourced the last I checked.
>
>
You're right, I haven't checked the Windows part. I see that cloudbase-init
is ASL2, but I haven't verified if it works in this scenario or not, ie. I
don't know if they have the ACS provider.
> Cloud-init doesn’t feel like the best solution, as the one good thing the
> current setup does is remove the password from the VR after it’s fetched.
>
> Thought there was a bug filed on this, but I don’t see it?
>
>
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by John Kinsella <jl...@stratosec.co>.
SSL - maybe we could use the same SSL cert used for the CP and secure download? Feels a little sketchy at first thought but might be an improvement...
John
On Aug 26, 2014, at 5:51 PM, Chiradeep Vittal <Ch...@citrix.com> wrote:
> The current design is “OK”, not great. Looking for suggestions to make it more secure. E.g.,:
>
> * HTTPS
> * Client authentication
>
> Another idea might be to attach a volume to the VM with the password, but hot plug detection varies widely from OS/Hypervisor combinations.
> HTTP(s) is the lowest common denominator, but it has some trade-offs.
>
> From: John Kinsella <jl...@stratosec.co>>
> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
> Date: Tuesday, August 26, 2014 at 4:04 PM
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
> Subject: Re: [DISCUSS] Changing the way password reset works, or allowing the cloud-init way
>
>
> On Aug 26, 2014, at 1:34 PM, Erik Weber <te...@gmail.com>> wrote:
> If I understand correctly, we currently deploy a web server on port 8080 on
>
> Slight correction: A processes on the VR listens on port 8080, and hands any connections to a UNIX script. Calling it a "web server" is way too kind.
>
> Also, you’re just looking at the unix use-case. The Windows agent is close sourced the last I checked.
>
> Cloud-init doesn’t feel like the best solution, as the one good thing the current setup does is remove the password from the VR after it’s fetched.
>
> Thought there was a bug filed on this, but I don’t see it?
>
>
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by Erik Weber <te...@gmail.com>.
On Wed, Aug 27, 2014 at 4:47 AM, Marcus <sh...@gmail.com> wrote:
> We had set up an agent in the VM that listens on the virtio serial port,
> similar to how the virtual router gets its configurations now in KVM. Host
> to guest communication is an option, and is fairly standardized (qemu guest
> agent, VMware tools, xen tools). It takes a little more work to write a
> daemon, but you could do a lot more with it.
>
> I'm not entirely convinced the current design is broken enough to warrant
> a redesign (or at least I wouldn't want to see compatibility go away).
>
I'm not saying it is broken in any way. I'm just saying that considering
the fact that most people already use cloud-init for keys or bootstrapping
or whatever, it would be great if we atleast discuss the possibility to
somehow provide it with password resets as well.
I'm not directly suggesting that we ditch the current way to do password
resets either, I don't mind it being there.
After all using cloud-init to password reset is currently working, but that
you cannot update user-data after vm launch is a limiting factor in ACS.
If we had that, which I think we should regardless of passwords, we could
easily document how to do it as a first phase thing.
--
Erik
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by John Kinsella <jl...@stratosec.co>.
Is that open source? I’ve been eyeing doing something with that virtio serial path for a long time…seems like it’d be a great improvement.
On Aug 26, 2014, at 7:47 PM, Marcus <sh...@gmail.com>> wrote:
We had set up an agent in the VM that listens on the virtio serial port,
similar to how the virtual router gets its configurations now in KVM. Host
to guest communication is an option, and is fairly standardized (qemu guest
agent, VMware tools, xen tools). It takes a little more work to write a
daemon, but you could do a lot more with it.
I'm not entirely convinced the current design is broken enough to warrant
a redesign (or at least I wouldn't want to see compatibility go away).
On Aug 26, 2014 6:51 PM, "Chiradeep Vittal" <Ch...@citrix.com>>
wrote:
The current design is “OK”, not great. Looking for suggestions to make it
more secure. E.g.,:
* HTTPS
* Client authentication
Another idea might be to attach a volume to the VM with the password, but
hot plug detection varies widely from OS/Hypervisor combinations.
HTTP(s) is the lowest common denominator, but it has some trade-offs.
From: John Kinsella <jl...@stratosec.co>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
Date: Tuesday, August 26, 2014 at 4:04 PM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Changing the way password reset works, or allowing
the cloud-init way
On Aug 26, 2014, at 1:34 PM, Erik Weber <te...@gmail.com><mailto:
terbolous@gmail.com<ma...@gmail.com>>> wrote:
If I understand correctly, we currently deploy a web server on port 8080 on
Slight correction: A processes on the VR listens on port 8080, and hands
any connections to a UNIX script. Calling it a "web server" is way too kind.
Also, you’re just looking at the unix use-case. The Windows agent is close
sourced the last I checked.
Cloud-init doesn’t feel like the best solution, as the one good thing the
current setup does is remove the password from the VR after it’s fetched.
Thought there was a bug filed on this, but I don’t see it?
Stratosec - Secure Finance and Heathcare Clouds
http://stratosec.co
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by Marcus <sh...@gmail.com>.
We had set up an agent in the VM that listens on the virtio serial port,
similar to how the virtual router gets its configurations now in KVM. Host
to guest communication is an option, and is fairly standardized (qemu guest
agent, VMware tools, xen tools). It takes a little more work to write a
daemon, but you could do a lot more with it.
I'm not entirely convinced the current design is broken enough to warrant
a redesign (or at least I wouldn't want to see compatibility go away).
On Aug 26, 2014 6:51 PM, "Chiradeep Vittal" <Ch...@citrix.com>
wrote:
> The current design is “OK”, not great. Looking for suggestions to make it
> more secure. E.g.,:
>
> * HTTPS
> * Client authentication
>
> Another idea might be to attach a volume to the VM with the password, but
> hot plug detection varies widely from OS/Hypervisor combinations.
> HTTP(s) is the lowest common denominator, but it has some trade-offs.
>
> From: John Kinsella <jl...@stratosec.co>>
> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Date: Tuesday, August 26, 2014 at 4:04 PM
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: Re: [DISCUSS] Changing the way password reset works, or allowing
> the cloud-init way
>
>
> On Aug 26, 2014, at 1:34 PM, Erik Weber <terbolous@gmail.com<mailto:
> terbolous@gmail.com>> wrote:
> If I understand correctly, we currently deploy a web server on port 8080 on
>
> Slight correction: A processes on the VR listens on port 8080, and hands
> any connections to a UNIX script. Calling it a "web server" is way too kind.
>
> Also, you’re just looking at the unix use-case. The Windows agent is close
> sourced the last I checked.
>
> Cloud-init doesn’t feel like the best solution, as the one good thing the
> current setup does is remove the password from the VR after it’s fetched.
>
> Thought there was a bug filed on this, but I don’t see it?
>
>
>
Re: [DISCUSS] Changing the way password reset works, or allowing
the cloud-init way
Posted by Chiradeep Vittal <Ch...@citrix.com>.
The current design is “OK”, not great. Looking for suggestions to make it more secure. E.g.,:
* HTTPS
* Client authentication
Another idea might be to attach a volume to the VM with the password, but hot plug detection varies widely from OS/Hypervisor combinations.
HTTP(s) is the lowest common denominator, but it has some trade-offs.
From: John Kinsella <jl...@stratosec.co>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Date: Tuesday, August 26, 2014 at 4:04 PM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Changing the way password reset works, or allowing the cloud-init way
On Aug 26, 2014, at 1:34 PM, Erik Weber <te...@gmail.com>> wrote:
If I understand correctly, we currently deploy a web server on port 8080 on
Slight correction: A processes on the VR listens on port 8080, and hands any connections to a UNIX script. Calling it a "web server" is way too kind.
Also, you’re just looking at the unix use-case. The Windows agent is close sourced the last I checked.
Cloud-init doesn’t feel like the best solution, as the one good thing the current setup does is remove the password from the VR after it’s fetched.
Thought there was a bug filed on this, but I don’t see it?
Re: [DISCUSS] Changing the way password reset works, or allowing the
cloud-init way
Posted by John Kinsella <jl...@stratosec.co>.
On Aug 26, 2014, at 1:34 PM, Erik Weber <te...@gmail.com> wrote:
> If I understand correctly, we currently deploy a web server on port 8080 on
Slight correction: A processes on the VR listens on port 8080, and hands any connections to a UNIX script. Calling it a "web server" is way too kind.
Also, you’re just looking at the unix use-case. The Windows agent is close sourced the last I checked.
Cloud-init doesn’t feel like the best solution, as the one good thing the current setup does is remove the password from the VR after it’s fetched.
Thought there was a bug filed on this, but I don’t see it?