 I think it's time, so we can debate the merits of HSMs. So my name is Audie Lee, I'm the PTL for Balvikin, and this is the project update for Stein. So, I'm sorry, did you start? You did? Okay, good. So, all right, so just as a refresher, if anyone who's here doesn't know what Balvikin is, although it seems like most people do, I think, Balvikin is the secret and key manager for OpenStack. And so what that means is that Balvikin users and operators can store things like encryption keys, passwords, TLS certificates, those kinds of things in Balvikin. One of the big use cases for Balvikin with an OpenStack is Cinder volume encryption. So if volumes are encrypted, and Cinder actually asks Balvikin to generate a key, a symmetric key, provide a reference to it and never actually leaves Balvikin. And at that point, well, it does leave Balvikin because then Nova, whenever Nova wants to mount that volume, it goes and it asks for that particular secret, and that's delivered to Nova, and then Nova mounts the volume, so those kinds of things. But it's a number of different places as well too. Like all the other OpenStack services, there's a REST API, and that's designed specifically for creation, storage, and management of the secrets that are there. It was founded in the Havana release of OpenStack. It's about, I guess that makes it about six and a half years old. In the last release, there were about 50 contributors from various companies, about 20 companies. So it's still relatively active. For Stein, there have been a number of new features that have been put out there, most specifically just in terms of a usability thing. For the longest time, our client has made you provide a full reference to the secret. So you do like an OpenStack secret store. You'd get back an HRF with HTTP slash all the stuff and a UUID at the end, and you'd have to pass that back end, which was very different from what all the other OpenStack services were doing. There is a ability now just to provide that UUID, and it'll allow Keystone and so on to figure out where that secret is coming from. In terms of security, in terms of the back end, so behind the front end, you've got an API, a REST API that talks to all the other OpenStack clients. In the back end over there, you've got various plugins that are available, and these talk to different things. So the most simple plugin you have there is something called Simple Crypto, which is basically just a key in a file that is used to encrypt things, but you can also talk to, as we were talking a few minutes ago, to things like HSM and DeVault and so on. And so there have been various improvements there. There have been and will, because this line's not over yet, there will be improvements to the HashiCorp Vault plugin to make it a little more production ready. There has been a number of performance testing and interrupt testing that's happened for various HSMs. Before, it was tested against the SafeNet HSMs, and now we've specifically tested it against TALUS and ATOS pool HSMs, and we've ended up having to parameterize the PKS CS11 plugin to make it easier to integrate with various HSMs. So if you're an HSM vendor and want to try and integrate with Bobbican, it should be a lot easier for you to do so, just providing the appropriate parameters and value for those parameters. Certainly, if you are and you're interested in doing it, come talk to me, please, and we'll see if we can figure out how to get that going. And there will be some testing against the soft HSM with the PKS CS11 by the end of Stine. Rolling upgrades, we hope that's been something that's been going on for the last couple of cycles. We hope to finish it off this cycle. And then there have been various things that have happened on the cross project side of this things. First of all, Castelan. Castelan is actually part of Oslo, and it is basically just an interface to talk to, for applications to be able to store and retrieve secrets. The idea behind Castelan before was that we didn't necessarily want to require people to have Bobbican, so we provided a generic interface whereby people could then go and use, use this interface to get secrets. As it turns out, there's, you know, at this point, the only implementation of Castelan really is Bobbican, but it is a very simple interface, and so a lot of people can use, have tried to use it in different ways. And a lot of the OpenStack services use Castelan now to go and get their secrets, and they go get the, through Castelan, and they go to Bobbican to get their secrets. The importance of it being a base service is that with the, you know, sort of a renewed focus on security and people being much more focused on security in OpenStack, we want applications to be able to say, you can store a secret securely somewhere, and this is a place to where to get it. And that means that applications, you know, as part of an OpenStack development, you should have a place that is a Castelan compatible key store somewhere where you can get secrets. At this point, there are two implementations for Castelan, one is Vault, and the other one is Bobbican. There has been additional work to integrate with triple O, specifically deployment with those HSMs, which I mentioned over there and setting everything up. Those are still in the flight right now. Fortanix, and, yeah, so there was some guys over here, they're using Fortanix. They actually use the PKCS11 plugin, and they're using it to talk to Fortanix. Fortanix actually uses SGX, which is an internal technology to create sort of a secure enclave of memory, basically some encrypted memory. That's hardware-based that you can use to store secrets in. And I just found out this morning that Airship, Deckhand, and so on are actually using Bobbican to store secrets. They have a bunch of files that they use for configuration, and they take those files, and some of them, they specify them as encrypted, and they store a reference to Bobbican there to the Bobbican key there, and they store their keys within Bobbican as well, too. Finally, because of all the performance testing that we're doing against the HSM, we've added a bunch of performance tests within Rally as well, too, so we can test the performance of Bobbican. Just some housekeeping. We did policy encode before, but we were supposed to do policy and doc encodes, documenting the policy as it goes through, so that has been done within Stein. And then, of course, the community goals that everyone is hoping to get through as well, so. So just again, sort of talked about this already, but let's secure the plugins that are in the back end. We have simple crypto. We have PKCS 11 with SafeNet. We have a KMAP interaction, so if you have a KMAP device, you can talk directly there, and you can store your secrets within a KMAP device. There's DogTag, which you can also use to store your secrets, and that can also talk to HSMs as well, too. And then finally, Vault. And then, of course, within Stein, we've implemented and tested changes for the PKCS 11 plugin to talk to all of those different soft ACSM and those different other HSMs as well, too, and, of course, for Tanix as well. And then the roadmap for, in future, we're hoping to do more SGX stuff, more TPM integration kind of go from there. Clients, not much has changed there, other than, as I get mentioned, we do have the UUID instead of just the HREF that was out there. But basically, we have the REST API. We've got a CLI, Python client, and then, of course, Castland itself. Documentation, we have all those things, and we're constantly trying to improve the docs. And these are all the projects right now that are currently using Barbican in some way. Of course, we have integration with Keystone, Oslo, again, through Castland talking that way. And then, of course, Cinder for Cinder volume encryption, Nova also Cinder volume encryption, as well as ephemeral volumes. Glance for image signing, so Hera to store passwords and so on, Magnum also storing passwords and certificates. Neutron, Octavia for storing keys and certificates for load balancing, TLS on load balancing. Swift to do encrypted volumes, encrypted Swift objects. They store the key within Barbican as well, too. Tacker Tattoo is another project that does SSL, sort of SSL as a service and provides the certs and so on. And they've stored everything within Barbican as well. Brabeats, Tempest plugin, and then, of course, within Stein, Deckhand, the Rally stuff, and the Triple O stuff, as I mentioned before. So access policies, pretty much the same as it's been. We found that we've needed to augment the policies a little bit, so we typically have Oslo policy, but then there are some additional things that we've added to Barbican to be able to do. So for example, on a secret, you can say, you can add an ACL to a particular secret that allows someone that's outside of your project, for instance, to be able to access that particular secret. Or you can specify that a secret is private, in which case only you, the creator, and not everyone else within your project can access that secret as well, too. So those are those kinds of things. All of the code, again, for policy is encode, and then it's basically overwrites and so on that you put in your policy, but Jason. In the future, you know, we're just gonna, there will be a read-only role that Keystone's been talking about for a while. We will add that. We actually have a role like that called Auditor, and yeah, if Keystone ever gets their act together, and it will happen there. If Keystone's getting to anybody else. Yeah, well, we'll follow you guys, so. So maturity, we've been at a five out of seven for a while now. We are hoping that the offline upgrade, that kind of stuff will, if we, once we finish it, we'll put us at six out of seven on that, and I don't remember what the seventh one is, but I think it's multiple languages or something like that, we'll probably, we'll never get that, so, most likely. So, just an indication as to how things are going in terms of users, again, there being a much greater emphasis on things like security, and so on. We're seeing much more interest in terms of deployers. We're, apparently, we're deployed in production in about 10% and people are testing or are interested in the Barbican, so we're talking about 40, 45% or so of deployers that from, at least from the user survey seems like they're interested or are actually working with Barbican. That's gone up considerably over the last few years, particularly as this is a service that is optional or has been optional and people have been resistant to creating, deploying yet another service, but as security becomes more important and the auditors come in here and say, what are you doing with your secrets? This becomes much more important for people. And in terms of new deployers, I guess on the survey, there's also something about POCs and new deployments, 9% are in testing right now, 25% are interested. So there's much more of an uptick in interest in Barbican. Finally, we need help. If you're an HSM guy and you wanna integrate your favorite HSM, come talk to us. We'll be happy to help you, TPMs and so on. I know that, for example, the Photonics guys are talking to us about creating an upstream gate so that they can do integrations and so on. Against all of that, I know some of the HSM vendors, for example, are talking about doing Barbican tests themselves as well too on all of their, whenever they put up a release and so on. So if you're an HSM guy, definitely come talk to us. As far as documentation, if you're a doctor person, we always need help with docs. There was a UI, if you're a horizon person, we would love to get a UI going for Barbican. There was a UI for Castaland, which I thought was a terrible idea. And it's still there and I'm hoping to kill that project in the next cycle. Simply because you don't want to access just Castaland, you wanna access a specific implementation of Castaland being Barbican or something like that because there really is no security that way. So there's too much capability of shooting yourself in the foot if you just have a Castaland UI as opposed to a Barbican one. And again, cross-project, any kind of integration efforts, anything, if you are someone from another project that would love to see something from Barbican, just talking to the airship guys, deck-end guys this morning, there were at least a couple of possible things that they wanted from Barbican to make their lives easier. We were totally interested in finding out what you want. And in fact, it sort of dovetailed into a couple of ideas that I had been mulling around and hadn't got enough motivation for yet, but now they might be, so we'll see how that goes. And again, all contributions, welcome. We are, I don't think I have a slide here with everything, but it's, you know, pound open stack Barbican. We're a very friendly group. We'd love to get comments, questions, anything else? So I think, yeah, I still have plenty of time, so. Any questions or anything? Yeah, sure, yeah. So the question, I want to. Yeah, yeah, yeah. So we have some, so I'll repeat the question for the recording. So the question was, do we have any performance results that we can share in the comparisons of say, simple crypto and using an HSM for things like key retrieval and so on and so forth? What we found, what we did is we did performance tests where there was no encryption, and then we did a test where you had Barbican with simple crypto and then a test with Barbican with an HSM. And what we found was there's a significant difference between using no encryption and using encryption. Which, yeah, it is what it is, right? But there really actually wasn't that much of a difference between using an HSM and not an HSM. And I don't have the specific numbers in terms of a percentage or someone, but if I looked at the difference on a graph, if this was no encryption, this would be with encryption and then just slightly more than that was going to the HSM. So there's, the HSM, of course, is, you know, it's optimized to do crypto and so on. So it's, there was, the differences that we did see that were significant who had to do with actually how Cinder, with more work of that, extra work that Cinder was doing than work that we were actually doing within the Barbican side of things. The Barbican side I think was actually relatively quick, but for example, we tested this like against a SEPH backend and when you do a SEPH backend and you bring in the key when you're retrieving, you know, mounting the volume and so on, there's actually, they do a significant amount of work when they actually create that initial volume in terms of adding things to the Lux headers and various headers and so on and so forth that adds a bunch of overhead there. And so the overhead was actually more there than it was really in the Barbican itself. So I can't, I don't have exact numbers with me, but it wasn't as significant as I thought it would be. Okay. Yeah. Okay. Yep. It's safe that it's all right in Jamaica. Yep. Yep. He also says it's going out of warranty real soon so he'll buy it and buy something else. We've been trying to be talking with his cool these days and he's really happy to learn. I, yeah, I don't know. I'm not so concerned that he's talking about it. Yeah, HSM vendors, if you happen to be around. It has to be cool, but yeah, I mean, we're still, obviously it's, yeah, I mean. So just to repeat for the recording, the question was which HSMs are cool? And I can't tell you that, right? I do know that we still support, you know, SafeNet and we support Tullis and ITOS. And those are the three big ones there. And then Fortanix is kind of cool as well too. So you can probably check out what they do for Fortanix. Yeah. So I know the, the SDK? Yeah. If not, is there something you can look at that? Oz, do you know the answer to that? I think, yeah. We'll read them on you, that's okay. Okay, yeah, read them on you. Yep, sorry, for the recording, the question was, are we in the OpenStack SDK and the answer is, I don't know, we have to beat up Monty. So, any other questions? Yes, so the question there was, is there a reason that we deprecated certificate issuance part of Barbican? So before Barbican was, you know, Barbican had an API whereby it could act as a registration agent for a bunch of CAs. You define a bunch of CAs in the back end and you could ask Barbican for a certificate and then we'd go to a CA. And I know a lot of that stuff was there because I wrote a lot of that code and then ended up having to rip it all out. And the reason that it was ripped out was that having, going to a CA is, it's a whole slew of work, it's a lot of work. And there wasn't enough, there weren't enough people in the community at the time that were willing to maintain that code. And so, we kind of went back to the whole UNIX philosophy of do one thing right and do it well, right? And so, it was just a huge amount of code that wasn't being supported by a community at the time. So that's the reason it was pulled out. Do I know any project that would be able to replace that? I know that people have talked about creating a project to replace that forever now. And it's never happened yet. So, every summer that I come to, I hear someone talking about that and it just doesn't happen. No. No. No, it's not. It's full access to CA that you use. I would love that to happen, but it's complicated. Absolutely. Absolutely, yes. And there's definitely a need for it, for sure. But there's no clear way forward. So, yeah. I'd love to resurrect that code in a different project, but it's anything else? All right. Well, thank you guys.