 Okay. So welcome. This is, whoops, sorry. So I'm Beth Cohen and this is Mark Durbin. And we're both from Verizon. And we're going to talk a little bit about securing OpenStack in some of the issues that we've worked in. I know you probably saw my keynote on Monday where we talked about the virtual network services product. And when you give product to customers, security of course is the most important thing that they think about. And more importantly, we need to do security for hundreds or thousands of customers. And so you can't just do root and everybody else. You have to really think about sort of a lot of different ways to deliver security because our customers care a lot. So Mark, do you want to say something about yourself? Oh, okay. Well you can see I'm with Network Security Infrastructure Planning. One of my functions is obviously to look at these systems and make sure that we're securing them properly, okay? Both internally and externally. So when we provide these services outside, we're scrutinized pretty heavily. But the focus here is going to actually be on a probably relatively, when you think about it, simple subject. But when you look at it in relation to OpenStack, it's actually pretty difficult. So we'll just skip through this. The agenda, we had several items on here. The focus for this is actually going to be RBAC. And specifically related to Horizon, I'm going to use the pretty pictures of the GUI, okay? But this applies to the command line and everything, okay? So Horizon in general. The pretty pictures are just for us to talk. So I went ahead and pulled up the wiki. Everybody go look at the wiki. You want it really technical, really cool little look out? It's great, okay? I'm going to break it down real simple though and explain why RBAC is so critical to us. Especially when you look at the size of Verizon. This is one of the keys that you're going to see up here. The size of Verizon and all the different systems that we have to interface with. Then also we have to provide services to the customers, right? And potentially even direct access to the customers. I'm just saying potentially. Let me talk a little bit about that. So one of the things that our customers ask for because we're offering security services specifically firewalls and next-gen firewall applications. And one of the biggest asks is can we have a security application that Verizon doesn't have access to? That it's sitting on our box which we're managing. But the customer doesn't want to have us getting into their image, their security image to do management of their policies or anything else. They literally are like, sorry, we just don't want you in there. We trust you but we don't. So that's one of the things that we have to address with this product. So you can see the subtlety of the role-based security can get pretty sophisticated pretty quickly. Yep, and obviously with the customer situation it's tough but let's just talk about internal to Verizon and all the different groups that have to be able to get into the system and what levels they need, okay? As you can see in this picture, we've got several groups. Talk about managed security services groups, network operations centers, security operations centers, so on. All these different organizations have different requirements for access, different functions that they need out of the system, different things that they can see in the open stack environment, okay? Also we've got reporting, monitoring, things like that that are going to go in there and pull information. Right now, a great example we're talking about and I'm going to pull it into this conversation. We need to be able to go in and look at IPs in our IP management. But the only way to do that is at admin level. That's it. To be able to look at the entire system, it's at admin level. We don't want that system and be able to write to it. We need a read-only level, okay? So this is going to apply as we go through the different areas within the horizon system. So I'm using the pretty pictures here. You can look at the overview. The key here is this is admin level access, right? Everybody seen this? Probably pretty familiar with everybody. Right now, the only way to go in and look at this is with full admin access. I can go in here and I can blow up anybody, right? Everybody agrees with that. I need to be able to provide some of my users of this system the ability to go in here and look at it, but not write to it, not change it, not modify it, okay? I know our box being worked on with the horizon, but the granularity is not there. We need the granularity. That's the key to this. So at this level, there's a whole bunch of stuff that needs to be broken down. So read-only is one concept, but also we may have admins that we want to give certain access to. For instance, we may want them to go in there and be able to work on networks and set up different network functions, but not go in and blow up tenant spaces. Those types of things. So that's how granular this needs to be. As we jump through this, I'm gonna go into more of the tenant space and more into a project space, right? Even at the project spaces, this is nice, right? We got a great summary here. We can go in, we can look at it real quick, see what the usage is of our tenant space. But in order to do that, I have to give you the same level of access that allows me to go in and drop an instance. Or build an instance. Or take down a network, right? So I've got to have controls to be able to go in and manage that access. This is something we might want to share with our customers. Our customers might want a reporting function, so they want to know how much they're utilizing, but damn, we don't want to give them right access. Yeah, that's probably dangerous in most cases. So as you look at this, for instance, I'm just gonna use some examples here. When you look at the user controls on instances, right, they can launch them, they can terminate them, they can start them, they can shut them off, they can reboot them. I showed you the overview a minute ago. I may not want a user to be able to do this. Just look at it. That was my point on it. However, then there's obviously got to be the guys that can go do this. There may be cases where I need users to be able to go in and put in images or a system to go in and load an image, preload the image, but not do anything else with that image, not be allowed to start it, not to be allowed to instantiate it. Just put it in there and have it staged, right? And of course you could do that through the other systems, but you get into volumes, obviously there's various controls on the volumes that we can get all the way down to this granular level. So within the volumes, there's all these different functions we can do to them, right? We may only want somebody to be able to go in there and look at them, right? That's one of the options. This is a great one right here, right, on the images. Look at all the different things we can do here. And right now, this is the only user access I have is to give them full-blown access. What if I want to give him access to be able to go in and look at his images, see what all is configured on his images, maybe even be able to console into his image, but he shouldn't be able to edit it, shouldn't be able to detach any interfaces, shouldn't be able to add another network interface, anything like that. Be able to look at a log, but not be able to change the instance in any way, shape, or form. Does that make sense? Actually I want to add to that. I'm assuming this is a single customer, so it's a site, but this applies even more so to a site that has multiple customers. So we're talking about, let's say there's three customers sharing this environment, and we want to segregate those customers. My classic example I always use is Hacker International, I just made up the name, it's actually a company that does test equipment. And the CIA, you really don't want them to know that they're on the same box. Yeah, yeah. It's probably a good thing, right? Not to share that. So access and security, this is an area that I was going to spend a lot of time in security groups and talk about it, but I'm not going to spend much on it. One of the things is, is when you looked at my original slide there with all the different groups accessing this thing, the other thing is, we have security operations teams that want to be able to go in and put a security group in place and shut down things and control things, but other groups should not have access. So anyway, before I run out of time, I want to jump back to this slide real quick. You can see all the different groups, you can see all the different organizations. Another key to that is customer portals. We need to be able to manage it down to that level so I believe we're going to be out of time here. I think he had us down to one minute there. Well, that's good, then I can talk a little bit more about it. So let me go back to the security group. I thought he put up one minute there. I can talk for a while on this. So with the security groups, again, this is one area that our security teams are having a real issue with. We have that security operations team that wants to be able to go in and manage these security groups and not let the other users of that tenant space control that. So again, you see the granularity of this. Now, if you look at this, this is all talking about what I've really focused on is just our internal groups. When we start opening this up to customers, you know, this is where we've got a real challenge. Hiding things is really a key to security. Arbok is one way to do it. We hide stuff from users. Don't even show it in the menus. Don't even give it to them. That's the level of access we need in there. So, I guess I tried to, I thought he held up one finger and I was off there. So we could actually maybe even take a question or two. Are we done or can we go for two more minutes? Yeah, let me take a question or two. Any questions on? That's the key right there is what's available. He would love to have implemented this. Yes. So, yeah, that's the key to this. This is a limitation in the system. Go ahead. I have looked at it, but look at the granularity that's available and the complexity of going in and try to set all that up. It needs to be cleaned up. That's the problem. The granularity that we need. No, this is not available. What we're doing is we're highlighting the fact that the holes in the system and that we need that type of granularity. It's not enough to, we have to be able to hide the other users. Internal groups can see, but it's essential that Hacker International does not know that they share a box with the CIA. Well, right now, we're here. I've been talking to a couple of folks off and on here, too. Right now, that's what we're doing. Okay. The purpose of this was to really highlight the need, and yes, we do need to address it.