| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-17 | |||
| 17:13:49 | sean-k-mooney | levy14: vms dont have identity's | |
| 17:14:12 | sean-k-mooney | a vm is a resouce that is owned by a project not a user | |
| 17:15:01 | levy14 | ok, is there a good reason why it cannot get an identity? for this specific purpose. to allow the vm to impersonate a user and access secrets? | |
| 17:15:39 | sean-k-mooney | you mean grab the token form the request that was used to boot the vm and then use that to call barbican | |
| 17:15:52 | levy14 | that would be an option, yes | |
| 17:16:09 | sean-k-mooney | well that would be a giant red flag form an auti perspetivce | |
| 17:16:19 | levy14 | although e.g. what aws does is generate short lived temp tokens on request for this purpose | |
| 17:17:13 | levy14 | ut in the end, any solution that allows users to grab secrets from bbarbican with a well-known identity, and without being a security risk, would be fine | |
| 17:17:31 | levy14 | I just want to end this cancer of credentials in code repos | |
| 17:18:15 | sean-k-mooney | usign jwt is proably trhe way to go | |
| 17:18:50 | sean-k-mooney | there was someone looking at extening keystone to supprot just json web tokens to be able to issue a new keystone token | |
| 17:19:11 | sean-k-mooney | and then useing vendor data or nova metadta to provide the token ot the vm | |
| 17:19:18 | sean-k-mooney | via the metadtat servie | |
| 17:19:18 | levy14 | I am not sure I understand how those would help | |
| 17:19:51 | sean-k-mooney | the vm could get a jwt token form the metadata endpoing without auth based in the vm mac and ip via curl | |
| 17:20:03 | sean-k-mooney | and then use that to issue a full keystone token | |
| 17:20:09 | sean-k-mooney | and make requesuts | |
| 17:21:12 | levy14 | and how would the metadata endpoint know what identity to issue a jwt token for? | |
| 17:21:45 | levy14 | I mean where is the ip/mac <-> identity info coming from? | |
| 17:22:27 | levy14 | so that vm creators/users can control it (so that that user gets access to the ecrets the code in the vm will try to fetch) | |
| 17:22:42 | sean-k-mooney | levy14: that comes for nova/neutron | |
| 17:23:12 | levy14 | so in the end nova/neutron does have an identity for each vm? | |
| 17:23:19 | sean-k-mooney | no | |
| 17:23:26 | sean-k-mooney | it used an external service | |
| 17:23:47 | sean-k-mooney | nova suport external dynimc vender data | |
| 17:24:13 | sean-k-mooney | service like nova-join can use that to add extra info into the metadata aviable to the vm | |
| 17:25:04 | levy14 | interesting | |
| 17:25:13 | sean-k-mooney | https://review.opendev.org/q/topic:bp%252Fjson-web-tokens | |
| 17:25:19 | sean-k-mooney | i think that is the keystone feature | |
| 17:25:25 | sean-k-mooney | let me see if i can find any more info | |
| 17:25:26 | levy14 | I am very curious in any solution that gets me closer to this | |
| 17:25:31 | sean-k-mooney | its been a while since this came up | |
| 17:25:36 | sean-k-mooney | like 2 years or more | |
| 17:26:50 | sean-k-mooney | levy14: https://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/json-web-tokens.html | |
| 17:27:43 | levy14 | thanks for the links, will do some reading | |
| 17:27:54 | levy14 | and add this to the next meeting's agenda | |
| 17:29:33 | sean-k-mooney | levy14: this likely woudl have to be implemted outsdie fo nova. if it was in nova we would need a very detailed spec of how to do this safely | |
| 17:29:41 | sean-k-mooney | just to set expecations | |
| 17:30:19 | levy14 | I understand | |
| 17:31:13 | levy14 | we're a federation of openstack sites, so solutions that require each site to config this would be problematic. I was hoping for a nova-native solution. even if it's going to take a while. | |
| 17:31:59 | sean-k-mooney | levy14: jrosser was asking about this before | |
| 17:32:21 | sean-k-mooney | levy14: just checked my irc logs let me get you a link | |
| 17:32:39 | sean-k-mooney | they did a poc of injecting the token https://paste.opendev.org/show/798996/ | |
| 17:33:25 | sean-k-mooney | https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2020-10-13.log.html#t2020-10-13T15:30:05 | |
| 17:33:36 | sean-k-mooney | levy14: it was based on https://cloud.google.com/compute/docs/instances/verifying-instance-identity | |
| 17:33:46 | jrosser | sean-k-mooney: I totally ran out of time to take that further | |
| 17:34:18 | jrosser | but still interesting if it can be made to work with an external thing like step-ca (that was my use case) | |
| 17:34:34 | sean-k-mooney | jrosser: maybe you can expalin it to levy14 and they could find resouce to work on it | |
| 17:35:45 | sean-k-mooney | jrosser: i have not been following keystoen recently but i belive tehy are also working on some oath/openid connect supprot this cycle | |
| 17:35:52 | sean-k-mooney | not sure if that is related | |
| 17:36:09 | sean-k-mooney | this https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | |
| 17:37:01 | levy14 | in any case, adding it to the agenda and we'll see next time | |
| 17:37:11 | levy14 | thanks for the links | |
| 17:42:11 | jrosser | levy14: I have POC code to insert a signed jwt into the metadata | |
| 17:44:17 | jrosser | https://github.com/bbc/nova/commit/c0e9a98fb96d0dff73d0a5c5e7ebad8078fd85a1 | |
| 17:45:03 | sean-k-mooney | jrosser: didnt knwo you worked for/with the bbc | |
| 17:45:10 | sean-k-mooney | or that they used openstack | |
| 17:45:18 | sean-k-mooney | thats cool | |
| 17:45:30 | jrosser | we use it in the R&D labs | |
| 17:45:59 | sean-k-mooney | even still that is nice to hear | |
| 17:46:08 | sean-k-mooney | even if its only for R&D | |
| 17:46:12 | sean-k-mooney | and not production | |
| 17:47:30 | sean-k-mooney | jrosser: your poc is that integrated with keystone in any way. can the jwt token be sued to auth with keystone | |
| 17:47:37 | sean-k-mooney | to then bootstrap to calling barbican | |
| 17:47:55 | sean-k-mooney | or did you just use it for the vm verifcation usecase | |
| 17:48:18 | jrosser | the idea (pretty much copied from what GCP do) is that you could validate that jwt against a published CA cert at some well known location | |
| 17:48:33 | sean-k-mooney | ya ok | |
| 17:48:34 | jrosser | and that is sufficient to say that the VM is what it claims to be | |
| 17:49:03 | sean-k-mooney | so keystone i think now support using jwt to auth and get a keystone token | |
| 17:49:24 | sean-k-mooney | so your poc is not tied into that | |
| 17:49:48 | jrosser | right - though i guess the JWT payload can be pretty arbitrary so i'm not sure how much that would intersect | |
| 17:53:58 | jrosser | hmmm hashicorp vault can authenticate with a JWT | |
| 17:54:09 | jrosser | now that would be really interesting to make work | |
| 17:55:47 | sean-k-mooney | jrosser: levy14's usecases is to use something to allow the vm to auth to barbican | |
| 17:56:13 | sean-k-mooney | jrosser: basically so that you dont need to sotre creds in teh applicaitons configs | |
| 17:56:35 | jrosser | right - i believe that such things are very straightforward in aws | |
| 17:56:44 | sean-k-mooney | jrosser: and since keystone now accpets jwt tokes to auth with my theory was | |
| 17:57:05 | sean-k-mooney | if we added a jwt token in the metadta you coudl use that to get a keystone token and then use that to call barbican | |
| 17:57:55 | sean-k-mooney | and sicne jwt tokesn can expire you could allow that only for x mintues after teh server is booted for intial bootstrap | |
| 17:58:59 | sean-k-mooney | anyway its not my usecase so i wont worry about it for now | |
| 17:59:12 | sean-k-mooney | but it could be a ncie feature if openstack could provide a simialr workflow | |
| 17:59:29 | sean-k-mooney | its proably not a nova feature however | |
| 17:59:31 | sean-k-mooney | ot not mainly | |
| 17:59:39 | sean-k-mooney | a nova feature | |
| 18:09:45 | jrosser | seems it is fernet or jws for keystone, not a mixture | |
| 18:10:02 | jrosser | and it does seem more clean to have keystone issue a token then then is in the metadata | |
| 18:10:37 | sean-k-mooney | well for there usecase tehy are tryign to prevent having to put credeitals in the vm to begin with | |
| 18:10:45 | sean-k-mooney | so they need somthign to bootstrap form | |
| 18:11:06 | sean-k-mooney | i think k8s solves this by definign env vars that are only accepable in the container | |
| 18:11:12 | sean-k-mooney | so you can get your pods secret | |
| 18:11:28 | sean-k-mooney | the metadta serivce is the closest thing we have to that | |
| 18:13:21 | jrosser | oh i am confusing the existing jws stuff in keystone with that new jwt auth patch | |
| #openstack-nova - 2022-05-18 | |||
| 00:01:44 | opendevreview | Merged openstack/nova stable/yoga: Adds regression test for bug LP#1944619 https://review.opendev.org/c/openstack/nova/+/838788 | |
| 00:01:52 | opendevreview | Merged openstack/nova stable/yoga: Fix pre_live_migration rollback https://review.opendev.org/c/openstack/nova/+/836014 | |
| 01:10:17 | opendevreview | Merged openstack/nova stable/ussuri: [stable-only] Drop lower-constraints job https://review.opendev.org/c/openstack/nova/+/838033 | |
| 03:18:03 | opendevreview | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Update Servers APIs https://review.opendev.org/c/openstack/nova/+/764292 | |
| 03:18:03 | opendevreview | Brin Zhang proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs https://review.opendev.org/c/openstack/nova/+/765311 | |
| 03:18:04 | opendevreview | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Rebuild Server API https://review.opendev.org/c/openstack/nova/+/766380 | |
| 03:18:04 | opendevreview | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List SG API https://review.opendev.org/c/openstack/nova/+/766726 | |
| 03:18:05 | opendevreview | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Flavor Access APIs https://review.opendev.org/c/openstack/nova/+/767704 | |