 Well, by my clock, it is exactly nine o'clock. So we'll get started. I'm sure a few more people will come in after we get started. And hopefully, the most important part of this will be the conversation that we have at the end. So I have a lot of slides, probably too many. And I'm going to race through them so we can get to the point where I'm sure a lot of people have questions and we want to discuss this. I'm Adam Young, senior software engineer with Red Hat. I am speaking today on securing OpenStack with free IPA, the Civic Matter, to make sure you guys are in the right room. If you're not interested in any of these things, this is your chance to leave. Securing OpenStack services, the bottom most layer. I'm going to be talking about Kerberos, LDAP, Xplot 5.9 certificate and any management, a little bit about AMQP and the databases as well. OK, there's no quite a few people in here, but still I'm going to do a quick audience composition survey. How many people here are actually coders? Python coders? You better be raising your hand. System administrators? People looking? How many people here know Kerberos? I've set it up. Feel comfortable. Yeah, I figured you should raise your hand, David. How many people here know LDAP? Just about everybody good. How many people here have worked with free IPA or derivative in the past? Good. So we got a chance to break some new ground. Last question, how many people are only here because you thought there was going to be free beer? It's 9 o'clock in the morning. The free beer from Red Hat was Friday night, and I didn't get any either. OK, IPA stands for Identity Policy Audit, not India Paleo. Sorry, guys. So let me talk about today. Securing the base, the bottom most layer, using free IPA to secure that bottom most layer of the open stack deployment. A little bit about free IPA, the project. Going to some technical details of actually doing the securing, and at the end, talking about looking forward because I'm a developer, I'm a coder. I'm almost exclusively focused on Keystone, and I'm not necessarily, here's a solution that's completely prepackaged for you, but here's a process moving forward. Here's a tool that we can use moving forward for getting better and better security. As we all know, security is a process, and I think this is a way to move that process ahead. So let's talk a little bit about securing the base. I've been told whenever you do a security-based presentation, you have to start off with a nightmare scenario. So here's my nightmare scenario. Darth Vader is in the back of a pickup truck. Oh, no, that was my nightmare from last night. This is the nightmare that I think a lot of system administrators face when you are setting up a cloud environment. Now, I know we put a lot of effort into securing the hypervisors. I don't want to insult the KVM team. But since Peter Pulio isn't in here, let's imagine that you have a Hyper-V hypervisor running in your cloud. Peter Pulio, by the way, is the Microsoft representative. And you have a hypervisor exploit. So sure, you can run your code in my virtual machine. The hypervisor exploit comes through. There's an escalation of privileges. From that hypervisor, they're able to run code and infects the other services. And now, all my base system is belong to this hacker that has just run code that I let them. So a little bit about how OpenStack is set up. This is a very busy slide and probably hard to read from the audience. I'm not so concerned with the individual details as much as you get the sense of the number of pads into the system from the OpenStack end users and between the components. And not all of these are super frightening. But if we look here, starting with this red one here in the center that says Q, that's the path out from Nova Compute. So if our Nova Compute gets compromised, can it compromise things via the Q? Can it compromise things via HTTP? And you see it sneaking all the way back to the Keystone backends and contain memory. Also, there's a couple red lines coming in from the outside. These are just your standard attacks from the public sector across HTTPS. And also potentially across VNC, if you're using that to manage newly launched virtual machines, you see this particularly long one in the middle, which is, again, as a Keystone developer, my nightmare scenario, a direct attack against Keystone from the outside. So these are the vectors of attack that I'm looking to try to secure. Now, when you look at setting up defense, you can either set up one big wall, a firewall with everything running in the inside, or as I like to call it, crunchy on the outside with a chewy center. Or you can try to do a defense in depth. Now, this is very Byzantine bro. But the idea that I wanted to visually portray here is compartmentalizing and be able to move from one big, open, base system to a system where nobody trusts anybody. And yeah, you can still get your work done. But it's secured, and it fails gracefully. If anyone's system gets compromised, you don't lose the whole thing. Thought a little bit about identity management. Identity management, we're talking about layers, like an onion, or Parfait, if you like Parfait better. At the top level, you have what the customers for the cloud are going to use as their identity management solution, the actual end application users. Below that, we have an identity management system for virtual machine administration. And you may want to believe between these two levels. But typically, you want to keep them separate. And the decision you have to make then is, are the people managing the virtual machines, the same people who are managing the base services, the open stack service administrators. And you may have these in the same identity management system, but for a really large scale deployment, you actually may want to keep them separate. That's a deployment decision. But I wanted to frame the conversation this way. So we're talking about the physical layer. Put it in quotes because as the open stack and open stack folks may say, it's actually virtual machines. But what I'm talking about is what typically you think of as that physical layer. The allocated machines that you're running, at least one open stack API or service on. Yes, you can consolidate. But you're probably going to try to separate those out for scale mode. So in a professional deployment, you're going to be running probably one physical machine for glance, one for Keystone, probably multiple and so forth. You'll also be running a Q server for NQP, your database server. I say Postgres. I'm foreshadowing a little bit here. You're obviously going to be running several for Nova Compute, several with disk for Swift. You're going to be administering, at a minimum, greater than 10 servers, probably significantly more than that. Does this sound like a reasonable setup? Are we all the same pages as far as we're starting here? So let's talk a little bit about free IPA. The first line is a quote from the free IPA page. It's an integrated identity and authentication solution for Linux and Unix network environments. We're not attempting to become active directory, but we're attempting to provide for the Linux and Unix systems an analog to active directory, but built with open source components, using standard protocols, and focused on easing of management, installation, configuration tests. How many people here have set up Kerberos before? The first time you went through it, it wasn't that easy, was it? The second time it wasn't that easy. That's one of the things that we're really looking to not just simplify the process, but just simplify getting it right. Same thing with LDAP, same thing with Bind and so forth, all the pieces that are in it. I'd like to mention that it's in rel, and if you're looking for it in rel or one of its derivatives, these packages are not free IPA, they're just IPA for hysterical reasons. But it is a tool that you have available to use. Now it is in Fedora, it is in rel, and so forth. And I think as a conditioned game to wear this nice new red shirt, I had to mention red hat at least twice in this presentation, so I've got that covered. OK, what pieces make up free IPA? Kerberos, the MIT Kerberos. At this point, I was told all our European comrades would leave, because they want Heimdall. Sorry, you have to choose one. And we are very much focused on MIT Kerberos. A directory server, an LDAP server, in our case is called 389. It is not open LDAP. I really don't like the choice of 389, because 389 is the LDAP port. I would have preferred that we chose the 686, the secure port for LDAP, but that's the title of it. It's deprecated? OK, thanks, Nemo. A certificate authority, a full CA. The project name is called Dog Tag. And it is, so I like to say, it's the artist formerly known as Netscape certificate server in its current incarnation. It's a really long live, really well tested, and used by some really big TLA's from DC. A domain server, it's bind, but with an LDAP back end. And then we integrate very tightly with a client-side piece called SSSD, the system security services daemon. And yeah, I have to look up with the order of those SSR every time I talk about it. It provides management for users, groups, and then users, groups of users, hosts, groups of hosts, services, the actual applications running on there, such as SSH and HTTPS from a security perspective. It helps manage key tags and certificates for those. And it obviously manages DNS, since we have a DNS server. So who, and then what can you do? The policy side of things. It manages the access control list for the actual database server. And in this case, the LDAP server, the directory server. It provides a means to do host-based access control. Who can log into which system, from which system, using which protocol? And that is enforced by SSST. It gives the ability to centralize SUDU, which might be interesting for some of the stuff that we do with root-wrap. It also can manage auto-mount. It has support for SE Linux user maps and cross-domain trusts, all Kerberos things. Actually, the last is good Kerberos thing. Let me talk a little bit about Kerberos for those who are not super familiar with it. Kerberos is an authentication protocol. It is, like I say, one of the few that is actually cryptographically secure. I might get stoned for saying that, but it's how I understand it. It supports multiple protocols. It's not just a straight HTTP protocol, as we had some discussions around OAuth and OpenID and stuff like this. Kerberos will work for pretty much all the major protocols that we care about in an OpenStack deployment. It does two-way verification by, not just by default, but it kind of enforces it. When I'm done registering with KDC and getting my ticket granting ticket, I trust that KDC is who it says it is, key distribution center. And it knows that I am who I say I am in both ways. And that's really powerful. As I said, it does cross-domain trust. There's a way of setting up Kerberos such that I can get a ticket from, if you look at the original MIT had Kerberos set up, and you could use a ticket from the MIT KDC with any organization that was then trusted by MIT. So if you were a graduate student doing an internship with one of the various companies around there, and they had a cross-domain trust, you could still use your MIT credentials to sign in there. So our free IPA helps manage the ticket policy, how long that ticket lasts. Everybody understand what I mean by ticket? It's a Kerberos term. Another way to think of it is a short-term certificate. It is a cryptographic document issued by the Kerberos server that says you can do something. So you'll hear me talk about tickets a bunch when I'm talking about Kerberos, but it sounds like people are familiar with it. It also, through Sassel, allows you to set up wire encryption. Again, for applications that support Sassel, this is pretty powerful. And you don't have to change code to do it, which is why I think it's important. And a new thing, how many people are familiar with the movie Highlander? I like to talk about Highlander syndrome. There can be only one. One problem with Kerberos, up until recently, was that you could only have one ticket-granting ticket active. You could only talk to one KDC at a time without jumping through some fairly significant hoops. And it's gotten a lot better. You have the ability to talk now to multiple TGTs. And that's one of the things that I think really makes it possible to start using in a multi-cloud environment. And it's worth, I think, bringing out at this level mentioning. So let me talk about some of the technical details about the start, free IPA and OpenStack together. So let's talk about mapping free IPA to the OpenStack clever. Again, Kerberos has a single sign-on for the physical layer. As I mentioned before, we have 10, or greater than 10, hundreds, maybe thousands of hosts. And how many people are doing some sort of custom solution for SSH key management between the hosts that are running OpenStack right now? Only a handful. Good. How many people here are already doing Kerberos? What are people doing? People are just afraid to put up their hands. How many people are aware that I just wrote a second head? OK. This provides a secure way of not just doing single sign-on, but managing the single sign-on across that deployment. Being able to revoke access without having to go to each machine in the system, it's pretty powerful. I will talk about using it. You can use it to actually encrypt AMQP. On the wire, it not only does authentication between the broker and the person attempting to either read from or write to a queue, but you can actually use it to set up an encrypted tunnel between those two without, again, as I said, it's part of the libraries that you use. It does certificate management for HTTPS. So you install Keystone. You provision certificates for Keystone. And those certificates have to be issued from a certificate authority. You have to have a chain of authority all the way on back so that you don't get these little people. People aren't constantly shaking. Oh, yeah. Let me trust this browser certificate. Let me trust this. Or having to import them into their local NSS database for curl for direct access. I have shown how you can use it, and again, in certain deployments, it is the LDAP backend for Keystone. And it's a powerful control layer for saying, I'm going to manage my users using a standard LDAP system. And yes, I can use that for Keystone and for my IPA, excuse me, for my open stack deployment as well. You can use it actually to authenticate to Keystone as opposed to passing a user ID and password. You can actually set up Keystone so that it uses Kerberos as your authentication mechanism. And again, whoever you authenticate with using, again, this is through Apache. So modoff krv5, whoever you authenticate with there has to match the identity backend for Keystone. So it makes sense to use one of the same implementation for free IPA makes that possible to do. A general approach, obviously, you have to have a free IPA server. And somehow you have to install IPA client on each machine and then enroll that machine with the IPA server. This stuff can be done, and there's actually fairly good documentation in the free IPA and related documentation about how you'd set this up with a pixie server. But you need to prime the pump. You need to get it so that each client machine is enrolled as a unknown host with the IPA server. And then you set up for the service the key tabs and the credentials cache. So if you're running Postgres, if you're running IAMQP, these things need to be able to not just authenticate themselves in order to request to do something, but be able to figure out Kerberos credentials that are handed off to them if they're valid and so forth. So you have a little bit of management to do for setting up those two distinct sets of files. You set up the service itself, and you test with the command line tools. You make sure you can do a database connection using PC SQL. You make sure that you can talk to IAMQP by sending them as a diagram, a little test program to do. And you set up SSL for the ones that don't do sassel. Postgres is an example of that. And that leads me to talking about certmonger. Certmonger is a client side piece. And here's the definition off of the certmonger page on its, I believe it's a four-door hosting project. It is able to track the expiration date of a certificate and notify you, hey, your certificate's about to expire. But even better, especially when working with free IPA, it can get you a new one. It can do automatic renewal of certificates. So, hey, I know this one's about to expire. Let me go to the certificate authority and get another one so that I don't have a break in service. Because once certificates expire, it can lead to some real matches if a user has hit a website that has an expired certificate on it. And it has to know about the certificate and key storage. It will work with both PEM and NSS. Everybody familiar with NSS as a crypto library? NSS is what, OK, I've got a couple hands, and I know a couple of people didn't know it, NSS is Network Security Services. Again, the artist formerly known as Netscape Security Services. But it's the one that A, Mozilla, and Firefox, and all that used to secure keys, and B, it's what Dogtag does for issuing the certificates. NSS is, if it's compliant. You can use software built using NSS when working with the federal government, Department of Defense, and such a type of situation. It also is able to work with PEM, work with OpenSSL in order to fetch a new certificate for service. The service choices, I've alluded to most of these already. I do my development on Fedora 18. I'll admit it. I'm a post-chrispigot. I like post-chrispigot as a database. In this case, oh, it also happens to be the one that supports Kerberos, where I use Cupid as my queue deployment mechanism, again, because the Sasslin and Cupid, excuse me, the Kerberos support. If possible, and certainly for Keystone, I like Apache as the web server. Again, Kerberos support there. 389 directory server, as mentioned before. NSS for cryptography, as I just mentioned a second ago. And then Cyrus Sasslin libraries, and that's what gets you that ability to encrypt on the wire. Now, I went through and setting up all these things. I tried to make sure I wasn't selling vaporware up here. Not that I'm selling anything. I'm trying to explain a process moving forward. So right now, I was setting up post-chrisp for Keystone. And so the TGTs, the ticket-grouting tickets, have to be refreshed every so often. They time out. The default policy, I believe, is $8. And so every six hours, you need to get a new one. Make sure you have a little bit of overlap. And right now, unfortunately, you have to chron it. And when I save my right now, if I was using Fedora 19, I wouldn't have to. And we'll talk about that in a little bit. But some of the ugly details. And then you notice in the SQL Alchemy URL, you specify the KRB server name. This is the service. This just has to match everywhere as post-chrisp. And this tells post-chrisp, hey, use Kerberos as my authentication mechanism. And then you also have to set up the Kerberos server to do that, actually the post-chrisp server to do Kerberos, except Kerberos is authentication mechanism. Keystone HDPD, as I said before, use mod-off Kerberos to authenticate people, authenticate users. This uses the remote user configuration in Keystone. It means that the web server does the authentication, not Keystone, and then it just passes off to Keystone, the tightly coupled. It's a trusted arrangement between them. This is the user name. So Kerberos is going to say, here's what the user name is. And then Keystone accepts that. And this will work, actually, for other authentication mechanisms as well. You could use this, say, if you do an X509 client certificates, which you could also do. And then, as I said, you want to use LDAP as the back-end identity for Keystone so that it matches. We still have some ugly details. We have to do a simple bind for the user. There's some code chains that need to go in there. But that's really just communication between Keystone and the LDAP server. It's something, again, we can move forward to improve. And once again, you have to do the key tab for HDB service and user, as opposed to the Keystone service and user, because HDBD is going to be the one that's doing the request for you, or doing the Kerberos to LDAP talk for you. A little bit about Cupid. Again, if you specify the Mech list as GSS API, everybody familiar with GSS API? Yes, no? OK. I see a couple hands and a lot of science out there. I'm going to assume that people aren't. GSS API is one in a series of wrappers for trying to abstract away what Kerberos does so that you can provide other mechanisms for it. So when you see GSS API, know that there is really one main implementation of it. Right now, as of today, it pretty much means Kerberos. There are other implementations out there as an X5091, but it is the library layer that basically says use a secure mechanism. And by the way, the only one we have is Kerberos. You tell Cupid to use GSS API. And as I said before, if you use the Cyrus sassel, use the Python sassel wrap or Python ACPQP for the clients, that will tell it to set up a secure communication channel when it's talking to the queue, instead of it just being clear text and just using Kerberos to do the authorization, it will actually encrypt the data crossing. Now, one thing I didn't mention when I talked about Postgres is you can't do this for Postgres yet. Sassel is not supported on Postgres, look into whether it's worth pushing on through. But you can secure an SSL layer between, say, Keystone and Postgres, but you have to do it using X519 certificates. So it will still be managed there, but it's a different way to configure it. Fairly well documented. A little bit about looking forward. As I said before, that cron thing is pretty nasty. There's code in place now that if you are using the GSS API, you can set up an automatic credentials refresh for a service. It involves getting things in the right location in VAR and all that. But basically, what happens is that you launch a service from systemd, and it.d for parole or things, but it's going to be systemd moving forward. And that thing needs a TGT, and it has a key tab. It will go and fetch it. As I said, I like Apache HDPD. I would like to use that more and more places and be able to carburize more and more of the system. I want to carburize horizon. I want to be able to. I'm not saying we're forcing this down people's roads, but I think it would make it a more secure deployment. One of the things that we've discussed, this is not a hard and fast thing that we're going to do, but something we could potentially do is, in the service tickets, we could actually put in the same information that right now is in the Keystone token so that you could send one message to, I mean, as part of that negotiating handshake when you talk to a road service, you could pass along. Here are my roles in my projects. Here's my service catalog. And again, have the same degree of confidence in this information as you currently get from the PKI sign token in Keystone. And one of my pet peeves, and I don't know if I'm out of throwing range from SEMO here, but is that he finishes cup, too. Good thing. Kerberos requires port 88. And that means you can't use it over the public interwebs because every data center blocks port 88. I want to be able to do the Kerberos code marshaled over HTTP or HTTPS so that you can use it, and potentially then Keystone could be a front as a proxy to a Kerberos server. I think that would be a very, very big step forward in making Kerberos more usable for a lot more people. A little bit more on looking forward. I've gone through how to use the access control list to do some pretty walking down delegations. For instance, you can use it to create a group, assign SEMO to that group, and delegate to SEMO the ability to add users to that group. So you don't have to be an administrator to control group access. You can actually delegate group administration to a specific user. Same thing for host groups. So if you have a set of machines that you've deployed via OpenStack, you should be able to administer them. And yet if you're using the free IPAs Kerberos, you want to be able to establish host-based access control. Who can log into each of those things? So these are the things that we can push down to users without granting them full administrative privileges on the entire system. As I said before, we have root wrap. Using the centralized sudo is a better way to control which machines can do which root wrap operations. I think they're very powerful. You add in a new Nova compute node. You want to crank down what it can do and have it only accept from the centralized LDAP server which operations given users about to allow it to perform. It can manage SSHGs now. We're not talking about integrating that into OpenStack yet, but it is a possibility that SSHGs can do a lot of things. And I would say that's a huge key management. And I would see this being used for places where you can't use Kerberos to get into the system. You're coming from a remote side from a new machine. You have your key with you. You can log on in. Also for managing encryption keys. Now, one thing that is part of DogTag, that is not currently part of free IPA, is a key escrow service, data recovering manager. And this, I think, ties in with some of the CloudKey securely store and retrieve keys that are used for encryption of block devices, encryption of files, encryption of whatnot. There's tools that we can pull in to make this done in a secure manner. So I don't expect you to be able to read that. But when the presentation is up online, you'll have a link to some of the documentation I used to do this. And you guys that came in earlier, you heard me play in the Dropkick Murphy's. I am from the Boston area. My mind's there right now, so I wanted to close with that before I put up the big red hat slide and open it for discussion in questions. So yes, I would never say only. As I said, free IPA is pulling together a bunch of technologies to make them easier to manage in the first place. So as a degenerate case, you could handle doing those by yourself and choose different approaches and still get a secure deployment. And I'm not saying that with free IPA, you have a completely secure deployment either. So I wouldn't go so far either way. What I really more I would say is the point of the presentation is to use this as an example and a way to move forward in looking at the problems that people have in securing their deployment. Free IPA is a tool that can solve that. And I think it is a lot of the right technology choices, especially in a Linux-Unix environment, for solving that. So you can do stuff with X509. A lot of the stuff that we're talking about doing with Kerberos, you could do more with straight X509. I think you can get the same kind of security, but you need to have a full X509 solution anyway. So you could just deploy dog tag and do this, but you better know what you're doing. You're not going to get the same degree of user in any management. You're going to have to build a little bit more solution around it. This is a little bit more turnkey. And this is very developer-friendly. I used to say I was sick of building address books. I went through .com bubble 1.0. And it seemed like each project, we had a user list. I like the fact that LDAP has a bunch of RFCs to lay out how a user should look. And free IPA uses that as its basis. Free IPA uses the RFC LDAPs as far as it can. Where it does custom schema beyond that, it's very deliberate decisions to solve problems that we can't do with the standard schema. It's not saying you can do it every way. It is saying this is how LDAP is going to look. But it's based on a lot of experience and a lot of heads-down design. Excuse me. Do we use it in production at Red Hat? No. Well, first of all, we're not a cloud provider. So Red Hat has a series of clouds in-house for development purposes. I can't speak to what the different people, because they're all run by different groups there, are using. In our cloud, we had to get an open stack up and running as fast as possible as baseline a manner. So it didn't make sense to. But we're not opening up to the public. Is it something that we're going to do? I don't control the offside of things. I'm a developer. I would like them to. But that's not for me to say. Right now, I'm going through in figuring out how to make it work. I'm just a keystone developer. One of the reasons I'm so late in starting this work is because I had commits that I had to get in so we could get Grizzly out the door. But in the back of my mind, while I've been doing this work is there's a better way to do a lot of this stuff. So once I got the main Grizzly work done, I ignored my responsibility. Sorry, Perry. And said, I'm going to get ready for this presentation. I want to make sure I can validate all the steps here. So this is the start. I've gone through and validated that these things will work. I'm not here to sell you a product. I'm not here to say this is the start of the conversation. I wouldn't expect to see that. I think this is too new a concept. As I said, I'm one of the few people that lives fully in both the free IPA and Keystone Realms. And so we're just getting started on this here. I think what you'll find is if you talk to people, they're using pieces of the same technologies. People are using LDAP. But as far as free IPA as a consolidated way of approaching it, I don't think that's there yet. I think this is the impetus to get things moving that way. Now, Red Hat Identity Management is part of the REL product. So if you're running REL, you get this. So as far as support and all that goes, that's part of being a Red Hat customer. And so that's where my Red Hat's at. But I'm up here not just as a Red Hat representative, but as an open stack developer saying, I want to crank down how we secure our deployments. Here is a series of technologies that will do it. Let's make this happen. Minimal. Minimal. I think most of these changes are below NOVA. Now, I think NOVA could potentially make use of some of the things. One of the design discussions that has been going on is in encrypting messages on the queue. And if they start doing that, then we could use the X509 support from DogTag to manage the keys for encryption. Or perhaps the Kerberos libraries to do that. There's a couple of different ways to go about doing it, and there's arguments for either. You could use the SASL connection to the queue. I believe it's with no changes to the client side libraries. It is a configuration option that will take effect once you set that up. But it may be that we need to do minor changes, config changes, to say, yes, allow SASL. I haven't gotten that far. On the Postgres side, for anything that needs a database server, Postgres is fairly well supported now. So it should just be a matter of changing the URL and the configuration files for the other ones. I haven't gone through and tested a whole system. I made sure Keystone worked. So this is the start of the conversation that way. So one of the things we need to do in future design summits is de-conflict the security and the Keystone tracks. Because today's Keystone day. And today we're going to figure out what we're doing for the next release. And there are actually a bunch of the developers, and I think people like Guam, who's core developers for choosing to come here. We had a bit of a pre-meeting to make sure that the guy who's talking right now got his information up to the key developers. We're going to figure out what we're doing for securing the tokens moving forward today. So I can't answer that yet, but I might be able to answer it at 5 o'clock. Sure, no, ask, ask, ask. If you have any thoughts, what pieces have you registered in the PIPA? Yeah. What are the different aspects of that? Well, finish with aspects of Keystone. Well, I mean, the obvious ones are users and groups are Keystone concepts already. So using groups to do the groups in Keystone groups being a grizzly concept. A grizzly concept. Never used that phrase before. Using those are the obvious ones. Keystone doesn't currently know about hosts. There is some question about whether we should integrate the service catalog with the services in Keystone. And I think that we would want to. That would be a very logical conjunction. But I don't know that everything that shows up in the service catalog would necessarily be something. Everything that shows up under services would be something you want to show up in the service catalog. So we'd have to look at how we do the integration to make sure we could filter at that point. But that would be really powerful to say, I'm registering a new Keystone endpoint. Let me see that in my service catalog. I'm registering a new Swift endpoint, so to speak. I could see some argument for that. There's no concept of host management. But it's been discussed. So if that happens, then there's a very logical thing. Spend up a new VM and see it as a host in a host group. I could see, again, for smaller appointments, very in-house. I could see that being a powerful tool. Again, I don't want to say there's going to be one-size-fits-all here. It should be a matter of making decisions that are appropriate to your deployment. But I think that the tools could be used that way. Well, first of all, I don't think we're going to be able to use anything but X509 for SSL. So X509 is a fact of the world. I do know that there are certain organizations out there, some of whom have spoken at this session in the big room upstairs, that are doing X509 everywhere. And I think for those people, they would want to make sure that they could do X509 for all the things that we're talking about. Would they use BIPA? I don't know. Would they use DogTag? Potentially. I would like to see Kerberos as an option. And one of the stumbling blocks there, of course, is the EventLib web server does not currently support Kerberos and Spanego or whatever as a authentication mechanism. And it may be worth putting the effort in to make that happen. And if that did, then you could potentially use Kerberos as a single sign-on. We'd have to make sure that the same information that we provide from Keystone in the off-token is available if we do that, hence that talking about putting that information in the service ticket. So it would still be an integrated solution there. But I would love to see that as a, I think that would make a very secure deployment. Again, not being prescriptive here. I want people to understand it's a tool that they can use. This is not going to drive how you must deploy OpenStack. You don't have the power to do that. And I don't think that's the right approach to take anyway. Anybody further on that? Yeah. We're in the make it work stage right now. That being said, we have a whole group at Red Hat called Merge, which is messaging real-time and grid that are focused on how to tune and speed up and secure messaging. So there's what you would do in a default deployment. And then there's what you do when your default deployment needs to still be secure, but needs to scale better. And I think that there's a lot that you can do. One very simple case is you may have lots of readers from the queue. You may decide to change your queuing topology to offload things, to keep things secure. But so that the readers are not necessarily hitting the same machine as the writers. There's things that you can do that way. But we haven't hit the point where we're profiling. We haven't hit the point where we're trying to get performance numbers yet. To benchmark it? Unfortunately, I don't think any of our performance guys are here. I know that we're focused on performance across the board with OpenStack at Red Hat. And I would assume that this would be part of the free IPA, which is, again, putting on my Red Hat hat and persona. The Identity Management Group, the group that is responsible for our free IPA development at Red Hat, is also responsible for Keystone development at Red Hat. So at least from that perspective, and we perform a student what we put out the door. So I don't think I am overstepping my bounds to saying yes that we will be doing that. Great, great, great question. Yeah, that's, I think, a real pain point. I don't know if it's necessarily OpenStack's place to do that, but we might do it as a de facto standard anyway. One of the things that, and so let me put it on my Keystone developer standpoint. I would love that. I would love to be able to say that this is how it should. I have to be sure to look at the CAs that are out there and figure out what would be that right level of it. Now, let me put on a different hat. And this is the hat that I wore for about two months before starting full-time on Keystone. And that is I was working on Dog Tag full-time. And one of the things that we did there is looked at the REST API, or lack thereof, and said, what should that be? And so we went heads down and said, this is what a good REST API would look like for talking to a certificate authority. And this is what Dog Tag should look like moving forward. And fortunately for me, somebody who is about as dynamic and smart as can be, A, was involved in that design decision, and has taken that and run with it in the time since I've moved over to Keystone. And so Dog Tag should have a really good clean REST API that I would love to see be the reference implementation for that. And then it could be, here's what we use when we talk to Dog Tag. Maybe we build one as part of OpenStack, a facade for talking to OpenSSL, blah, blah, blah. And it will work talking to Dog Tag down the road. That is what I would love to see happen. Again, I don't have the power to make that happen. But it is something that we've discussed. Sent to us what? IPA RPMs are part of the base rel distribution. Oh, OK. Yeah. Yeah. Right, right. It hides the Dog Tag you saw from you. And yeah, that's, I mean. I just want to say, if you guys could let me add anything to the IPA and talk that moving forward. You want to talk about that, Sino? No. I can't speak to it. A lot is demand. A lot is really demand. If there is more demand for direct access to Dog Tag as part of the free IPA thing, then we'll open up more and more of it, I would say. Yeah. A little bit of the reason for the pain is that free IPA was ready to go out the door before we even addressed the rest IPA, the rest API for Dog Tag. That stuff is new. And the goal was to not break IPA. So it had to use the older manner of talking to it. And so it's a very, it's a security product. It's very, very cautious in its development. And so opening up the rest API, first of all, meaning the rest API need to be added and all that. At some point, we hope that IPAs only consume the rest API and that old. If you looked at it, you would be, it falls under the realm of laws and sausages, stuff that you really would feel better. But the communication mechanism is locked down. So to make more and more of that available through free IPA to the outside world makes perfect sense. I mean, to proxy it through HTTPS or HTPD is pretty much how you want to front a Java app anyway and Dog Tag is a Java app. More questions? Questions about Kerberos? This general approach is seven minutes early. This is good because when I did the presentation before, I was running over. Any? Going once. Well, thank you very much for attending.