Earlier  
Posted Nick Remark
#openstack-nova - 2020-11-19
14:48:39 f0o but if they claim that the cloudbase-init creates and shoots the password to nova
14:48:45 f0o then injection shouldnt matter
14:48:55 f0o or am I off?
14:48:58 sean-k-mooney its not using injection and that is not what cloudbae does
14:49:13 sean-k-mooney cloudbase-init just reimplmente cloud-init for windows
14:49:19 sean-k-mooney it does not interact with nova at all
14:49:29 sean-k-mooney it just consumes the metadta generated by nova
14:49:42 dansmith gibi: looking through our install docs,
14:49:42 sean-k-mooney its a one way comunication
14:49:50 f0o >> Cloudbase-Init generate a random password and post it encrypted on the Nova metadata service. << that part is what makes me think it actually attempts to do something tho
14:50:14 sean-k-mooney we dont allow external things to add metadata that way
14:50:17 dansmith gibi: we already do provide quite a bit of sample config per compute and per "controller", and it's all seemingly duplicated in each doc, and for each distro flavor :/
14:50:20 sean-k-mooney its not part of the api
14:50:28 f0o well that's a great lie from the vendor then lol
14:50:42 sean-k-mooney the only way to do that woudl be to set a property on server
14:51:05 sean-k-mooney but cloudbase-init is only installed in the vm image
14:51:16 sean-k-mooney it does not know about the openstack its one and has no credentials
14:51:22 sean-k-mooney so it cant set a property
14:51:49 f0o yeah that's exactly my thoughts as well
14:51:50 lpetrut sorry for stepping in, but you can in fact post changes to the metadata server
14:52:06 f0o hence why I got so massively confused when they write "oh dont worry, we post the password to nova"
14:53:26 lpetrut https://docs.openstack.org/api-ref/compute/?expanded=replace-metadata-items-detail#replace-metadata-items
14:54:16 f0o thanks for the clarifications tho :)
14:54:23 openstackgerrit Stephen Finucane proposed openstack/nova stable/victoria: Add missing exception https://review.opendev.org/763389
14:54:25 f0o I thought I was being blind or insane
14:54:42 openstackgerrit Stephen Finucane proposed openstack/nova stable/ussuri: Add missing exception https://review.opendev.org/763390
14:55:29 lpetrut cloudbase-init will just encrypt the generated password and post it to http://169.254.169.254/openstack, so you can then retrieve it and decrypt it. IIRC the nova client even accepts a key that decrypts that password.
14:56:36 sean-k-mooney lpetrut: you can i was not aware of that. i tought this was readonly
14:57:47 sean-k-mooney unless you used the property api. i guess not but i dont think we have any cli commnds for this
14:59:28 openstackgerrit Elod Illes proposed openstack/nova stable/train: Test for disabling greendns https://review.opendev.org/761763
14:59:28 lpetrut well, the idea is that the netron metadata agent is also forwarding POST/PUT requests
14:59:48 lpetrut not just GET requests to http://169.254.169.254/openstack
14:59:50 bauzas dansmith: around for a RPC question ?
14:59:58 dansmith bauzas: yeah
15:00:37 bauzas dansmith: ack, just wondering why https://review.opendev.org/#/c/761452/ is getting the 6.0 version as the minor version
15:00:53 bauzas " Nov 13 10:14:02.664855 ubuntu-focal-rax-iad-0021755641 devstack@n-api.service[72892]: ERROR nova.api.openstack.wsgi [None req-dbe8b15b-bd32-46ab-93b4-b0097a6a86a3 None None] Unexpected exception in API method: oslo_messaging.rpc.client.RPCVersionCapError: Requested message version, 5.0 is incompatible. It needs to be equal in major version and less than or equal in minor version as the specified version cap 6.0."
15:01:22 lpetrut sean-k-mooney: so basically each guest can update its own metadata by just sending it to http://169.254.169.254/openstack
15:01:51 sean-k-mooney lpetrut: that might be a bug. i think that was only ment to be updated via the nova api
15:01:57 bauzas dansmith: but I provided an additional endpoint for the v5.0 proxy
15:03:10 dansmith bauzas: well, you haven't implemented 6.0 in the client, but all the servers are reporting that they support 6.0 (via the service version) and everything is new, so it's choosing to use 6.0 but the client doesn't support it, right?
15:04:11 lpetrut sean-k-mooney: fwiw here's where cloudbase-init is sending the password: https://github.com/cloudbase/cloudbase-init/blob/master/cloudbaseinit/metadata/services/httpservice.py#L55-L80
15:04:31 dansmith bauzas: remember, the client has to be able to speak both versions as well, depending on the version pin, but it's choosing to speak the new one based on the service version, and you only speak 5.x on the client side right now
15:04:41 bauzas dansmith: sure, but if the client is only supporting 5.0, the server should still accept it given the additional endpoint, nope ?
15:04:56 lpetrut sean-k-mooney: I wouldn't say it's a bug, it allows the guest to communicate back various metadata items. I'm not sure if it's filtered in any way.
15:04:57 dansmith bauzas: yes, but the auto pin will try to configure the client with 6.0
15:04:59 sean-k-mooney lpetrut: i see well that is undocumented behavior that they are relying on i think
15:05:10 dansmith bauzas: because everything is new
15:05:30 bauzas dansmith: why this worked then with https://review.opendev.org/#/c/541005/6 ?
15:06:02 sean-k-mooney lpetrut: unless im mistaken and you can point me to docs or a spec to the controy i dont think that was ever intended to work
15:06:21 dansmith bauzas: were we auto calculating the pin then? we'd have to look at devstack config from back then to know
15:06:29 lpetrut sean-k-mooney: I'm sure I can find some docs on this, checking
15:07:01 bauzas dansmith: maybe, I dunno
15:09:43 sean-k-mooney lpetrut: this is the metadata docs https://docs.openstack.org/nova/latest/user/metadata.html
15:10:05 dansmith bauzas: Nov 13 10:14:02.660873 ubuntu-focal-rax-iad-0021755641 devstack@n-api.service[72892]: INFO nova.compute.rpcapi [None req-dbe8b15b-bd32-46ab-93b4-b0097a6a86a3 None None] Automatically selected compute RPC version 6.0 from minimum service version 54
15:10:18 dansmith bauzas: that's trying to configure rpcapi.py with version 6.0, but it doesn't support that
15:11:29 bauzas dansmith: yup, I understood it
15:11:46 bauzas dansmith: OK, I can try to support 6.0 for the rpcapi
15:12:03 sean-k-mooney lpetrut: that behavior is not descitbe in either the metadata docs or api docs
15:12:10 dansmith bauzas: well, you have to :)
15:12:25 sean-k-mooney lpetrut: when you do that is the metadata stored back to the db
15:12:35 sean-k-mooney they way it would be if you called the nova api
15:12:38 lpetrut sean-k-mooney: fwiw, here's an explicit handler for "POST": https://github.com/openstack/nova/blob/master/nova/api/metadata/password.py#L62
15:12:54 sean-k-mooney lpetrut: right that is for the nova api
15:13:06 sean-k-mooney it supproted if you call the nova api with an authenicated token
15:13:21 sean-k-mooney but doing it form the guest vai the 169 adress is not as far as i know
15:14:22 lpetrut nope, that specific request doesn't require a token
15:14:41 lpetrut https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L214-L225
15:14:49 sean-k-mooney so this is something ill have to bring up with the security team
15:15:07 sean-k-mooney we have discussed it publicly at this point but its potentially an issue
15:15:10 lpetrut from what I can tell, the guest can only update specific fields, the password being one of them
15:16:38 lpetrut I've just checked, so actually the "password" field is the only one that can be updated
15:16:38 f0o sean-k-mooney: actually it seems that /password accepts POST on the metadata service... The issue was that the sshkey used was ECDSA and cloudbase-init went bananas. I get the password posted correctly if I load it up with an RSA key
15:17:16 sean-k-mooney f0o: ecdsa need a newer version of pycyrptography to work
15:17:21 lpetrut tbh I'm a bit surprised that the nova metadata docs don't mention this, this feature has been there since forever (<2014 I think)
15:17:48 sean-k-mooney as i said im not sure it has been
15:17:55 sean-k-mooney i think this was unitnetional
15:18:01 sean-k-mooney there is no spec for it
15:18:05 lpetrut here it is: https://github.com/openstack/nova/commit/a2101c4e7017715af0a29675b89e14ee2884bd89
15:18:08 sean-k-mooney i checked
15:18:15 lpetrut 2012, pre nova specs era :)
15:19:03 sean-k-mooney this is only nova v1 api behavior
15:19:30 sean-k-mooney actully no its liberty which is not pre sepecs
15:20:01 lpetrut I guess it seemed simple enough not to mandate a spec, but it's definitely intentional
15:20:23 lpetrut and it's not just nova v1
15:20:42 sean-k-mooney lpetrut: we require specs for all api cahnge regradless of how trivial it is
15:21:20 sean-k-mooney lpetrut: yes the nova v1 comment was because you said it was pre specs
15:21:32 sean-k-mooney we have specs for similar feature in libvirt https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-set-admin-password.html
15:21:37 openstackgerrit Stephen Finucane proposed openstack/nova stable/train: Add missing exception https://review.opendev.org/763393
15:21:40 lpetrut oh, got it
15:22:54 lpetrut I think that libvirt driver feature is slightly different than https://github.com/openstack/nova/commit/a2101c4e7017715af0a29675b89e14ee2884bd89
15:23:29 sean-k-mooney we are missing an api microverion bump for this too
15:23:52 lpetrut bump the microversion for what?
15:23:59 sean-k-mooney the metadata api
15:24:08 lpetrut https://github.com/openstack/nova/commit/a2101c4e7017715af0a29675b89e14ee2884bd89 this is there since 2012 :)
15:24:30 lpetrut it's not something that was added now
15:24:41 sean-k-mooney yep and it was not documented and did not follow our spec proceducer and did not do an api microverion bump to the metadata api
15:25:08 sean-k-mooney lpetrut: sure imjust not sure it shoudl continue to be supported unless we at least fix the docs
15:25:40 lpetrut well, just because it wasn't properly documented doesn't mean that it should become unsupported, there are projects relying on it
15:25:41 sean-k-mooney if its just this field it might be ok. if other fiels can be arbitrally updated then it could be a an issue
15:26:03 lpetrut sean-k-mooney: indeed. well, it's ok, it's just this field

Earlier   Later