 We're going to go ahead and get started. So today I'm going to talk with you about policy. Policy is becoming pervasive across our industry. Many products, inside and outside of OpenStack, are exposed policy today and more are working on it, as we speak. My name is Peter Bland, and I work on a project called Congress. Tim Henrichs is also on the schedule, but unfortunately he had a last minute conflict, so he wasn't able to make the presentation. He will be here tonight and later through the week, though, so we can catch up then. So in this talk I'm going to try to discuss and describe the policy problem, what it is, why it's important. I'll just describe Congress, which is a system or a framework for policy-based management across cloud infrastructures, and discuss how Congress complements existing policy infrastructure and enables cross-component policies in OpenStack. So what is the policy problem and why are so many people interested in it? Well, the answer is based on a very simple observation. We live in a world full of rules and regulations. So governments pass laws, industries gather together and describe best practices, the organizations enter into contracts with each other, and also we'll have meetings to discuss best practices. Some of these rules and regulations impact IT systems, some don't, but people who are responsible for cloud services and IT systems need to be aware of the rules and regulations because there's penalties for breaking them. There's government legal penalties, financial penalties, sanctions from other governments, for example, and public outcry. These are all things that people who are managing large infrastructures worry about on a day-to-day basis. So here's some of the IT-specific use cases in the cloud and some of the things that we hear from our customers of how policies affect them in IT. At VMware, of course, we interface with IT operators and cloud operators on a daily basis. When talking about policy with them, we can distill the conversation into two main themes. One theme is everyone has a different perspective of what policy means, and that's mainly affected by what they see in their day-to-day operations, what they care about, what they're afraid of, and what is really on their front burner constantly. The other trend we see is that everyone tends to agree that most policies span the traditional silos you see in clouds. So most policies aren't purely compute or purely storage or networking-based. They're actually more generic and span the entire cloud. So one example I like is the series of geofencing problems and policies. In some countries, for example, Singapore, Japan, there are laws in place that say that data that originates from a citizen of that country cannot leave the geographical boundaries of that country. So it's easy to see from this policy, one that is very simple to describe in English, but it also has impacts of where the VM can be placed by the compute management stack, where the disks' arrays can be, and what kind of network policies need to be in place. So this is an old problem, and it's actually being addressed today. I'm told that there's a long and interesting story about how that happens, but at its core level, it boils down to the fact that we throw a lot of manpower, time, and energy to solve it. So lawyers, government, organizations, auditors, IT professionals, everyone involved with the entire end-to-end process are responsible from distilling these high-level goals all the way down into low-level policies or configuration that happens in the underlying systems. So in some instances, the policy might turn into configuration files and might turn into actual physical topology of networking gear. We get turned into ACLs on firewalls and et cetera. But we can see that the actual enforcement point is very far away from the top-level desire or stated policy that we're trying to achieve. So OpenStack actually improves on this to some degree. So with the invent of, let's say, logical topologies in neutron or even group policy procedures, we're actually getting closer to what the policy writer wants. So the one challenge remains, however, in that these remain policies at individual silos. And while those address concerns at that level, there is a higher plane where we want to be able to go to to analyze and describe policies that go across the entire system. Another point that I want to bring up here is that while OpenStack improves things because we're software-defined, it also hurts a little bit. And that is, if you look at the way policies were traditionally enforced, the people in the manpower who was implementing this had time to do it. So for example, if I wanted to get a new system to run my application on, I had to submit a ticket for the system to be ordered. And I'd expect that to take a couple weeks. Well, that system also facilitated someone to sign off and say, does he really need four processors? Is that a reasonable amount of RAM for that? Now in the world of self-service and software provisioning, I expect that operation to take a couple seconds. And there's no way for a human to get involved with that. So these are all challenges that we see in deployments that people are trying to grapple with today. So now I want to get into Congress and introduce where we feel that that fits in the organization or in the in clouds. So Congress is a new cloud service whose sole responsibility is policy in the cloud. If you give Congress a policy that's important to the cloud, it can monitor the cloud for violations. It can enforce that those violations cannot occur or it can correct them after the fact. And to do its job, it relies entirely on the other services that exist in the cloud today. So one of the key tenets we wanted to achieve or thought was critical to achieve when we were designing Congress is to ensure that it worked across any cloud service. Conceptually, the way we do this is we provide a plug-in interface across any cloud service and a common data model in which it can communicate data up to the service. Each cloud service from Congress's point of view exposes the policy-relevant data that it knows about in a form of tables. So if you're familiar with databases or SQL, this should be fairly straightforward to you. This may or may not be the way that the data is organized internally in the component, and that's the job of the plug-in to do that translation. So these plug-ins can either be tightly or loosely coupled with the component themselves. They can use the component's existing API to query the data that it has or they could be tightly integrated and push the data up to Congress via triggers whenever that policy changes. But the important point here is that there is a common data services framework where all of the data that is available in the cloud is put in a form that can be reasoned about consistently. In addition to being able to interoperate with any cloud service, we also feel it's critical that we support any policy that the cloud operator wants to use. So at lower levels of... or kind of domain-specific levels of the system, you have policy languages that have nouns in them that make sense within that domain. So for example, the term VM is actually specific to compute storage array or network subnets. All of these are specific terms that at a higher level would be very expensive to express in a kind of cross-cloud policy system. So instead, what Congress does is it treats input data as a series of tables and uses a policy language based on a form of data log, SQL, first-order logic. These are all kind of systems that have the same base principles. So Congress achieves... enforces policy by reserving a few table names and by carefully crafting the data that gets pushed up into those tables, you can both monitor the state of the cloud as well as affect... and by populating data into those tables we can control what those components are doing. So using these reserve tables, Congress does really two things. It monitors policy and how the state of the cloud is in compliance or out of compliance with the policy, and it enforces policy. So I'll go through this in more detail. Monitoring is achieved by simply evaluating policy over the current state of the cloud that Congress sees and populating through the policy statements, populating the special table that describes policy violations in the cloud. Enforcement is a bit more involved because there's actually two ways that you may want to enforce data in the cloud. One is to keep violations from occurring, and one is to resolve violations after they occur. So to permit violations, Congress expects that the services who are making changes to the state of the cloud first ask Congress whether that would result in a policy violation. Clearly, this involves an actual change to the component itself, component being an application or a given open-stack component. One of the reserve tables in this case is permitted actions, and permitted actions would list the kind of, given on the current state of the cloud, list the operations that would be allowed from that point. To correct violations, Congress can identify violations and populate another table, which is actions to execute. So actions to execute correspond to operations that should take place to remedy the existing policy violations. So these can boil down to bash scripts or API calls at the end of the day, but from Congress's point of view, what it is doing is looking at the data exposed from the cloud services, identifying the violations, and then using the policy it knows about to know what changes it needs to make to those source tables. So let's go do an example. Before we get there, I want to dive down deep into an assembly-level view of the grammar of the policy language. So if you've studied policy languages and undergrad or post-grad, I'm told that this is pretty straightforward and obvious. I did not study, get a PhD in policy languages, and Tim isn't here, so I guess we're out of luck on that one. However, my goal of showing this grammar is to reinforce that there's nothing domain-specific in this policy language, and that has benefits and drawbacks, which means it has a place where it makes a lot of sense to apply this and places where it may not make as much sense. The policy language gets its power from the objects that are exposed to it from the cloud services. So I can declare things only based on object names or resource names that other components expose. So if Nova exposes VMs and VM owners concepts to me, I can now write policies based on those concepts. So jumping back up, let's go to an example, and this is an example of a policy that we've gone through with a customer who has a very large open-stack deployment and actually has coded up this in Python. It's very rigid, and we're going to describe how we could achieve that same thing using that same goal using Congress and a policy-based framework. So the policy is this. Every network attached to a VM must either be a public network or if it's a private network, that private network must be owned by a user who is in the same group as the VM's owner. So why this example? Well, this is important because this policy actually crosses three different services here. We have Nova who knows about VMs and their ownership. We have Neutron who knows about networks and their ownership, and we also have some LDAP server who manages group membership. I specifically put LDAP here instead of Keystone because that is specific to this customer's environment, and it's an example of that in all installs we're not going to be pure open-stack, so we need to have a system that can be compatible across both open-source and proprietary solutions. So to enforce this policy, Congress can do three things. It can do one, two, or three of them. It can monitor, which means it's just watching to see as VMs are deployed, do they obey this policy? If it's deeply integrated with Nova, it can also let Nova know before Nova is to deploy a VM that that would not be within policy, and it can correct problems after the fact. For example, if an LDAP group membership changes, it can enumerate all the possible ways that policy could be brought back into compliance. I like jumping back to the low-level view in the assembly language where you can see that as we've added cloud services here, we've actually increased the namespace of the policy. So in this case, we've included some tables that are exposed from Nova and Neutron, and LDAP, I'll get a little bit more into that later. But the point is that these data represent principles that the policy writer knows about. Congress doesn't actually know what a VM is and doesn't really care. All it cares about is that the VM owner says that these two, the joins of these principles shouldn't be ever be seen in the cloud. This next rule down here is interesting because it's actually an intermediate table in the data model. So what we've done here is we've taken an LDAP data model which just has users and groups, and we've created an implicit, you can think of it as a view in SQL terms, or a join, but what we've done is created a view or a rule that indicates that two users are in the same group. This functionality is very useful when you want to take low-level services and create concepts that are more relevant or more directly associated with how the user wants to write policies. So I don't have to go to LDAP or my LDAP server and implement a concept of same group. I can actually write a policy rule that implements that for me. So how does this work in the cloud? So in this example we have three VMs, VM1, VM2, and VM3. VM1 is connected to a private network. VM2 is connected to a public network, and VM3 isn't connected at all. We also have five tables down here, four of which are representing input tables that are coming up from plugins and various cloud components, and the fifth is a reserve table in Congress. So you can see that we've defined an fictitious LDAP server here, which has four users in it, and all of those users are members of the group Congress. We also have Neutron providing ownership of networks. We have Neutron providing lists of networks that are public, as well as Nova providing VM ownership. In this case if you think back to the policy I presented and you look through this data, you can do the quick join in your head and realize that there's no violations in this case. So the result of that is that in Congress of course the reserved errors table won't have any rows in it. But Tim wasn't able to make this meeting and maybe someone got mad at him and directly went to the LDAP server and removed him from the Congress group. He said, you're no longer here. Maybe we could have prevented that from happening, maybe not, but the result is now there is a violation in our cloud state as compared to our stated policy. And so in that case what Congress will do is represent that by adding a row to the error table. And so this is again a low level view of the system. You can imagine putting kind of nice, more user friendly interfaces on top of this. You could add alerting systems. Maybe we could start sending Twitter feeds of violations, etc. So why do we think Congress is a good fit for OpenStack? Well I think the first reason is pretty obvious. Why we got involved is we got really pulled in by our customers. We have customers who are happy with OpenStack. They love the power and flexibility it provides. And because of that they're getting pulled into deploying OpenStack into more and more tightly regulated environments. And as this happens they're feeling the pain more about trying to manage these cross-component policies in a consistent and easy way. There's also an interesting aspect of policy in that since it's a interface level with the user this provides a place where vendors can achieve lock-in to some degree because when you define the policy language if that isn't an open framework then you can actually create lock-in just by the fact that you create experts on your policy language and prevent others from implementing that. So we feel strongly that it is very important that we have a community-based project such that no vendor can control the policy language including VMware. This is actually critical to achieving the goal because policy is really best achieved when everyone is cooperating on it because then we can all leverage the other systems that are part of the entire cloud I guess. So that brings me to the last point. So having Congress support a project means that future projects can leverage the data exported by those previous projects. So let me give an example. If we look at something like neutron it's clear to see that there is value in integrating external data from the system into neutron. So for example if I know that a VM is vulnerable we may want to add that to a security group or add ACLs to block access to that port. Now anyone of the OpenStack developers can write a single integration with another system and query data from neutron or another system. But what we can't do is query data from systems that we don't even know about today. So I'm really looking forward to going to Paris and hearing about all the new things that are coming out in OpenStack being developed over the next six months and let's imagine that a new component comes out that does something magical. Say we can predict attacking IP addresses on the internet before they even send packets to us and someone deploys us. I don't think that's going to happen but if it did it's clear that the neutron project would be really interested in getting that data so that it can proactively put ACLs in the network. Well one way to do that is for the neutron team to learn about this go back to their code and an interface to query the API of this new system and do it. However if neutron is Congress aware and this new system that comes up publishes its data to Congress as well then the actual integration of those two features could be done by simply adding a policy statement by the user that says that attacking IP addresses should be blocked. So where are we at with Congress? We have a base design implementation proof of concepts that have been done. We're actively developing the system. This is a very small snippet of the roadmap which is actually posted on the wiki. This includes some things we've prototyped and implemented other things that are on our immediate and slightly longer term roadmaps. But the point is that this system is actually very early on. We think it's important to work with the open stack community to vet both the design and the roadmap of our ideas before we get too far and so that's why I'm talking to you today. While we can take the system and show some demos the real power of the system comes in when the community actually interacts with it and agrees that this is the right way to go about it. So a lot of things on this roadmap are things that we want to discuss further with the community and that's why we want to keep this conversation ongoing. So Congress is currently a project pushed in Stack Forge. You can see that the way we develop is actually very much in common with any full-fledged open stack project. We have IRC meetings. We communicate on the open stack dev mailing list. We do everything out in the open for community involvement. And then the big point that I want to point out here is that we have thanks to the generosity of the open stack foundation they've created this open source sessions this time around and we have a room on Friday for the community to discuss this project and how we should take the next steps on it. So here's some kind of quick references to it. We do have our code hosted up on Source Forge. The Wiki is kind of the holding ground for our kind of state of where the project is at and stuff we're working on right now and links to everything else. We also have some other corollary information there. And so that was the key just of it. I guess I talked pretty fast this time. These are some other talks that VMware is sponsoring at this session and I know that the majority of them have already happened but as you know a lot of these talks will be up on YouTube so that you can watch them in the future. So yeah key takeaways here is that we have that Congress is applicable to any cloud service and any business logic or any policy. Enforcement of course we continuously monitor the cloud status. This is in support of operations and administration of clouds. And then also Congress can work at an immediate level where you simply are polling data from existing services but then can over time become more tightly ingrained as services closely interact with the system. So with that I think plenty of time for some questions if there are any. Yeah, you might want to use the microphone. Hi. So you mentioned becoming Congress aware. Could you give us a sense of what that involves? Sure. So as I said let me go back a few slides here. So the way that Congress views cloud services is as a one or more tables of data and so for Congress to interact with the cloud service it needs that view of the data and we have a plug-in interface that basically describes how the data needs to be formed. That plug-in can either be integrated with a given component which basically means it's part of that source tree or it could just sit outside of that component and pull data from it using that component's APIs. So that's at the base level for Congress to be able to monitor violations. For if you want to take that one step deeper and actually do proactive enforcement in that case the component would actually need to know that Congress is there and know to query Congress for policy violations before certain actions are taken that you may want to prevent in the system. Does that make sense? So my question is with the data that you're getting so are you taking any steps to verify that those components that are giving you data are trusted because otherwise I would just lie to you and tell you I'm good if I wanted to circumvent it. Well, I mean if you wanted to break the state of the cloud you could just do it anyway and not tell Congress is what you're getting at, right? I guess if one of the policies you had the one on there with the networking like I guess I could modify the neutron service and have the plug-in do bad data even though it's not actually doing that. So I'm just wondering if you're verifying the things that are giving you data. So as far as that goes the system trusts the data that the plug-in provides so if the plug-in isn't trusted because you allow users to access NOVA or an external system then, yeah, you could actually fool Congress. Congress only knows the state of the cloud to the extent that it is informed by plugins which it implicitly trusts. So the part about Congress which is to enforce policy isn't there some overlap there with the traditional role-based policies that the different OpenStack projects support? Right, yes. There absolutely is and I think that the key point there is that the two types of policies are actually they actually help each other out they each fill different roles. So if you look at a language you'll say the group policy language because I'm familiar with that one there's constructs in that language that are domain specific so we have a concept of networks, endpoints, ports and so on that are relevant to networking. If you use that type of policy language in Congress and Congress was meant to span the entire cloud of services you'd see that the number of kind of primitives in the language would be extremely huge and kind of unmanageably large. So that type of language that's domain specific doesn't really work at a cross component level. Now if you go the other way around and you look at Congress and then try to write some of the neutron based policies that you could write since it is such a high level language it would be extremely challenging, it would require a lot of work to actually describe those component, those concepts down in a terminology that the cloud can understand or that the individual vertical can understand. So there's actually a cooperation of a high level overarching policy and a domain specific policy and these two policies can communicate with each other. So for example we might be able to expose vulnerabilities that are referenced kind of like Congress can communicate with a IDS vendor to understand vulnerabilities of a given host and change group membership based on that and a group policy object in in neutron can have a policy that says anything in this vulnerable group has these network restrictions in it and where that line is drawn I think is best agreed upon by the operator and kind of depending on their individual environment of where it's the least painful to write that. First question is are there any of the core projects currently taking steps to integrate with Congress or is this sort of like the first introduction like is there any patches to know the integrating with Congress. So we first kind of started talking about this with OpenStack in Hong Kong and we have an unconference session just to kind of bridge the subject with people and we've been having pairwise conversations with a lot of the community since then. But this is the first point where really broadcasting to the entire community other than on the mailing list to get it kind of out there. So at this point we've written a couple of very rudimentary plugins that simply using the existing Nova and neutron APIs queries data out of them where you can write policies but the projects themselves have not I would say probably don't even know that this project exists or understand why it's valuable and that's why we're here today. So kind of the point of that is we want to we feel like right now is the right time we have the right we have the vision enough well formed that I think we can describe the concept to people but I think it's not it's not baked enough that the community can't take the time to actually make sure that it fits out all of our needs. And the second thing is it might be more of a comment but have you heard of CADF there was a talk earlier in the week it seemed like the two CADF and Congress might be able to play off each other like you effectively just listen for CADF events and make policy decisions based off of those might be. Right so I actually went to that talk and I thought it was very interesting and they're focused on an audit level framework which is a piece of this where we can see that Congress may kind of put out audit events that are exposed via CADF and your point that we could perhaps ingest data through the CADF format that's certainly something that could be done because data as long as it's translated to a common format is data I think in most circumstances we might want to go to a more direct route for efficiency reasons but at a conceptual level I think you're right on. It's a very interesting topic I just wonder if there is what's the relation between Congress and Kingston. Since Kingston we have the identity and the role so is there a possibility to export that into Congress or vice versa? Yeah so that's a really good question and of course Keystone does mention policy as part of their charter as far as what my understanding of Keystone is and where it's at and I am no expert in Keystone so I'd be happy to talk with more specific Keystone devs afterwards but Keystone is more focused on the RBAC use case role based access control for a given component whereas Congress is more focused on the cross component interaction and kind of doing a common data layer and then a policy based layer on top of that for queries so Keystone's policy is more focused for a specific component and roles and using the kind of taking the identities one step further into roles whereas this is a more abstract or high level concept of cross interfaces I should add that we of course will ingest data from Keystone just like any other service because it does have valuable policy relevant data in it so we have like I mentioned the design summit on Friday and as well as Tim and I will be around the conference up until then we'd be happy to have any other conversations you might have and we'd love to have any your involvement with the project thank you very much so folks the vSAN session is going to start on time at 5.20 as scheduled