| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-07 | |||
| 21:17:37 | sean-k-mooney | im not sure | |
| 21:17:43 | sean-k-mooney | bu tjsut skiming ther eapi ref | |
| 21:17:56 | sean-k-mooney | i think if we anted to chagne teh bhvior we would need 3 calls minium | |
| 21:18:04 | sean-k-mooney | 1 to create a metadata only secrete | |
| 21:18:09 | sean-k-mooney | then to apply the acl to it | |
| 21:18:15 | sean-k-mooney | and finaly to upload the data | |
| 21:18:47 | sean-k-mooney | i would assume we are not doing that today | |
| 21:19:12 | melwitt | yeah that's exactly what I thought we would have to do and no we are not doing that today | |
| 21:19:18 | sean-k-mooney | so when we are creatign the "user" secreat its likely project scoped | |
| 21:19:34 | melwitt | secrets in nova have always been create with the default acl, so have always been open to project | |
| 21:20:16 | melwitt | I don't know why I thought they were private to a user :( | |
| 21:21:54 | sean-k-mooney | so its the secret:decrypt | |
| 21:22:00 | sean-k-mooney | polyc that we care about rahter then get | |
| 21:22:07 | melwitt | correct | |
| 21:22:07 | sean-k-mooney | get is just the metadata | |
| 21:22:19 | melwitt | yes | |
| 21:23:26 | melwitt | man the test_resize_reschedule_uses_host_lists_3_fails unit test is going crazy in CI | |
| 21:23:48 | sean-k-mooney | https://opendev.org/openstack/barbican/blame/commit/661386a517fac2f81d6b35706dd360b045955c3f/barbican/common/policies/secrets.py#L21 | |
| 21:24:03 | sean-k-mooney | so that acl rules has been there for at least 10 years | |
| 21:24:47 | sean-k-mooney | so in effect they have never been user scoped unless you change the acl | |
| 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 | |