 Hello everybody and welcome again to another OpenShift Commons briefing this time, like good friend Mark from Terminalo security is going to talk again about identity management, a problem that keeps popping up in the cloud native space and they've done some wonderful open source projects that help with this. We've done one previously you can look up on open unison, which I think is a bit of the talk today too. So I'm going to let Mark introduce the topic and we're going to do Q&A in the chat and then we'll open it up for live Q&A at the end. So with that Mark taking away. Thanks Diane. So, like Diane said, we're going to be talking about identity management and OpenShift and primarily we're going to be talking about how you manage identities inside of OpenShift. So we're going to talk about the challenges around identity management, why it's something important that you want to think about and then ultimately how OpenShift manages identity. So we hope that we're covering useful information here, even outside of our own project. And then finally, we're debuting a new identity management project specifically for OpenShift to be able to make this process easier. So real quick, who are we? We've been around for a little while. We're founded back in 2010, myself and my co-founder Brian and we're really built on experience. I started off as a software engineer at a company called OctetString. It's not owned by Oracle. If you're familiar at all with Oracle Virtual Directory. That was kind of my baby back at OctetString. And I've been an open source developer pretty much my entire career. Once I left full-time software engineering, I became a consultant and contractor. Brian had similar track. He comes from more of the classic, what we used to call threatened vulnerability management security, SAS 70 audits, PCI audits, TAC penetration testing. And so we came together and we said, you know, we can do this better between our 20 years of experience. And if you take a cross-section of vendors and industries, there's a pretty good chance one or both of us have done implementation with it. So what we learned out of that is we want small, lightweight, rapid deployments. Anybody who is familiar with cloud-native methodologies, that's going to sound really, really familiar. And then the other thing is we want to integrate a virtual directory. That's a big technical differentiator for us. We wanted to make it very easy to integrate multiple different types of data types because as we'll talk about here in a minute, the easier it is to integrate with systems, the faster you're going to be able to deploy. And then finally, this is an open source solution. We're an open source company. We write all of our code first in open source. There is a commercial version with a management UI and whatnot, but there is no piece of functionality that you're going to see today that is not available in our open source GitHub repos. So why is this important? What's good about identity management, especially when you combine it with DevOps? Well, this is my kind of math equation here where, you know, if you add DevOps and identity management, you get love from both your suits and your developers. And your suits can be executive management all the way down to users. You know, often the first thing people interact with is that login screen. If that login screen doesn't work, regardless of what's going on in the background, people say the system's not working. So even if there is a breakdown in the connection to AD or some other system that you don't own, that login screen, that's the first impression people get of your system. So that becomes really important. And then if users can't do what they want to do or what they're trying to do, it can often be because they don't have the right permissions. That becomes very difficult to manage, very frustrating as well. And then you've got your developers. You know, maybe it's just me. I just hate doing things manually. I hate manually adding users to groups and going into GUIs and clicking buttons if I can avoid it. And I suspect most developers are that way. And so the last thing developers really want to do is be in this process of having to manually add users to groups and respond to tickets. You know, I know with DevOps, we talk about, you know, this utopia of, you know, Dev and Ops coming together as one in harmony. A lot of times that actually ends up being an excuse by management to say, we're not going to buy multiple teams. So we're going to have our developers do everything. Your developers are expensive resources. The resources you want to keep happy as well because you want to keep them around made a lot of investment in them. So let's keep them from having to do things they really just don't want to do. So why is this so hard? I mean, you know, identity management is not new. This is not a new concept. You know, back from time sharing, I mean, whenever multiple people had to sit down at a computer, you had to figure out who was who. And so there are technical aspects. The things just need to be able to talk to each other, which isn't always that easy. I mean, it's 2017. And I still hear often people say, well, I want an API on top of LDAP, even though LDAP hasn't changed in 20 something years. You know, there'll never be an LDAP v4. So there are technology issues. But what really makes it hard is the non-technology aspect of it, especially when you're talking about enterprises. Enterprises are very siloed from an organizational standpoint. So here we have a chart where on the left we have a director. This director said, you know what, we're going with OpenShift. We're going cloud native. We're going to deploy this. Our apps are all going to work wonderfully. We're going to automate everything. That's great. Then you've got somebody else who owns your Windows infrastructure, which is typically where Active Directory sits. And that's your technical source of truth for most identity information. And then finally, you've got your CISO over there on the side who, even if you're not in a highly regulated environment, like I do a lot of work in the U.S. federal government, very highly regulated, you know, but even if you're just in a public company, Sarbanes-Oxley, there are different regulations, PCI, that you have to take track of. And a lot of those policies are written without actually having the technology thought of. Now, we could get into an entire, you know, long discussion about the difference between security and compliance. But one thing that's really important, especially as somebody who's trying to bring in a new technology to understand, is that compliance is often used as a weapon against you by people who don't want to change the status quo, whether they simply don't understand the value of what OpenShift or other new technologies are bringing, or they see it as a threat to the way that they operate. So it's important to understand that the policies in place need to be, if not followed to the letter of the law, at least know what might be used in discussion. And then from a security standpoint, this becomes very difficult because, all right, you're deploying OpenShift, and you could probably get a read-only account to Active Directory. That's usually pretty easy. But you need to store who has access to what and where. And we'll talk about the technical specifics of how OpenShift handles that particular use case in a moment. But for the sake of argument, let's say you say we're going to keep all of our users and groups inside of Active Directory. That seems to make sense. You own OpenShift. You don't own directory experts. And you don't want to get into the directory management game. So now the question becomes, okay, we need to be able to write into Active Directory. Well, Microsoft doesn't really have great access controls on Active Directory for those types of use cases. Not as flexible as what you would think of from maybe a more generic LDAP directory. And so that becomes very hard to do. The other issue is Active Directory. That's the keys of the kingdom. That goes down. People can't log into their workstations. Their MDM systems go down. Dogs and cats living together. It's mass hysteria. So it becomes really important to make sure that you understand that there is a reason why this is so well guarded. So trying to cross these boundaries can be really hard. And if you say, okay, we're going to go without crossing these boundaries, that now means we're managing our own directory. We're managing local users. Maybe we're doing things manually. And now you're opening the door for attack. It becomes a security issue. You might be compliant by the letter of the law. But if you have unmanaged accounts that can then be leveraged in a complex attack, you now are opening yourself up. So what does identity management look like without DevOps? Especially when we're talking about open shifts. So I'm a new user. I'm a new developer on the team. I need access to a project. So I sent somebody an email. That person then forwards it on to some poor hapless admin who is probably just sitting there waiting to get a task. Nothing else better to do. Saying, yep, Mark's approved. So the admin creates access. You know, maybe adds the user to a group in a directory and a database or a UI. It says a little prayer that they did it right. No wrong spaces, et cetera. And then stores the email someplace if they're well organized for a rainy day. And then tells the user, yep, you're on your way. Now this might be automated through a ticketing system somewhat. So it might not necessarily be the email shuffle. But still there are people involved, namely the admin, who have nothing to do with the business reason of why this user is requesting access to a project. And then, you know, every six months to a year, you might have to go through an audit, whether, you know, you're in the government, so you're talking about FISMA audits, you know, private sector, you go through your audits every single year. You got to talk about PCI, StarVance, Oxley, et cetera. The auditors come to town and they say, okay, tell us why all these people have access and when the last time somebody said they should have it. And you send them a bunch of emails. That makes auditors really, really unhappy. And I've been on both sides of that table and unhappy auditors are not your friend. So nobody really is happy at all of this. And, you know, if for some reason somebody made a mistake along the way, the user is not happy. The user complains to their boss. Boss complains to your boss. You have to sit through meetings where somebody asks these questions and it's just, nobody likes it. Nobody's happy with the state affairs. So what's our happy path? User logs into a portal, says give me access to the project. Project owner gets a message that says, hey, somebody's asking for access, please respond, approves it, tracks it, provisions it. And there's no admin anywhere in this process. It's all automated. It's all consistent. And at the end of the day, when the auditors come in, they're looking at reports. They're not bugging you for every single thing. So let's talk tech. That's my favorite part, right? I'm sure that's everyone else's too. How does OpenShift handle identity management? Now we're talking specifically about OpenShift itself, not necessarily the applications that run on OpenShift. They're all going to handle things a little bit differently. So I break out identity management into three separate categories. Who, what, why? Who are you? What can you do? And why can you do it? The who is typically encompassed two things. Data objects, some kind of data point that, you know, is how the application tracks you. And some kind of authentication mechanism. So in OpenShift, your user is stored as an object inside of SCD. Incidentally, if you're coming from the stock Kubernetes world, this is different than Kubernetes because Kubernetes does not track individual user objects. That's an OpenShift feature. Then it comes to authentication. And you have a lot of options with OpenShift. LDAP works really well out of the box, connected on up. Let's say that's your active directory. You just can authenticate right in. And OpenShift is going to suck that object right into SCD. So you don't really have to do a lot. Works really well. OpenID connect. That's my personal favorite. That gives you a layer of separation between your OpenShift deployment and what you're authenticating against. I like that because again, if we went back to our silos, it keeps you in control of what you can control. So from a management standpoint, by keeping everything inside of your silo, it keeps you in control of your own destiny. From a security standpoint, it lets you build more isolated networks. You can look at the Google Beyond Corp, and you trust nobody, right? That idea of creating an isolated network where you can't trust everybody that's talking to you. And then reverse proxy and header. It's useful. It's powerful. I'm not a huge fan of it. I've been doing identity management implementations for 20 years. And the reverse proxy plus header integration has always given me heartburn. It's a fairly easy integration, but the problem is you can't, it's not that you can't, it's hard to correctly lock down the connection between your reverse proxy and your application. It can also become difficult to debug issues when they happen with a reverse proxy. So I try to avoid this if I can. It's very easy to do wrong. It's very hard to do right. So that's the who. A lot of options. The what. So let's talk about how OpenShift defines a what and specifically what you have access to or your authorizations. It's a triangulation between your subject, which is who you are, a role which is defined inside of OpenShift with a set of permissions and a project, or if you're talking about a cluster, the cluster level. So those three things become a role binding. So you as the admin need to be able to supply the subject. Now the subject can be a user. It can also be a group. Personally, it doesn't matter the application. I hate manually adding users to permissions. Very hard to manage. I'd much rather have that layer in between of a group. So for me, typically I add the user to a group. I add the group and use the group as a subject in this instance. The objects are stored locally. Both the role binding and the groups are stored locally. Again, this is a little bit different than Kubernetes where Kubernetes doesn't actually store group information. You have to assert that. So that's an OpenShift feature. And then there are different ways you can manage those objects. The console gives you a nice UI to do it. There's an LDAP sync tool. So if you go back to our example, maybe you want to store everything inside of a directory. The issue that I've come across with LDAP sync is you have to run it for each group and you have to run it manually. It's a command line tool basically. So you could probably create a container that runs it, you know, maybe every hour or whatever it is. But if you think about an OpenShift deployment, you've got one project. And that one project has two, maybe three roles. Not a big deal. You have two projects. Now you have four, six roles, three projects. You're seeing a little linear progression here of how unmanageable that could be. And you still have to put the information inside the directory. So you still have the potential organizational issues where if that information is going to AD, how are you adding that info to AD? If you have to store it in your own directory, which directory admin do you have on your staff that's going to manage that? So that still leads to some other issues. You could use the OADM command or of course web services. Now of course API world, I like web services. That's what OpenUnison does. And then the final aspect is why. Why do I have the ability to manage this project? And OpenShift doesn't provide any capability for answering that question. You have to use some kind of external tool to do that. Whether you're doing things manually with a ticketing system like Remedy or ServiceNow, the email shuffle, you know, or something like OpenUnison, OpenShift has no answer for that particular question. So I'm going to go ahead and break out the presentation here for a second and introduce our OpenShift identity manager. So this is on GitHub and we have a link in the presentation. And what this is is this is a starting point that's meant to be a semi turnkey approach to be able to handle identity management for OpenShift. It lives inside of OpenShift. So it runs as a container. It's built on top of S2Y. So it is a J2E web app that you're able to just go in if you were to fork this repository. You could edit the configuration and we'll talk about some things that you can do with it after the demo. And what's great about it is you can use our source to image builder to then generate a lock down Tomcat container that you can deploy into OpenShift. And if you're using the OpenShift container platform, the downstream stuff on RHEL, you have a certified image inside of Red Hat's container store for this. So it's a really nice approach. Right now it's a little bit of a manual deploy but we do take you through step by step of generating your key stores, generating your different trusts, creating your service accounts, et cetera. I'm not going to walk through the whole thing. And then from a security standpoint, all of your information goes into a secret. So that secret file gets loaded. So that's why we publish this. You could edit this file, generate the key store and use this exactly as it is without any changes and still tailor it to your environment. So let's talk about the fun part, the demo. So the demo we're going to do for you today is running our OpenShift Identity Manager. We're running it on AWS on top of a RHEL instance and we're running inside of the container. So we actually wrote a deployment, which I'm going to have to deploy here in a second. And OpenShift is integrated for SSO and it's integrated for user management. So when we log into OpenUnison, which provides a very simple interface, we'll have a link that says, click here, log into the OpenShift console. And then from there, we can go ahead and use the link for a token to be able to log into the CLI if we wanted to. Now, the way that we're integrating that is with an Enterprise Active Directory Federation Services that's local inside of our data center. There's no connection here. We're not talking LDAP to AD. We're using ADFS for everything. So if we go back to our silos, we draw a line here. You own everything in here. You have full control. Draw a line here. The person who owns AD owns that. They have full control. We're using Aurora DB because we wanted to just get something up and running quickly. And the nice thing about this is we're storing audit data, but we're also storing role information. So the nice thing is, is that you don't have to store anything external to what you as the OpenShift admin controls. And we're able to bridge the authentication from OpenShift into AD using ADFS. So everything runs through the user's browser. There's no need for firewall rules or anything like that. So it keeps it nice and clean. So I'm going to go ahead and fire up that deployment. There is a issue in my cluster where for some reason after 10 minutes, the pod gets destroyed. And I haven't quite figured out the issue with it yet. But it looks like we are back up and running. Mark, we're looking at your slides and not at your home. Oh yeah, no, I'm actually, I had to deploy this off of the other box. So I am now switching. Okay, cool. All right, so let's go ahead and let's log into here. Now you'll see I'm already logged in as a user, J.Solo. I'm a big Star Wars nut. So I tend to use a lot of Star Wars names. If you are as big of a Star Wars nut as I am, you will notice some of these names as well. So I'm going to go ahead and log out so you can actually see the login process. Now what you didn't see is I'm also logged out of ADFS. That all happened really quickly. So let's go ahead and log in. And you can see I'm bounced over here to ADFS. And this is ScaleJS. This is a AngularJS application. It's hosted inside of Unison. All of this is open Unison. All of this is driven by the open Unison configuration. So which badges you see, what roles you see, et cetera. Now this user J.Solo doesn't have access to anything right now. I'm just a standard user inside of open Unison. So I don't even have any roles inside of OpenShift right now. So when we're talking about requesting access inside of OpenShift, one of the things that often comes up is new project creation. There is a button inside of OpenShift. If I click on the OpenShift console, and you can see I'm SSO'd in. There's J.Solo. I can click this create project button. You can see that you're in a managed environment. You probably don't want that to happen without some kind of approval process. So, and even OpenShift has a real straight forward, you know, this is how you delete that button. A lot of different ways that you can go ahead and create a project. I've seen a lot of people do roll your own, especially with customer facing systems. I've also seen an enterprise, folks using Jenkins working with the web services. OpenUnison actually provides a real interesting capability here where if I want to create a project, I can do so via a workflow because we're directly integrated with OpenShift. So what I go ahead and I say create OpenShift project, if you think about what are the things that you need when you create a project. You need to create the project, right? That's obvious. But then you need to create group bindings into roles. So here we've got an editor role and a viewer role. And then you need to figure out how do you approve access for that? You know, if we're going to automate this, do you need to create an approval role? Now that you're not going to put inside of OpenShift. That you're going to create inside of the OpenUnison database. And then finally, you need somebody to be able to approve it. So we're going to say that whoever requested the project will be that first approver. So I'm going to go ahead and create a project called Jason's project for common demos. So I've submitted this request. Now the nice thing about having a workflow based solution is I can go in and see, hey, I've got this open request and this guy named Matt Mosley is sitting on it. I don't know why. And, you know, these reports are all customizable. We ship inside of OpenUnison kind of a standard set of reports. The other nice thing is if you've got a nice business intelligence solution, maybe you're using Jasper, Red Hat Reporting or whatnot. Pentaho, I know is another popular one. Our data model is completely documented. It's very standard schema. So you can actually drop it into a much more powerful reporting tool than what we have here. You're not bound to our reports. So I'm going to go ahead and log out. And I'm going to log in as Matt. So I'm now logged in and you can see I have this open approval. And, you know, by the way, you know, if you're an assist admin sitting in the data center and you have to do this stuff, it's all responsive. So I'm going to go ahead and respond to this request. All this information is customizable. I'm going to approve the request. So at this point, Jason's received an email saying, hey, go ahead and log into your project. The project's created. And as an auditor and assist admin, I can now go ahead in and let's see the single user change log. And you'll see that associated with this user is the, oh, sorry, it's actually not associated with this user. Let's go to the change log for period. This should give it to me. Yep. And so we can actually scroll down here and see that we created a, we created some projects that allow us to be able to do some work. I'm actually a little curious why I'm not seeing this. So hopefully this project got created properly. So I'm going to log in as J solo. Hmm. All right. Maybe I have some data validers. Let's do this one more time very, very quickly. This is the beauty of live demos. Exactly. Okay. Some projects. I can go over here. Go away. Go away and go away. Yeah. Let's go to my pod and let's see if there was a error in the deployment. Actually don't see any errors. So let's keep an eye on that. All right. So that was submitted. Let's log out. Log back in. An open approval. And, oh wait, no, there it is. Just took a minute. So one of the nice things about open unison is that it is it gives you the ability to run both symmetric synchronous and asynchronous workflows. So the asynchronous workflows don't always run quite as quick as we expect them to. 2k12. To. Still not there. All right. So I'm going to log in as a different user where I've already had that project. Because I look here and I'm an editor for Jason's project. I'm an approver for Jason's project. The. Oops. All right. So I'm going to go ahead and log in as a user that already has a project. So Jason's dad, Han. I tested with the earlier today already has a project. So if I go into the console, I might have to log out. Yep. Because there's not single log out with open shift. Log out. My login is Han Solo. No, I'm not. Solo at 2k12.domain.com. Now I'm logged in as Han Solo. You can see Han has his own project. And so that project was requested through the same process you just saw. So I'm going to go ahead and log out. And I'm going to log back in as Jason this time. And I'm going to request access. Now when I say I want to be a project administrator and I click on this link, what's actually happening is. Open Unison is talking directly to open shift. So when we do add a new project, it gets added here to the list like you see this H Solo project. So the workflows are dynamic. They're driven directly off of open shift. So you don't need to create a new workflow every time you create a new project. All right. If the gods abandoned me. This cluster does not like me very much. One moment. It's gone over to the dark side. Yeah, it really has. I seem to have a 10 minute limit. And then open shift decides to kill my. Decides to kill off the pod. So there's clearly an issue in the way to find my deployment. So I'm just going to drop it, recreate it. This is how you know we're live. Yeah. My apologies, everyone. Is it something in the configuration? I'm pretty sure it's in the way that I have the open shift. Deployment YAML setup. So now we can see that it's back up and running. The pod is up. And the logs are going. All right. So let's try this again. And if you're watching this and it's the recording, you know, this is just three times. You're going to learn all the commands while. Solo request. Commons briefing. Submit log out. Now let's log in. It's on solo. So there you can see I've got a request. I'm going to review it. And just to show that everything is going. I've got the log there. I want that open. May. Windows. Windows do I have open? All right. Okay. There we go. So let's go ahead and. Commons. So now we can see that it has. Hopefully run. I don't see any errors. That's a good sign. Let's log out. Look back in as Jay solo. I look here you can see I'm an editor now on the Han Solo project. And let's hope that it's inside of open shift. Yeah, there I am. Jason solo. I'm now in the Han Solo project. So the application onboarding for Jason's project, something seemed to have gone wrong. Maybe need some more data validation. But now here's the important part of identity management. I'm now in I can do my work. What happens when I leave. I'm going to log out. Jason in the books did in fact go to the dark side. Han does not want him in his open shift project anymore. So I'm going to log out. And there are a lot of different ways you can automate this. Automating deprovisioning. Can be very tricky because it's a lot harder to prove. When something negative should happen as opposed to when. Something positive should happen. So, you know, you don't always get a request. So often, so you can base this off of. Changing a project changing a role at a business level. I'm generally not a huge fan of role based access control at the business level, but sometimes it'll work out. In this instance, Han got an email. Hey, your kid just went to the dark side. So he's going to request access to remove him as an administrator. So he's going to add it to his cart as if he's requesting it for himself. And he's going to check off this little request for someone else. So we're going to do J solo at and 2k 12 domain. Actually, no, I think just J solo. And we're going to attempt to pre approval. Denied. So what's happening here is we're saying, all right, we're going to request this for someone else. And since I know I can approve this, I'm going to pre approve it. So this will short circuit the whole I'm going to get an email that I'm going to click on the approval step. This does it all at once. This will not bypass any security controls in place. So if I am not the actual approver, the approval will fail because access will be denied. It's recorded that Han made the request and attempted the approval and failed. And also it will go to the actual approver. So everything's logged audited. So I'm going to try to control who gets these options. By implementing a couple of simple Java classes. So I'm going to go ahead and say submit the request. And at this point, if I go to the reports. Let's go to approvals completed by me. And you will see that here is a rejection went to the dark side. This is a previous request. And if everything went the way I wanted it to. Let's take a quick look at this. There are no errors there aren't. So let's go ahead and log into OpenShift console. I should no longer have that project, which I don't. And it's all auditable. So we went through that whole life cycle there of showing you capabilities. There are onboarding users, offboarding users, creating projects. If you want to see the project creation live, check out our website. We've got a demo video of what we did. So we saw that whole life cycle. What else can I do with this? Let me go back to the presentation. So multi-factor, that's always a question. So lots of different authentication ideas that you can do. You can also layer authentication. So right now, for instance, I've got a customer that is using PIV, smart cards, but doesn't get enough information out of that. So we're wearing together smart cards and SAML to be able to build a user profile. And then you can also add on additional identity sources. So let's say you want to be able to onboard partners. You can just add them as another connection. So different options there. You have much more complex workflows. I mean, these are very simplified workflows. But one of the things that we demoed at Red Hat Summit was the ability to do privileged access. So let's say you didn't even want somebody to be able to get into open unison unless they had some kind of approval. You can intercept that request and force them to ask for access first. And then recertification, automated deprovision. So let's say for the sake of argument that you have an app that is a little more sensitive and you want to make sure that users that are admins have to get re-approved every six months, nine months, a year, whatever. Using the integrated scheduler, you can kick off a workflow. Once that workflow is kicked off, if the user gets denied access, they get deprovisioned. So it helps you automate that process. I've got another customer that, if a user doesn't log in because they're disconnected, it's a disconnected cloud. I think it's like six months. They want one of these recertification workflows to kick off that says, make sure you still need this because if you don't, I'm deleting your account in 30 days. So lots of different options. All you got to do is fork that code base and you can start tinkering with it. And then of course there's the rest of the stack. OpenShift runs on top of an OS. That OS has to be locked down. So same for the sake of argument using Red Hat Linux. We integrate very well with Red Hat Identity Management, aka Free IPA. And we have a similar to the OpenShift Identity Manager. We have a Free IPA Identity Manager where it gives you that same type of UI, registration, password, reset, self-service, et cetera. And then OpenStack, we don't have the nice package like we do for OpenShift and Free IPA. But we have all the integration in there to integrate with Keystone. So the same way with OpenShift, you're able to dynamically request access to projects. We can do the same thing in OpenStack with projects or tenants, pick how you want to call them. And then obviously applications need their own Identity Management. So it's pretty easy to stand up OpenUnison, either use the same one with different workflows or stand up another one because it's so small and lightweight specifically for your apps if you want to have a little bit of separation. So what's next? Here's the link to the pre-release, I guess I'll call it, of the OpenShift Identity Manager. It's still in beta. As you can see, it's got a couple of kinks that we're still working out. But we're hoping to do a final release here in the next few weeks. So anybody who is interested, please open an issue, provide feedback, stuff that you want to see. Don't be shy. It's open source. We'd love to hear from folks. You can find us on the web. Apparently everybody's got a website these days. And we got a bunch of different demo videos. It was about a 10 minute video that takes you through a very similar provisioning process, except with the commercial product, also adding in U2F and privileged access. And we're on the Twitter. The corporate account, Tremolo Security. And then my personal account, MLBIM, I love talking to people, love 142 character discussions. So I've had discussions about Python and IDEs in the last couple of days. So come one, come all, love to interact with folks. And with that, I guess I'll open it up. Do we have any questions? We don't have any questions right at the moment, but you mentioned something at the, before we started recording earlier, that you were also going to release an identity manager for Kubernetes. That's right, that's right. And, you know, in OpenShift being, you know, sort of a, I kind of describe it as a value added distribution of Kubernetes. I'm wondering what, how different those are, those two offerings are going to be here and if you're coming to KubeCon in December of this year, I'm hoping we can coerce you into maybe doing a session in one of the dev rooms that they're going to have on identity management too. I think that would be really good because I think lots of people are still working on, you know, what the best approach to identity management is for OpenShift and Kubernetes. I have not made my plans yet for KubeCon. It most likely will be there and I am definitely interested in doing one of those dev sessions. So that's the easy one. So the great question on the difference between Kubernetes and OpenShift, and I could probably fill up an entire briefing just on that when it comes to identity management, but the key differences, OpenShift stores identities and groups internally, whereas Kubernetes doesn't. You have to assert it somehow. So whereas in OpenShift, we actually provision the identities directly into OpenShift using the APIs. The Kubernetes identity manager will assert everything via OpenID Connect. So when you sign into OpenID Connect, we're not going to provision your accounts directly into Kubernetes. We're going to include it in the claim that we give Kubernetes. So instead of adding you to the OpenShift group of Han Solo app project admins, we'll still define the policy bindings for you in Kubernetes RBAC, but we'll assert it in the OpenID Connect provider. So we'll store everything inside of the OpenUnison role database. Now, what is interesting, and I've got to do a little more research, I see that the latest alpha of origin supports everything's now built on top of Kubernetes RBAC, and it looks like some of that same thing might be there. So it might actually make for a little smoother integration. So from a functional standpoint from what the user sees, the exact same process. You'll be able to find a workflow that creates a project, creates the correct approval groups, adds users, removes them, et cetera. Yeah, so it'll be interesting to watch the evolution of the two different identity management, because I think they're not really that different and as OpenShift just is always about one release cycle behind because we're doing that, but the RBAC stuff is all coming in the next round of OpenShift origin, so you should see it very, very, very soon. Yeah, and it's worth noting that most of the Kubernetes stuff was actually lifted from OpenShift and put into Kubernetes. So it's kind of a, it's an interesting, secular relationship. Yes, it is. We really are trying to push a lot of the OpenShift functionalities into and make it available in Kubernetes. And, you know, it's just nice. More people will be maintaining it and it'll get wider use, so it should be, some of it rightfully should be in Kubernetes and not in the OpenShift origin project. So it's all working out very cyclical on some of this work. So, well, I don't see any more questions in the list of participants in the chat. So I think we've done a pretty good job. You want to put up that last screen of yours again? Absolutely. So that people can find you again. And as he said, this project isn't beta. It's launching really soon. So your feedback on their issues page, if there's questions you have, please reach out to Mark and the OpenUnison folks in the general and give them your feedback sooner than later. Awesome. And thank you very much, Diane, for the chance to talk. All right. You guys take care and hopefully we can get you to KubeCon into Austin. All right. Take care. Bye.