 OK. So good morning, guys. My name is Adi Lee, and I'm going to be talking to you today about provisioning IDM clients in OpenStack. My co-presenter is Robin One. Unfortunately, I couldn't make it today. So most folks over here, you guys are familiar with what OpenStack is, but you may not be familiar with what IPA is. IPA or FreeIPA or IDM are all essentially the same thing. It stands for Identity Policy and Audit. This is about security, essentially. And it's a centralized identity store. So it's a product that allows you to do centralized identity. It gives you a Kerberos domain. It's kind of like a domain controller in the Windows world. It has a CA that allows you to generate SSL certificates, which is one of the key things that you need in order to have TLS-enabled services. And clients can enroll using passwords and so on and so forth. When hosts do enroll as IPA clients, they get an identity. And that is a key thing, because that identity is something that could be used to get certificates and participate in host-based access control and centralized pseudo and so on. So what is auto provisioning? Well, auto provisioning is simply enrolling NOVA instances as IPA clients when they first boot up. So why would we want to do this? Well, I already talked to you about the benefits of host-based access control, centralized pseudo. But one of the key problems that has been facing OpenStack for a while now is how to deploy OpenStack services with TLS-enabled endpoints. This has been a long but an open problem in OpenStack. And the basic problem there has been, well, how do you get the certificates onto the newly created instances? Once you have them up there, you don't necessarily have an identity or something that you can get certificates. And there have been two ways to solve this. The first is a push model. So you basically generate the certificates outside of the instance. And then you push them in either through Ansible or Heat or whatever the case may be. And in the triple O context, for example, this would mean having the certificates and the private keys and so on generated on the under cloud and then pushing them to the instances as you push them up. The main disadvantage of that, of course, is that now you have private keys that are hanging around both outside of the instance and inside the instance. And so you have a security problem, and then you also have a maintenance problem. Because what happens when the certificates need to be renewed, what happens when you redeploy, and so on. In the pull model, you do things differently. So you generate all the private keys inside of the instance. And then you use a service like Surtmonger, for instance, to go to your CA and request, do a certificate request for your certificates. The trick there, though, is that once you're in this newly enrolled instance, you need an identity. You need something to be able to tell who you are that you are, in fact, this VM instead of some random schmuck. And so this is where being enrolled as an IPA client comes in. So the related questions there are basically, how do you issue certificates when you add new instances? How do you revoke those certificates when those instances go away? And so that you don't get calls at 2 AM on Christmas morning when your certificates expire. How do you get them automatically renewed so that you can keep things running? So all of this led to the NovaJoin project, which is a dynamic metadata service. So Nova has the ability to provide metadata to your instance as part of through a magic URL that's only accessible to that particular instance. And Nova also added the ability to get that data dynamically. So what Nova will do is it'll actually go and, as configured, it will go to a REST service somewhere and it will get the metadata that it needs and it will bring it back. NovaJoin basically has two parts to it. It has a REST service, which will provide that metadata and which primarily has the responsibility of enrolling something as an IPA client. And then secondly, there is a second server which will listen to notifications and wait for the delete notification for deleting the server or something like that and then will remove hosts from the IPA. So we have a basic toolbox. We have the NovaJoin service, which is, again, is a metadata service that talks to IPA and to Nova. We have cloud in it, which, as you know, is the first boot for a cloud instance and that's going to actually run a script that will go and get the metadata. Then we have free IPA and, of course, we have certmonger, which is a service on the system that is going to request the certificates. So let's see how all this ties together. So first of all, the user is going to create an instance with a flag IPA enroll equals true. Alternatively, it could use an image where in the image metadata we set IPA enroll equals true, one or the other. At that point, Nova is going to create the instance. And when the instance boots, then cloud in it is going to kick off and it's going to run a script that's going to install all the IPA client packages. And these are available on pretty much all the distros. So at that point, it's also going to go ahead and contact Nova to get the URL via that magic URL over there. So it's going to go ahead and get the metadata. Nova, at that point, is going to read all of its static metadata and it's going to contact any dynamic services that it's been configured to do so, which, in turn, triggers a REST call to the NovaJoin service on the REST side of things over here. And it's basically going to send a JSON with a bunch of UUIDs, the instance name. One of the other things that it could be inside there, for example, could be a list of services that it would like to be created with an IPA. So things like HTTPD or HA proxy or MySQL and so on. All of those services need to have certificates in order for them to be tailored as unable to begin with. So all of that gets sent over to the NovaJoin service, which NovaJoin will then check with Glance and make sure that the image actually exists, as you never know. It'll also check to see whether IPA enroll equals true, either in the Nova parameters that are passed in or in the image data. And if so, we'll proceed. We'll generate a one-time password and then we'll pass that to free IPA as part of a host add command. And at that point, this adds a host onto IPA with that OTP. Now at this point, the host is not actually yet, and it'll also create all the various services. Now the host is not yet actually enrolled. What we do have is we have an OTP and we have an entry there saying, at some point in the future, this host is gonna enroll with this OTP. This is the host that you have here. So at that point, the OTP and the host name are returned back to Nova and from there returned back to the instance where it is parsed by the cloud in its script, gets the OTP, enrolls the instance as an IPA client by calling IPA client install with that particular OTP. And at that point, you're essentially done. You have an enrolled IP instance. It has an identity. Because it has an identity, you can pull things down like a Kerberos key tab or something like that so you can use that for your authentication. And then you can go to certmonger and you can request certs for any of the services that you're interested in or for that particular host and so on. So you can imagine at this point, there's a lot of different things that can happen. Conceivably, you could be part of a host class that allows you to have certain kinds of access controls. So automatically, you have host-based access controls depending on what host class you're in. You can have centralized pseudo control. All of that is essentially already set up at this point and you're ready to go. So also, certmonger is set up to track your certificates so that at this point and when your certificates are about to expire, it will, using the same credentials that are there, the same key tabs and so on, go and request new certificates so that you're all set up to go. So your certificate problems are solved. Once again, when you delete an instance, Nova's going to delete the instance and it's gonna send out a notification that an instance has been deleted. That will be read by the NovaJoin Notify service on the message queue. And then we're gonna go ahead and delete that from, that will go ahead and delete that from free IPA. While it's deleting that from free IPA, it will remove any DNS entries that have been added there. It will clean up any services, revoke any certificates that have been issued and so on. So I'm getting the time thing. So this is my last slide over here. But basically there's a full version of this talk that was given by DevConf earlier. By Rob, you should take it out if you're interested. And this will be delivered as part of ROS12 as a mechanism for creating certificates and TLS-enabled services. And there's a quick start script if you wanna try it out. It's pretty cool. It actually will create an additional node which has an IPA server in there. So it's an all-in-one, fire off your undercloud, overcloud, IPA, and everything all works flawlessly. Any questions if we have any time? Yeah. Is there any open? Yeah, it's all open source. So NovaJoin is up there. Where is the, there's a GitHub thing. NovaJoin is up there. It's also all of the integration within triple O. All of that is up there and so on. So all of this is open source. The update procedure. Yeah, we're working on that. Right, right. So, well, I mean, so what are you updating? I guess it's the question. So, right, so with the update procedure, certmonger, which is running on the instance, is configured to track the certificates, right? So in the event that the certificates are about to expire, certmonger will automatically take the credentials that you have and will go and ask for another cert. It's not using one time. It's using the Kerber's credential, right? Because you're enrolled as an IPA client. So the one-time password is only to enroll. Yeah, it's only one time, right? You're enrolled and I am definitely getting the time signal over here. So if there are any other questions, I'll be around over here. So thank you very much.