Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-12
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
21:29:37 sean-k-mooney Matko[m]: thos ecould also be commign form the keystoneAuth optiosn we add
21:29:44 Matko[m] yes, I found the usage of tooz. However there is nothing feeding the config to tooz
21:30:06 Matko[m] I did look into keystoneauth too
21:30:09 Matko[m] There is no trace of memcache in keystoneauth project: https://github.com/search?q=repo%3Aopenstack%2Fkeystoneauth+memcache&type=code
21:30:09 Matko[m] No dependency on oslo.cache or dogpile that might consume the config: https://github.com/openstack/keystoneauth/blob/master/requirements.txt
21:30:37 Matko[m] I'll ask the Ironic team then.
21:30:54 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/conf/ironic.py
21:31:10 sean-k-mooney that is where that config section is regeistered and its not an option we are addign explcitly
21:31:37 sean-k-mooney so that measn it coming from either keystoen auth or the sdk i think
21:31:46 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/conf/ironic.py#L128-L131
21:32:42 sean-k-mooney so if those have any effect i suspect it via the sdk/keystoneAuth common logic not anythin ironic specific
21:33:10 Matko[m] I looked into those as well and couldn't find anything. The openstack-helm code I linked to was added 9 years ago. And I wonder/suspect if it was a bad copy/paste from similar code in the chart for keystone_authtoken which has memcache configs.
21:33:38 sean-k-mooney did you check our current config ref
21:33:43 Matko[m] yes
21:33:47 Matko[m] I would also assume list_opts would list and include all the supported configs in the docs.
21:34:03 sean-k-mooney ya we generate the config ref form that
21:34:09 Matko[m] https://docs.openstack.org/nova/latest/configuration/config.html#ironic
21:34:37 Matko[m] if it doesn't ring a bell to anybody, then I'll conclude it was a bad copy/paste.
21:34:43 sean-k-mooney i dont see them there
21:34:49 sean-k-mooney so i think they are not used any more
21:35:13 Matko[m] alright, thanks for your help and time
21:35:14 sean-k-mooney i suspect they may have been used when we use the python-ironic client
21:35:22 sean-k-mooney we swapped to the sdk about 3-4 releases ago
22:33:50 opendevreview Ashish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures https://review.opendev.org/c/openstack/nova/+/980179
#openstack-nova - 2026-03-13
06:31:57 opendevreview Ashish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures https://review.opendev.org/c/openstack/nova/+/980179
09:04:57 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron Ports https://review.opendev.org/c/openstack/nova/+/969298

Earlier   Later