 Hello and welcome to the PTL interviews for the Newton design series I'm here with Douglas Mendes Ball from the Barbican project and Kenny Johnston from the OpenStack Innovation Center Doug, can you start us off by introducing yourself a little bit and telling us about your background with OpenStack? Yeah, sure. So let's see. I've been a Racker for about three years I know as a contractor for about six months before that And most of my time I've spent working on Barbican Now this was sort of before Barbican was an OpenStack project and prior to this I didn't have any any kind of OpenStack experience. So coming in I you know, I worked with Jared Rehm Who was a previous PTL for Barbican? And I think I was like the second developer on this so so a lot of us that was pretty new So it's around sort of as we went through incubation And help Jared and the rest of the team sort of go through that process to to have Barbican become an OpenStack project And then with Jared sort of moved on to do a lot of things. I followed in his footsteps, so to say to To lead the project and so I've been a PTL for Barbican for about a year and a half now I'd say I'm pretty familiar with Barbican specifically maybe not so much with the rest of OpenStack That's what it sounds like you've been with the project since it's infancy. So that's great Can you tell us a little bit about what Barbican does and who uses it? So Barbican is a restful service that provides Key management right and so when I talk about keys I'm talking about stuff like passwords as stage keys encryption keys GPG keys even that people use to sign packages All sort of sensitive material That needs to be protected and managed there's there's like a life cycle management of these things And so we created Barbican to have a to be the key manager for OpenStack specifically, right? But we we did the sign the project from day one to be part of OpenStack And the idea there was to allow other OpenStack projects To enable security features by using Barbican, right? And so if you think about sort of The use case that that really comes to mind first is that it's Swift Which is still sort of in progress. It's been they have some interesting challenges on their end of things But the idea was for Swift to be able to provide encrypted storage and to be able to encrypt Sort of at the scale that Swift operates they would need, you know, maybe hundreds of thousands of keys They probably want to provide, you know Distinct or unique encryption keys at least at the user level maybe even at the Swift container level And so we designed Barbican to be a place where Swift could store thousands of keys securely, right? and the System itself is designed with high security in mind and so We wanted to be able to work with Devices that are that are specifically defined for secure storage. So if you think of HSMs I don't know if you're familiar with it with an HSM. I certainly wasn't before I started working on a project But their purpose-built hardware devices sort of like one you racks that that you can rack like you would a server But instead of running a normal operating system, they run sort of custom firmware In addition to have custom hardware that that can do like really fast crypto operations and stuff like that one of the interesting features or at least that I find really interesting is the ability to Create encryption keys in the system that can never be retrieved out of it And so this you know if you compare that to encryption done with maybe a key that you store in a file You can see how how much or how better the security sort of profile for that would be You can't just go in and grab this device or whatever and plug some nails into it and get that stuff out We also wanted it to be a little bit flexible as far as the employer goes to be able to choose sort of the hardware device that they prefer or Be able to do in a software if so the one sort of a drawback at least HSM says that they're really expensive The ones that we use their rack space are I think are about $15,000 a unit And if you want to have you know high availability and stuff like that You probably need a few of those and then a few for standby in case stuff happens So it can add up real quick And so with that in mind we we design a plugin system for the back ends for these things And we've got basically three of those That that we feel are ready for production use and one of them is a pkcs 11, which is a crypto standard These devices sort of all speak the same language so to say the same protocols pkcs 11 being one of them Came it being another protocol that other devices use and so we have both of those plugins to be able to connect Barricade into these secure hardware modules And then in addition of that we have a software only Back end that can talk to red hats dog tag Which is sort of a system in and of itself But we're leveraging that sort of not try to reinvent the wheel, right? If you know red hats already got a pretty good system and dog tag Being the test sort of answer the question It does Yeah, it does Given that the team just met at the Austin design summit Can you tell us some of the priorities for the Newton cycle that the Barbican team is going to be working on? Yeah, so I think one half of the question I didn't answer is who is using it, right? And so as of today Rackspace has a production deployment on it We're an early access beta and so people have to request access to it and then we'll run access and They're able to use it IBM also has a public beta of a rack space or a Barbican deployment HP also has a deployment, but I don't think that there's this public facing I think that you only use it for internal things And so as far as the the Austin summit I'd say probably the most significant change is Was requested by HP and they want to be able to operate Barbican with multiple back ends So I did talk about a little bit about the plugability of the back ends with As of the last release we're limited to only a single back end for deployment And what what the folks at HP want to be able to do is say, you know for for these tenants or for these users maybe they don't Need a hardware module to be backing their usage of Barbican And so maybe a software-based one is good enough for them. And so I would say that's probably the Biggest feature we talked about Another thing we we've sort of been kicking around and it's a significant amount of work is to Separate Barbican or at least some features to Barbican into a separate service And It's specifically the the ability of Barbican to provision TLS certificates from public CAs It's a feature that I don't think has really gotten a whole lot of traction in the community And so what we talked about this summit of actually deprecating a lot of those API's So there's a start preparing to to remove that from Barbican and then if there is interest from from other folks to keep that going Maybe you make that happen in a separate project I think those were sort of the major themes everything else was sort of You know more around. Oh, we did talk about Performance quite a bit so now that that IBM and racks face are both using this pkcs 11 back end to run Barbican at production level We're not seeing sort of performance. We'd like to see for a big cloud deployment And so we had a lot of discussions around how we can get better performance out of the system And it was nice at the summit to actually have a gentleman from Jamal to which is One of the companies that produces or that sells HSMs And it just so happened that both rack space and IBM are using their HSMs to back Barbican And it was so so it's really nice to have him sort of on hand to answer questions and give us a little more insight Into these these hardware devices and how we could leverage them better to or or different knobs We can we can tweak to try to get a little better performance out of them Cool So one of the things that we've been tracking across open stack projects is is cross project themes themes like scalability or resiliency Antibody modularity and interoperability, and I'm wondering if you could speak to what work The Barbican team is doing in the Newton cycle with regard to those themes Wait, so um scalability. I think I mentioned a little bit. We're we're I'd say we're pretty happy with as far as the the storage Scalability of Barbican At least in one of the plugins we device the scheme in which we basically offload all the storage into a database And so we were able to scale the storage sort of as as big as we needed now I Think Performance is definitely going to be a big big push this cycle. We're hoping to have Good performance numbers to to compare at the next cycle to see, you know, how The try to get a little better performance out of our out of our project As far as resiliency we have been talking about maybe adding more gates To our Garrett gates specifically grenade gates to to make sure that we are able to provide sort of continuous Upgrades and Barbican I know definitely a rack space we're striving to have a zero downtime if possible or at least I think five nines That's what we're shooting for And so we're definitely going to be doing some work there manageability Let's say which which my little cheat notes here say it's about user experience. I actually Had of I was speaking at a different rack space office in Austin yesterday about Barbican or our deployment of it trying to get some more users and I got a lot of good feedback from that There's the the way in which our client works is a little bit different Then most other open-stack clients is We want to get some work done maybe the cycle to to get our client to be a little more in line with the rest of open-stack What you'll already we talked a little bit about Separating the the CA certificate provisioning features from Barbican This was something that that Rocks face was pushing for a lot maybe two three years to go But then decided to go in another direction and there wasn't really a whole lot of traction from any other companies except for red hat, but they're I Wouldn't say they they were pushing real hard on it They're so it's it's a feature in Barbican that hasn't seen a whole lot of development in last couple of cycles And so I think it would be good for sort of the long-term health of Barbican to Get rid of a lot of that stuff or at least move it into another repo where it could live and I think it would also help with the Deployment of Barbican, I think it would simplify the deployment of Barbican a lot As far as interoperability we talked a little bit about Federation Sort of one of the bus words in the security world right now is be y okay for bring your own key We we actually talked about that quite a bit in Austin as well And I think sort of the community well the feedback we have from the community is that Be like a feature that it seems a lot of people want but not necessarily a Barbican feature Now it might seem a little weird because you know Barbican is the key manager for open stack Why bringing your own key wouldn't wouldn't have to do with Barbican, but if you really think about the feature it's really more about Customers that don't want to give their key material to their cloud provider They want to keep everything on their side, and they only want to provide it Sort of at the least amount of time is needed And so if we think about we talked a little bit with the Swift team And also with the with the glance team and the idea there is like looking instead of Putting Barbican in the middle of this be able to provide sort of a consistent API Or at least guidelines to have consistent APIs for customers to provide their keys at the time that they request something And so a good example of that would be you know if I want to encrypt the container in Swift I Would provide that encryption key that I wanted to be encrypted with every time I send a request to Swift to Say encrypt something for me We we We talked about a sort of a different model for BY okay, whereby we would ask Both customers to have a Barbican deployment and then the cloud provider to have one as well And then have the cloud provider and that private Barbican sort of established some sort of linked together very much in a federation kind of spirit, but the sort of a feel we got from the community was that it wouldn't That wasn't a very compelling sort of model for BY okay That's a yeah, well, I think that covers the the five themes dog And I think that concludes our interview thinks a lot for taking the time to give us some insight into what's coming on with Barbican this cycle Absolutely. Thank you for having me