| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-07 | |||
| 21:08:00 | dansmith | but these are API policies - doesn't barbican also have a more robust internal ACL system? | |
| 21:08:03 | dansmith | I guess I thought that | |
| 21:08:12 | dansmith | is what we were talking about here and not just API policy | |
| 21:08:27 | melwitt | I guess the old rule had rule:secret_project_admin which allows project admin also | |
| 21:08:34 | sean-k-mooney | hum actully on gerrit i think i might be https://review.opendev.org/c/openstack/barbican/+/853680/9/barbican/common/policies/secrets.py#72 | |
| 21:09:15 | melwitt | secrets are not as secret as I had thought :P | |
| 21:09:26 | sean-k-mooney | im not familar with rule:secret_is_not_private | |
| 21:09:59 | melwitt | that's the project_access thing. project_access=false=private. at least that's how it is today | |
| 21:10:09 | sean-k-mooney | ah | |
| 21:10:33 | sean-k-mooney | so seperatly form the acl you can mark it as prive to a user or public to the project | |
| 21:11:05 | sean-k-mooney | i assume acls were an evoltion of that with more granualatiy or someitng in later release | |
| 21:11:08 | melwitt | no that is the ACL. i.e. if you want to change it, it's a PUT to the /acl API | |
| 21:11:28 | dansmith | so the api policy defines the default but I can still ACL individual secrets however I want? | |
| 21:12:11 | melwitt | as far as I can tell the default is hard-coded, I don't think you can change it | |
| 21:12:16 | melwitt | *don't think you can change the default | |
| 21:12:33 | melwitt | and you can't create a secret to have project_access=false from the get go | |
| 21:12:34 | sean-k-mooney | https://docs.openstack.org/barbican/latest/api/reference/acls.html | |
| 21:12:53 | sean-k-mooney | so apprenlty the acl is on tdefien on indeivual secrets but the contienr the sectes are contied in | |
| 21:13:10 | sean-k-mooney | it feels like this is not fully baked based on teh documantion warning | |
| 21:14:37 | melwitt | yeah... kinda also why I was thinking cross-project at the ptg, to just get a sanity check from barbican experts if they are out there | |
| 21:14:37 | sean-k-mooney | https://docs.openstack.org/api-guide/key-manager/acls.html#default-acl | |
| 21:15:02 | sean-k-mooney | { | |
| 21:15:04 | sean-k-mooney | "read":{ | |
| 21:15:06 | sean-k-mooney | "project-access": true | |
| 21:15:08 | sean-k-mooney | } | |
| 21:15:10 | sean-k-mooney | } | |
| 21:15:19 | sean-k-mooney | so that apprently the default os i guess whne they added acls it change the behvior | |
| 21:15:45 | melwitt | ok so you are saying before ACLs even existed, it was like private secrets? | |
| 21:17:13 | melwitt | vtpm was added in the victoria release which was in 2020 | |
| 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? | |