| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-19 | |||
| 14:45:54 | f0o | The secure and proper way to set passwords in OpenStack Windows instances is by letting Cloudbase-Init generate a random password and post it encrypted on the Nova metadata service. | |
| 14:46:33 | f0o | to me this means that cloud-init in this case is actually not doing it's job because the password is not set. trying to find the issue here since it can be both sides | |
| 14:46:37 | sean-k-mooney | well the proper way to do it is via user-data yes | |
| 14:46:55 | sean-k-mooney | but that is different to what those config options do | |
| 14:47:37 | sean-k-mooney | f0o: https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-set-admin-password.html | |
| 14:48:07 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-set-admin-password.html#other-end-user-impact | |
| 14:48:14 | sean-k-mooney | that is what is missing | |
| 14:48:24 | sean-k-mooney | this is unrelated to cloudbase-init | |
| 14:48:28 | f0o | I'm not 100% sure tho | |
| 14:48:28 | openstackgerrit | Merged openstack/nova master: Add missing exception https://review.opendev.org/762898 | |
| 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 | sean-k-mooney | its a one way comunication | |
| 14:49:42 | dansmith | gibi: looking through our install docs, | |
| 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 | lpetrut | well, the idea is that the netron metadata agent is also forwarding POST/PUT requests | |
| 14:59:28 | openstackgerrit | Elod Illes proposed openstack/nova stable/train: Test for disabling greendns https://review.opendev.org/761763 | |
| 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 | 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:16:38 | lpetrut | I've just checked, so actually the "password" field is the only one that can be updated | |
| 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 | |