| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-07 | |||
| 21:24:58 | melwitt | I don't think so right because of this https://opendev.org/openstack/barbican/src/commit/661386a517fac2f81d6b35706dd360b045955c3f/barbican/common/policies/base.py#L50-L52 | |
| 21:25:14 | melwitt | oh wait that's not decrypt | |
| 21:25:49 | sean-k-mooney | righ if you look at https://opendev.org/openstack/barbican/blame/commit/661386a517fac2f81d6b35706dd360b045955c3f/barbican/common/policies/secrets.py#L21 | |
| 21:26:03 | melwitt | https://opendev.org/openstack/barbican/src/commit/661386a517fac2f81d6b35706dd360b045955c3f/barbican/common/policies/base.py#L53-L55 | |
| 21:26:03 | sean-k-mooney | that has the 'rule:secret_acl_read' rule alaready | |
| 21:26:30 | melwitt | if I read that right it was allow project admin, project observer, project creator | |
| 21:26:44 | melwitt | so it's true it was not project member | |
| 21:26:55 | sean-k-mooney | right os creator was the old role they mapped to member | |
| 21:27:00 | sean-k-mooney | and observer i guess was reader | |
| 21:27:24 | sean-k-mooney | so before srbac to us babican at all admin had to assing you the creator role | |
| 21:30:21 | sean-k-mooney | melwitt: i think this is perhaps the relvent spec https://github.com/openstack/barbican-specs/blob/master/specs/kilo/add-creator-only-option.rst | |
| 21:30:50 | sean-k-mooney | well and https://github.com/openstack/barbican-specs/blob/master/specs/kilo/add-per-secret-policy.rst | |
| 21:31:34 | melwitt | ok yeah that is showing that private secrets was a new feature at the time. wasn't even possible originally | |
| 21:32:05 | sean-k-mooney | rigth so the second spec is the one that intouced tha acl api | |
| 21:32:33 | sean-k-mooney | and the first was specificly usignit for providign diffent options for the creator role | |
| 21:32:53 | melwitt | interesting. good to know | |
| 21:34:06 | sean-k-mooney | i hate to say this but.... this would allwo a 4 mode of operations | |
| 21:35:03 | sean-k-mooney | we could have a "delegated" for lack fo a beter term mode where the secret is owned by the end user isntead of the nova user but we just add an acl for ti when creating it for the nova user to be able to read it when needed | |
| 21:35:17 | sean-k-mooney | and do that only for the tpm secrets that we are cretaing on there behalf | |
| 21:35:58 | sean-k-mooney | that almost what the deployment mode is with the only delta being the secret remaisn owned by the project that owns the vm | |
| 21:36:11 | melwitt | yeah .. that would work I think | |
| 21:36:30 | sean-k-mooney | you coudl also upgrae to that by backfilling the ACL | |
| 21:36:56 | melwitt | honestly that seems easier because then the service project thing doesn't come up | |
| 21:37:33 | sean-k-mooney | although well it kind of does but only in the sense that what ever auth cred we are usign to talk to it need to be one form our config | |
| 21:37:51 | sean-k-mooney | but just lookign at master for a second | |
| 21:37:53 | sean-k-mooney | https://opendev.org/openstack/barbican/src/branch/master/barbican/common/policies/secrets.py#L19-L26 | |
| 21:38:08 | sean-k-mooney | rule:secret_project_admin | |
| 21:38:17 | melwitt | yeah but I mean if we do it by giving the nova user access via acl, then it's never open to the service project right | |
| 21:38:37 | sean-k-mooney | i asumem that is someone wiht the admin role that has a project scoped token for that project right | |
| 21:38:58 | melwitt | I think that's what that means, yes | |
| 21:39:06 | sean-k-mooney | oh well there may or may not be a shared service project | |
| 21:39:20 | sean-k-mooney | we do that in devstack but in our down stream we dont i belive | |
| 21:39:28 | melwitt | true, but the "common" deployment is done that way | |
| 21:39:43 | sean-k-mooney | it woudl allow use to restict ti to just the nova user however | |
| 21:39:52 | sean-k-mooney | if ther was a shared service proejct so that still better | |
| 21:41:04 | sean-k-mooney | well not nessicarly "beter" then owned by nova in genreal jsut better then "accsabel by anyone in the service project" | |
| 21:41:38 | melwitt | right | |
| 21:41:57 | melwitt | it's the open-to-the-service-project that seems a bit too out there | |
| 21:42:34 | sean-k-mooney | right. so looking at barbican base policy they do impmente proejct scoped admin to some degree | |
| 21:42:49 | sean-k-mooney | but that really global admin | |
| 21:43:14 | sean-k-mooney | so today if an admin added themselve to a end users project the shoudl be bale to live mgigrate | |
| 21:43:32 | sean-k-mooney | provide we just dont block it in the api and try to download the secret when needed | |
| 21:43:46 | sean-k-mooney | i.e with teh defualt "user" policy | |
| 21:44:04 | sean-k-mooney | what "deployment" or "delegated" what ever we want to call the acl approch gives | |
| 21:44:13 | melwitt | yeah exactly. it is possible for project admin today | |
| 21:44:17 | sean-k-mooney | is the ablity to skip adding yourself to the end users policy | |
| 21:44:47 | sean-k-mooney | *end users project | |
| 21:44:53 | sean-k-mooney | jsut to do the live migration | |
| 21:45:25 | sean-k-mooney | so its a net win still be but the security posture is mostly the same as user or host | |
| 21:45:53 | melwitt | yeah. it feels like it makes more sense too in a way. like more intuitive | |
| 21:46:30 | sean-k-mooney | i think this also means that an admin coudl also jsut live migrate any vm with the user policy if they just add the acl to the relevent secret right? | |
| 21:46:35 | sean-k-mooney | for there user? | |
| 21:46:40 | melwitt | I really don't want to have to migrate 'deployment' secrets though, ugh. | |
| 21:47:01 | sean-k-mooney | well you dont have to move them | |
| 21:47:20 | sean-k-mooney | that the nice thign about deployment you jsut get them form barbican in pre live migrate | |
| 21:47:27 | sean-k-mooney | there is no copyign right. | |
| 21:47:28 | melwitt | yes you can with acl also. a bit more code is needed to enable 'user' live migration and I have them proposed | |
| 21:47:59 | sean-k-mooney | by migrate deployment secret did you mean add the acl? | |
| 21:48:08 | sean-k-mooney | or did you mean move them during live migrate? | |
| 21:48:21 | sean-k-mooney | or i guess copy them to a new secret | |
| 21:48:31 | sean-k-mooney | but that woudl be on resize right | |
| 21:48:45 | melwitt | yeah but I mean if we wanted to do the user + acl for nova user thing, taking the nova user secret and creating a user secret and copying the passphrase over and adding the acl, I dunno. mess | |
| 21:49:13 | sean-k-mooney | oh your sayign supprotign the 4th policy | |
| 21:49:19 | sean-k-mooney | fo ading the nova user by acl | |
| 21:49:20 | melwitt | for potentially already existing 'deployment' | |
| 21:49:29 | melwitt | secrets | |
| 21:49:39 | sean-k-mooney | ah well we dont have that yet do we? | |
| 21:49:46 | sean-k-mooney | i tought that was not merged | |
| 21:49:55 | melwitt | we do have the secret generation but not the live migration | |
| 21:50:01 | sean-k-mooney | ah ok | |
| 21:50:14 | sean-k-mooney | well if we atned to suprpot it its feeld like a 4th policy | |
| 21:50:42 | sean-k-mooney | but i htink as you suggested talking to the barbican folks at the ptg would be a good next step | |
| 21:50:48 | melwitt | yeah.. that would be easier to not have to deal with it. and then let it stay open to the service project? I dunno. just rambling | |
| 21:50:53 | sean-k-mooney | to confirm that the acls are actully workign as we think they do | |
| 21:51:25 | sean-k-mooney | melwitt: well if its a new policy we can recommend that you resize to delegated for better security or something | |
| 21:51:54 | sean-k-mooney | where deploymene i "nova owned secte" adn delegated is "user owned secreate with nova acl" | |
| 21:52:08 | melwitt | yeah. that would be much less pain | |
| 21:52:19 | melwitt | ++ | |
| 21:52:23 | sean-k-mooney | in anycase i think we shoudl finsih the deploymetn live migration supprot first | |
| 21:52:35 | melwitt | yeah, I agree | |
| 21:52:39 | sean-k-mooney | then maybe tack this on if folks agree | |
| 21:52:58 | melwitt | the way I have it is I put 'user' ahead of 'deployment' since 'user' support is a subset of 'deployment' | |
| 21:53:38 | sean-k-mooney | ya host was the most invasive one | |
| 21:53:43 | melwitt | much smaller change than 'deployment' bc 'deployment' ultimately needs to be able to do secret conversions for resizes | |
| 21:53:47 | sean-k-mooney | as all the resed didnt need rpc/obejct changes | |
| 21:54:18 | sean-k-mooney | right ya i see | |
| 21:54:46 | sean-k-mooney | its not alot diffent for the acl approch as you woudl still need to add/remove it when you change form user | |
| 21:54:52 | sean-k-mooney | but that a singel api call | |
| 21:55:04 | sean-k-mooney | no need to copy the data and reupload it | |
| 21:55:05 | melwitt | yeah, I don't think it would be much to add | |
| 21:55:57 | sean-k-mooney | all fo this falls apart if acls dont work that way but that seams to be what those spec imply | |
| 21:57:06 | sean-k-mooney | kilo era features with "This ACL documentation is work in progress and may change in near future." | |
| 21:57:38 | sean-k-mooney | make me causiously optimistic | |
| 21:57:47 | melwitt | they seem to work how we think, at least in my unexpert testing in devstack. I also used the acl in the 'user' live migration tempest tests I wrote and that works too | |
| 22:00:21 | sean-k-mooney | ok im going to call it a night o/ | |
| 22:00:52 | melwitt | seeya o/ | |
| 22:01:55 | opendevreview | sean mooney proposed openstack/nova master: Add regression test for unified limits resource bug https://review.opendev.org/c/openstack/nova/+/975859 | |
| 22:01:55 | opendevreview | sean mooney proposed openstack/nova master: Fix unified limits to include all resource types https://review.opendev.org/c/openstack/nova/+/975872 | |
| 22:03:14 | sean-k-mooney | i dont know if i resoved all the comments on that but i just pushed what i had ill take a look at it again tomorrow | |
| 22:08:10 | melwitt | ack | |