 Welcome, everybody, to yet another OpenShift Commons briefing. We have Amir Sharif with us from Aparato. I'm sure I'm saying it wrong. Every time I say it, I say a different variation on it. But we're really pleased to have them here. They have a unique cloud-native security offering and a unique perspective on implementing security for cloud-native applications and systems. So, I'm going to let Amir introduce himself. The format for this session, as always, is you can ask questions in the chat. We'll have a live chat after the session in the Q&A. And with that, I'll let Amir take it up away. And I'm looking forward to learning. Thank you, Diane. And thank you for giving a chance to talk at the OpenShift Commons briefing. As Diane said, my name is Amir Sharif. I'm the co-founder of Aparato. And Aparato is a cloud-native security company. Basically, our focus is to look at distributed workloads across any cloud on any infrastructure. And OpenShift is a big focus for us. In this talk, I will discuss the challenges that we're facing with going cloud-native, the various challenges, and I'm going to actually highlight a customer's environment and talk about the problems that we have encountered there. And that's going to be common across many other customers. And then talk about how we approach cloud-native security. So with that, let me get started and let me paint the scene. And this slide basically describes the transition that we're making from servers to a serverless world with VMs and containers being waypoints along the way. The point is that as we went from servers to VMs, the number of endpoints on the network increased tenfold or by an order of magnitude. And by their nature, VMs are more transient than servers. Therefore, the change frequency also went up by an order of magnitude. Now, we are getting to inside a container's world. And again, we're seeing at least an order of magnitude increase the number of endpoints and the networks because the number of containers that can fit inside a VM or inside a server and correspondingly, the change frequency again is going up by an order of magnitude. And projecting the future, we can see the same thing happening in the serverless world. Now, by saying serverless, all we're saying is that we're abstracting away containers and what containers are doing is abstracting away the OS, whether they're running on a VM or a bare metal server and a VM is abstracting away the server. But by going up the stack, nothing's actually disappearing except we're abstracting away complexity. That abstraction allows us to have more working units in the network and have a more dynamic environment. Now, here's the rub. When we are focusing on security from a networking perspective, we are solving a quadratic problem. We're solving an n-squared problem. So hold up your hand and you have five digits on your hand. And the number of connections that you can make from every point to every point is 10. That's basically n-squared minus n over 2. So you're solving an n-squared problem whenever you're trying to calculate the number of connections between points. And as n gets larger, as we're showing here across this x-axis, the calculation becomes harder and harder, especially as you have to do it more frequently because the change frequency is going up. So what we are doing in the lower range of the market with servers and VMs is where we give them beautiful names and effectively they're pets. They're not nearly as dear as Diane's dog that she's adopting right now. But we do give them names like Fred and Joe. We had a very hands-on manual approach. So if somebody wanted to have an isolated network inside an enterprise, they would file a ticket. That ticket would go to some IT administrator or network administrator somewhere and he would create a subnet. He would track those on spreadsheet and he would give it to the developer. And that subnet probably would live on for a very long time, if not ever. Going to the cattle business where containers are coming and going and we really don't care. And if you've seen any kind of Docker labels that containers get, they are cattle. What we ought to do is have an automated and scalable infrastructure for security. That's basically platform-independent. You want it to work on Cloud Service Provider A and Cloud Service Provider B. You want to work on a hybrid cloud. You want to work on your private data center. And ideally it should be part of DevOps pipeline, meaning that the security layer should be invisible to the developer. But have the ability to ingest the application intent and know what it's trying to do. So when the cattle goes wild, when the application goes wild, it provides the right level of security for it. So let's talk about the cloud-native application, the way we're building cattle. This is when people talk about what a cloud-native application is. This is the beautiful, pristine picture that they think about. You know, you have some services talking to each other and some load balancer maybe, and there is some data back in. In fact, what the application tends to look like is something like this. The application typically has to be deployed in multiple availability zones. You have to do some sort of database replication. The way you do this is so the application is resilient to failures in a cloud. So if one availability zone goes away, you have other availability zones available to take care of it. You usually have to interface with some sort of legacy infrastructure, some partner network, some external stuff. And the picture that you're seeing here is actually from a current customer that we're working with who is running OpenShift to orchestrate their workloads in three different availability zones and GCP. Now, as I mentioned, the number of endpoints inside the network is getting higher. So the freckles that you see inside the cloud does represent the containers that are coming and going. And what this customer has done, and this pattern has been repeated across multiple customers, what they're doing in order to provide security for this type of environment is the following. It's a mess, basically. They're overlaying an SDN, either some open-source variant of SDN to stitch together different VPCs. They have virtual appliances running in. They're access control lists. They're doing Natting. They're doing KVMs in order to control traffic between the availability zones. They're firewalls across both sides, and there are firewall rules that they have to maintain. And they establish a VPN tunnel with gateways and so forth and so on. And take this into account with the number of endpoints that are coming in and going on the network with the numerous endpoints, and it's really difficult for them to maintain coherence, coherence security, the security policy across all these availability zones. And the system is ultimately very complex, fragile. And because of this complexity and fragile fragility, things do break. And as such, their environment was basically insecure. And what you're seeing on the screen is reminiscent of what Target had done. Target is not a dump company. They just had a very complex and fragile and fundamentally insecure environment that allowed somebody to get in and exfiltrate a lot of data and harm a lot of consumers. That's the problem. Now, the question is, why do we have such a complexity inside the cloud? And the answer is that basically we're trying to solve four different types of problems. There's segmentation that we have to do. There's encryption. There's enforcement. There's secrets management. These are the types of problems we're trying to solve in order to provide security in a cloud. And when you look at any particular solution, they typically address two of these sectors, maybe three. And what you have is sort of a set of disaggregated tools as a previous slide shows that run all over the place and there's no established best practices. So it's up to the customer to kind of cobble stuff together and good luck to you as you go through. Now, the question is, why do we have this? Again, peeling the onion on why we have this complexity. What we get into is this is the way the internet is designed. The internet was designed to connect all points to everything. That's an HR TCP traffic. That's everything supposed to be discoverable and open network. Great, it works. But as the number of nodes gets larger, I talked about the N squared problem. As the number of nodes gets larger, the exceptions that you have to create for preventing certain nodes to talk to each other. That's the isolation that you do. It becomes more and more difficult. So in a world where everything's supposed to talk to each other and you're trying to prevent bad actions, the number of exceptions keeps getting exponentially higher. So what we ultimately want is a white security model where we know what the application intent is. We know what we should do in order or what how the application should behave out in a while. And to do that, you need to have basically three core concepts. One is identity. What is my application doing? That's effectively part of the intent. Know what component of the application is. Second, we need to have policy. And the policy is the application intent and organizational intent. What should the application be doing in the wild as it is supposed to be doing? And what is the organizational posture for security as dedicated by corporate guidelines or by regulatory requirements? And third, you have to have some sort of enforcement. So let me talk about how Appareto solves the identity problem and then talk about how we approach policy and enforcement. So basically, think about your distributed application running an open shift in a cloud somewhere. There's a service that you have that's trying to access some resource. When that service comes up, there is a YAML file that's associated with the entire application. And that YAML file provides some metadata as to what that service is. But we can also correlate what open shift is doing to what system V is doing and say, OK, and derive certain information like who is running this application? Where is it running? Is it running on Amazon East or Amazon West, for example? What's being run? Is it Redis? Is it Ubuntu? Is it CentOS? And what's being run in this particular application? The metadata is what comes from the YAML file, as I mentioned, and additional key value pairs. And in terms of reputation, that comes from image scanners that provide the vulnerabilities of that particular service that's come up. All that we call a trust profile. Think of it as a dynamic three-dimensional FICO score for a particular service that's come up. And at this point, because we have noticed that the services come up and it's talking to certain resources because that's when that described in the application, the YAML file, we spray this trust profile across everything. So anything that comes up that's related to that application that we want to secure now has an identity. And I'll get into the mechanics of that a little bit deeper in a presentation. Now that we have the identity, the next question is how do we allow the service to connect to a particular resource? What is our security posture and how does a policy address that? So let me talk about the way we approach policy and why that's actually a fairly unique and intuitive way of approaching cloud-native security. Our inspiration for policy was the English language where you have a sentence that has a subject, a verb, and an object. And in our case, the verbs are pretty simple. There are things like allow, read, encrypt, drop, connect, so forth and so on. And finite set of very well-defined verbs that we work with. And in terms of subjects and objects, basically we are looking at the key value of prayers that define the trust profile. And in order to define policy for the subject and the object, the thing that does the action and the thing that receives the action, what we do is do set operations and the key value of prayers. So to illustrate this, if I want to have a very permissive policy, I say a sentence like environment equals production can connect to environment equals production. So anything with that tag ends equals prod can now talk to itself. That's a permissive policy. If I want to get more restrictive, I would write a policy like my payroll application production can talk with confidential data and production as long as my connection is encrypted. That becomes my policy. And as you can see that with these set operations, I have further narrowed the scope of the subject and the object. And I can continually narrow down the scope as much as I want down to a level of a definite subject and a definite object. The singular item that I'm concerned about, if that's what my policy should be about. Or I can operate at a much higher level than say anything with the following characteristics must behave in a certain way. So when you look at our platform, what apparatus does, you know, between a service and a process, we do authentication, we do authorization. Because we're proxy between the notes, we can transparently encrypted communication between the notes. And we also do monitoring and enforcement. The reason we can do monitoring is we know what's trying to connect to what and we can map it. And enforcement is basically the application of the policy. So effectively, we're doing application segment, secretion, secrets management, encryption and real time monitoring and enforcement and taking us back to this slide. What we have tried to do is provide a holistic solution that addresses the security needs of cloud native application as orchestrated by something like OpenShift in a very unified way and a very simple way. So in a slide, what we do basically is take any application, any distributed application and any infrastructure and you may have services and external services and files basically. And we put a protective layer around each one that defines what can connect to what and encrypt, optionally encrypt the communication between the notes. Simple, scalable, secure, that's what we do. So, at this point, I want to get a little bit deeper into the mechanisms of how we do things. So that you have some appreciation of why this is unique and why it radically simplifies the world. And I'll talk about some use cases that we handle specifically with OpenShift or other Kubernetes clusters. So, imagine having two different clusters with micros, you know, these could be pods with microservices up. There's a source and a destination that's coming up. And there's a set of state information that each side has. So on the top, we have, you know, the production environment that the application is web and my image is engine X. Those are my key value pairs. At the bottom, I have other attributes application type equals production and instances of database, for instance. Now, you see my policy down the bottom. The policy says accept the connection from application equals web in a production environment. So that's what the policy will allow us to do. So on top, we do have a web application in a production environment. And one of these guys tries to attempt a note or a note in a cluster below. So what he does is sends a request that request goes out as a TCP send packet. So the send packet, when it goes out at this point, we intercept it and we provide the trust profile as payload on the send packet. So now you have a cryptographically signed identity associated with the send packet that's going out. As such, we're not using the IP address as the identity. We're actually using a much more sophisticated set of attributes associated with the workload that becomes the identity. Then the TCP packet goes off. At this point, we can provide transparent encryption basically without the application knowing that is talking in an encrypted language. We can provide that encryption and then do crypt it on the far side. Simple, easy. And off we go. So the application isn't clear that the rest of the world cannot read it and that makes a developer's job a lot easier. Now on the far side, we ask two questions. Number one is when the send packet's coming, is it signed? Does it have an identity piece to it? If it's no, we drop the packet and we don't allow the communication to begin. If it is signed, then we ask the question, is there a policy that allows the sender to talk to the receiver? And if the answer is no, again, we drop the packet and the connection is never established. If the answer is yes, then we validate based on policy and we allow the send packet to go forward. It hits a target. The target at this point responds with a symmetric action and then you have a mutually established trust between the sender and the receiver. They both know who they are and that can happen regardless of where they are in a network. So they can be on the same subnet, they can be on the same VLAN or they can be on two different clouds across the internet. The point is that we actually do not use IP as a proxy for identity. We actually use a much richer set of attributes that allows us to apply security policy and a much more granular level. So that's at a high level what the mechanism looks like. I should also add that when you do, the key difference is that when you do add additional instances, this is a linear operation. It's not a quadratic operation because all we care about is the identity. We don't have to calculate the entire route and exceptions and firewall rules and so forth. So we are operating in 01 space or linear space. Let's talk about a few use cases with OpenShift and how we can handle them. So imagine having an OpenShift cluster running. And the first use case is OpenShift providing its native network policies to Apparedo and Apparedo rendering them as services. So basically a fully compatible model. So what OpenShift does is provide the network policies to Apparedo. What Apparedo returns is policy that makes that environment secure. And at this point we actually haven't added much value. We've just been fully compatible and provided Apparedo security based on network policies. So we're in complete sync. Now at the next level is we can actually augment network securities with additional capabilities that Apparedo has using the key value pair matching in the policy language that we have. So network policies go in and Apparedo at this point provides a super set of security policies that go above what OpenShift can do or Kubernetes can do to provide a much richer context. And the third, and this gets more interesting, there is egress network policy support. And as you probably know, is that the pods in OpenShift have only ingress policies, meaning that they reject things that are not supposed to talk to them, but there's no policing into what the pod is doing for communicating with the outside world. What Apparedo allows you to do is also define ingress policies, egress, rather egress policies. When a pod inside an OpenShift cluster wants to communicate to the outside world, that communication can also be policed. It's not just rejecting incoming traffic, it's making sure that when the pod is communicating out to the world, it's paired with a certain set of rules. And building on top of that is we do provide support for external services. So let's say that you have this pod, what Apparedo allows the pod to do, or allow you to do is to provide sanctioned access to various resources. Let's say that you're doing a Google Maps mashup. In that case, Google Maps would be an external resource, and it can say that this particular pod or this particular cluster has access to this particular external service. And again, that's a value add that we can provide to Kubernetes distributions. Now taking a step back, I think the key value prop that we can provide for Kubernetes clusters is multi-availability zone security, similar to the first slide that I provided. And imagine you have a private data center somewhere and you're running OpenShift on AWS, and you have ELBs and Natting and so forth with a bunch of firewalls across. Now if you are trying to provide communication or application security across this environment, it's highly complex and basically it's going to be mind-boggling and very difficult to maintain. And partly it's because you are speaking different languages inside your data center and what the cloud service provider is doing. With Apparedo, basically you're defining a policy. You're saying that that particular pod running inside my data center can talk to another particular pod running in AWS, and as long as the two can ping each other, the connection is established. That's it. You don't have to worry about providing firewall rules. You don't have to worry about losing state as you go through load balancers, so forth and so on. It's a simple statement that says A can talk to be regardless of location because IP address does not matter to us and that security services provide it regardless of where the application is residing. So going back to this big messy picture that I provided up front, and this is a common architecture that we see with all this complexity, what we do is reduce this complexity to a much simpler picture where you can rip out a lot of the of the infrastructure and go to effectively a zero trust network and assume that everything's on the internet and the applications are then prohibited from communicating in or out unless your policy allows them. And that then allows you to take full advantage of a flexible platform like OpenShift and focus on application delivery instead of maintaining a state. So looking, stepping back, basically what you're getting is a reduced attack surface, a verifiable security posture and you can actually go back and forth at any time. And because it can rip out a lot of the complexity within the network, you will get a lower cost. They can happen on any cloud and we do scale pretty well. I don't want to state the numbers. Let's talk about the numbers are quite, quite nice. So looking at our architecture, you know, we do talk about identity, we have analytics and management and we have multiple plug will enforcers. We have open source part of our enforcement layer that's useful by itself. The project is called trirem. If you go to trirem.io, you will be able to see the code downloaded play with it. It's, I think we just hit more than 50,000 downloads today, actually, as of last month. And the solution within itself is useful for developers to provide connectivity rules and not have to worry about any sort of infrastructure complexity but you now have a broader picture of what is it that we do and all that is exposed in a UI like this. And I would encourage everybody to actually go and sign up for a free account. That's free account is console.apparito.com and then connect your OpenShift workload to it. Let us ingest the network policies and then experiment with with how we write policies, go through our use cases and our tutorials and see how much simpler and more secure application can be with in a cloud-native environment, especially when it's orchestrated with a platform like OpenShift. And with that, we come to the end of the presentation. Diane, I think we did it and half an hour or less, I talked pretty fast. So let me know if you have any questions. That's actually perfect because in terms of people watching the videos and stuff, about a half an hour is about all they'll tolerate in terms of watching a YouTube video and this will get up on the YouTube channel shortly after we finish today. I had a quick question about overhead and any sort of performance issues when you inject something or wrap something around your application or into OpenShift. Can you talk a little bit about that? Sure. That's an excellent question. So when we do provide identity and do a policy lookup between the two nodes in this transaction that I described, we do increase latency. That latency is currently on the order of three milliseconds. So it's pretty fast and it's once per connection. So once the TCP session is established, basically it can happen at wire rate if there's no encryptions is going on. And if it's encrypted, we encrypt the entire data path and then we dump it to TCP and the performance at that point is actually slightly better than an SSL, but I would say it's on par with SSL. So at the startup, there is a hit of about three milliseconds and they'll get further enhanced, but at runtime it's at wire rate or on par with SSL. That's actually pretty impressive. So tell me a little bit about your roadmap. What are the other things that you think are coming or you're going to bring, I know you've open sourced, I'm telling you these things. We're going to work on some of my pronunciation of these things. I apologize for that, but 50,000 downloads is pretty impressive. And so that's, and that's great. And it's not that I'm going to tell you to open source your entire project though. Sometimes I might push you that way. But tell me what's coming next for you guys here. Where are you going with this? So we do live in a brownfield world and a lot of the open shift clusters that that are deployed do talk with legacy applications. So a lot of our effort is to make sure that there's an operational model that works within the enterprise, let's say operational model that allows brand new applications to talk with older applications and have a consistent security policy. I don't want to get into a lot of details in that, but the work is to make sure that we take cloud native workloads and make them well suited for the enterprise and more acceptable. And so the enterprise thing is very important. I know for everybody in the Kubernetes and the open shift space as well. So this, and I apologize if I missed this when you were talking before. This sounds like it's a hosted solution or is this something that people can use on site on their private clouds? I did not mention it and you did not miss it, miss it. But basically there are two models. One model as applied by a slide where I put the triad, that is a hosted model where you run your workload wherever you want to run. And then Forcer that runs on your operating system then dials back to Apparedo and provides a security service. And then you can manage the security service on apparedo.com. That's model number one. What we see happening is people start with a hosted solution and because of various concerns, they want to have their own hosted solution, meaning that they take apparedo and they install it in their own private cloud. Where would that maybe it may be on the hosted environment on GCP or AWS or it may be inside their private data center. And at that point, it's exactly the same operational model, except we do not get the customer data. The customer has their own has their own analytics engine. And they generally feel more secure in that environment. Well, it's great that you have both options available to so I'm looking and I'm I'm thinking you've done a pretty good job covering off all the bases I really some of the the intro slides were really great from from my perspective I like four pillars of security perspective a lot and I really do think you did a great job of explaining the the pets and cattles in the beginning to so I'm definitely I've seen it done a lot of different ways and I think you did an awesome job of explaining the security challenges there. So thank you very much. And is there anything else you'd like to add and maybe go back to your very first slide because that's the one that had your email address if people want to get a hold of you. And there and we'll leave it at that. And I will try and get this up with all the links and a link to the the open source project as well. So thanks again Amir for joining us today and we look forward to hearing more from you in the future as well so Thanks, I appreciate the opportunity have a good day and good luck with the dog adoption good for you for doing that. Yes, Monty is coming soon.