Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2018 (Seattle), 16 Dec 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Don’t Forget the Data When Embarking on Your Journey to Service Meshes - Shriram Rajagopalan, VMware

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Don’t Forget the Data When Embarking on Your Journey to Service Meshes - Shriram Rajagopalan, VMware

It’s no secret that sophisticated enterprises are using data to deliver new value and gain competitive advantage. In the modern application architecture, decentralization of data management results in the data being distributed over a vast surface area across different data stores and locations. At the same time, sensitive data needs to be controlled and protected for compliance with data security and privacy regulations such as PCI-DSS, HIPAA, and GDPR. The service mesh (Istio/Envoy) provides universal observability across the infrastructure. However, there is more work to be done to track how sensitive data flows, provide data-centric policies and telemetry. This talk highlights some of the challenges, describes customer use cases and how adopting a data-centric approach from the beginning is essential in the modern enterprise.

To Learn More: https://sched.co/GrY4

A

So good morning, everybody and just waiting for the folks to come in so today, I'm gonna, actually talk about some of the problems that we actually face like when they talk to customers in terms of how to handle data tracking issues in the enterprise and like how they can actually solve it with a service mesh to start off with.

A

Let's I will just give you a brief background of the service, and most of you would have heard of it, and so I won't linger around, and you know there are so many other talks that go into detail on what our service measures and what are the benefits are, but I'll just give a brief overview, followed by, like you know why the mesh is not enough for problems that you face in enterprise today, and you know what are the things that we can actually do to enhance the mesh and or the system itself, so a so that we can actually effectively tackle a the problem that we have today.

A

Ok, so to begin with, the applications today are no longer in silos that that used to be it's. The whole thing is fully distributed and it's actually like spreading across, not just in a datacenter, but it's moving beyond the data center. You have stuff that's running on a cloud you have such as running on your edge devices, depending on your enterprise, like expertise, Enterprise like what he called the market segment- and you know the application is completely spread across a diverse spectrum.

A

This I mean, of course like to manage or to handle this level of change, and you know ask for your application to move from a traditional, siloed, websphere stuff to a whole bunch of things that are new. You start like the architecting applications, decomposing your monolith and two smaller in those pieces, and you know this just changes into a more distributed mass. You know it becomes its own separate nightmare and you have a whole bunch of framework languages, hippie languages and old languages, all alike, and then you know it just gets.

A

The whole thing starts building up and, of course, the usual set of challenges that you start facing today, which is you have a network which has limited visibility in terms of what is actually happening. You don't see what is what how two services are behaving talking to each other and you don't actually see what the columns are. Nor do you actually see you know decent metrics, because everybody has their own development workflow.

A

Somebody has some log message, while the other person does not have been a loud message, so no no uniform visibility, no uniform, metrics, no uniform, like no behavioral control and no control over the entire system, and you know the problems that we all face today. That's where the whole industry's here it does get more complicated. As you start, adding like more platforms and more fancy, things like sigh I mean, like you, know, functions and then a different platform start foundry coupon.

A

It is how you start going different clouds, which is I, mean most likely it's going to be on Prime on the cloud and so on, and so, as with all things in computer science, we solve this problem by adding a layer of indirection which would be like yeah I, stick a proxy in front of each and every service in your system across the like diverse spectrum of applications, and then the proxy will mediate all communication between any two pair of services across the system and given that the proxy understands the protocols that your application is using, that should be or like a PC or like your database, specific language and so on.

A

You get a decent amount of visibility, because you can. The Prophecy's will like what are called like transmit all the telemetry cater to a control plane, and you get to see like the number of error successors latency. The golden signals that you actually want from different cases. At the same time, you have some level of control in terms of who can talk to who what is allowed?

A

Where is not allowed, and you know, given that we are mediating all communication as a service mesh, you can actually encrypt all data in transit, so you get a decent set of MPLS systems out of the box, and you know always hunky-dory I mean it's like it's it's nice and it's decent, and this is the state of the service mesh today and like I've personally spoken with and work with a bunch of customers who actually use this in production and, like you know, they're happy with the state of affairs, but that's just one class of customers like who have limited set of requirements as it is now, if you notice this diagram, the the whole idea I'm here is it's a uniform way to connect, secure and manage your services like, and you know it's irrespective of your platform.

A

It was particular development process and you know it was part of like a whole bunch of other things that just makes it much more easier for you to like move your applications across clouds across platforms and what-have-you, but the buck stops here. What happens to your data?

A

If you are a traditional enterprise right and your data is your most important asset, it is not your services, it is not what you build in code, but it is actually your data, but it's your customer data, whether it's the data that you actually generate and, like you know, you curate, and how it's like, whether it's insurance company, you have a whole bunch of our data that you actually have.

A

If you are like a hospital or if you have, if you're a bank and so on and so forth, you have a whole bunch of data that you actually like curate. You actually build your own API layers on top of it, and you actually have a bunch of vendors that use this data and, like you know, you have whole bunch of value, adds and data asking. That is where you monetize.

A

That is what you actually Jen like generate a whole bunch of revenue from none of this here is actually tackling the data problem today, and this is the crux of the problem that I mash trying to tackle, which is that the systems that we have today are not focusing on the the one of the core pain points that we have in enterprises today, which is tracking and observing and controlling the data flow across this diverse spectrum to to see polymer in different light.

A

If you take the same picture where your application, there was once there in the data center in a silo, is now spread across the entire spectrum, from different clouds to already different, like you know, I devices and so on and so forth.

A

When applications move your some of your data also moves like you can no longer afford to have all your data in one single central Oracle is like a rack silo and then make everything access that thing you end up moving some equi data along with your applications, and you end up having, like you know, local caches. You end up the whole thing, moves across the place and you no longer know who's touching your data or very Raiders flowing or what is actually being done with it.

A

You have no idea how much compliance is actually being violated or how much of the data is actually leaking until you know somebody posts, some big giant lump blob of data on the internet and says: hey look I have all your emails and Social Security numbers. So this is a classic problem that, like several of us, are very intimately familiar with I said: I. Can you don't know who's touching leader and I?

A

Think there was somebody yesterday, I think was telling me a funny story about an employee in a big company who managed to like also the entire job to some place in China and the guy who actually managed to get away with this for a year and the claim China.

A

Basically, it was like you know the IT department, chorded saying that there's a random VPN connection from somewhere in China for this employee, but that's an extreme use case, but the point being that you know in a world where it is actually very sensitive and controlled data and us may may or may not actually reach the reader Europe or should not, depending on your enterprise, on your data and similarly, like you know within Europe itself, or you have a whole bunch of locality level restrictions that you can no longer enforce when you have such a distributed application, it's you need to have be very careful in terms of how you architected or you end up.

A

Creating silos are called different countries, and then you end up losing a level little bit of in terms of flexibility, and you know the problems just continue going. So, for example, right when you have your micro services, you decide to have politoed persistence, the best database for them, but the best job you use Ruby, you have acted records which probably get stored in some local database. Doesn't matter use something else: hey I need a Redis. Cash just go click on something on the AWS like dashboard, you have, it is provisioned.

A

Redis, like you know, manage ready server. You cache a whole bunch of data for performance for whole bunch of variety of reasons, because you found a nice library on the internet that says like hey, you can actually like import. This use this and here's a snippet of code that actually makes your whole accesses faster. Little. Do you realize that, like you, might actually be caching some sensitive data in that radius database, which is wild transient if it gets compromised already?

A

It actually goes out on this on the road right and at the same time like given this scenario like with with in distributor Enterprise, you no longer know who's touching the AIDA. Not all users are the same. Not all like you know.

A

Roles are the same, but in this model you don't know if somebody using the gateways actually like trying to touch the data from you know in an unauthorized manner, so to drive the problem home I'm, actually going to talk about a real real use case and customer case studies that we did, which is actually I mean, and this is Polly gonna drive the problem much more easier. So this was an enterprise IT department.

A

Three years ago, like you know, you had your standard sort of like things that, like you, have servers and you have your best via logic servers and everything is in one enterprise. You have a nice UML diagram that can actually represent the whole thing and it was there. This was three years ago and today I mean like you know. This is the standard stuff that you have like. The Oracles are like what he called your messaging bus and then you connect to a bunch of external services.

A

You have a database layer, it's all set now this, like you know this is a classic picture. So now this is a picture of an enterprise IT department. Today that same department that we worked with this is a picture of enterprise, the IT department. If you look at these two pictures, this was where things were, and your CSO or CIO, who were just. We had a very nice contained system. He said, like oh I, know where all the stuff is I know.

A

Where already does I can put entire fortress on this thing make sure everything is nice and safe. This is what the exists in motion devices today. We're like you, have a stack of things. You have a bunch of code phone. Do you have kubernetes? You have probably like some functions of a service. You have your developer portals where you actually go on you. Click on, like you, get a entire temperature sort. Just like that, and you just go and write your code and boom stuff starts working. It's it's a K, modern enterprise transformation.

A

So you start moving things out and you start like you know, building things in a little bit more. You know agile manner. So the problem with these two is that, like now you don't know where your it is actually going. You no longer have that centralized store where you can curate and protect your data. Think about the spirit. So what exactly happen so we started with this and then you know Along Came, somebody who said like hey look.

A

This is fancy new thing called you know what be conquer or, like you know, Salesforce how many of you use conquer and how many of you use workday yeah they go, and so it's like all of you later is actually running with I mean it's. It's your employee data and you're, like typical data, is actually with these guys and you don't know where these guys are storing the raid, and you know this is I mean in terms of the enterprise to lick audits and logging and so on and so forth.

A

If some day like this, for example, and a hypothetical situation concur was to go bust, you lose all the data, you have no access to the data and you have no access to like what's happening within that system and today, and so this is phase one and then, of course, along came some other CIO and said: hey.

A

We can actually modernize because we are getting more cheaper infrastructure somewhere else on the cloud, so you start provisioning, some AWS Amazon AWS or as your or GCP name it, and then, like you, start like running some applications, and then you slap some API gateways on your enterprise edge and we try to access the data from the cloud and you try to serve it. And you know it's before you know. Your team is actually using a bunch of services on AWS.

A

They provision a whole bunch of things and they start like caching, things here and there and storing things locally for a better locality, and you know the storage that continues. So what is what is happening here is that a security perimeter is starting to disappear. What was once a nice security perimeter around this whole enterprise thing is now actually like spread out. It's the security parameter disk.

A

Now that the footprint of the entire, a Douglas you and your footprint on AWS, plus whatever it is at AWS, inherits plus all the other SAS service that you actually have right. And then you start throwing in your in-house modernization efforts which includes, like I'm, actually going to deploy some taught: foundry I'm, actually gonna deploy some kubernetes stuff because I'm actually going to load up some new stuff in-house. Well, you know these things are going to directly access. My databases and these I mean, of course, then you start building your own.

A

Like you know more nate cloud native stuff and again, the dispersion continues to happen and this believe it or not is exactly the state in several enterprises, including VMware, and also believe it or not. We spend a lot of time effort and money and resources in trying to repatriate all the data from all of these services and all of these other places back into a single silo for variety of reasons- and this is, there is an actual big department in VMware and black and other companies that I spoke to that.

A

We spend time and data warehousing and collecting all the data from that they have actually like you know that is going into sales forces and workdays and putting it back in their enterprise. It's at least a copy, but at least they have some idea of what else is actually out there. On top of this, you start applying all the compliance things. When somebody comes for audit, you have a much bigger problem. You have no ideas like who's compliant, who is not compliant.

A

Maybe workplaces TSP are fully compliant, but you don't know if, like you know, you're using something like box and you're, storing some critical customer data sensitive customer data in box, just because your organization has a box-like account, you can't simply go around storing some of that data into box right and you don't know what is actually going out there. So this is the the meat of the problem that we are trying to tackle that.

A

How many of you actually face a similar problem in your enterprises- and this is not something that your service master day is actually gonna solve. Nor is it something that most of the frameworks today actually solve. But if you take the approach to solving this problem as a first-class citizen, then everything else will start falling in place in a more you know, different cohesive manner.

A

So as to why the security here is actually important, let's look at a sample security example that, right now that we have, within the same system, take a traditional three-tier web application. We have a fear of like web servers and then app servers, and you know a bunch of databases, and today I, like most of you, have some form of network segmentation, whether it's like you know, you buy some software-defined networking solution. All you have something is like hard I mean the traditional based or use kubernetes network policies.

A

You know you name it you got it and you start doing like hey I need to make sure the system is secure, so you start creating a simple nice micro segmentation policy. That says, like you know, like all the there's, a group of web applications as a group for databases and a group for app service- and you know, then you start setting policy that, like Web Apps, cannot touch the database I only app servers can touch the database and you know so on.

A

This is the very standard stuff that you can do today with kubernetes network policies or any of the like, for example, you can use NSX or Cisco's ACS. You can do something similar very easily, but here is a problem. All data is not equal right and but your micro segmentation policy treats the whole thing has just all day does equal.

A

You simply says the entire set of app servers can touch anything the database that is no longer to write with not all data is actually the same, but that's basically what your micro segmentation policy can give at that layer for all users are also not the same like if I were to access my data, it's great, but if I were to go and, like you know, access somebody else's data, because I found a vulnerability in your application and I tried to like you do with you know: user, like very tricky, sequel, query, and so on.

A

Try to like do the whole sequel injection thing you have no way of preventing it with your standard network security policies that are happening now. Do you have a way of preventing input with other systems that you have today, so the users are data connection is actually missing right and the second part is that you know. Within the user group itself, you have limited access from one person to the other. I can access my data, but I should not be able to touch some other person's data. How do you actually ensure this today?

A

Today you have some access policies as a database layer, but that is also done at the level of like rules where you assign that hey app servers will like connect me with a particular rule and with this role I'm actually gonna love. You access to anything else, would Anita base, but that is not sufficient.

A

So as more concrete examples like, if you take the scenario right where, if let's say Joe the doctor from office, can a can he access, Ben's medical records may or may not be true, depending on whether that dough is actually Ben's doctor or not right. But if Joe as Ben's doctor from his office can I access Ben's medical records- yes sure, which is because there's an association that Joe's actually Ben's doctor, and then you created that policy which says like yes, a doctor for that particular patient.

A

The primary care provider has access data and then, at the same time, can Joe as a research doctor. Cannot can you access Ben's medical record, it's Lydia. It depends on situation. You could probably provide partial view, but not a complete view, and this is not a very specific problem. This is very special. This is very common to almost all of the people who actually, if I, did the problem that this is like.

A

You have partial new requirements, you have a complete view requirements and you have the Associated view requirements as well and the same time kanjo the research doctor. Can he access, Ben's medical record from you know, a different locality, some someplace in China that is may or not be true or someplace in Europe, for example, right it is actually not allowed. So this is like you're missing the data, the user and the locality information and the policy that we have to date.

A

So these are things that we need to actually have as first-class primitives in the service mesh or anything that you actually build so that we can actually tackle this problem in a more like strong away, so I mean some of the things that we've been working on at VMware along. This front is to like try to tackle this problem, no piecemeal slowly, and so there are different ways by which you can actually tackle the problem.

A

So what the service mesh offers a nice way, because you can now see what is actually happening at the layer, seven from an application point of view.

A

If you understand the protocols, if you understand some of the semantics, then you can try to impose or some control, and you can provide some good level of telemetry and log in to see what was accessed very Rader's actually going across the system, because all of this actually recommends that layer, seven access- and today this mesh is probably the only thing that actually provides you with a decent layers of an axis where you don't have to change your application.

A

At the same time, you know a bunch of proxies in the system will actually decode everything it's actually going on the wire, and it will tell you like what it has being accessed and so on, but that is not really enough. Why?

A

So, if you look at this model today right if you were to write a policy for your database, you're gonna, see here is an actor which is like a user with a particular role in standard, our back style stuff, and here is a resource that they can access on, cannot access under certain conditions. This is very rudimentary in very, very, like you know basic. This is a standard. Our back thing that you tend to think of, but this is absolutely not in up to date, because you have a whole bunch of services in between right.

A

The same act, I mean I as an end user would actually access and you will have or thought indication of a whole bunch of other authentication mechanisms, authorization and other stuff, after which I login and my request, transits through multiple services along the chain, at the end of which is actually going to go and fetch database. So you definitely some way of a propagating the user context and propagating the authorization and authentication context across the system, and then you actually get to go and implement that policy.

A

At the tail end, when you're passionate about itself, you can decide that this user, with this role and this kind of from this location, can or cannot touch this data read or write and so on. So this is the crux of the problem: I mean this.

A

Is the I mean the solution model that we are working on, which is that if you connect users, services and data together, then you get to have a much more cohesive security models that would fit the modern enterprise requirements where you can pack all data flow and track and, like you know, provide control over the whole thing. So you know in a big picture, fancy big picture which shape on somewhere.

A

Is that, like you know, in your the whole ring, if you connect the users and the services and the data you actually actually see where it as actually going and where it's transiting and who else is touching it?

A

So this is I mean, and you know, and I saw this mesh in this model will actually help I mean some of the work that we've been doing recently tackles this, which is that you know you have I mean take kubernetes as an example, but this applies to so cloud foundry or your bare metal installations, and so on.

A

Where, like you know, if your proxies are aware of the data protocols and you have an identity management system in the front which is emitting enough information to identify an end user with emails or some tokens and so on and so forth, then you can create those associations that this user Shriram from this and this location touched this table and your my sequel database at this time and knowing is the first step to actually providing enough control because you can then provide like you, can understand who's, touching the data and where and then you can actually provide start providing policies.

A

On top of that, of course, the problem is simple: with just a day basis like my sequel or like you know both queries or someone, but it gets much more complicated when you start actually accessing things like you know your whole day, so a system something in the backend. It's no longer gonna use a sequel query, but is actually gonna use something else and you rate a format is actually very different. You're, probably gonna, have you know good old, XML stuff?

A

That's actually, like you know, pushing and reading writing data in a different format and especially all being talk to SAS services. You're gonna use their api's, and your data is actually gonna, be embedded as API objects inside the whole thing, so those require a little bit. I mean much more of an intelligent way of like processing and understanding what is going through the wire and what is taking so that you can actually impose controls, but you're not there yet, and that there is a lot more work left to be done on that front.

A

So, to conclude, I've been saying for wrong, like we need to refine the notion of a connectivity like users, services and data, and with that like with the help of a service, massive people enough controls on top of it, then we can actually observe interactive law yeah, that's it! Thank you.

A

A

Right now, yes, I am doing within. So the question was like you know: where are you trying to tackle this solution? So the yes I am that trying to tackle the solution within the context here, because that's what I'm, mostly familiar with I'm working on, but the solution I mean the approach applies equally well to any other service mesh solution that you would have that you would have take this approach in order to give that visibility.

A

A

So I think it has his own trade-offs and turns up like you know you can either try it I mean it depends the performance qualities that you actually want, but from a data point of view it neither of them Ashley would make much of a difference, because metrics is not what you want when you want to track data accesses, you want to see what tables are being accessed, what is being read and what is being written and by what user, identity and those effectively end up being somehow blogs that like, but not access logs as it is, but it's just like streaming set of blogs that you actually use or imposing all of these audits.

A

Any other questions. Okay, thank you.