| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-12 | |||
| 14:34:49 | sean-k-mooney | honestly it woudl be better if we sotred this in barbiacna but this is hella old | |
| 14:35:11 | dansmith | yeah, that's an idea I guess if we were going to modernize it | |
| 14:35:17 | sean-k-mooney | same for keyparis in keyston or barbican | |
| 14:35:49 | dansmith | the cloudbase-init post back to metadata sort of can't be private, so I guess it still needs to encrypt it manually or something | |
| 14:36:07 | dansmith | it's all pretty crusty hacks for 2026 | |
| 14:36:15 | sean-k-mooney | ya so that realying on just ssl at the infra level | |
| 14:36:29 | sean-k-mooney | but also cloudbase dont really do openstack stuff anymore | |
| 14:36:35 | sean-k-mooney | so we coudl perhaps deprecate/remove that | |
| 14:37:10 | sean-k-mooney | i think that was partly put in because we dont have a way for such an agent to call barbican or similar | |
| 14:37:31 | dansmith | what I mean is, no verifiable SSL cert for the metadata service | |
| 14:37:32 | sean-k-mooney | i.e. we dont have the k8s thing of providing a bootstrap/service token | |
| 14:38:08 | dansmith | yeah, deprecate would be best here I think.. but I also want to know if windows users are still relying on the nova->cloudbase-init for the initial password setting part | |
| 14:39:47 | sean-k-mooney | dansmith: by the way we alwasy encyrpt the password with your keypair at least when storign it/returning it | |
| 14:40:00 | sean-k-mooney | i dont knwo if cloud-base was doing that when posting it | |
| 14:40:06 | sean-k-mooney | or if that was on the metadta api side | |
| 14:40:14 | sean-k-mooney | im hoping it was in cloudbase | |
| 14:40:31 | sean-k-mooney | so that nova was never handelign the plaintext password | |
| 14:40:42 | dansmith | yep | |
| 14:41:24 | sean-k-mooney | windows user do often use this but they can use winrm (an i think ssh in newer windwos) or userdata to set the inital password | |
| 14:41:36 | dansmith | also, it looks like the password on create is only used by libvirt if we do injection or if we're creating config_drive.. I haven't yet seen that we store it if not doing either of htose | |
| 14:41:37 | sean-k-mooney | they likely wont | |
| 14:41:47 | sean-k-mooney | but that does at least work | |
| 14:42:07 | dansmith | oh also, I'm not sure if the admin password on create is encrypted ... it seems like not.. once you do set-admin-password its only encrypted, you're right about that | |
| 14:42:32 | sean-k-mooney | ... i dont alwasy like to be right | |
| 14:42:38 | dansmith | yeah, ssh in newer windows for sure | |
| 15:31:24 | dansmith | sean-k-mooney: FWIW, the adminPass generated on boot is stored in plaintext in the config_drive in meta_data.json | |
| 15:32:09 | dansmith | not stored in the database, so not visible via usual http metadata, but.. that would be easy to mount world-readable somewhere and expose your root password _if_ you decided to use it | |
| 15:33:58 | sean-k-mooney | not ideal. i hope we seting it to 440 or 400 today but ya with out nova providsion storage encycrption storing it in the configdriver vs root disk does nto really chagne the postture | |
| 15:35:25 | dansmith | it's either fat or iso9660, so no permissions.. depends on how you mount it | |
| 15:35:47 | dansmith | or if you have an OS that automounts CDs, it probably mounts it 555 | |
| 15:35:49 | sean-k-mooney | oh you mean in the guest rather then on the host | |
| 15:35:52 | dansmith | yes | |
| 15:36:07 | sean-k-mooney | ack | |
| 15:36:22 | dansmith | I meant expose your root password to any random untrusted thing that is running that can read world-readable things on the filesystem | |
| 15:36:22 | sean-k-mooney | i tought you ment an operator or soemoen with acess to read the file on the host | |
| 15:36:42 | sean-k-mooney | but yes so it wont automoutn by default however cloud init will do that | |
| 15:37:00 | sean-k-mooney | so if you have a clodu iamge i think its bindmounted in o /etc/cloud/config.... | |
| 15:37:38 | sean-k-mooney | i have never looked at hwo that is doen in the guest really so im not sure what permissison it will use | |
| 15:37:53 | dansmith | Windows will "mount" it automatically and a general-purpose OS would automount it | |
| 15:38:06 | dansmith | like ubuntu-desktop would end up with it mounted | |
| 15:38:32 | sean-k-mooney | oh right the DE(gnome) ectra woudl | |
| 15:39:02 | sean-k-mooney | not really sure now to avoid that other then contineut to advise agians enabling the fature | |
| 15:39:03 | dansmith | since cloud-init won't set the root password from that (AFAICT) then it's not a big deal there, but on Windows where cloudbase-init would/did it'd be readable | |
| 15:39:27 | dansmith | advise against enabling what, configdrive? | |
| 15:39:43 | sean-k-mooney | the admin password injection | |
| 15:39:49 | sean-k-mooney | not config drive | |
| 15:40:04 | dansmith | there's no way to disable that part AFAICT | |
| 15:40:46 | dansmith | the admin password is always generated in the API and passed to driver.spawn().. if libvirt is creating a config_drive, it will put it in there.. no injection enabling required | |
| 15:40:56 | sean-k-mooney | oh ok was not aware of that. i assuem we only do that on windows images base on the os_type value in glance | |
| 15:41:00 | dansmith | if cloudbase-init was running, sees it and honors it then... | |
| 15:41:16 | dansmith | no, I'm testing this with a linux guest | |
| 15:41:36 | sean-k-mooney | oh ok. perhasp we shoudl add a flag for that somewher then | |
| 15:43:09 | dansmith | $ grep -Po admin_pass.*?, /mnt/openstack/latest/meta_data.json | |
| 15:43:09 | dansmith | admin_pass": "CExk4PUfQLgA", | |
| 15:43:34 | dansmith | well, it doesn't matter for linux guests regardless because cloud-init won't use it | |
| 15:43:49 | dansmith | and for windows guests, if they rely on that, it has to work | |
| 15:43:58 | sean-k-mooney | dansmith: do you know what other palthforms do. i asume aws and kubvirt have a similar issue | |
| 15:44:21 | dansmith | it's not really related to what I'm doing so it doesn't matter, I just thought I'd point it out based on the conversation above | |
| 15:44:35 | sean-k-mooney | ack | |
| 15:46:04 | dansmith | FWIW, I don't see anywhere that we allow a POST/PUT from cloudbase-init via metadata to locally generate and set it | |
| 15:46:12 | dansmith | do you know that's a thing for sure? | |
| 15:53:41 | sean-k-mooney | it is but its hard to find ill grab a link | |
| 15:54:12 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/api/metadata/password.py#L58 | |
| 15:54:51 | sean-k-mooney | dansmith: it can only be set once via that flow | |
| 15:55:22 | sean-k-mooney | https://github.com/openstack/nova/commit/a2101c4e7017715af0a29675b89e14ee2884bd89 | |
| 15:55:39 | dansmith | oh thanks.. how does that get linked from the actual handler that services the GET? I didn't see it ... (don't answer, I can dig) | |
| 15:56:24 | dansmith | so it already has to be encrypted in the way we're expecting in that case I guess.. all we do is split it into pieces | |
| 15:56:27 | sean-k-mooney | my guess is that handeler is jsut alwasy used for both but not sure | |
| 15:57:09 | dansmith | this stuff is so gross | |
| 15:58:00 | sean-k-mooney | that was my reaction when i rediscoved it exested a few years ago i dont know if i have the linke to the cloudbase init code but i thikn its useing the keypair to encyrpt it | |
| 15:58:33 | dansmith | it has to if it wants horizon to be able to use it I think | |
| 15:58:47 | dansmith | well, horizon lets the user choose a private key to decrypt with so.. I guess that could be something else, IDK | |
| 15:59:02 | dansmith | the cloudbase-init code is available, I haven't gone looking through it yet but I will | |
| 16:01:40 | sean-k-mooney | it has to be the private key that releated to the publick key for the server | |
| 16:02:52 | sean-k-mooney | https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/metadata/services/httpservice.py#L71-L81 | |
| 16:03:30 | sean-k-mooney | https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/plugins/common/setuserpassword.py#L50 | |
| 16:03:55 | sean-k-mooney | https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/metadata/services/base.py#L115-L126 | |
| 16:04:32 | dansmith | yep, so same as nova basically | |
| 16:04:35 | sean-k-mooney | so it alwasy the first public key in the list which for opentack is where we put the ssh/x509 pub key form the servers keypair | |
| 16:05:09 | sean-k-mooney | yep so it shoudl be end to end encypted | |
| 16:05:57 | sean-k-mooney | althogh i hate the idea that horizon has a view where you can send it your private key ever | |
| 16:06:18 | sean-k-mooney | hopefully they do that clint side with javascript of somehtign liek that | |
| 16:07:04 | dansmith | yep they do | |
| 16:07:18 | dansmith | and yep, showing the password in cleartext ever seems like an anti-pattern anyway | |
| 16:07:35 | dansmith | I assume there has to be some windows-specific workflow that requires it be generated on the instance at first boot or something | |
| 16:07:44 | dansmith | like maybe post-sysprep or some such | |
| 16:07:49 | dansmith | post-un-sysprep I mean | |
| 16:09:51 | opendevreview | Florian proposed openstack/nova master: Add check for PCIe devices attach limit for volume and ports https://review.opendev.org/c/openstack/nova/+/955584 | |
| 16:24:32 | opendevreview | Merged openstack/nova master: Update compute rpc alias for Gazpacho https://review.opendev.org/c/openstack/nova/+/979008 | |
| 16:24:54 | opendevreview | Merged openstack/nova master: Add Gazpacho prelude section https://review.opendev.org/c/openstack/nova/+/979023 | |
| 17:59:34 | opendevreview | Merged openstack/nova-specs master: Amend vTPM live migration spec https://review.opendev.org/c/openstack/nova-specs/+/980165 | |
| 21:25:28 | Matko[m] | Would anybody know if the ironic driver can or ever consumed in any shape or form the memcache_servers and memcache_secret_key configs from the ironic section in nova.conf? | |
| 21:25:31 | Matko[m] | I'm doing some cleanup in openstack-helm and found those configs are configured in the ironic section: https://opendev.org/openstack/openstack-helm/src/branch/master/nova/templates/configmap-etc.yaml#L166-L172 | |
| 21:25:39 | Matko[m] | I want to remove them as I couldn't find anything consumed them, even through libraries. I want to cover all bases and confirm with the Nova team this is actually not used. | |
| 21:26:25 | sean-k-mooney | Matko[m]: the ironic driver used to use tooz to provide a distibute hash ring | |
| 21:26:35 | sean-k-mooney | i think tha tmight have eben able to use memcache to store it | |
| 21:27:07 | sean-k-mooney | https://opendev.org/openstack/tooz/src/branch/master/tooz/drivers/memcached.py | |
| 21:27:17 | sean-k-mooney | so maybe if it was integrated via that | |
| 21:27:45 | sean-k-mooney | Matko[m]: it woudl proably be better to also check with the ironic folks | |
| 21:28:09 | sean-k-mooney | this i beilve is what it sued form that lib https://opendev.org/openstack/tooz/src/branch/master/tooz/hashring.py#L30 | |