guest agent public ssh key add/remove support?

guest agent public ssh key add/remove support?

[David Vossel]

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]

Hey,

- Quick background

I'm investigating a feature for the KubeVirt project [1] (virtual machines
on Kubernetes) and ran into an area that I think the qemu guest agent might
help us solve.

A common usage pattern for nearly every Iaas platform (AWS, GCP, OpenStack,
Azure) is the ability to inject public ssh keys into VMs in order to grant
access to the VM for automation tools (like ansible) and users. One of the
more straightforward ways to do this is using cloud-init, which injects ssh
keys at boot.

However, in KubeVirt we're interested in taking this a step further by
allowing public ssh keys to be dynamically granted and revoked on live
"running" VMs. To accomplish this, we need something for our control plane
to coordinate with that is running within the actual VM guest.

- Guest Agent SSH add/remove Support?

As a PoC, I cobbled together some guest agent exec and file write client
commands which can technically achieve the desired result of
adding/removing entries in a /home/<user>/.ssh/authorized_keys file. It's a
little unwieldy, but it works.

This got me thinking, an officially supported guest agent api for this ssh
key management would be really nice. There's already a somewhat related
precedent with the "guest-set-user-password" guest agent command.

So here's the question. What would you all think about the guest agent API
being expanded with new commands for adding/removing ssh public keys from
authorized_keys files?

Thanks
- David














1. https://github.com/kubevirt/kubevirt

[-- Attachment #2: Type: text/html, Size: 2082 bytes --]

Re: guest agent public ssh key add/remove support?

[Christian Schoenebeck]

On Dienstag, 18. August 2020 15:25:56 CEST David Vossel wrote:
> - Guest Agent SSH add/remove Support?
> 
> As a PoC, I cobbled together some guest agent exec and file write client
> commands which can technically achieve the desired result of
> adding/removing entries in a /home/<user>/.ssh/authorized_keys file. It's a
> little unwieldy, but it works.
> 
> This got me thinking, an officially supported guest agent api for this ssh
> key management would be really nice. There's already a somewhat related
> precedent with the "guest-set-user-password" guest agent command.
> 
> So here's the question. What would you all think about the guest agent API
> being expanded with new commands for adding/removing ssh public keys from
> authorized_keys files?

There are two pass-through file systems in QEMU: 9pfs and virtiofs. Don't you 
think they would be sufficient for the use case?

Best regards,
Christian Schoenebeck

Re: guest agent public ssh key add/remove support?

[David Vossel]

[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]

On Tue, Aug 18, 2020 at 3:10 PM Christian Schoenebeck <
qemu_oss@crudebyte.com> wrote:

> On Dienstag, 18. August 2020 15:25:56 CEST David Vossel wrote:
> > - Guest Agent SSH add/remove Support?
> >
> > As a PoC, I cobbled together some guest agent exec and file write client
> > commands which can technically achieve the desired result of
> > adding/removing entries in a /home/<user>/.ssh/authorized_keys file.
> It's a
> > little unwieldy, but it works.
> >
> > This got me thinking, an officially supported guest agent api for this
> ssh
> > key management would be really nice. There's already a somewhat related
> > precedent with the "guest-set-user-password" guest agent command.
> >
> > So here's the question. What would you all think about the guest agent
> API
> > being expanded with new commands for adding/removing ssh public keys from
> > authorized_keys files?
>
> There are two pass-through file systems in QEMU: 9pfs and virtiofs. Don't
> you
> think they would be sufficient for the use case?
>

probably not entirely.

Understand this isn't an either/or scenario. Our api has been designed to
support multiple "propagation" methods for the ssh keys. We've converged on
the qemu guest agent for some other features and the agent appears to have
the potential to provide us the greatest flexibility when it comes to how
we want this pub ssh key use case to work.  This isn't to say something
like virtiofs won't make sense either in certain scenarios, but for the
purposes of this discussion we're hoping to explore how the qemu guest
agent could be used.

I don't want to go too deep into the shared filesystem approach. I'll
provide some context on the challenges there though.

- virtiofs requires guest kernel >= 5.4. We aren't considering 9p due to
security/performance concerns.
- file ownership/permissions. requires prior knowledge of uid/gid on the
host.
- persistence. if we share authorised_keys via virtiofs, then we have to
put this on a separate persistent network volume (otherwise user
modifications within guest are lost)
- potentially clobbers existing authorization_keys file on disk, with agent
we can merge our additions/removals to whatever the user has set in
authorized_keys.
- lack of KubeVirt support for virtiofs. however, it will likely make it
soon




> Best regards,
> Christian Schoenebeck
>
>
>

[-- Attachment #2: Type: text/html, Size: 3154 bytes --]

Re: guest agent public ssh key add/remove support?

[Christian Schoenebeck]

On Mittwoch, 19. August 2020 15:49:50 CEST David Vossel wrote:
> > There are two pass-through file systems in QEMU: 9pfs and virtiofs. Don't
> > you
> > think they would be sufficient for the use case?
> 
> probably not entirely.
> 
> Understand this isn't an either/or scenario. Our api has been designed to
> support multiple "propagation" methods for the ssh keys. We've converged on
> the qemu guest agent for some other features and the agent appears to have
> the potential to provide us the greatest flexibility when it comes to how
> we want this pub ssh key use case to work.  This isn't to say something
> like virtiofs won't make sense either in certain scenarios, but for the
> purposes of this discussion we're hoping to explore how the qemu guest
> agent could be used.
> 
> I don't want to go too deep into the shared filesystem approach. I'll
> provide some context on the challenges there though.

Expected response, but I could not resist. ;-)

> - virtiofs requires guest kernel >= 5.4. We aren't considering 9p due to
> security/performance concerns.

Hey, there had been no security issue for quite a while with 9pfs. :)
And I am working on the performance issues actually.

Best regards,
Christian Schoenebeck