| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-31 | |||
| 16:33:55 | bauzas | elodilles: feel free to take the mic | |
| 16:34:00 | elodilles | #info ussuri is unblocked, thanks to gmann's tempest pinning patches | |
| 16:34:17 | bauzas | \o/ | |
| 16:34:21 | gmann | yeah, and stable/victoria is also pinned with old tempest | |
| 16:34:27 | elodilles | #info stable branches are now unblocked, but intermittent failures need further investigations. melwitt's tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:34:32 | elodilles | gmann: thanks! \o/ | |
| 16:34:33 | gmann | took almsot 1 week to get all these merged | |
| 16:34:42 | elodilles | :S | |
| 16:34:57 | elodilles | #info placement's stable/branches are unblocked back till victoria (see melwitt's etherpad ^^^) | |
| 16:35:12 | bauzas | \o/ agai, | |
| 16:35:17 | gmann | cyborg-tempest plugin job which is non voting in nova gate also will be fixed by #link https://review.opendev.org/c/openstack/cyborg-tempest-plugin/+/843329 | |
| 16:36:27 | elodilles | gmann: ack, thanks for that, too! | |
| 16:36:41 | elodilles | (that's all from my side) | |
| 16:36:42 | bauzas | :) | |
| 16:36:51 | bauzas | greatly appreciated, thanks gmann | |
| 16:37:03 | gmann | np! | |
| 16:37:18 | bauzas | and thanks melwitt for the tracking | |
| 16:37:24 | bauzas | moving on | |
| 16:37:29 | bauzas | we have one last item | |
| 16:37:48 | bauzas | #topic Open discussion | |
| 16:38:00 | bauzas | (levy14) Discuss ability to call Barbican from inside VM without supplying credentials | |
| 16:38:03 | bauzas | levy14: around ? | |
| 16:38:06 | levy14 | yep | |
| 16:38:25 | levy14 | was not around last week to put it on the agenda | |
| 16:38:34 | bauzas | levy14: I'll be honest, I'm not sure we have quorum for discussing your point today, but we can try | |
| 16:39:36 | levy14 | but my org would greatly benefit if any code in a vm could call barbican to fetch secrets. now there are secrets in code, in config files, injected but not properly handled. I'd like to get rid of that. | |
| 16:39:59 | levy14 | without having to put the credentials in the code, I mean | |
| 16:40:31 | levy14 | I see this as a big security improvement for users of nova | |
| 16:40:50 | sean-k-mooney | i actuly see it as the opisite form a nova point of view | |
| 16:40:57 | sean-k-mooney | is potentally a large security whole | |
| 16:41:22 | sean-k-mooney | nova today almost excilulive does not handel any tenatn secrets | |
| 16:41:45 | bauzas | yup, that's what we said | |
| 16:41:48 | sean-k-mooney | nova or admins by default cannot retirve secrets form barbican | |
| 16:42:00 | sean-k-mooney | only the user can | |
| 16:42:05 | levy14 | I understand. but that forces users of nova to improvise. and it's not good what users do. the outcome is nasty. | |
| 16:42:32 | sean-k-mooney | yep thats also true | |
| 16:42:46 | levy14 | if there would be a feature to allow this specific use case, that would make life of nova users much better | |
| 16:42:48 | sean-k-mooney | realisticaly the simpelte way to achive this today id via an external vender data service | |
| 16:43:06 | sean-k-mooney | which could inject a bootstrap token via the metadta api | |
| 16:43:25 | sean-k-mooney | simialr to how nova-join works https://opendev.org/x/novajoin#design | |
| 16:43:35 | levy14 | the problem with that is that I cannot realitically get it implemented across the federation of sites we represent | |
| 16:43:38 | sean-k-mooney | https://docs.openstack.org/nova/latest/admin/vendordata.html | |
| 16:44:31 | sean-k-mooney | levy14: what you are trying to achive is somethign simialr to k8s ablity to inject secrets into the pods right | |
| 16:45:16 | sean-k-mooney | kubernets allows secreates to be injected via config maps or other mechanium such that the pod applciation can the interact with the k8s apis | |
| 16:45:40 | sean-k-mooney | levy14: what you want is a way for nova instance to be able to bootstrap talkign to keystone/barbican | |
| 16:45:53 | sean-k-mooney | so that they can programitacly get teh secretes that are stored there | |
| 16:45:57 | levy14 | not necessarily. I would like a transparent mechanism. that watches for outgoing https reguests to barbican and adds a header with the auth to access the secrets. based on some form of vm identity | |
| 16:46:14 | sean-k-mooney | levy14: nova does not controll the guest networking | |
| 16:46:25 | sean-k-mooney | so such a serice woudl be outside our scope | |
| 16:46:48 | levy14 | sean-k-mooney: they can do that today, if they inject a secret. but that needs them to properly tend and handle the secret with care. users don't care, they are sloppy. | |
| 16:47:13 | sean-k-mooney | one posiablity but its a hack | |
| 16:47:28 | sean-k-mooney | woudl be to take teh token we are invoked with and include it in the metadata | |
| 16:47:35 | sean-k-mooney | that token would expire | |
| 16:48:01 | sean-k-mooney | but it woudl be suffient for the app to bootsrap potenally by issueing an application credetial | |
| 16:48:25 | levy14 | sean-k-mooney: it was just a suggestion. or a way to describe what I expect to happen, don't know which project implements it. I thought I bring it up in nova, as it seems some sort of vm identity is needed for it to work | |
| 16:48:46 | sean-k-mooney | if you want the http request to be intercepted transparently you would need service function chaning or similar to implement that | |
| 16:49:08 | sean-k-mooney | levy14: that the thing vms dont have an identiy | |
| 16:49:14 | sean-k-mooney | they are owned by porjects | |
| 16:49:24 | sean-k-mooney | secrets are owned by users | |
| 16:49:28 | levy14 | sean-k-mooney: maybe they should start having one | |
| 16:49:46 | sean-k-mooney | perhaps | |
| 16:49:56 | levy14 | or secrets in barbican can be set up so that an entire project has access to them? | |
| 16:50:14 | sean-k-mooney | im not sure but that would still not allow nova to access them | |
| 16:50:33 | sean-k-mooney | services and cloud admins cannot acces barbican secrets | |
| 16:50:44 | levy14 | so the possibilities are: | |
| 16:50:48 | sean-k-mooney | that is doen intentiolly for improved security | |
| 16:51:01 | levy14 | 1. metadata service | |
| 16:51:19 | levy14 | 2. interception of network calls outgoing from a vm | |
| 16:52:30 | sean-k-mooney | those are two possiblities yes | |
| 16:52:42 | levy14 | any other? | |
| 16:52:49 | sean-k-mooney | for 1 you would have to define what the metadata service will provide the vm | |
| 16:53:03 | levy14 | and anyone sees this as a valuable feature for nova? | |
| 16:53:05 | sean-k-mooney | 2 is not in scope of nova | |
| 16:53:36 | sean-k-mooney | levy14: if it was done securly maybe. | |
| 16:53:52 | sean-k-mooney | but i also see it as a non trivial feature | |
| 16:54:11 | jrosser_ | i did some more looking at this after it was discussed ~ 1 week ago | |
| 16:54:22 | levy14 | sean-k-mooney: I am sure is non-trivial | |
| 16:54:53 | jrosser_ | and came to the same conclusion that there was no user associated with a VM so it was not possible to generate a usable token, even though it was possible to assert the identity of the vm | |
| 16:55:00 | levy14 | sean-k-mooney: but I see it very valuable to have | |
| 16:55:27 | bauzas | timebox : we only have 5 mins left | |
| 16:55:55 | sean-k-mooney | levy14: do you feel comfortable wrting a spec propsoal even an incomplete one with your usecases | |
| 16:56:09 | sean-k-mooney | levy14: and or would you be able to implement this with our guidance | |
| 16:56:11 | bauzas | yes, we should rather discuss this by a spec | |
| 16:56:31 | levy14 | sean-k-mooney: I can try writing an (incomplete) spec, I am not up to implement it myself | |
| 16:56:41 | sean-k-mooney | jrosser_: i could see us adding a --application-credetial or something to the api | |
| 16:57:00 | sean-k-mooney | jrosser_: i.e. you precreate one and tell nova to pass it to the guest via the metadtaa service | |
| 16:57:03 | jrosser_ | i think that spcifying a service user for a VM might be enough | |
| 16:57:40 | jrosser_ | anyway this is a rabbit hole and i don't want to disrupt your meeting | |
| 16:57:58 | bauzas | jrosser_: no worries, we don't have other discussions | |
| 16:58:47 | bauzas | at least, looks to me we have a consensus : levy14 will provide an incomplet spec or a backlog one | |
| 16:58:54 | bauzas | levy14: do you know about https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html ? | |
| 16:59:09 | jrosser_ | tldr was that other $clouds let you associate a service user (thats already in your project) with that VM, and that combined with a JWT from the metadata to auth against keystone would give you a token for that service user | |
| 16:59:36 | bauzas | anyway, we're at the last minute for our meeting | |
| 16:59:48 | levy14 | I saw the page, seemed convoluted. next week I'm at openinfra, but for the week after that I'll try to create a spec. | |
| 16:59:50 | sean-k-mooney | jrosser_: i think the closest thing to a service user we have in openstack in an application credential | |
| 17:00:46 | bauzas | levy14: ok, then, we're done today | |
| 17:00:54 | bauzas | thanks folks | |
| 17:00:56 | bauzas | #endmeeting | |
| 17:00:56 | opendevmeet | Meeting ended Tue May 31 17:00:56 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:00:56 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-31-16.00.html | |