 Well, thank you for coming out this afternoon and respect to those who came out actually because this is an interesting subject, I think. Given the week we had here at the OpenStack Summit, so I'm Christoph, I work for New Edge Networks and I'm presenting on EU GDPR, primarily inspired by last year's session by Kim Hindard at City Network SE in Sweden. I think it's a hot topic because there's some impending regulations coming down, which actually impact everything we do around technology and OpenStack, and I'm speaking as a European citizen here. So I'd like to talk about that in the context of what we do, which is software-defined networking, and obviously that's a pretty hot topic with some of the things that we're seeing at the summit around cloud networking and containers beyond just OpenStack, right? So I'll talk about what EU GDPR is for our friends from the US here. Europeans should be probably familiar with this, and it's probably the right moment to be talking about it. So one of the things that we all know and appreciate is that information is probably the most critical asset these days, and it's growing very, very fast and large, and there's also a way of hoarding information. Each of us create a ton of files. I have the habit of not deleting a lot of information myself, especially as we learned from Edward's talk this week, public clouds consume a lot of data, and handing that data over into the public cloud has repercussions because it is stored by the party, possibly outside of your region, and therefore beyond the reach of your own privacy rights if they're local or European or otherwise. So that kind of creates a challenge, right? There's a company called Veritas which put out a report, which I'm referencing here, and it creates something called a data berg or a mountain of data which has a lot of dark data that we just don't know where it is, clean data which we know and care about and protect, and then this kind of rot in the middle. And the reality of this data hoarding is it just increases, and with cloud computing and a lot of the work we're doing with OpenStack, we simply just don't know, and the talk before actually was quite interesting about the role-based access into APIs and who am I authenticating against the APIs of OpenStack itself, which is a novel idea in itself as well, and I hope they succeed with what they want to do because you can audit and be compliant that way, right? So three problems are overarching here. Number one, you know, most organizations and companies and cloud operators and OpenStackers will keep data forever, right? You just want to keep that data around as much as possible just because you're hoarding it, or you might need it at some point in time. A lot of organizations have the second problem as well that you just don't know who's accessing this data, right? And I think that is the challenge in itself, finding out who it is that is looking at what I have and can I be informed about it and is this data informational and valuable? The other thing is, you know, the problem is the two combined, right? So you have both problems and you have a ton of data and you can't actually find out who it is because you have so much of it. And that is the overarching challenge of all of this stuff. Now, when we look at things and how they are interconnected today, and I am a victim of this myself, having a Slack channel open for OpenStack work and using OpenStack myself as well as Office right now to present this, as well as the work that we're doing around containers with backend services being spun up on containers, also using AWS and public cloud with Salesforce, for example. You get into a situation where you have interconnectivity between all these end points and things go all over the place and your OpenStack cloud suddenly is no longer just this little silo of information, but it interconnects to a lot of places, right? Let's skip into EU GDPR itself, right? It is a law that's coming in the European economic zone or in the EU. And everybody who is a EU passport holder or resident will have the rights into privacy laws that will come into effect on May 25th of next year. So that's literally next year, one year from today. You will start to have this implemented and what it means is you have the right for certain data privacy and that's outlined here, which means you will have things applicable to you and you will have also the right to find out who it is looking at your information and identify who is looking at information. And you will also have the right to figure out why it's being done. So if a government agency wants to access your information, you have the right to know why and also opt out of spamming. So if you're going to a marketing booth, for example, as a European, you have the right to say, hey, please don't spam me because I don't want to share that information or email address out with you. It's a lot like today you can have the rights with an airline to get money back for delays, right? If you're in the EU and those airlines are operating there. So you have additional rights globally, right? The privacy right will reach you here in this country as well or Canada or anywhere outside of the EU because if I'm traveling in here and going to a booth at the OpenStack Summit, I can opt out as well, right? And that's a pretty heavy impact because multiply that by the cloud computing model and OpenStack clusters running in the US, OpenStack clusters running abroad, interconnecting them, you'll have to apply some policies and methods as an operator or a developer like the guys were presenting earlier about being able to identify API calls, who it is, where is it from, at least be able to prove things, right? And last but not least, there's money involved. So the penalty thing is going to be probably the most radical bit that we're going to deal with because up to 20 million euros is quite a bit of money for a higher penalty. And then you have lower penalties as well, which could be minor, but nonetheless, there's going to be real money involved now for privacy violations, which up to now has not occurred because you could have privacy violations as a pure citizen or resident and be completely out of receiving any kind of compensation for the violations. And that will probably drive the biggest adoption of policies, audit, automation controls and so forth, which I think will drive adoption of cloud computing further and probably push also a lot more on-premises private cloud computing of which I think OpenStack will benefit quite frankly because there isn't many alternatives. So these are the facts for you and these are from the EU. Now I'm not representing the EU as an organization, but there's a fact sheet which I referenced in the presentation, which they sent me for this presentation as I came over. I emailed them at the EU Direct and they were really friendly. They're fully aware of this and they will help anyone out with information. I found that really useful. So you have a set of rights. You have the right to access your own data. So now you're going to have to prepare OpenStack for, hey, give me my data. I want to know what you're storing on my private cloud, right? You have the right also to rectify any wrong or incomplete information such as background info on you or maybe like a misspelling in your name or residency or so forth. In some cases you have the right also to object to processing of your data, on legitimate grounds of course. You will have the right not to be subjected to an automated decision or some sort of evaluation on your personal aspects, which is this kind of marketing spam information. Also you have the right to be opting out of the credit worthiness and reliability and conduct information such as how your behavior is and so forth or just simply moving around with your Google apps between different locations and that history. But the other bit, which I found pretty interesting, looking at the presentation from Barcelona and then doing some further research on obligations as a controller, right? So this would be you, the OpenStack operator, having to actually fulfill these things, right? And how you do that becomes a bit of a challenge because you will have to automate quite heavily to ensure these processes can be done, right? So you will have to be able to inform a user if their data is being accessed or if the user is moving that data into an area or a region where it could be violated and how you do that is not easy, right? So there's gonna be a heavy bit of automation everywhere and this is where I'll jump into the software defined networking bit about leveraging your network through a fully programmable SDN in conjunction with Neutron to make it happen by applying security policies and isolation and so forth. And you'll also have to be able to assure confidentiality as well as security in this processing. So it will likely require additional encryption beyond what you've got in OpenStack and you have to be able to notify people on data protection and the authorities in each country. Because believe it or not, just because the EU has this higher level law which protects you, there will be regional laws as well. And in some countries, even city laws. So where I'm from, for example, Berlin has its own data privacy law and it is applied to the EU law in addition. So that adds more complexity into the picture. So there's a business challenge, right? I mean, how do you get a grip on your mountain of data which is storing it? So you'll have to store a lot of information into your OpenStack deployment and be able to track that information back into wherever it ends up. You will have to also deal with the fact that your subjects or the people using your cloud computing environment may have the right to be not forgotten or forgotten, which you heard about a lot. And what you keep must be protected, right? So it cannot be lost either, right? Backed up and so forth. So I noticed that there's a lot of talks around backing up OpenStack clusters, which is quite interesting. What I found also very useful is that there's an OpenStack security guide which I recommend having a look at because for me, from a personal perspective, we have a lot of clients deploying OpenStack clusters which are in a very secured environment. They could be a financial company, for example. And it's nice that, finally, OpenStack has a security guide that you can say to the CSO team, hey, look, you're gonna be PCI compliant or HIPAA compliant or compliant and EU GDPR as it matures into next year. And this is what I wanna share with everybody who hasn't seen it. And if you're seeing the recording, I recommend going into the docsopenstack.org section and looking up the security guide for information on your OpenStack deployments. So what about software-defined networking? Where does it connect from that picture and how would you deploy it in addition to Neutron, which is the OpenStack networking stack and software-defined networking layer that comes per default? Well, you need SDN in addition to what Neutron does because by principle, EU GDPR implements this kind of logic where it says everything which is not forbidden is allowed and the golden rule of policy configuration in general is everything which is not allowed is forbidden, right? So you'd rather take the chance to do or deny all and then allow things than the other way around. So far so good, right? Now, the simplest way it looks like this, right? You would allow from target to destination port and you would apply that on every host in a very immutable manner so it doesn't change. However, it becomes impractical once you do OpenStack deployments and start looking at Kubernetes, containerized workloads, operate this OpenStack cluster for interconnectivity into public clouds, where you might have additional networking layers and complexity. So what do you do, right? So you have to introduce software to find networks. Now in software to find networks, there's some principles that need to be applied, right? And things are handled in a programmatic fashion all throughout and this is simply a way to look at your network truly in software and it allows you to automate every component of it because legacy networks are built on an old world where things are mostly static and it's hardware centric, right? So a switch, a port and everything is very much a manual task because of the heritage of the network being so old, right? When you pivot to a software defined world, suddenly every object from a port to an ether type or a non IP resource can be described in a JSON policy and then you can apply these policies at different domain levels in the same fashion that you would apply some sort of policy in a legacy world without the software definition just much faster at scale, right? So in the software defined stack you have layer two domains and layer three domains which Lutron caters to but beyond that you need to do also packet inspection and accepting and dropping and forwarding traffic and also be able to prioritize packets and apply sort of port level security groups and that you can't do, right? Especially once you reach out outside of Lutron. So a security policy in a software defined network allows also the flows to be intercepted and do inter-domain endpoints, right? And external endpoints. So suddenly you can view holistically your entire network programmatically, call up automation as you need it and also build organizational structures and policies based on what you need to define and you have the network get out of the way and you can have internet organizations and public zones all programmatically represented beyond what just Lutron tenant networks will do. Now you can also apply these Ingress egress policies which will direct traffic from a VM and I have a nice diagram on that as well as building unidirectional policy entries. So by default you get egress traffic from endpoints to other endpoints within a domain which could be a layer two domain or layer three domain, apply these implicit rules within a domain and they can be enforced, right? So it looks like this, right? You have a graphical representation of a SDN network and you can interconnect these endpoints at a subnet level, down to a port level, down to an ether type and basically have a visual map of every tenant network beyond just what Lutron gives you, right? So if you have that Lutron diagram, you can go one level down and incidentally all SDNs, third party SDNs will provide also an ML2 plugin and let you do that within Lutron mapping security groups using policies from an SDN and then you can self provision those things. So this is a use case for having third party SDN in addition to Lutron because of regulatory concerns that are coming down and the business case behind it is simply you want to avoid penalties because if you can't actually tell somebody when they're violating past the region, it becomes a problem and potentially subject to a penalty which is financial, right? With software defined networks, you can also build sandwiched policies so you can actually create this kind of deny all rule and then sandwich in specific policies underneath it or inside of it and then check mark them. So you can have a corporate policy which is EU GDPR compliant and an alternate policy for particular networks that interconnect into regions where it's not compliant and then be alerted by it, right? Incidentally, these can be applied into the physical network or the layer two network as well as the IP network layer three domains and that it itself can be of huge value because a lot of open stack clouds need a provider network as well. So you can define that in a software defined way and automate that provisioning and guarantee consistency. I hope that's good so far. Now, things become really interesting when you look at security policies and ACL entries, right? Because with SDN and in addition to Neutron, you can connect also container ports, right? And you need that consistency because let's be honest, a lot of open stack deployments are now mixed in with container workloads, right? So you can either provision containers on top of VMs which is fair enough because you might spin up a CentOS 7 VM and then deploy Kubernetes on top of it. Or you can actually mix in Kubernetes on worker nodes into your open stack deployment externally onto the same network and use something like Courier or other projects as an abstraction layer. But nonetheless, you still want to be able to guarantee a consistent policy model against a container port as well as a VM port. And how you do that today is, again, by leveraging an SDN, right? Because container networks have their own networking stack. By default, they might be using either Flannel or Calico or Canal or some of the other projects that are going on. Or you might leverage something like the Nuage or NSX type of solution which is a third-party SDN layer which inserts itself in there to apply policies basically at a granular level for any workload. So it could be a bare-metal workload, right? So you could have containerized workloads on bare-metal without a VM. But you still need to connect that container port to a virtual machine in your open stack cluster for whatever reason. There might be some data points or an application running in a VM and apply the policy and be able to visualize it, right? And therefore, it's the need for a third-party SDN that's overreaching. And it'll be interesting how container networking crystallizes over the next few years because there's a lot of discussions back and forth about different plug-in models, CNI, CNM, Kubernetes, driving a lot of adoption right now, as you guys know, and probably felt at the summit a lot of talk about containerizing open stack itself. I think the Marantis guys have done a wonderful job with MCP. Little shout out to them as well as Red Hat with what they're doing with OpenShift. On top of OpenStack, and therefore the need for plug-ins to cater to those workloads. And this is what it looks like, right? This is the example of what we do at Nuage, which is basically create an abstraction layer between Ingress and egress and virtual ports on a virtual machine and apply that policy using OpenVswitch on each of the Nova compute nodes where we outfit it, but then have a controller in the middle directing where that traffic is going, right? So if you picture OpenVswitch on a compute node mimicking a real switch, you just insert the policy model using a controller and a northbound API, which is then consumed and basically turns it into a flexible and easy to automate policy model on the compute nodes. So every compute node is basically controlled through the SDN layer in addition to what Neutron does for provisioning a VM. I hope that's good so far. Under the hood, we can see the entire workflow from a virtual machine provisioning way, which says when a virtual machine is instantiated, I need to connect out to an SDN network and get myself policies, right? And these policies are basically mapped at instantiation point. Now they can carry a few other things, right? Besides security and being able to isolate and find where an SDN network might get its security rules, you can also classify the quality of service. Again, very useful if you're applying it to regulatory compliance and you want faster packet pushing into one region versus another one. You can also forward things, right? You can build a forward policy on an SDN network which can redirect and send traffic from a virtual machine port to somewhere else for a future analysis, which is very useful if you're doing service chaining, right? If you're doing service chaining and there were a lot of talks at the summit so far on service chains, especially from the telco provider space, they need to be able to do that because they need to send things into some sort of intrusion detection, BNF or virtual network function, and you need to redirect that traffic. Now currently, service chains can be automated using heat and other mechanisms, but underneath it to actually stitch ports together, you need something to go beyond neutron itself, right? And this is where SDN comes in, and this is where the policies and also the ability to stitch policies based on regulatory necessity come into play around SDN. And I hope that's the connection between the two and also the ability to automate the entire stack, right? From network provisioning, virtual machine provisioning, forwarding policies, all of this at scale cannot be achieved without SDN or a fully software-defined stack, right? So these are the references and I give credit to the EU as well as Veritas and City Network for providing the initial talk last year. And Kim, a little shout out to you if you're gonna watch this. There's a good amount of facts and documentation to get ready if you're into technology and the links here from the EU will provide that. There's a excellent fact sheet which describes your rights, what you need to do, how you need to prepare yourself, additional material from them in legal terms and which articles will be applicable to you and how to also prepare yourself in the event of penalties if you're running a cloud computing environment, right? So that's very useful. And I hope that you can also try out what we do at Nuage using our SDN stack. We have a cloud-based tool and you can actually start playing with policies and applying it to containers. It's all running an open stack, by the way. It's a fantastic way to sign up for free and just give it a try. So I don't have anything else really after that and open to questions because it's late and I think everybody wants to go have a drink or coffee after a very, very long three days. So thank you very much. If you have questions, feel free or not. Thank you.