Open Stack

I think new-keypair-on-rebuild makes sense for some forms of key rotation
as well. For example, I've worked with a big data ironic customer who uses
rebuild to deploy new OS images onto their ironic managed machines.
Presumably if they wanted to do a keypair rotation they'd do it in a very
similar way.

So yes, I think you've reached the right conclusion here. Thanks for your
work Sean.

Michael




On Wed, Oct 4, 2017 at 9:06 AM, Matt Riedemann <mriedemos at gmail.com> wrote:

> On 10/3/2017 3:16 PM, Sean Dague wrote:
>
>> There is currently a spec up for being able to specify a new key_pair
>> name during the rebuild operation in Nova -
>> https://review.openstack.org/#/c/375221/
>>
>> For those not completely familiar with Nova operations, rebuild triggers
>> the "reset this vm to initial state" by throwing out all the disks, and
>> rebuilding them from the initial glance images. It does however keep the
>> IP address and device models when you do that. So it's useful for
>> ephemeral but repeating workloads, where you'd rather not have the
>> network information change out from under you.
>>
>
> We also talked quite a bit about rebuild with volume-backed instances
> today, and the fact the root disk isn't replaced during rebuild in that
> case, for which there are many reported bugs...
>
>
>> The spec is a little vague about when this becomes really useful,
>> because this will not save you from "I lost my private key, and I have
>> important data on that disk". Because the disk is destroyed. That's the
>> point of rebuild. We once added this preserve_ephemeral flag to rebuild
>> for trippleo on ironic, but it's so nasty we've scoped it to only work
>> with ironic backends. Ephemeral should mean ephemeral.
>>
>> Rebuild bypasses the scheduler. A rebuilt server stays on the same host
>> as it was before, which means the operation has a good chance of being
>> faster than a DELETE + CREATE, as the image cache on that host should
>> already have the base image for you instance.
>>
>
> It also means no chances for NoValidHost or resource claim failures.
>
>
>
>> A bunch of data was collected today in a lot of different IRC channels
>> (#openstack-nova, #openstack-infra, #openstack-operators).
>>
>> = OpenStack Operators =
>>
>> mnaser said that for their customers this would be useful. Keys get lost
>> often, but keeping the IP is actually valuable. They would also like this.
>>
>> penick said that for their existing environment, they have a workflow
>> where this would be useful. But they are moving away from using nova for
>> key distribution because in Nova keys are user owned, which actually
>> works poorly given that everything else is project owned. So they are
>> building something to do key distribution after boot in the guest not
>> using nova's metadata.
>>
>> Lots of people said they didn't use nova's keypair interfaces, they just
>> did it all in config management after the fact.
>>
>> = Also on reboot? =
>>
>> Because the reason people said they wanted it was: "I lost my private
>> key", the question at PTG was "does that mean you want it on reboot?"
>>
>> But as we dive through the constraints of that, people that build "pet"
>> VMs typically delete or disable cloud-init (or similar systems) after
>> first boot. Without that kind of agent, this isn't going to work anyway.
>>
>> So also on reboot seems very fragile and unuseful.
>>
>> = Infra =
>>
>> We asked the infra team if this is useful to them, the answer was no.
>> What would be useful them is if keypairs could be updated. They use a
>> symbolic name for a keypair but want to do regular key rotation. Right
>> now they do this by deleting then recreating keypairs, but that does
>> mean there is a window where there is no keypair with that name, so
>> server creates fail.
>>
>> It is agreed that something supporting key rotation in the future would
>> be handy, that's not in this scope.
>>
>> = Barbican =
>>
>> In the tradition of making a simple fix a generic one, it does look like
>> there is a longer term part of this where Nova should really be able to
>> specify a Barbican resource url for a key so that things like rotation
>> could be dealt with in a system that specializes in that. It also would
>> address the very weird oddity of user vs. project scoping.
>>
>> That's a bigger more nebulous thing. Other folks would need to be
>> engaged on that one.
>>
>>
>> = Where I think we are? =
>>
>> I think with all this data we're at the following:
>>
>> Q: Should we add this to rebuild
>> A: Yes, probably - after some enhancement to the spec *
>>
>> * - we really should have much better use cases about the situations it
>> is expected to be used in. We spend a lot of time 2 and 3 years out
>> trying to figure out how anyone would ever use a feature, and adding
>> another one without this doesn't seem good
>>
>> Q: should this also be on reboot?
>> A: NO - it would be too fragile
>>
>>
>> I also think figuring out a way to get Nova out of the key storage
>> business (which it really shouldn't be in) would be good. So if anyone
>> wants to tackle Nova using Barbican for keys, that would be ++. Rebuild
>> doesn't wait on that, but Barbican urls for keys seems like a much
>> better world to be in.
>>
>>         -Sean
>>
>>
> Sean, thanks for summarizing the various discussions had today. I've also
> included the operators list on this.
>
> --
>
> Thanks,
>
> Matt
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171004/34f0c7ae/attachment.html>