 Can you guys hear this? OK. So we are going to start. Thanks for everybody for attending. We are going to talk about security, and especially when building clouds around OpenStack. What does it mean? How do we provide a solution? And here today, we have Rick from Onyx. We've been working for a while with them at PlumGrid, creating solutions for OpenStack. So basically, they serve a very tough crowd from a customer point of view. He's going to tell us a little bit more about that. So without making you wait any more, I'm going to let Rick introduce himself. And meanwhile, I'm going to put the presentation. And we are going to start talking first about how do you see security from a use case and a user's perspective. And then we are going to talk a little bit more about a forward-looking vision in terms of what can we do beyond the security paradigms that we have today in OpenStack to find different ways to provide better environments. Thank you. My name is Rick Kendiger, CEO and one of the founders of Onyx. It's great to be here in Tokyo. I was born in Japan 10 years ago. But I've lost a lot of Japanese. I'm sorry, let me switch back to English. So I'm CEO of Onyx. The crowd that we prominently serve is the US federal government market space. Myself and the co-founder of Onyx are former data center architects for the Department of Defense and the Department of Agriculture. So we'll go over a couple of scenarios and some of the things that we've seen, what we've learned in the past, and a couple of things that you can do using SDN and stuff to help secure your networks and your data centers. So just to start off, VLANs are typically in ACLs, what a lot of people use today within their data centers for a degree of security, security zones, VLANs for your web servers, your mid-tier, and your databases. The problem is that it's kind of snake oil. They're typically routed to each other. ACL management becomes very manual and problematic. I've actually seen core routers where there's 5,000 ACLs on one and 6,000 on the other so it can't fail over. There's obviously some sort of process problem there in terms of managing those things. And because they're typically grouped together to create these applications and services you provide, they're not really doing anything, right? The traffic from one can get to another. So if you get your web server exploited or attacked in one way or another, it becomes a jump box for the rest of the place. Look at OPM and Target and whatnot. And so traditional firewalls, once you get past them, not really much better than you're into the VLAN and ACL space. And then the hacker can jump around and move around and do whatever they want because it's kind of an open market inside. They can sniff and tap and attack and get whatever they want. What people think, you look at your silos, you get your network folks. That's what a lot of people think. The network guys aren't getting their job done, they're down there in the mess someplace. Everybody thinks the security guys are out there denying everything, right? Nothing works, deny all. The customers don't know what's going on. The clients, the people using these things. So what did you do? Why isn't this work network guys? Why isn't this work security guys? And then there's tickets, right? You got to put in tickets. They go through some sort of process. There's approvals. There's the enterprise changing control boards and all kinds of stuff going on. So the end result is that security is kind of lacking. The process of getting security implemented or not is arduous, takes a long time. Customers are unhappy. Everybody's unhappy at siloed. Nobody really knows what's going on. So what do we need? Well, we need a lot of things, but we can get those things with OpenStack and software defined networking. There's application segmentation, micro segmentation of the network, app tier isolation, tenant isolation, and so on. So there's a number of things, and we'll go over a couple of quick scenarios. So these are just some concepts and some graphics of what you can do inside of a software defined networking space inside of OpenStack. By using tenants, you or your clients or your customers can easily go in there and create all of this infrastructure themselves, and they can do it in minutes. This is an example of creating a security tenant. It's a services tenant with all of your infrastructure in it, maybe a virtual firewall, some form of a UTM appliance IDS, IPS, various networks within there. And you can actually route that all your traffic via internal, full network subnets that are within the SDN overlay, and you can route them all through there that way. And so you can use it kind of like you would with a top of network firewall and so forth, but you have the flexibility of using the SDN and the components inside of it. So it's extremely flexible. You can move that around. You can add pieces to it. You can remove stuff from it. You can do it within a couple of clicks. Making it a little bit more complex, let's add another network. And let's break up the application. So now we have a web tenant, and we have a mid-tier tenant, and we have a database tenant. We have multiple networks for those, and this can just keep going. You can do this for every application. You can do it for every instance. Every web server could be in its own network. Every web server could be in its own tenant, and so on. So if somebody does happen to penetrate one of these, let's say they get into this web environment here, if you look over on the right, they have to go over that private network that's inside the SDN overlay, get into the security tenant, break all of that security too, and then get back out to go to the next area. Doing that with traditional networking would be impossible. The amount of time it would take, the physical infrastructure it would take to do, would be so cost prohibitive and take so long that you wouldn't be able to do it, which is why no one does it today. However, in SDN, we can do it. We can do it quite simply and quickly. Let's say something does get attacked. Well, what if you had a forensics network? Now, if you'll notice, the forensics network has no gateway on it. It doesn't talk to the security tenant. It doesn't talk to the internet anywhere. But because we're using the software-defined networking overlay here from PlumGrid, what we can do is simply change the IP on the gateway of the compromised tenant and attach it to the forensics network. And then over here, we have another set of tools, which your forensics and security experts use, and they can go ahead and figure out what's going on inside of that compromised tenant in the event that it happens. But it doesn't get anywhere else. And again, in a matter of clicks, if you're doing this with physical infrastructure, I guess go find somebody and have them start changing network context, routing tables, plugging wires into different places. Well, you can do all that virtually and immediately. Or you can even clone that entire tenant and move it off somewhere if you wanted to. Start it back up, same IPs, same names, same everything, and then run the forensics against it out of band. So that's an interesting use case for it. So let's look at detection and remediation. Everybody here know Karan Shinchan? All right. So you can also do a number of other things. Let's say you have your various different types of UTM appliances or firewalls, and they detect something. Well, using APIs that are available both in OpenStack and in PlumGrid, you can use those things to automate some of your security and remediation. If they see an event, they're looking at the telemetry and the net flows, and they see something that looks like there's a problem, well, they kick off an event, it goes over and it talks to your overlay via its API, gives it instructions, stop that traffic, change that virtual security group firewall, vNIC, shut it down, send it off to a honeypot. Maybe you have a honeypot, send it directly into the forensics network, right? You can automate all those things. So kind of the concept there, and I think what we might see in the future, some sort of heuristics-based tenant, which will have a number of tools in it that will perform these monitoring functions that will allow more of that automation, right? We'll see that come in over the coming months and years. Security groups and firewall rules. So security groups are like having a firewall but on every single NIC, right? So you want to talk about defense in depth. If someone were to get into your web server, your whatever today, right? If we look at any of the high-profile hacks that have been out there experiencing just recently, I'm currently in possession of I think five notices of all the credit monitoring reporting I get, right? So if you get in via one of the web servers on your traditional thing, very rarely is there going to be any more security inside of there. So they use those as jump boxes, and they begin to hop around, right? So they get into this web server. They hop to the mid-tier. They go to the database. They hop out of that VLAN because there's another service that that has to talk to. They hop into the next one. They leave payloads behind, right? So you finally catch them, you shut them down, but then they wake back up again. I've actually seen this. One of the places I was at before, they got compromised, doing the sniffing on the network, passed the hash, started running around, jump boxing all over the place, right? So this does happen. Now inside of a SDN space, right? Using the security groups, everything has its own firewall. So it's not to say that those security groups are going to prevent all hacking. I mean, if there's some bad code or whatever, people still have to get to the web app. They can still possibly get in if they can hack the app, but when they do, that doesn't mean that they have direct access to the mid-tier server, right? They still have to hack that because it's only going to listen on whatever port it's designed to listen on from that app. Same thing. Let's say they somehow get into the mid-tier. They want to get down to the database. They have to put an equal amount of effort into hacking that because it's got another, if you will, firewall. Now Plumgrid has an interesting way of handling firewalls with this policy engine for the security groups, not being IP table-based per se, right? So it's extremely powerful. It's actually much more powerful than what you can find in most of the SDN overlays that plug into Neutron today. And there'll be more and more features that we'll be able to see exposed by that. But if you can go into the director UI and stuff, you can do a number of things way, way more complex and way more interesting than what you can simply do in just Neutron via Horizon and so forth today. So you can prevent a lot of stuff there, right? So it's way more than just having a simple firewall and then pretty much an open networking side. Encryption 2, SDN overlay, all the traffic is in its own separate encrypted domains. That doesn't happen in your traditional networking, right? If you're in there and you can see traffic, sniff it, have a good time, TCP dump everything you want, capture all that and then replay and hack away. Well, in here, inside this SDN overlay, all of that's encrypted. So if you did get into one, that doesn't mean you can read anything else that's going on that network. You'll see all the traffic, but it'll look like nonsense, right? So it makes it extremely hard to continue to pursue and infiltrate that tenant, right? Or that service. So extremely powerful, extremely flexible, fast. We've been doing OpenStack with SDN for about three years now and the number of use cases that really this is just a couple examples, but the number of use cases are infinite. When you can do everything in the software to find space, the sky's kind of the limit, right? Whatever you can dream up. As many routers as you want, as many networks as you want, as many security groups as you want, you know, as complex or as simple as you want it to be. So it's extremely powerful. One of the reasons why we founded Onyx is so we could get in and work with folks like here in Parry and everybody at Plumgrid and do some awesome stuff with this kind of stuff. So that's it. That's all I got. So I'm gonna turn it over to Parry now. Thank you. Thank you, Rick. So I'm going to talk a little bit more about the technology behind the type of problems that Rick and Rick's customers have been encountering. And originally, let's say the notion of creating a software-defined network layer was to have this notion of agility. I would like to be able to create a cloud service that every time that the network is needed, you can instantiate it through APIs and magically gets created. And this would be kind of the first iteration of where Neutron created the set of networking APIs, create network, create router and so on. And the idea was that regardless if I was trying to modify the configuration of a physical network or a SDN overlay, you would like to have this agility to create it on demand. But there was much more than that. So Rick was explaining the idea that just creating the network on demand was the whole point about cloud is flawless, because when you have a multi-tenant environment, you are going to have probably different people that may not like each other and they may try to attack each other, as well as people outside that are trying to use the cloud that may compromise one of specific tenants and then may propagate. So at Plumgrid, we created a secure networking environment and the idea was to create what we call a virtual domain. A virtual domain was an environment that would contain all the network definitions that an OpenStack project would need. And the only way to connect to the virtual domain would be if you had the proper identity credentials to connect to it. So somehow the virtual domain, you have to think it as a policy boundary, that the first requirement that you have to meet is, who are you and what project do you belong to in a way to connect to a virtual domain? And then of course there's going to be all the networking services that OpenStack provides, switching, routing, floating APIs, security policies, security groups and so on, addressing that we provide on top. So that's kind of the fundamental principle that Rick was referring to, that if instead of just dealing with automation connected to VLANs or connected to a BX LAN that provides you some sort of distributed switch, if instead of that you have a more powerful construct that abstracts the network, now you can start thinking as networking as a fundamental component in your security posture for your cloud. Of course, that was not enough because you have to have a set of capabilities and features and the virtual domain somehow is a boundary that provides you first of all operational constructs in the sense that a virtual domain you can clone it, you can create a template of it, you can migrate it to another location. And the point is that in the same way as a virtual machine would be a collection of components like four gigabytes of RAM, two virtual CPUs, a hard drive, a virtual domain was a similar concept. It was the idea of how could they create networking definition with distributed switching, routing and so on, in a way that every time you would need it you could instantiate it again and again if needed or migrate it to another data center. Then of course, inside the virtual domain you have the topology concepts that you are familiar from an open stack point of view. And then around it you have what Rick was referring about the policy framework that we have that maps to security groups but it can do many other things. It can intercept traffic and it can create policy constructs that you can prevent certain communications to happen or to tap the traffic. So all this is good. This is what we've seen so far in the open stack community and companies like Plumbridge providing a network infrastructure and focus on security. But what's going on now? I mean the picture is becoming much more complicated. Somehow in open stack we live in the wall of having a virtualized environment with virtual machines that belong to a specific tenant or project. But now as we start getting into the area of these containers, we have an environment that spans from bare metal to hypervisor based infrastructure with VMs that open stack has been managing this with Nova for a while. To now we are entering into containers in two different type of flavors. The first one would be the environments where containers run on top of a bare metal machine or environments where you have virtual machines that are running containers. And now the question is, what is this policy boundary that we are talking about? How do you secure the environment when you have virtual machines that contain containers that belong to multiple tenants? So this made us think a lot in Plumgrid and we were saying, well, what's going on with networking? Are we thinking it right? Are we creating an environment that is kind of future proof as the networking requirements to go across environments increases? And if you think somehow we've lived in the physical wall for a long time. As Rick was mentioning, when you created topology with routers and switches and firewalls and load balancers in the physical wall, you have a problem that at the end of the day the machines connect to the network by villains. And if a machine gets compromised then you have to essentially put firewalls closer and closer to the machines but you cannot change the physical topology. So we went from having physical networks with a view of topologies in the physical wall towards overlay networks or SDN over the top solutions that could still emulate topologies in a way that the experience needed to manipulate them, configure them and understand what was going on would be preserved. But as we were discussing this was not good enough because we have to go into a policy view of the wall. Now we have a data center, a cloud, multi-tenant and you say my web application cannot talk to my database. It should talk to the application server. Expressing this with policy concepts may become even easier than topology concepts. And now when we go to containers it's becoming even more interesting because you have this notion of elasticity. I create a service, maybe a web service and I don't care about the specific IP address of my instances because what I want is an elastic environment that based on the service I created more and more container instances appear to help me to manage my workloads. So what we realized early on when we started the company around five years ago was that the type of data planes and network characteristics that we had inside the hypervisor were not enough. And we were struggling on saying well if we have to provide all these features, all these capabilities within an environment that the Linux kernel we are building, how do we do it to have data planes that are rich enough to provide this policy enforcement and this security and these different networking models? So at Plenary we started with the idea that there should be an extensible data plane that would have to live in the Linux kernel. And this is what we call IOvisor. We work with the community, especially with the Linux kernel community and for the last two years and a half we upstream that capability, that code inside the Linux kernel. Now that we have this in the Linux kernel what we did is we went to the Linux foundation and we created a project called IOvisor project. It's a collaborative project by the Linux foundation that the goal was to create an open source community about this idea of extending and programming data planes. And this is programming not from the point of view of how to configure a flow or how to configure a routing table but how to express and create new networking capabilities that are the ones that are needed to for example enforce security and containers based on their identity. And as Rick was mentioning this was very useful to us because when we had to create our secure networks and our policy engines we couldn't translate the policy constructed into IP addresses and use for example IP tables because that was not a scalable system. So what we did is we managed to create native data planes that enforce policy within the kernel based on this infrastructure. That of course we couldn't do alone. So what we did is we created a community and we had a variety of members that joined from the starting and this is the picture of the current members of the IOvisor project. There's more people working on that. Of course when you see one organization like that is not only the formal members but all the developers behind contributing in the Linux kernel into the tools into the network capabilities that we are carrying forward. So now going back to our problem we are saying well now we are equipped with something much more powerful. So now we have this code and this IOvisor code inside the Linux kernel upstream but somehow lives everywhere and this is fairly new. I mean it's part of the 4.x kernel so slowly it's propagating into all the distributions so all the distributions in the market are going to have this type of engine inside as well of things like Android devices and mobile phones. So now equipped with this engine what we can do is start thinking that the code doesn't run only into the hypervisor and to the bare metal. It starts to run into the VMs and in everywhere that you have a Linux environment and all these container environments run especially in Linux frameworks like even CoroS or Docker or things like that. So now once we had that what we started to do is to think how to connect from a networking point of view instances that you would have in this plane in a way that they would look and feel as the picture that they had at the beginning. That now you have physical machines, virtual machines and containers and somehow they map to a network concept policy based or policy based based on the needs of each cloud that would unify based on OpenStack and container management frameworks the connectivity between them still offering the secure environment that companies like Riggs would need. So this is the place where we started taking it. Now until now we've been always thinking about networking security. And this is because when we think about what we expect from an SDN layer we expect that you create a network and this should be automated and there's no reason why you should manual intervene on the process of course my network should isolate OpenStack projects one from the other I should not be able to talk and cross talk between tenants that are potentially hostile. Of course I would like to have a policy enforcement based on what we are discussing and make sure that certain application can perform properly while keeping some security posture in it. And I would like to understand what's going on. I would like to have network analytics incident response and forensics and all the things that are needed. Now the interesting thing is that we are still talking networking but when you start thinking cloud and all the security requirements that were seen in the field it's not only networking automation networking security and so on it's application automation. When we start thinking containers you start thinking how do I create a microservice that automatically scales up and down that at the same time is secure that is isolated. So what we were trying to do is go beyond the notion of networking and when you start thinking how do I create my network and how do I secure my network especially in container based environments there is much more to the picture because now what happened is that with the iOvisor engine that we just upstream in the Linux kernel the visibility that you have in what's going on in your hypervisor is much more. Now you know not only what packets are coming to you you know what's the user that launched the process that send the packet. What's the process that send the packet and if it sends a port 80 traffic is it a web server or is it some rogue device that is using a raw socket. So the place where we are taking these concepts where SDN and security starting to march and Plumgrid is putting a lot of effort on this convergence is how do we make sure that when we think security and networking we understand what the application is trying to do. And the reason is because security has always been like a very tough business because there's always this tension between the people trying to create an application and the people trying to secure it because there's a lot of times not all good understanding of what's the intent of the application. So with this project and how we are now blending networking and application behavior what we are doing is we are creating systems for cloud that become much more secure at the same time of understanding what's the intent of the application and of course working across environments like containers, physical networks and virtual machines. And just when here and open for questions to record myself I just took his slide I liked it a lot it's like remember that networking and security is always a complicated topic because there's much more to networking than networking. Networking is always understanding what's the security posture of your application how do you scale your application how do you abstract it from the physical elements like the location where it plays. So when we start thinking networking and how to solve your problems it has to be a much more holistic thinking and this is the power of what software defined networks is supposed to mean is like you start creating all these requirements to your network environment and you can still automate and fulfill your goals without having to basically configure or reroute or wire anything in particular. So that's the talk that we wanted to cover essentially bridging kind of what we are seeing in the field, the customer problems what's possible today with solutions like Plum Grid providing virtual domains and explain a little bit of what's going on in the community and how do we take it forward beyond just traditional networking. So if there is any question, we can, yes. So there's two ways. Of course what I was saying only works if you have a bare metal running a Linux kernel that contains that capability, right? So if you have the proper Linux kernel then it doesn't matter if it's physical or virtual because the Linux kernel can abstract and can start overlays and virtual networks even from a bare metal server as far as you have the right kernel, the Linux kernel. Now you're right that what's going to happen is that you're going to have applications like a NetApp or Oracle database, things that by definition are going to be closed and locked. Then what happens is that you start by the top of the rack and this is what users call a VTAP gateway, virtual tunnel and point gateway. So solutions like Plum Grid, what we do is we control or we configure top of the racks to start the tunneling overlay from a certain top of the rack vendors that have those capabilities. But yeah, you are correct that in order to have a complete story we do configure top of the racks. We cover both. If you think Plum Grid is an SDM provider that would have a traditional scholar controller, the controller plugs into Neutron and basically from Neutron we start taking commands and we distribute the commands across all the perimeter of the network including the VTAP gateways as well as the hypervisors where our data plane exists. You expect to have layer three connectivity from any compute node to any compute node and of course to get out of the data center now you'd have another VTAP gateway that essentially would terminate the overlay and send the packets to the internet. It's essentially the way you install usually solutions like Plum Grid is you install your open stack distro. You have a layer three network or layer two, doesn't matter. And as far as you have connectivity from any compute node to any compute node then you install the software. The software puts the data plane, the hypervisors and the hypervisors. If you have bare metals you put the credentials of the top of the rack that we have to control to terminate the overlay and that's it. And then you go to open stack and you start orchestrating your network. Any other questions? Thanks a lot. Thank you. Thank you.