| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-10 | |||
| 21:32:23 | fungi | oh, i assumed that was for ssh's x509 auth | |
| 21:34:06 | clarkb | it may be, though I'm not sure how nova would configure the VM to enable that? it would have to add the CA to stuff right? | |
| 21:34:14 | clarkb | in any case ssh vs x509 vs ecdsa is a bit confusing to me | |
| 21:34:20 | clarkb | as they don't seem to align | |
| 21:35:01 | fungi | yeah, agreed | |
| 22:13:59 | opendevreview | Merged openstack/nova stable/xena: [rt] Apply migration context for incoming migrations https://review.opendev.org/c/openstack/nova/+/820553 | |
| 22:24:55 | ade_lee | fungi, you haven't heard anything from canonical re: fips yet , have you? | |
| 22:25:22 | ade_lee | clarkb, ^^ | |
| 22:25:31 | ade_lee | if not, I'll re-ping | |
| 22:26:05 | clarkb | I haven't seen anything | |
| 22:26:15 | clarkb | there was an initial response and then fungi jumped in with more info iirc | |
| 22:27:24 | ade_lee | clarkb, ack thats the last I saw too -- I'll re-ping them | |
| 22:58:20 | fungi | ade_lee: clarkb: while i'm trying not to be pessimistic, we're really no good at running things which are locked up by commercial registration (cf a decade of failing to find a legal solution to testing on rhel) | |
| 22:59:10 | fungi | the easiest solution to it, from our perspective, is if ubuntu made their fips compliance solutions free for everyone | |
| 22:59:42 | clarkb | ya I suspect the easiset thing is for specific jobs to have access to a secret thta they use the enroll | |
| 22:59:49 | fungi | but that's a business decision involving the parts of canonical we rarely have the pleasure of interacting with | |
| 22:59:51 | clarkb | and then run that post merge or something | |
| 23:00:08 | clarkb | assuming their license system is ok with changing IPs and maybe even duplicate IPs over time | |
| 23:21:51 | gmann | ade_lee: ack, will check | |
| 23:37:14 | sean-k-mooney[m] | ade_lee you willl need a spec to change the api to allow ssh key gen with the ec algorithim | |
| 23:37:55 | sean-k-mooney[m] | nova currently allows you to import ecdsa keys | |
| 23:38:23 | sean-k-mooney[m] | but it cant generate them | |
| 23:39:02 | sean-k-mooney[m] | ade_lee if you want to start using them in tempest you should not relay on nova generating them | |
| 23:39:25 | sean-k-mooney[m] | at least not if you want to do it this cycle given spec freeze is thursday | |
| 23:44:31 | sean-k-mooney[m] | clarkb fungi gmann is there a reason for trying to do this in nova andn not in tempest | |
| 23:44:42 | sean-k-mooney[m] | i dont think the current approch is the correct one | |
| 23:45:13 | clarkb | sean-k-mooney[m]: well Ithink if nova generates keys it is reasonable to generate different key types. As a nova user I have never once relied on a key generated by nova for me though so I can see both sides | |
| 23:45:30 | sean-k-mooney[m] | ecdsa is not a differnt key type | |
| 23:45:45 | sean-k-mooney[m] | its a diffent algortiom for ssh key generation | |
| 23:45:54 | sean-k-mooney[m] | so the existing key-type fileid is not valid to extend | |
| 23:46:08 | sean-k-mooney[m] | and if we wer to expose this implentation detail we also should be exposing the key lenght | |
| 23:46:28 | gmann | sean-k-mooney[m]: there are two things here 1. add support and tests in tempest for ecdsa which is this (I have given comment to add tests for that) https://review.opendev.org/c/openstack/tempest/+/807465 2. add support in nova to autogenerate the ecdsa key this is what can be proposed in spec | |
| 23:47:09 | sean-k-mooney[m] | which spec? | |
| 23:47:11 | gmann | and in nova spec we can discuss about autogenerating the ecdsa key in nova. this nova change is not only because of tempest test but a new feature | |
| 23:47:28 | gmann | sean-k-mooney[m]: it is not yet proposed. but as you mentioned this is API change and need spec | |
| 23:48:10 | sean-k-mooney[m] | right so if we want to extend this feature we really shoudl add 2 knew parmaters 1 key size and 2 key algorthim or key cypher | |
| 23:49:03 | fungi | alternatively, consider that nova api deprecated and, as you say, have tempest generate and upload ecdsa keypairs instead | |
| 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 | |