Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-04-07
17:50:03 gibi that is better
17:50:25 sean-k-mooney but i suspect we wont see much of a delta on the perodic althoug hif we do it would be an interesting datapoint i guess
18:17:33 gibi a quick look in two GMRs ~5 minutes distance I don't see increasing number of Green Threads or Threads reported.
18:25:59 gibi OK. This is the starting state of my measurement setup for the night https://paste.openstack.org/show/b96mgBQpguw6KUseBAgZ/
18:34:26 melwitt awesome gibi
20:10:24 melwitt dansmith: fyi potential cross-project PTG topic re: barbican secrets https://etherpad.opendev.org/p/nova-2026.2-ptg#L90 cc Uggla sorry if I put the text in the wrong location in the etherpad, feel free to move it
20:28:00 dansmith melwitt: ack, not sure that needs to be a cross-project session really, but cool.. I also didn't realize you were worried about the deployment side of the ownership thing, more the user one
20:28:11 dansmith but good point that neutron would have access to those keys
20:28:19 dansmith unless nova could change the ACL itself
20:29:20 melwitt dansmith: my brain started on user and then the realization about service hit. but yeah nova can change the ACL itself as far as I know
20:30:02 melwitt I thought you had suggested we talk to ppl who know more about barbican so I put it cross-project
20:30:20 melwitt it does suck that there's no way to do ACLs through castellan. not sure if that's by design
20:31:12 melwitt I guess maybe not all key managers support ACLs
20:33:31 dansmith ack
20:56:44 sean-k-mooney melwitt: by the way i belive there as a specic commit possibel as part fo there srbac work that change teh secrte to be owned by the proejct
20:57:36 sean-k-mooney melwitt: i dont exactly know why i feel tha tway but i think we talksed about it before
20:58:22 melwitt sean-k-mooney: I wondered if that could be a possibility. I'll take another gander
20:58:30 sean-k-mooney i.e. the fact that is not only accable by the user is someitng that i was vaugly aware of an that it was not alwasy that way
21:00:40 melwitt as far as I could find it goes down to the model and object level, so always been that way
21:01:15 melwitt (this was just me looking in the code)
21:01:30 dansmith yeah I really thought we were told that it was specific to the user and not the project
21:02:12 sean-k-mooney melwitt: maybe https://opendev.org/openstack/barbican/commit/cd9b0ba9f0b4606193858d3cf05acd413a66ba1e
21:02:34 sean-k-mooney they use to enforce _SECRET_CREATOR = "user_id:%(target.secret.creator_id)s"
21:03:09 sean-k-mooney ... storybaord 2010235 has more info
21:03:38 sean-k-mooney huh its actully working https://storyboard.openstack.org/#!/story/2010235
21:03:47 sean-k-mooney i guess the bots doen know about story board
21:05:37 sean-k-mooney ya so in https://opendev.org/openstack/barbican/commit/cd9b0ba9f0b4606193858d3cf05acd413a66ba1e the allowed project member not jsut teh orgial secreat creator to decrpte the secrete adn basiclly mange it
21:06:24 melwitt lol storyboard
21:06:30 sean-k-mooney without the need for acls so that proably shoudl ahve at least had a release note... or a doc update....
21:07:20 sean-k-mooney https://review.opendev.org/c/openstack/barbican/+/853680 apprently that was aslo cherry-picked which is qustionable
21:07:24 melwitt yeah that's a pretty major change
21:07:34 sean-k-mooney although i coudl eb misreading those polices but i dont think i am
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

Earlier   Later