 Hello, and welcome to the Barbican Project Update and Overview for the Pyke Release. My name is Dave McCowan, and I'm Principal Engineer for Cisco Cloud Solutions Business Unit, and I lead security efforts there. Also with me today is Doug Mendesabel, Key Manager Expert and former PTL of Barbican, and Kaitlin Farr, who is a Barbican core member and lead for the Castelon Project. First, what does Barbican do? So Barbican is the official key and secret manager for OpenStack. Secrets in this context includes encryption keys, passwords, TLS certificates that you might need for OpenStack services or virtual machines running on OpenStack. And Barbican provides a way to securely manage and access these secrets. It provides a REST API that allows you to create secrets, store secrets, or manage the life cycle of these secrets. A little background and history for Barbican. Barbican was founded in the Havana release of OpenStack. Over the last cycle, we've had 36 individual contributors from across 17 companies. So we have great energy and diversity across the development front. Looking at the last OpenStack user survey, we find adoption is still low. The 27% of users say that they're interested in Barbican and checking it out. 11% so far have brought it to deployment. That's 8%, testing Barbican and 3% actually deploying it in production. So the pike release, we're excited that we have a lot of good features. Most of them fall under the bucket of either improved usability, improved security, or improved interoperability. And over the next few slides, I'll go into details about what's coming in pike and why it could come after pike. So first of all, let's look at secret store plugins. So when Barbican has a secret to store, it doesn't keep it itself. It provides an option of plugins that go behind Barbican to securely store these secrets. In the current Ocata release of Barbican, there's four choices. Two of these are database adapters. So the secret is encrypted and then stored into your OpenStack database. Option one, we call simple crypto. This is great for running on your laptop or running in DevStack, running in the gate. And simple crypto is nice because it's simple, easy to start. But the master key or the key encryption key lives in the Barbican config file and key text. So that's a little bit dull for production use. So the other option for a database adapter is our pkcs11 plugin. In this case, we connect with an HSM and then the master key is actually stored in the HSM. And that's where the encryptions are done of the secrets before it is stored in the database. Another option we have is our KMIT plugin. This allows Barbican to talk to an HSM and actually encrypt and store the secrets there. And Barbican just keeps the metadata of the secrets in the OpenStack database. And then the fourth option is the Red Hat Dog Tag plugin. So Dog Tag is part of free IPA, the identity policy authentication plugin, our audit plugin, and it can be a back end to Barbican to securely store secrets for you. Looking forward in Pyke, we have under development a new plugin to use the Hashicore Vault plugin. This is something that's come up before at Summit that people are using Vault or heard about Vault, excited about Hashicore's Vault. So we're looking forward to a new plugin to allow Barbican secrets to be stored there. And then, future roadmap, we're looking at the free IPA Vault plugin and TPM integration hopefully, something in the future roadmap. Another aspect of Barbican is the clients. So there's a variety of different ways to access Barbican. In the current release, we have the typical OpenStack offerings. We have a REST API, we've got the OpenStack CLI, we've got the Python library. And we also have Castilon. The Castilon is a Python programmable library that's written for OpenStack projects, such as Nova, Cinder Glance, and so on. When they want to store secrets, they can import the Castilon library. And most of the heavy lifting of interacting with the key manager, or in particular, Barbican, is done by Castilon. So that provides a nice consistent way for OpenStack projects to communicate with Barbican. So looking forward in Pyke, under way, we've got some usability enhancements to our APIs. So we've got list filters. So instead of just being able to get a full list of the objects stored in Barbican, you can apply filters to get partial lists and sorted lists. In addition, we're going to add an ID field to return to objects. When Barbican was founded, instead of having a UUID only as the ID field, we had a complete ref, which included the DNS name, port, the full URL to Barbican, plus the UUID, all in one string. And more and more OpenStack has more of a standard to just use the UUID. So this is just going to add an additional field. This will be great for tempest and other programs that access Barbican to have just a more consistent way to access Barbican objects. So historically, back in the Juno timeframe, we looked at expanding the scope of Barbican to include certificate lifecycle to request certificates from a certificate authority, to renew certificate from a certificate authority. And we found that sort of bloated Barbican a little too much. It strayed from the scope and then changes in the way CAs are issuing certificates, common CAs like Let's Encrypt, that offer a REST API. We just found that it wasn't a good fit for Barbican. We announced last cycle we were going to deprecate that part of the API and we're doing that this cycle. And finally in Pike, something exciting, the Castelon library that I talked about, which was developed by the Barbican team, has been adopted by Oslo and to becomes that much more official open stack. If you want to talk to a key manager, you would use import the Oslo library Castelon. Looking forward in the roadmap, something missing from Barbican is there is no horizon dashboard for Barbican yet. And that's something that is a future roadmap item for us. So documentation is something else we've done to work for the Pike release. We currently have a quick start developers, an install guide, an API guide. And for Pike, we're looking at writing a new chapter to the open stack security guide. And that'll cover key management in general, covering Barbican and other possible options and considerations when adding key management to your cloud deployment. And in general for documentation, each release there's a little bit of care and feeding that goes on to keep it up to date and improve for documentation. That's another piece of Barbican that's improved over time. And we have some development items for Pike release is cross project integration. So in the current release, foremost we have Keystone integration. Keystone provides the authentication and authorization for Barbican and that will continue. So the current tally of open stack services that integrate with Barbican to store their secrets includes Cinder working together with Nova. You can have encrypted volumes. Nova can also, you can encrypt your ephemeral storage. And then Glantz working with Nova, you can sign and verify your VM images before you boot. In addition, Sahara and Magnum also can store encryption keys and authorization keys. And Neutron, Elbaz, Load Balancer and Octavia also stores TLS certificates that you can use for TLS load balancing. So that's great and starting at the PTG for Pike, we had some discussions with some other teams, including Swift and Tacker. They're planning this release to integrate with Barbican to store their secrets through the Castelon library. And Oslo, as I mentioned, has adopted Castelon for a key management interface as part of Pike. And also in general, we're improving our gate jobs. So we're doing scenario testing where with every patch of Barbican, we're doing scenario verification tests that the interaction with Senator Nova and Glantz and so on continue to work. So that'll help with the stability and testing of Barbican going forward. Another area of improvement for Pike is around access policy. So Barbican, when a user requests, hey, give me your secret, please. Or create the secret for me, it needs to check a policy to decide whether this user is authorized to do perform that action. And Barbican offers a variety of ways to implement this access policy. First and foremost, we have role-based or RBAC access policy. And we have a pretty robust offering in this where we have a creator, an admin, an audit, and a viewer role that can be used. You can use it on a per project basis who has access to the project secrets. If you wanna go more granular than that, we also have an ACL access control list that on a per user basis, you can assign access to various secrets. And if either of those don't work out, we also offer there's a policy.json file that can be modified by an operator when they start up Barbican. And you can customize this arrangement. So for Pike, we're looking at improving the usability around ACLs. Some projects, particularly the Octavia group, has said that using the ACLs has been a little bit cumbersome. So we're working with them to design some usability enhancements for our ACL lists. Future roadmap in this area, we leverage Keystone for authentication and authorization. So we really need to follow their lead, but we've had some good conversations about the desire to have scope tokens. Where to have maybe single use tokens to somehow improve the, to additionally secure and improve the access policy. But we really need to follow Keystone's lead because the tokens are controlled by them. So the project navigator on the OpenStack website is sort of a way of keeping score, if you will, of maturity of a project. So we're currently over the Ocata release in the beginning of Pike release. We've had a lot of improvement in this area. We've improved our maturity index up to four out of seven stars. And we have also achieved the VMT managed tag on the project navigator dashboard. And we're looking at adding an additional maturity point during the Pike release by adding offline upgrade and a gate test with each patch of Barbican to make sure that you can upgrade from Ocata to Pike and to keep that up. So the maturity is improving and it's showing up on the dashboard. So overall, the release themes for Barbican for Pike is we're focusing on interoperability, security and user experience, and less so some of the other areas. And for Queens, we don't really see that changing. Just the nature of the Barbican project will continue the focus on those areas. So a little bit of advertisement, we need your help. The Barbican team is a dedicated team, but we're a pretty small team. I think we've done a good job managing our backlog. We keep up to date with reviews. So it's a great project to get involved in if this is your area of interest or expertise, specifically if you're a security guru and know things about TPMs, HSM, soft HSMs. Would really like your help with secret store back end plugins. In terms of documentation, if you're a writer and you want to help out the security guide. If you want to help working on the key management chapter for this release, that'd be great. Horizon Developer, if you have dashboard experience, you can write a new dashboard for Horizon to support the Barbican interface. And cross project developers, if you work on a different project and you're interested, you need a place to destroy your keys. Please reach out, we're looking to grow and be part of all the OpenStack Big 10 projects. And in general, everyone is welcome. I think we do a reasonable job keeping up with our bug backlog and our review backlog, and we're a friendly group. So please feel free to join us. Also operators, we need your input. The OpenStack survey is perplexing, honestly, to a lot of the Barbican cores. Our adoption rate is still pretty low and we really don't know what other options are there. So if you have some input along these ways, do you have a key management strategy that you're currently using? And is that solution meeting your needs? And if not, what are the gaps? And can Barbican help? So any input you have experience after investigating checking out Barbican, please let us know. And a good place to let us know is a little advertisement for Barbican sessions at Summit. There's four more following this one. Tomorrow there's an onboarding session. So if you're a developer and interested in getting involved with Barbican, please drop by. We'll have a chance for one-on-one interaction and answer your questions and get you set up and started. In the afternoon is a Barbican workshop. So hands on, we'll walk you through setting up Barbican in a virtual machine that we'll provide. And provide you some interaction of working with secrets in the Barbican API. On Wednesday, there's, as part of the OpenStack Forum, there's a community coordination session on key management to talk about Barbican and any other key management topics. That's a great place to bring up your needs, desires, and complaints. And also on Thursday, we've got a session on comparing security models, comparing Barbican with the HashiCore Vault security model, pros and cons, and maybe some suggestions on how we can work this together. So thank you very much. That is the project update for Pike, and if there's any questions.