| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-31 | |||
| 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 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-31-16.00.log.html | |
| 17:00:56 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-31-16.00.txt | |
| 17:00:56 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-31-16.00.html | |
| 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 | bauzas | #endmeeting | |
| 17:01:12 | bauzas | sean-k-mooney: gibi: elodilles: fwiw, I'll be off tomorrow | |
| 17:01:13 | elodilles | thanks o/ | |
| 17:01:19 | elodilles | bauzas: ack | |
| 17:01:21 | sean-k-mooney | bauzas: ack | |
| 17:01:38 | sean-k-mooney | bauzas: for rest of week or you back thursday | |
| 17:19:10 | bauzas | sean-k-mooney: no, only tomorrow | |
| 17:19:35 | bauzas | I have a few appointments so I thought it was better to just take one day off | |
| 17:20:24 | sean-k-mooney | bauzas: cool i did have one topic for the meeting but it can wait till next week | |
| 17:20:40 | bauzas | sean-k-mooney: which meeting ? | |
| 17:20:46 | sean-k-mooney | the nova one | |
| 17:20:46 | bauzas | the upstream nova one ? | |
| 17:20:51 | sean-k-mooney | ya | |
| 17:20:57 | sean-k-mooney | we didnt have time anyway | |
| 17:21:02 | bauzas | hah, we just said that we won't have a meeting next week | |
| 17:21:06 | sean-k-mooney | but i had a previous downstream meeting that ran over | |
| 17:21:14 | sean-k-mooney | oh well it can wai | |
| 17:21:17 | sean-k-mooney | *wait | |
| 17:21:19 | bauzas | sean-k-mooney: but if you want, you can run the meeting | |
| 17:21:21 | sean-k-mooney | its not urgent | |
| 17:21:33 | sean-k-mooney | no its fine i just wanted input on a patch | |
| 17:21:39 | bauzas | sean-k-mooney: this is just that gibi, stephenfin and me at least won't be around | |
| 17:22:08 | sean-k-mooney | bauzas: ya no worreis i frogot summit was next week | |
| 17:22:30 | sean-k-mooney | i was going to turn https://review.opendev.org/c/openstack/nova/+/842359 into a real patch with a release note | |
| 17:22:38 | sean-k-mooney | but wanted to get input form other before i do | |
| 17:22:46 | sean-k-mooney | i.e. is this somethign we want to do | |
| 17:22:52 | sean-k-mooney | before i spend time on it | |