15:00:22 <dmendiza[m]> #startmeeting barbican
15:00:22 <opendevmeet> Meeting started Mon Nov 10 15:00:22 2025 UTC and is due to finish in 60 minutes.  The chair is dmendiza[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:22 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <opendevmeet> The meeting name has been set to 'barbican'
15:00:26 <dmendiza[m]> #topic Roll Call
15:00:33 <dmendiza[m]> Courtesy ping for dmendiza[m] ade_lee d34dh0r53 Luzi tosky tobias-urdin jjung mharley Freeman Boss lpiwowar xek tkajinam LinuZZ
15:04:19 <dmendiza[m]> rajiv: you around?
15:04:29 <rajiv> hi, yes
15:04:35 <rajiv> i have 2 questions
15:05:03 <rajiv> can i ask now or wait for Q&A ?
15:06:40 <dmendiza[m]> Looks like it's just you and me today
15:06:49 <dmendiza[m]> #topic Open Discussion
15:06:57 <rajiv> i would like to know if anyone has any experience with BSI or vs-nfd audits ? secondly, how to make barbican multi-tenant using p11_crypto plugin
15:07:36 <dmendiza[m]> > BSI or vs-nfd audits
15:07:46 <dmendiza[m]> I don't know what either one of those acronyms mean 😅
15:08:37 <rajiv> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zulassung/VS-Anforderungsprofile/BSI-VS-AP-0027_en.pdf?__blob=publicationFile&v=2
15:09:22 <dmendiza[m]> Interesting ... I'll take a look at that, but afaik, we have not done that before.
15:09:26 <dmendiza[m]> > make barbican multi-tenant using p11_crypto plugin
15:09:54 <dmendiza[m]> What do you mean by "multi-tenant"? --- Historically, "tenant" was the name of Keystone Projects before they were renamed
15:10:16 <dmendiza[m]> so, in that sense, yes, Barbican is multi-tenant because many projects can use Barbican at once while having their data be separated
15:10:41 <rajiv> tenant A uses slot A of HSM A, similarly tenant B uses slot B of HSM B
15:11:09 <dmendiza[m]> I see
15:11:40 <dmendiza[m]> Hmm... I don't think it is currently possible.  Not with two PKCS#11 devices anyway.
15:11:48 <dmendiza[m]> It can be done with two different types of backends
15:13:42 <rajiv> okay, we were testing this multi-tenant concept but looks like we need to manually add a backend everytime we need to add another
15:14:08 <rajiv> https://github.com/sapcc/barbican/blob/stable/2024.2-m3/setup.cfg#L69-L71
15:14:50 <rajiv> looks like setup.cfg doesnt support regex or any other to over come this manual addition and DB uc_secret_store constraints
15:14:55 <dmendiza[m]> e.g. you can configure SimpleCrypto, and then also PKCS#11 and then use the /v1/secret-stores API to set a global default (that everyone uses) and then override that on a per-project basis
15:14:56 <dmendiza[m]> #link https://docs.openstack.org/barbican/latest/api/reference/store_backends.html
15:15:03 <dmendiza[m]> I think the limiting factor for doing this with two PKCS#11 backends is the plugin loading logic
15:16:06 <dmendiza[m]> Yeah, we don't maintain that fork.  The official Barbican repo does not have that.
15:16:08 <dmendiza[m]> #link https://opendev.org/openstack/barbican/src/branch/master/setup.cfg#L65
15:16:57 <rajiv> okay, lastly, i am planning to upgrade from dalmatian to flamingo, i reviewed the release notes, anything else i need to keep in mind ?
15:18:27 <dmendiza[m]> I don't think there were many changes last release.
15:18:35 <dmendiza[m]> As usual, I'd recommend testing the upgrade in a staging environment before you roll it out to production.
15:19:08 <rajiv> okay, thanks
15:19:17 <tobias-urdin> o/ – i have a couple of patches i would like to bring up, when possible :)
15:20:36 <dmendiza[m]> tobias-urdin drop the links and I'll take a look today
15:21:40 <tobias-urdin> added functional testing for openbao (fork of vault) and make the vault functional testing voting again https://review.opendev.org/c/openstack/barbican/+/957206
15:23:04 <tobias-urdin> i would also like to open a discussion about a delete on a secret with consumers being a hard failure directly in the API with a new microversion https://review.opendev.org/c/openstack/barbican/+/961599
15:23:49 <tobias-urdin> it's really painful that it a soft block in barbicanclient and not enforced on the api level
15:27:27 <dmendiza[m]> Historically, the Barbican team's position is that the owner of the secret should be able to delete it at will regardless of who is using it.  I want to say that the argument usually revolves around a break-glass scenario where the owner of the secret needs it to be removed "RIGHT NOW!" ... and forcing them to go through the process of deleting everything that is using it before they can delete it is burdensome.
15:28:03 <dmendiza[m]> I don't remember off the top of my head what the current status is
15:28:45 <dmendiza[m]> Personally, I would not be opposed to the change as long as we keep a --force or ?force=true parameter in the cli and api respecively to immediately delete a secret when required to do so.
15:28:49 <tobias-urdin> the implementation i linked takes that into account and implements the `force` query parameter, so the owner can force it, but it's just not the default behaviour when calling the api
15:29:39 <dmendiza[m]> Got it.  I'll take a look then and leave my comments on the review.
15:29:57 <tobias-urdin> the problem with it being soft in barbicanclient is that secret consumers is ignored by all third-party implementations, so we (as a community) need to implement it everywhere instead of enforcing it
15:30:04 <tobias-urdin> dmendiza[m]: thanks!
15:34:20 <dmendiza[m]> Anything else before we call it a day, y'all?
15:36:46 <dmendiza[m]> Looks like we're done then.  Thanks for joining!
15:36:48 <dmendiza[m]> #endmeeting