| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-10 | |||
| 23:49:28 | sean-k-mooney[m] | ya | |
| 23:49:51 | fungi | i agree i've never used this nova "feature" either, so it does seem like maybe it's a vestige of a bygone era | |
| 23:49:54 | sean-k-mooney[m] | personally i would prefer to consider the generation part deprecated | |
| 23:50:28 | sean-k-mooney[m] | same i have always uses ssh-keygen or simialr espically when scpriting in ansible or similr | |
| 23:51:03 | fungi | the classical way to handle asymmetric keys is to generate the pairs client-side and only communicate the public part | |
| 23:51:29 | fungi | so having nova supply both halves is not great from a security perspective | |
| 23:51:44 | sean-k-mooney[m] | yep espically since using this api means if the rest api is not protected with ssl the private key is sent to you in the clear | |
| 23:52:33 | sean-k-mooney[m] | meaning it can be intercepted and while we dont log or store this key anywere as a user you dont know that | |
| 23:53:16 | sean-k-mooney[m] | the other benifit of the client generating it is they can generate it with any secuirty requirements they like | |
| 23:53:52 | gmann | yeah that seems more reasonable and secure. | |
| 23:53:57 | sean-k-mooney[m] | fungi this is being motivated by limiations in the cirros image ssh server right | |
| 23:54:28 | fungi | yes | |
| 23:54:28 | gmann | sean-k-mooney[m]: that is from proposed goal https://review.opendev.org/c/openstack/governance/+/816587 | |
| 23:54:46 | gmann | part of that | |
| 23:54:49 | sean-k-mooney[m] | do we need to revisit using alpine or an alternitive guest image at somepoint or do we think cirros will continue to be upddated | |
| 23:55:22 | sean-k-mooney[m] | gmann ack ya the fips goal | |
| 23:56:21 | fungi | in short, the sshd in the cirros images lacks support for rsa with any signarture hash other than sha-1, and fips mode won't let tempest's ssh client use that, so ecdsa (which works on both ends) is an afreeable alternative | |
| 23:56:44 | fungi | agreeable | |
| 23:57:14 | sean-k-mooney[m] | yep its using a old version of dropbare from the commit message which makes sense | |
| 23:57:18 | fungi | and yes, swapping out or improving cirros there is another option of course | |
| 23:57:59 | sean-k-mooney[m] | ya i think long term we should look into nixos, alpine or maintianing cirros oursleve so we can update it | |
| 23:58:11 | sean-k-mooney[m] | but ecdsa is a vaild short term step | |
| 23:58:32 | fungi | if only someone had the time to resurrect emdebian | |
| 23:58:53 | sean-k-mooney[m] | did the dib form docker feature ever land? | |
| 23:59:12 | fungi | yeah, it's currently used to bootstrap fedora images, i believe | |
| 23:59:13 | sean-k-mooney[m] | i more or less had alpine working i just could not get the init ram to find the root disk | |
| 23:59:29 | gmann | from tempest test perspective we cab do either way 1. ecdsa in proposed patch which seems ok and does not depends on nova featrure | |
| 23:59:59 | gmann | 2. new image has been considered in wallaby PTG and we said ok to try but again need someone to try adding/running tests with new image | |
| #openstack-nova - 2022-01-11 | |||
| 00:00:40 | sean-k-mooney[m] | fungi ack, im not sure ill have much time in the short term but i would like to expore a new image again i might look into the docker file support | |
| 00:01:22 | sean-k-mooney[m] | fungi presumable we could host such an image in the ci infra somewhere or on tarballs.o.o | |
| 00:01:29 | sean-k-mooney[m] | if we were to make that move | |
| 00:01:53 | fungi | sure, ironic does (or did) that with their ipa images too | |
| 00:02:18 | sean-k-mooney[m] | we have had times where it would have been useful to upgade specific packages like the guest kernel in the past to workaround itermitent gate issues | |
| 00:02:19 | fungi | but if it's small enough we could just bake a copy into our test node images like we do with cirros | |
| 00:02:57 | sean-k-mooney[m] | ya any replacment would have to be both small on disk and on ram requiremnt | |
| 00:03:07 | sean-k-mooney[m] | but hosting it woudl be usefull for devstack | |
| 00:06:30 | sean-k-mooney[m] | i have been leaning about and using nixos on my work laptop over the break and they have a way to make very small image for contaienr but also have generator for many other formats https://github.com/nix-community/nixos-generators | |
| 00:06:35 | sean-k-mooney[m] | one of them is openstack | |
| 00:07:09 | sean-k-mooney[m] | nixos is also declaritvie by design so we could specify exactly what we wanted to include | |
| 00:19:39 | clarkb | sean-k-mooney[m]: sorry I've been distracted and the point about types is exactly what I was trying to say before | |
| 00:19:47 | clarkb | but it seems nova assumes rsa == ssh in this case | |
| 00:19:58 | clarkb | I don't think its crazy to have ssh_rsa and ssh_ecdsa and so on | |
| 00:20:34 | clarkb | note a new version of dropbear isn't good enough either I don't think | |
| 00:20:42 | clarkb | I don't think they have fixed this issue in dropbear | |
| 00:20:45 | sean-k-mooney[m] | well the value we have rith now are ssh or x509 | |
| 00:21:02 | sean-k-mooney[m] | technially there is no guarentee that ssh is rsa i think | |
| 00:21:13 | sean-k-mooney[m] | ill have to check the api ref | |
| 00:21:14 | clarkb | I think nova is hardcoded to do that though | |
| 00:21:22 | clarkb | but ya I doubt it is written in api docs | |
| 00:21:27 | sean-k-mooney[m] | right but its and implemention detail | |
| 00:21:34 | sean-k-mooney[m] | not part fo the api contract | |
| 00:22:05 | sean-k-mooney[m] | we just promice we will give you a valid ssh key we dont tell you how its generated | |
| 00:22:36 | clarkb | I've not been very fond of nixos image generation fwiw. our matrix gerritbot image is generated with nixos and it does a bunch of silly stuff like set a unicode shell prompt. But then doesn't install a shell | |
| 00:22:57 | clarkb | Its a super power tool and if you aren't using it for everything seems extremely clunky | |
| 00:23:38 | sean-k-mooney[m] | ya i just lost my will to live with fedora any longer and tried it to get back some contol of my laptop | |
| 00:24:40 | sean-k-mooney[m] | its seams to be working fine for me right now but just geting used to it | |
| 00:25:01 | clarkb | the problem with the give me an ssh key api is that as a user I don't want an ssh key per instance. I want each instance to use my ssh key | |
| 00:25:06 | sean-k-mooney[m] | clarkb honetst alpine or simlar would still be my perfered alternitive | |
| 00:25:22 | clarkb | ya alpine would be a good choice too since they target embedded environments | |
| 00:25:39 | sean-k-mooney[m] | alpine was what i prviosuly tried to get working | |
| 00:25:43 | clarkb | but running a full openssh server on alpine etc isn't likely to be much faster than say on ubuntu | |
| 00:25:48 | sean-k-mooney[m] | i should proably abandon does patches | |
| 00:25:51 | clarkb | which is why I mention that dropbear isn't patched yet as far as I know | |
| 00:26:05 | clarkb | to me using ecdsa and dropbear regardless of the image is still going to be necessary | |
| 00:26:11 | sean-k-mooney[m] | well its not about speed right | |
| 00:26:15 | clarkb | it definitely is | |
| 00:26:22 | sean-k-mooney[m] | we could use ubunut if we could get it to fit the ram requiremnts | |
| 00:26:24 | clarkb | tempest is running however many hundreds of instance boots per run | |
| 00:26:33 | clarkb | if you make each one 5 minutes longer that isn't sustainable | |
| 00:26:36 | sean-k-mooney[m] | ok ya speed is also imporant | |
| 00:27:13 | sean-k-mooney[m] | but the first limit we have is must work with 64-96 mb of ram | |
| 00:27:22 | clarkb | ok I'm wrong dropbear does do rsa-sh2 | |
| 00:27:39 | sean-k-mooney[m] | then must have small disk footprint then must not really be any slower then cirros | |
| 00:27:41 | clarkb | as of version 2020.79 | |
| 00:27:46 | sean-k-mooney[m] | yep | |
| 00:27:56 | sean-k-mooney[m] | the version in the cirros image is just too old | |
| 00:27:59 | clarkb | I think frickler mentioned that a new cirros is in the works though | |
| 00:28:06 | sean-k-mooney[m] | so alpine with dropbear would be nice | |
| 00:28:51 | sean-k-mooney[m] | i mean thats also an option buy if frikler does i hope they also update the kernel to something form this decade | |
| 00:29:27 | sean-k-mooney[m] | i think cirros is still using a ubuntu 18.04 kernel | |
| 00:30:02 | sean-k-mooney[m] | it might be from 20.04 but its several years out of date in anycase | |
| 00:30:11 | clarkb | I'm not super familiar with cirros build tooling but I think last I looked you get an entirely new user space when you update busybox to get a new dropbear | |
| 00:30:18 | clarkb | and when you do that chances of needing an ew kernel are much higher too | |
| 00:30:44 | clarkb | I would be surprised if it wasn't a comprehensive update. But also if not updating the kernel as a subsequent step is probably not terrible | |
| 00:30:49 | clarkb | one step at a time and all that | |
| 00:31:06 | sean-k-mooney[m] | the current one has a bug that we ocationally hit | |
| 00:31:33 | sean-k-mooney[m] | its patched in later version of that kernel in ubuntu but not in the specific point release they have imported | |
| 00:32:09 | sean-k-mooney[m] | ya they skip updating the kernel the last time they rebuilt for somethign we needed so hopefully they will do it this time | |
| 00:33:13 | sean-k-mooney[m] | clarkb i just generally like the idea of using something more mainstream but on the other hand its worked well for us for a long time so i dont dislike cirros just its update cadence | |
| 00:33:34 | clarkb | ya, but also frickler seems to be working on solving those problems so I'm happy to defer to epople doing the work :) | |
| 00:33:46 | clarkb | the good thing about cirros is its a proven system that works while still being tiny | |
| 00:34:02 | clarkb | whittling something else down could be significant work and as far as I know no one is doing that work (unlike with frickler and cirros) | |
| 00:34:12 | sean-k-mooney[m] | so one option i think woudl be more viable would be to update nova ssh keygen to use ecrsa unconditioanlly | |
| 00:35:15 | clarkb | There is a problem with that: ecdsa isn't considered secure by many beacuse it relies on magic from NIST | |
| 00:35:25 | sean-k-mooney[m] | clarkb well alpine because of its embeded and contaienr focus is the only thing that comes close form off the shelf solutions | |
| 00:35:39 | sean-k-mooney[m] | clarkb well that depend on the curve | |
| 00:35:40 | clarkb | FIPS is on board with it, but you might notice there is a conflict of interest between the people making FIPS and NIST :) | |
| 00:35:54 | sean-k-mooney[m] | no one should use the nist curve | |
| 00:36:41 | clarkb | I don't think there is another kind that ssh-keygen emits? | |
| 00:36:51 | clarkb | ecsda as supported by fips is the curve that nist magic'd | |