 Hello and welcome everybody to this OpenShift Commons briefing this week in November 5th. We have Sid Chetay from Crypterum who is going to be giving us a presentation on securing your Java applications on OpenShift 3. It should be a very interesting talk. This conversation is new to me. I often don't think enough about securing my applications. So when Crypterum joined the OpenShift Commons recently, I started taking a look at their service and I thought it was something that would be a really good topic for us all to dive into and get some more background on. So Sid, I'll let you do introductions and get started and then after about 30 minutes or so we'll have some Q&A. You can use the chat room to ask questions. There's a couple other folks from Crypterum on who will try and answer questions for you. And if you have any left over, we'll do them in the Q&A and then open it up for a conversation about securing your apps on OpenShift 3. So take it away, Sid. Thanks, Diane. Hi everyone and good morning. Good afternoon, good evening, wherever you might be and whenever you're watching this session. So we're talking about something really exciting today. We're talking about how you can secure your applications on OpenShift. And today our focus is going to be on Java applications specifically. So there's a quick, the kinds of technologies you're going to be seeing. It's going to be Java. It's going to be on OpenShift and bulk of the data security is going to be from the front technology. So those are the three logos you'll see. Customary, always to talk a little bit about the speakers. As much as I don't like talking about myself, this is my bio that you can see. I've been in the security space for over 12 years. Primarily a developer at heart, worked at Qualcomm many, many years back and had the good fortune of designing their encryption algorithms and secure boot loaders and it's now in over six billion devices. So it's actually at this point the world's largest deployment of secure boot on the planet. Also have, you know, open startups as well as large companies. And, you know, Windows School right over here in Southern California at USC as well as UCSD for business and engineering. I will let Wolfgang speak quickly about himself. So yeah, I should first of all apologize that I'm feeling not the greatest this morning. So my voice is a little bit on the low side. But I actually want to have an experience mostly on the Java side. Enterprise development worked a lot in the DoD space. Know a lot of how they like to approach security from their enterprise perspective. Great. So, you know, quick question. How many of you have heard of data breaches? And I know we're not doing this live. So we're not going to be able to like do a show of hands. But in this day and age when I do this live in person, pretty much everyone in the conference room has their hands up was definitely a different scene over a year back when you had a few data breaches sprinkled over the course of a year you'd hear for a few. But right now it's almost like every single week there's a new company getting hacked. There's a new business which is going down and under because their data was compromised. And if you're in a regulated industry or a regulated business, the data breach also means heavy penalties and we kind of see what we're talking about. The Sony that was hacked. There was a federal government that was hacked. Accounts, Uber accounts were hacked and then being sold on the dark net. NASDAQ was also hacked. JP Morgan, pretty much anyone and everyone has been hacked. So you should be taking data security kind of seriously. Data breaches are also extremely expensive. This isn't just a question of, hey, one thing, our data base server was hacked and we've lost XYZ number of customers. You've also lost a substantial amount of enterprise value. You can kind of see, depending on which kind of industry you're in, whether it's healthcare, finance, those are the industries where a data breach is extremely expensive. And you can see in healthcare, it's roughly $230 for every data breach incident that you have. So it's almost like every row in your database is going to cost you $230. If you have 1,000 people, that's a quarter million dollars that you've lost. Same thing in finance, but even if you go down that list, even in something as mundane as retail, these costs are pretty substantial. We're talking about almost 80 bucks. You multiply that by the number of customers you might have. So if you're a target, this was big bad news for you. If you look at it in terms of data breach over the last five years, rather than the absolute values, these are the averages. What you're saying, what is important is it's growing year over year. So 2014 was when this data was captured, we're kind of close to 2015. So it's obviously going to be a lot more expensive on an average. Now, data breaches are also expensive, not just looking at a poor record that is lost, but on a poor incident basis. So if you look at it on a poor incident basis, the place where it hits us the most is right over here in the US, where on an average, a single data breach is going to cost you $5.5 million. And in this day and age, it's not a question of if you're going to have a data breach. It's mostly a question of when you're going to have a data breach and whether your organization will be aware and will be in a position to be on top of it. I love this slide because it's great as a developer when you're asking me for resources, you're asking me for tools, you're asking me for deployments. A lot of times you get hit hard by saying, well, what is the budget? Like, why should we give you a budget more than what you already have? And this is hard concrete evidence, not on one organization, not on 10 organizations. This is for the entire world, all the different organizations, all the different data breaches that have happened. And that's kind of what you see. You might have more than $5.5 million, or rarely even less. And this is another sea of change. Traditionally, this was a technology issue. You have a data breach, chances are the developer might be fired, or maybe the VP of engineering might be called in and might be disciplined to some extent. That's no longer the case. In 2015, for the very first time ever, the CEO and the chairman of a Fortune 500 company got fired. So this is no longer just a tech issue. Everyone is seeing this. It's not just developers, architects, or even CISOs. So this is another thing that you should be aware of when you're thinking about your architectural planning, your deployment, how much you want to spend, what kind of tools you need. When you go to your boss in Italian, you should say, well, this isn't just an issue which is for the engineering group. This is going to impact the overall business. So that is something which is definitely different in 2015. The security space, there's a lot of different players. And it's mostly bimodal. There's a lot of solutions which are secure. But they require a lot of effort from the developer to put things together. So there's a lot of custom code. There's a lot of code review that goes in just so you can interface with a bunch of these different devices or services. And then you have a couple of ones which are really easy, but they're not entirely secure. Like in a SQL transparent data encryption, no matter which vendor or which technology you pick it from, is mostly designed when you were concerned about somebody coming in picking up the hard drive and running away. So you'd encrypt the file of that particular database. And unless you're Tom Cruise, no one's going to hack into a data center and steal hard drives and run away. So it's kind of, the security model doesn't match the threat vectors against it. So there was an article from Computer World which kind of hits this matter really well, which is developers, whether you're a Java developer, whether you're a Scala developer, no matter what kind of a developer you are, the key thing is software developers aren't implementing encryption correctly. You might throw an AES over there, but what about the keys? There's, we're going to be sending these slides out later. So you can read this article when you have, it's a long article, but it's a really good one. It kind of goes through all the different pitfalls, application developers go through when they're building data center applications. And essentially developers are adding a lot of cryptography to their code, especially when you look at finance or healthcare. But the thing is, not everyone is a security expert. You wouldn't go to your general practitioner and ask him to do grain surgery on you. You would go to someone who specializes in that. But in the world of software development, we still haven't followed that as the kind of practices that we have to do. And this just makes security really difficult. And don't take my word for it. In the largest data hack today, with the OPM, the Office of Personal Management, with the federal government, this is 20 million people affected. Wolfgang was affected being in the DOD space before. There were a lot of people, I was affected by data breaches. This is affecting the common people. It's affecting it in a way that is not really easy to control. And when she was testifying against Congress, the head of that particular agency, one of the key things she mentioned was it's not easy. And this is a federal government with a lot of security experts as well as a lot of backing. And even then, with the processes they have to go through, someone makes a mistake somewhere and the overall system doesn't work as expected. It's kind of illustrated by this. I kind of like this visual. This is what it is to build a secure application. You make any mistake and you basically fall down and it's certain debt for you as an individual developer or as an organization within which you're working. And so essentially you need a good platform as a service which takes you from this and makes it into something like this. We like the thing we give our developers superpowers. So essentially there needs to be a large simplification. So that was kind of the whole backdrop about why security is different in 2015. What are the chief problems with it? It's really complicated. It's too complex. And let's take a look at what we're going to be covering today. So security in the cloud when you're talking about a data center application is essentially you have something that is unique to your business which is your application logic that's kind of in the middle. And so I like to think of this as a sandwich model. You have front end security where your users access your application through a bunch of different devices. And then you also have back end security. And both those pieces of security are really important but they're kind of boring but they're still really important to implement. And so today's focus is going to be mostly on how your application logic we're going to be looking at Java on OpenShift and how its back end security is going to be when these things are put together. Now I'm pretty sure everyone on this call knows Red Hat and a lot of them have heard about OpenShift. I'm not sure how many people might have heard about Cryptron. So I think to do justice to the audience over here I think it makes sense to give a quick introduction on who Cryptron is. So Cryptron is basically a developer friendly platform for securing applications in the cloud whether it's public, private or hybrid it doesn't really matter. And Cryptron is proud of its partnerships with supporting Red Hat on OpenShift. We also have for .NET developers who prefer who have been working on Azure. We also support a lot of these other cloud platforms. I do want to say you should watch out for there was an announcement yesterday super excited about that. You can now run OpenShift on Azure VMs as well as AWS VMs. The underlying infrastructure could be any card provider but the platform as a service component by Red Hat OpenShift is incredible so you can use it anyway. Back to who we are, Cryptron is we essentially bring resilience to data breaches, save over a year of development time. We get rid of risky code. Risky code which is that custom code that people write thousands of lines of code just to be able to interface with a bunch of different key managers and you have access controls all of that stuff. That is not adding any value so you get rid of it. And you make compliance in the cloud possible. We're targeting developers, software architects, CTOs, CISOs. As a platform as a service this comes as no surprise. So we're going to quickly dive deep we're going to be focused on Java for today's session. We also support Scala as well as .NET. And essentially the seven characters that you see at secure it's actually that simple. When we're going to jump into code, when we're going to be doing deployment you'll see this in greater detail. But if there's one thing you remember from today's entire session it's got to be this at secure. Just remember this that's going to be your savior. We're going to show you this is just a screenshot of it in C sharp. Since we're not going to do a C sharp D dive we just thought we'd give you one screenshot. And essentially we're going to take this where if you deploy something in the cloud you have to trust your app, your network, your blob storage, your database servers, your database admins. And your circle of trust just keeps expanding and expanding. This is unsustainable in the cloud. So essentially what we do is we take an application architecture which looks like this where you have to trust a lot of different systems and we convert it to something much smaller and something tighter that you can control. So when you do something like this and you deploy to open shift the kind of results that you see are essentially you get compliance in the cloud where they're doing HIPAA compliance. They're doing PCI compliance. You have credit card processing or other kinds of data that flow through your system or sieges compliance which is actually an FBI standard which is way above any of these two. That's something that you can do within minutes. And as a developer myself I love platform as a service. There's a reason we love open shift and there's a reason we ourselves run a platform as a service and because as developers it just saves us time. If you're a freelancer this means you can make more money because you can get projects done faster and move to the next one. Platform as a service also promotes DevOps where essentially the developers are the center point, the focal point of everything. And the other reason we love platform as a service, we love open shift is because you don't have to reinvent the wheel. There's a lot of things that is taken care of and you can focus on the things that make your application unique. If you stick around we're also going to talk about CloudMedic which is an open sourced healthcare back end that is already on GitHub. We're going to make a formal release at the end of December so you guys are getting a sneak peek at it. So if anyone over here is developing applications in healthcare, we're open sourcing a fully compliant healthcare back end app for you and you can deploy this wherever you want and if you make changes to the code we'll be more than happy to plug them back in. So it's time for a demo. So I'm going to let Wolfgang come in and drive that. I do want to, before I switch gears and hand over this to Wolfgang, we do have a special for all Red Hat developers. We're going to talk about the special at the end of this. So Wolfgang, go for it. Sure. So Wolfgang, can you make the text on your terminal a little larger? I believe so. There, that I can read. Okay, good. And then how about the browser here that has the OpenShift Origin running? So we have here an instance of OpenShift 3 which is actually in this case running locally. We did not deploy this to the Azure Cloud option that Sid mentioned before but using a vagrant script or vagrant file I should say, this was very easy to spin up. You can go to openshift.org slash vm and you can get the instructions for how to use yourself. Okay, so first step here is I'm going to create a new project for holding all the contents of this demo and call this security showcase. So in this case, I'm not going to be using one of the pre-built images or templates. I'm going to be deploying my own application. In fact, it's going to have a set of data that I want to protect with the security framework that Kepron provides. So to kick off that process, I'm going to be using a command line tools. Specifically, it's going to be the O.C., sorry, name of the command provided by OpenShift for this. So I'm going to start by logging in. Okay, so it shows that I have my project here. So I'll choose that. All right, and now I'm going to enter the command for creating a new application here. So I'm just going to go over this a little bit piece by piece here. We're creating a new app. We're going to be basing this off of the latest wildfire, the community edition of JVOS here. We're going to combine that image with a public GitHub repo that we have for the simplification. And we're going to pass one environment variable, which is going to be the app secret used for securing our application. So to get that, I'm going to now log into our portal. I'm going to start off by creating a new application. So we have several options available here. I'm going to be starting with the developer plan for putting this project together, but we have other options available as you scale up. So now that I've created my application, you'll see I have some options available to me. I have some default data for security partition that's been populated for me. If you look at that, we also have the ability to establish access control lists based on roles. We can do key rollovers here, provide fine-grained control security. Sid, did you want to mention any of the other features we have available here? No, not really. I mean, you know, what Wolfgang is kind of showing you is a lot of different features that you can see on the Criptrond dashboard. You know, when you guys make, you know, it's free to join, so I would encourage anyone to just make an account and try out different things. There's a lot of advanced features that we allow you to express, but the important thing is everything over here just works right up the box, which is something that you'll kind of see as we go ahead with this. Right. So the important thing for what I'm doing in the demo here is looking at the app secret that I need to copy into my application so we can establish secure communication with our server. So now that I put that in, I'm going to kick off this new app command and switch back to here. You'll see that that basically started a new build process of the application. So to see the progress of that, so OpenShift deploys all their images to pods. Which I can get the name of here, copy that guy, and I'm going to look at the log. So what you see here is this is a Maven project we have here. It's performing the Maven build right now. It's going out to public repos to pull down all the dependencies, which actually includes the security framework for Criptrond itself. It's also published publicly in Maven. You can add that with just a few lines of configuration in your POM file. And so for this application, by the way, we're using very standard Jaxrs back end to provide the REST API. The implementation in this case is Jersey. And we're using AngularJS with Bootstrap for the front end of this web application. Got it. Now this process usually is kind of variable. It can take two minutes. Sometimes it takes longer than two minutes. So do you want to switch and continue with something else? So perhaps there's one question that's popping up right now, and Randy Burgess has asked for fine-grained authorization. Is XACML available? No. The way it's configured right now is we can actually jump back and show what's going on over here. So we actually don't support XACL right now, but what we do support is, you know, since I guess we have a few minutes over here, when you log on to your crypto dashboard, you can have a bunch of different applications. So, you know, if you're a development house and you're building one application for a hospital, another application for, I don't know, marketing agency, you'd have a bunch of them right over here. Let's assume this is your hospital. You'd go inside this and you can now have, you know, a few different security partitions. Our concept of security partitions is where you can have completely isolated data silos. So you might, you know, for a hospital, you might have one security partition for patient data. You might have another security partition for billing data. And so you can build out those security partitions. And the cool thing with fine-grained control is within a security partition, like let's go into the default one, you can have ACLs. And, you know, you can kind of change what kind of ACLs you want. You can add another entry and you can say, you know, only doctors might be able to do encrypt and decrypt. And you can have a bunch of different roles that you can configure and, you know, express your policy for that particular data silo right over here. But in terms of, you know, the format, right now it's only based on, you know, the UI that we have over here. And this UI is mostly designed for, you know, security officers. And so you could have, you know, your security officers have access to the dashboard, but your development team will have access to the source code. And so you still have some separation of concerns. So it looks like the bill process is finished now. All right, well, let's switch places. Okay, sure thing. So what it did was it actually built the web archive, the war file, and then it published, it combined that with the existing image we already had for the Jboss server, pushed that to my local Docker repo. And now it actually has spun up a new pod running that server instance. So I copy the name of this guy and I now look at the logs on him. You'll see here we have some pretty standard Jboss starting up messages. You'll notice that we're using Hibernate in this case for the data persistence. And actually for the data underlying it, we're using an on disk in Java implementation, which is called H2. I'm not sure if any of the developers are familiar with it, but it's a great tool for developing and bootstrapping some simple applications. And I'll be showing how we inspect the data inside of that a little bit later on. But the server has started up successfully. And so now to get access to the application, the next step is to expose it from outside of OpenShift itself. In this case, so in this case, I tell it to expose the service for security showcase, which has been deployed. I'm giving it a fake host name in this case. We don't have it publicly hosted on the internet, so I'm not going to be able to set up a DNS entry for it. It's going to have to set the host manually to get access. So now that that's been set, we're going to add a header here for host with that value, refresh the page, and then you'll see it'll connect to the server and it'll load the front end for our application. Yeah, and just to give you guys a quick background, because depending on the kind of OpenShift developer, you might have different levels of experience. But OpenShift internally, we'll be looking for this in the HTTP header as the host name. And this is obviously, we didn't go in and we didn't change DNS. So as a way of faking that, our browser is just going to put that inside the HTTP request it makes. Even though the server is actually just locally on our machine. And this is one of the techniques that's brought up in the, there's a white paper actually on the OpenShift.org slash VM for setting up your environment. So yeah, this will be one of the steps they recommend for getting started. So in this case, you'll see pretty standard bootstrap looking app. I have two tabs here for two different tables, actually is what this is implemented as in the database for insecure versus secure patients. In fact, if you want, I can go ahead and show you the the Java code for how we have that implemented. Might as well. This guy up here. Pretty standard layout of the project. You'll see there's a patient controller and insecure patient controller. These two are very similar with the only real difference here of one has the path of patients. Is there a way you can bump up the font size? Oh, not easily. Try and control it. Let's try this. You don't think Clip's the answer actually. There's preferences are kind of varied for the fonts. Okay. All right. Well, yeah, sorry. Yeah, the only the only real key you need to see from here though is that there are two different arrest endpoints. So one has insecure patients and the other has just the regular patients. If you look at the model, and so each of them work with the patient versus the insecure patient object, which if you look at those guys, you'll see the secure has these annotations that Sid had mentioned earlier on the slide. These characters tell us that we need to intercept the data, encrypt it on the way out, and decrypt it on the way back in from the database. Yeah. And all the key matters when API is completely handled for you. Right. And so I think what Wolfgang, you know, the key point is if you look at the actual data, you know, data bearing class, the DTO itself, they're almost identical with the only difference being, you know, the secure annotation that you have right here. That's the key to take away from this, is just adding that annotation is what's going to produce the differences we'll see in their behavior. Okay, let's go back to the front end now. I'm going to go ahead and add a patient here, rather, to the insecure side. And so now that I've added data into the database for this patient, I'm going to show how we can take a look at the contents of that. So in this case, I'm actually going to be connecting, to accomplish that, I'm actually going to be connecting to the VM. This is running in a virtual box VM that's running OpenShift itself. It's using vagrant to spin that up. So I'm going to SSH in. Okay, now that I'm connected, I'm going to run a command. So each of these containers is run using Docker. So what I'm going to do, it's a little bit of a trick, is I'm going to find the last created Docker container, copy from outside of that container, inside the app route, which is where all the files were deployed. There's a target folder, which is where the database files actually live. I'm going to copy that to a folder on the VM that's shared with my host, and that's vagrant in this case. So now that I've run the copy, I'm actually going to run... So H2's jar provides this pretty nifty web console that you can use for connecting, viewing data, and even modifying data if you so choose. So I'm going to connect to OpenShift 3 was where I was running that vagrant out of. And then there's a copy of the target, and DB1 is the name of the database in this case. And we do want to say that obviously this works with any kind of database you might have. Postgres, Mariah, MySQL, SQL Server, Oracle, whichever database technology you want. The only reason we've picked H2 is just because it is developer friendly. It's easy to do demos. It's easy to just throw it up on GitHub. Maybe in a future instance, we could do any specific database technologies if you want. Essentially, the rest of the demo is pretty much the same. So now that I've connected, you'll see I have the two tables that I mentioned before, insecure patient and patient. I'll take a look at the rows inside of insecure patient. So you'll see there's the record I created here. Kind of troubling. The name is out in the clear, but way more troubling is the fact that we have the social security number is stored completely in plain text. Someone who were able to walk away with this database or there were SQL injection against the application that would spit out the value. That would not be nice. That would be very bad. So we're going to completely circumvent that. So let me just show you that we have this patient table here. It currently has no records, but you'll see the columns are all exactly the same and that's because they're all named the same when it created the schema on startup. So I'm going to go ahead and exit out of this. I'm going to go back. Now I'm going to switch to secure. So I'm going to trust the data. I'm going to go ahead and, sorry, put in something slightly more realistic here. That is your real assistant, right? Yeah, I'm just not lucky. It's a screen check. Maybe you can throw in one or two more. Okay, sure. What else do you want to throw in? I don't know. Let's say John Doe. What's his social security? Oh, he's very nice. Yeah. So we have a couple of, you know, patients right over here. Sure. And we have full CRUD operations. You know, if I decide, I'm going to shorten my name. For example, I can't really know. It's pretty standard front end application here. So now to show the data again, I'm going to run the copy command here. Copy to the same location. What's interesting is, you know, when Wolfgang said that all CRUD operations are supported, it's really important to note that, you know, from an end user perspective, like the data looks exactly the way, you know, you might have right over here. Sure. But what's interesting is, let's take a look at it behind the scenes. And, you know, how that data is actually seen. Right. So I'm going to run the H2JAR file again. It's going to bring up the console here. You're going to reconnect because it copied over the existing database. Just to show you, there's no funny business. This has the same insecure data we looked at before. However, now if you look at the patient table, you'll see there's two rows, which do have a form of our data stored in there. However, it's a little bit tough to decipher without having access to our security pipeline. Yeah. And well, I don't want to say that all the data over here is, you know, is encrypted with AES GCM mode, which is NSA Suite B certified for up to top secret military data. So you could use the same security framework, use it on a project for HIPAA, deploy that in OpenShift, and the next project that comes along, and you're going to be capturing credit card data or financial data, you could use everything remains the same. Use the same security framework, same platform that serves, deploy it back again to OpenShift, and everything is secure and consistent. The demo itself, you know, this is in the interest of keeping things simple, is just two different tables with different kinds of security being applied over there. But essentially, it's all going to be the same. And what I do want to show you guys is, you know, let's take a look at the code once more. And let me get Eclipse back in over here. So Eclipse, I think it's minimized. Oh, that's pretty nice. There it is. So let's get Eclipse back over here. Oh, you know what? It's not being zoomed in though. Okay. So, well, I mean, the only thing over here is, you know, if you look at this, you have ID, first name, last name, SSN, ID, first name, last name, SSN. Pretty much the same thing over here, patient class, ID, first name, last name, SSN, which is exactly the same as this. The only difference is, you know, when you apply something like this and you try to save it through the database, you know, that's where the security pipeline kicks in. So Wolfgang, why don't we show them, you know, when the patient is captured over here and you're trying to save it to the database? It looks just like regular code. Sure. Yeah. So if you look at one of the controllers, for example, there's, I'm using standard JPA syntax here. You know, I get entity managers, I do fines, I do merges, I do removes when I want to delete. I mean, it's all very standard syntax that we're running here. Exactly. And that is also another key feature, which is there is no new framework to learn. You don't have to learn a completely new API. The only API that you actually have to learn is essentially seven characters over here at secure. That's way smaller than a tweet or a Facebook update. So I think in terms of educating developers on how straightforward this is, it's going to be super easy. The rest of the framework is just the way you would do any other Java application. And, you know, this is going to be on a public repository. So, you know, when we send out this information, you guys can take a look at it. In fact, it already is out of the public. Exactly. It already is out. So, I do want to switch gears. Is there anything else you want to show them? I think that was it. Okay. Yeah, great. That was excellent. Thank you. All right. There are a few questions coming in, too. So when you... Sorry. We're going to leave some time at the end now. Since you've made it this far, you know, for all the devs in over here. All right. Well, we're going to give, you know, all our Red Hat OpenShift developers two months free of any trial. So if you go at that particular link, you'll see a sign up form. If you sign up from that sign up form, you know, we're going to give you a special discount code right over there. So you can, you know, get started on OpenShift wherever you want. You can put your healthcare, whatever, you know, PCI compliant application you might have. There's a couple of other videos. You know, we haven't explained a high level concept. I also call it FOIAboss. You know, why you need security. And then also for developers who want to get started, you guys have, you know, the full session 40 minutes of training so far. But the actual core essential training probably we've commenced it to two minutes. There's also, you know, documentation and guides. And so with that, I know we have a few questions. So I'd like to, you know, bring that up. Yeah. So Randy, who's from Optimum, has been asking a couple of questions. Back a little while earlier, he asked about if there was an LDAP integration. No. So in terms of integrating with LDAP, this would again be for the ACLs themselves. Krypton doesn't hook up directly to the LDAP. The hookup is actually to where you might be saying, like, okay, we're now going to open a database connection and we're going to be opening it on behalf of, you know, instead of individual users, it's going to be based on the entire role. So you might say, well, now we're opening a database connection on behalf of doctors. And, you know, CypherDB comes in and understands that that is the context in which all IO is going to be happening with the database and essentially enforces those ACLs at that point. There isn't necessarily a direct interaction with LDAP. I think the kind of interaction you want with LDAP is one layer above the data security layer, which would be in the form of when a user logs in, the application would be aware of, hey, one second, John Smith just logged in. John Smith is actually a doctor. So I think that level of knowledge is one layer above the security platform. I just wanted to jump in too and add to that. This is your own guess, Chief Software Architect at Crypturon. I'm the one who's been answering some of the questions on chat. The access control rules that Sid's been talking about, those are for our security partitions itself. You can do any sort of, you know, as a developer, you can add any sort of access rules yourself within your applications. If you want to have really fine-grained control over what happens for different users as your own LDAP, our access control rules are really for the different security partitions and which encryption keys are used. So I just want to add that clarification. There was another question I think Nicholas had where, you know, he asks if there is an on-premises version. So the answer is yes. And I do also want to give a final nuanced answer to that. You know, even the Crypturon managed platform, you can actually deploy it anyway. You could deploy it in public, private, or hybrid cloud. We have had some cases where people wanted to deploy this in a nuclear station. Now, obviously for good reasons, the rest of the nuclear facility is not connected to the public internet, so it's got to be off the public network. And we do have a solution for just that. It's our enterprise self-hosted plan. And again, I haven't actually covered that, you know, the details of our business over here. This was mostly targeting developers and helping them get started. But you can check out some of the plans that we have online, our website, crypton.com, slash pricing. And you'll see we have an enterprise plan which takes care of that. So I hope that helps Nicholas's question. There was fine green, held up integration. There was another question about the spring framework which I think Yaren answered as well. And I've unmuted Randy and Kurt who've been asking the question. So if they'd like to speak up and ask the question, go right ahead. You might have to unmute yourselves. But it looks like the spring framework uses the hibernate. And so it is compatible with what you're doing. Yeah, so using spring for your MVC is not going to have the impact on whether we're able to use JPAs, which as long as you're still using standard JPA for your persistence, it'll work. So it is compatible. All right. And also, there are three different products within our security platform itself. They all use the same subscription billing, the same security model. CypherDB is the one we've been showing you for dealing with structured data that integrates directly with your ORM, JPA, hibernate and hibernate entity framework. But we also have CypherObject which allows you to call seal and unseal on any type of class objects, whether they're going to be sent over JSON, whether they're going to be stored in a NoSQL database. You just have to call the seal and unseal basically the encrypt and decrypt methods yourself. And we also have CypherStore, which is for dealing with file streams and other data that's to be persisted in the file storage or blob storage. Got it. Yaron, could you also paste in the chat window? You know, I thought we have a poll for developer platforms. It would be interesting to see, you know, we did this demo on Java. If people had other preferences and other platforms, they won't, you know, support from us on OpenShift. So, got it. So yeah, I just pasted that in. There's a poll where you can vote on which programming language or framework you'd like us to port our security platform to next. And you can easily write in, you know, we'd love to hear what other people are using. So, Kurt had another question about key rotation management, et cetera. And he was assuming that it needs a connection back to micraterian.com. And Yaron kind of answered it, but I'm wondering if, Kurt, you want to add any more to that? Yeah, no, that was basically it. Like just whether, I mean, they have an on-premise version. I guess one question would be, for example, what does the on-premise version require hardware-wise? Like, can it actually say run with an OpenShift? Like, what if somebody wants to have an on-premise instance of Krypton running inside of the, you know, OpenShift with their application and whatnot? Like, does it require a hardware security module or is it strictly software? No, so if you actually don't need an HSM to run in, essentially, you know, even if you have an HSM, the weakest point is usually the, you know, the API that you use to get information in and out. So I typically say, you know, you might be having your keys at the other end of the galaxy. No one's actually going to go and get it from over there, but the weakest link is going to be the API that gets in. So, you know, taking this back to your question of whether there are HSMs or not, essentially what is done is there's a key vault that would be on-premises for you, and that particular key vault, there's a software key vault, would be the one which is used for the key management requests. All right, and Nicholas has, does that answer your question, Kurt? Yep. Okay, so Nicholas had one more question. Does CAN Criterion Server run on an OpenShift v3? And do you have a darker image for this and is this supported and recommended? And I think you touched on this just in the last question, but you want to? Sure, so, you know, there's nothing about us which is unique. You know, this is basically an API, so there isn't, you know, a separate darker image per se. It's essentially, you know, you would add the secure attribute, you know, your Maven build, whatever your Java application you're doing, you'd have a Maven, you know, essentially artifacts. So, we have an SDK that you add to your existing application and enhances it by adding the security behavior to it. So, I guess to tie this to the specific question, there is no need for a separate darker image. You know, this would be a part of whatever code that you're building and checking in to get anyways. The actual bits are pulled in straight from Maven, and then the API is always live over a rest interface. So, there is, you know, you don't have a separate darker container that you have to manage or deploy. So, if there's any other questions popping in or out, how about if you, I don't see any at the moment. Hey, guys, let me clarify a little bit, though. This is Nick. I'm talking about the Enterprise on-premise server that serves the needs of your application running within OpenShift itself. Got it, got it. All right, so, you know, for the Enterprise version also, you would essentially use the same Maven bits. And for the Enterprise version, there's actually a distributed key manager which is a part of those Maven bits. And, you know, then all of them talk to a single storage. So, you could have, you know, whatever storage systems your organization already lives, the key vault would essentially live over there. And every individual node would have a distributed key manager server inside it, which would talk to that. So, again, you kind of don't need a separate darker image for this. What you do need is just any kind of accessible, you know, file system. And also, do we have that functionality already in the Java Maven artifact at this point? All right, that's still coming. Yeah, that's still in the next release. And actually, what I just described is not yet being publicly released. So, I guess, think of it as a preview. It will be coming in the future Java versions. The C-sharp version already has what I used to describe supported out of the box. All right, well, let's also do this. If you have any additional questions. Sorry, I had one question about, like, SQL searching. So, obviously, searching, like, last name equals Smith, you know, it would encrypt it, search for the encrypted version in the database, find a match. But what about, say, doing, like, SQL searches for, like, you know, with just a partial text string? How does it handle that? Great. So, you know, unfortunately, searching is going to be an even more complex topic. So, what we've done is we've actually created a full blog post on just that. Oh, that's why the Maya is why it won't open anything. Okay. Yeah, I did. Okay. All right. So, let's go. Oh, now, get rid of it. Yeah, okay, now. Oh, we're getting an extension again. Okay, that explains this. All right. So, let's get rid of that here. And cryptron. I posted the blog post into the chat. Oh, you did? Okay. Got it. So, you know, you could also search cryptron, you know, searchable encryption. And there's an entire blog post which goes into, you know, the technical details and the nuances with doing the kind of search that you mentioned. So, there's a couple of different strategies that we do discuss. Essentially, you know, if you want to do searchable encryption on the data store side, there's something you would have to give because, you know, if you truly do randomized encryption, there's no way of connecting, you know, the search space and actual data that lives in the database. That is full-blown security. But there's different ways that you can actually get to the point where you balance your security needs with your search requirements. So, I would encourage you to, you know, take a closer look at the blog post. I believe it's also in the chat window. Yeah, just read it. That was a very fast read if you just read it. So, I think we're almost at the end of our hour and this has been actually really enlightening and pretty cool stuff. I'm going to have to try it. I'm going to vote on the poll for Python. But I'm also going to see if once we've got our .NET Azure relationship all cemented, which was just announced yesterday, so it might take a little bit. I can get you back on and talk about doing pretty much the same thing with .NET applications. So, that's, it sounds like a great service. And I'm hoping that Nicholas and Randy and everybody else got as much out of it as I did and we'll put this up for viewing as the recording, probably tomorrow, on the OpenShift Commons home page, on the Briefings page at commons.openshift.org. And we'll be doing lots more of these sessions over the coming months, especially now that we've gotten v3 out the door. 3.1 will be dropping sometime soon, so we'll probably do an update on new features for that. But what I'm going to try and do over the next few months, if you want to listen in, is bring in more of our service providers and people are doing interesting integrations like Pteron have and showcasing them over the January, February stream. So, thanks very much, everybody, for joining us and thanks Sid and Wolfgang and Yaron for bringing this great technology to bear for all of the OpenShift development community. Much appreciated. Thank you. Thanks, Ryan. Thanks. Thank you, everyone. Take care.