Kong Destination: Zero-Trust, 8 Feb 2021

Previous Meeting

⏯

youtube image

►

From YouTube: How to Achieve Zero Trust Security With Service Mesh

Description

Join Kong CTO and Co-Founder Marco Palladino as he explores what zero-trust security is and why we need it and shows it in action with Kong Mesh, which is built on top of CNCF’s Kuma and Envoy.

Read the blog post here: https://bit.ly/3qWAUmV

Check out all the recordings from this event: https://konghq.com/resources/?video-category=destination-zero-trust

A

Today, we're going to.

A

Be going over the importance of your trust security as we build the modern applications.

A

First and foremost, zero trust security becomes even more important as we transition to microservices.

A

As a matter of fact,, microservices can be a chance to improve the security of our systems, even.

A

In a better way than we used to do with monolithic, applications.

A

And I know that this may sound counterintuitive,, but we're going to be exploring why this is the case and why we can make our systems more secure.

A

With micro services and zero trust, security.

A

So, first and foremost,, as we increase the number of services that we create across the organization,. And we do that because we want to.

A

Ramp up our teams in a faster way,, we want to be able to scale and deploy in a better way more often so that we can shift features and back fixes to our customers. Every.

A

Day, and we can become distributed and decoupled in order to become highly available.

A

In order to do all of this,, we decouple our large part to scale hard, to build monolithic applications and we and we decouple them in micro,.

A

Services. well, decoupling them in micro services really means that we're adding more and more services over time and with them we're adding more and more.

A

Connectivity that connects all of these services together.

A

Now, as we build a modern application, that's micro services based,. We must always remember that we cannot.

A

Rely on the concept of trust across all of these different services to enforce security among them.

A

And the reason really is, trust is exploitable.

A

Trust can be taken advantage of even more so when we have an increasingly high number of services.

A

Running across the organization that teams all over the org are creating as they create these new modern applications.

A

So the more services we create and the less and less we can, we rely on the concept of trust.

A

The concept of trust is exploitable,, and in order for us to be secure,, we must remove it from our systems. Entirely.

A

And this is why a few folks ask me in the past few months.

A

But the concept of zero trust really that the name zero trust can be misleading. Sometimes.

A

What do you mean by zero trust?? Because we think trust is a good thing. trust is not a good thing., trust can be exploited and our systems cannot be fully secure until we remove it.

A

And let me make an example to better explain: this.

A

imagine walking into a new country.

A

And going through going through the immigration chaos of the airport without a passport,, so without a passport,, the.

A

Immigration officer- that's talking to us and interviewing us and asking us why we're entering the country.

A

Without a passport,, they would essentially have to trust us that we are who we claim. We are now.

A

I'm pretty sure that nobody, who's listening to this presentation is ever going to be lying to an immigration officer.

A

But guess what? somebody eventually would,, because trust is exploitable.

A

So sooner than later, somebody will walk in to the same immigration court and they will claim they are who they are not.

A

And thus a criminal enters the country.

A

And so, since trust is exploitable,, we cannot have the immigration office of trusting us to prove that we are who we are.

A

We must enforce some form of identity,, something that really certifies that we are who we claim. We are.

A

And that one thing in our case is a passport.

A

A passport is a document that effectively allows us to remove trust from the security system that we implement as.

A

Passengers entering your country and the passport allows allows the officer to determine,, with no mistake,, almost no mistake,, that we really are, who.

A

We claim we are because it certifies our identity.

A

So in the in my core services, effectively, essentially,, we have to implement a form of a virtual passport that we can.

A

Rely on in order to be able to certify that our services really are who they claim they are.

A

Likewise, in the real world,, we have something that tests our identity.

A

Likewise,, we need to have the same thing in our microservices.

A

Effectively, we we need, we need to have those virtual passports for our services.

A

So let me tell you why, with a more practical example.

A

We're going to be looking at a very simple application,, a marketplace: application that, like amazon,, like ebay,, that allows users to be able to search for items.

A

And then purchase those items.

A

if this application is a monolith, every resource that we create,, the users,, the items,, the invoices, anything that's part of the monolith.

A

Can be accessed by any other object within the same code, base.

A

So typically,, all of these resources are going to be encapsulated into objects.

A

If you use object, oriented programming that will expose initializers and functions that any other object can.

A

Consume in order to change the state of these resources in the first place.

A

So if we're building a marketplace and and at one point one of these users is going to be purchasing something,, we must create an invoice.

A

In order to do that,, we would be initializing a new invoice object that we would be storing into our database.

A

So typically, this really means that everything can consume, can invoke everything else, anything can create, delete or update any resources.

A

From anywhere else in the code base in the monolith.

A

Now,, there are ways that we can restrict access to resources,, think of public or private or protected access level, modifiers or.

A

Package level visibility., so there are ways we can restrict this., but typically anything that we can do,. It's not going to be very secure.

A

Everything that we do is going to be one comment away from being disruptive.

A

So this is not a security model that we can trust in order to enforce a strict security into determining what resources can do,.

A

What operations on what other resources.

A

In a monlith,, a good mindset to adopt, when we think about our resources, is that essentially anything can access.

A

Everything else. and even those access, modifiers, limitations that we may put in place can be worked around very easily in a large.

A

Codebase, where many people are working on the same application.

A

So with microservice,, instead of having every resource, being in the same code, base, we're going to be having these resources being decoupled away from that one large monolith.

A

Into separate services. now,, each one of these different services is going to be exposing an api,. An api that can be restful, can be. Grpc, can be really anything that.

A

We can consume over the network that would allow another resource, another service to be able to change the state of of another service.

A

And this really means that we are replacing those function, calls within the monolith with whichcalls among all the services that we create.

A

Now by default,, this doesn't change our situation.

A

Effectively without any other check or security in place,, anything can make a network request to the api of another.

A

Service and then change the state of the resources within that other service that we're consuming.

A

So without there being anything in place, technically we haven't fixed any problem. Here.

A

We have the same situation as the monolith,, except that this problem, the security problem, runs over the network as opposed to running inside the same codebase..

A

The the the gotcha here is that, because these requests are now going going over the network,, we.

A

Can adopt software that we are familiar with, that can operate over the network layer to block access or restrict access.

A

To certain operations, without necessarily having to reinvent the wheel from scratch.

A

So, in order to determine the security rules among our services and determine, for example,, that a service can do something on this service, but not of these other service,. We.

A

Must essentially do a couple of things., we must create permissions and we must enforce those permissions.

A

So, for example, we may want to allow the invoice service to consume the item. Service,, but not vice versa..

A

Like in the following scenario that I've described in the slide.

A

Now,, these checks can be done by our services themselves or really anything that's on the execution path of our requests,, but it has to happen. Somewhere.

A

And here comes the biggest problem of all before we even think about enforcing permissions across our services to restrict what they can do,. We must, as a.

A

Prerequisite, have a reliable way to identify if the service that's making the request, really is the service that's making that request.

A

We must have that virtual passport that identifies all the services in our infrastructure.

A

Identity is essential in any modern application, in any modern architecture.

A

Because without identity, there is no security.

A

Without identity, we would be reintroducing the concept of trust,, which is exploitable.

A

So, in order for zero trust to be implemented,, we must assign an identity to identify every service instance. That will be.

A

Used for every request that happens within our systems.

A

And this identity will become that virtual passport that we need for the request.

A

That's going to be confirming that the originating service really is who they claim. They are.

A

And in order to implement zero trust,, we can use a mutual tls to assign this identity in order to provide both the.

A

Identity and the encryption to every request that our services are making.

A

Now, when I said before that, if we go over the network,, we can reuse networking technologies that the world has already been using since a very long time.

A

To enforce zero trust security,, I was really talking about tls in these kind of identity, really.

A

It's something that's very common. so, for example,. When we go to a typical website, in this case, google dot com,. We know that the identity of google is.

A

Being certified by the certificate that's being associated to the domain.

A

And in the case of microservices,, we can use, subject alternative names (sans) in order to associate.

A

A name to any certificate that is going to be assigned to any outgoing requests from every service.

A

To recap,, as we transition to microservices, we're going to be having different services that are going to be in charge of different resources in.

A

The big picture of our applications.

A

In order for us to determine what services can consume,, what other services,, we must assign an identity,, a virtual passport to every request that the.

A

Services are making so that upon that identity, we can then verify if that service is allowed to make the operation it's trying to make or not.

A

In order to create this identity,, we can leverage something that we've already been using in our industry: certificates that are going to be associated.

A

Across the board, across every service, for each request that those services are making.

A

And that service name can be part of a very specific field,, an extension of our certificates called san,, which can identify the service.

A

Name so that when we implement the checks on the receiving end of that request,, we can determine that the service name matches the service name in the.

A

Certificate., therefore, that service can now execute these set of permissions or not.

A

Now, this sounds very complicated,, but in reality, there is going to be tooling in patterns,, like service mesh,. That can help us do all of this. In one.

A

A

we're going to be looking at a more practical example in just a second on how service mesh can help us with this.

A

San is an extension to the x509 certificates that allow us to assign a custom value to to.

A

The certificate., the custom value, could be, for example, a service name.

A

The service name can be one of those custom values assigned with a certificate that we can load and read on the receiving end of that request from the service that's receiving.

A

That request. and then once we do have the service name,. We can finally perform the checks that we want to apply.

A

Now,, there is a lot of infrastructure that goes into this, because not only we must, you know, create those certificates,, not only we.

A

Must associate to the sans to each certificate,, not only we must create the permissions,, but we must also check for those permissions, and we must check that. All of this happens in.

A

A safe and reliable way across any technology or any platform or any programming language that our application teams are using when creating their services.

A

One way to build this would be to effectively create a library that our teams can leverage in order to generate the.

A

Identity every time they they make a request to another service.

A

But that would be very dependent on the programming language and the framework that the application teams are using.

A

Plus,, this is not going to be their job..

A

The job of the application teams is to actually build the applications themselves, not to secure the network or the infrastructure.

A

Architects can provide the application teams with the underlying infrastructure that out of the box, is going to be generating those certificates, assigning those identities.

A

And verifying the permissions across each request that the services are making.

A

And we can do that with service mesh.

A

Service mesh allows us, as infrastructure architects, to provide all of this as a service to the application teams in such a way that the application teams don't have to worry.

A

About any of this., they just make the requests across their services and, by default,. Those requests will be secure, encrypted and.

A

The security of those requests will be enforced with the traffic permission, checks that you decide to set up.

A

And at kong, we have built a service mesh called kuma that we have donated to the cncf foundation.

A

Therefore, kuma is a neutral, open technology and product that we can use to create a service mesh that, among many things, can.

A

Also enforce zero trust security in one click.

A

There is much more to kuma.. There is the observability component of it.. There is the routing component to it.. It's a full service mesh that does all sorts of things.

A

But one of the primary use cases for kuma really is the implementation of zero trust. The security in one click.

A

So kuma is leveraging envoy data plane, proxies to enforce the identities and to enforce the permissions.

A

That we're going to be setting up in the control plane.

A

So kuma effectively is a control plane that implements the xds api of envoy in such a way that the data plane proxies can run alongside our services.

A

On kubernetes and virtual machines or hybrid.

A

So this is a platform agnostic service mesh that can run pretty much anywhere and we can use the control plane, kuma itself,, to determine how we want the.

A

Certificates to be issued, to be rotated,, how do we want them to expire, and how do we want to use permissions checks to be set up as well as enforced.

A

. and when, since we released kuma in early 2019, today, there is more than nine hundred plus organizations in.

A

The world, enterprise organizations in the world that are using kuma to to do exactly what we were just talking: about,, implementing zero trust, security,, but also capture the.

A

Observability of the request that we're making, as well as the discovery and so on and so forth.

A

We can have effectively kuma running on both kubernetes and.

A

Virtual machine based workloads., it can run in a standalone mode, in a single zone, in one kubernetes cluster, for example,, or it can run in a multi zone,, which means that we can out of the.

A

Box support the multiple kubernetes clusters, as well as we can support hybrid vm based environments and kubernetes clusters.

A

We call it the universal service mesh because it runs everywhere.

A

And although we do use envoy as the data plane proxy technology,, there is no envoy expertise that is required to get up and running with kuma.

A

So when we use kuma,, the envoy complexity is being encapsulated within our kuma decoupling process in such a way that no.

A

Expertise is required., although if we do want to go a lower level and change the low level settings of envoy,, we can certainly do that via the proxy template policy that kuma offers to the end.

A

User. kuma supports multimesh.. This is one mesh that can we can deploy once across any zone,, any cloud, any cluster,, and then, on top of this one deployment of the service mesh,, we.

A

Can create, as many virtual service meshes as we want.

A

Each one, backed by its own certificate, autoric.

A

Now the certificate autoric is very important for zero trust because the certificate authorityis, what is going to be used by kuma to generate the data plane.

A

Proxy certificates that are going to be associated to each replica of each service so that every request that we're making in our systems within the mesh is.

A

Identified and secure., so the virtual passport, in this case, is being created by that data plane proxy. That runs on top of envoy,. But it's being orchestrated by the control.

A

Plane that connects to all of these data plane proxies running on top of on envoy.

A

So this entire lifecycle of generating the certificates and replacing them and even the provisioning of the certificate autoric.

A

Itself,- all of that can be automated so that we don't have to worry about it.

A

And, like I said, with kuma,, we we can do much more to it.

A

Of course, zero trust security is one of the biggest use cases for kuma,, but we can use it to connect and discover services across any application that things are.

A

Creating. we can run across any platform. Therefore, all that kuma provides can be distributed across any application. The organization has been creating.

A

. the new ones built on kubernetes and the old ones, perhaps built on top of virtual machines.

A

As well as it supports single and multi zone deployments in such a way that the complexity of running a distributed service mesh across multiple clusters,, it is.

A

Completely taken away from us., we don't have to worry about it. the same way. We don't have to worry about implementing zero trust security if we use kuma .

A

The same the same way, we don't have to worry about distributing the service mesh across multiple environments. If we use kuma.

A

And kuma does that by supporting the multi zone deployment,, which allows us to not only propagate the service mesh policies, as well as the security.

A

Configuration across each zone that we want to support and make part of the service mesh by adding the global and remote control plane, separation.

A

But it also automatically connects the services from one zone to another, from one cloud to another,, from one region to another, without us having to worry about building the.

A

Discovery in the first place. every time there is a service that belongs to kuma in any zone, that service,, if zero t rust is enabled, will have that certificate that allows us to.

A

Create an encrypted infrastructure with identities in place, in order for us to enforce permission, checks on every request.

A

And all of this is made very simple by the support of native kubernetes resources,, as well as the support of a gui,, as well as the support of.

A

Native cli that allows us to understand really how many certificates we have when the certificate was generated, when it was rotated,.

A

And much more to it when it comes to routing observability and so on.

A

So we're trying to build a service mesh, that's easy to use.

A

That's not complicated. that can run everywhere., kubernetes and vms, that in one click can enforce zero trust. Security.

A

And zero trust really is being enforced. Thanks to the policies that kuma provides.

A

This is an open source project, by the way., so you can go today on kuma.io and you can look at the getting started and get up and running with zero trust security in a second.

A

And we can see here that, among the policies that we have, there is a few security policies like mutual tls and traffic permissions.

A

And these are the two policies that we're going to be using to enforce zero trust security across our systems.

A

With mutual tls, we're going to be updating our mesh objects,, so this is a kubernetes example,we're going to be updating our mesh objects with the mutual policy.

A

In such a way that we can determine how we want to generate the certificate authority and how we want the data plane proxy certificates to be generated out of that certificate.

A

Authority and how often they should be rotated.

A

So this is all you need to generate a built in certificate authority that will provision the root certificate and key that we're going to be using to then automatically issue.

A

Certificates to each data plane proxy, you have running across any zone, any environment, inyour organization.

A

And kuma is going to be in charge of rotating those dataplane proxy certificates every day by using the rotation property that we.

A

Have here in this example.

A

and it doesn't matter if we had one data point proxy or a thousand dataplane proxies, kuma will take it from there and automatically issue and rotate those certificates.

A

From us and for us., and if we do not want kuma to generate the certificate authority by itself,, we can provide the system with our own certificate authority. If we.

A

Want to reuse an existing one for our infrastructure.

A

And then, once this is done,, we can then apply traffic permissions that would allow us to determine on top of those certificates and those identities,. It would allow us to.

A

Determine what are the permissions that we want to enforce and what services are going to be able to consume other services.

A

So in this case, there is an example here in front of you of a traffic permission policy that allows us to execute all traffic across any service to any service.

A

Now, of course,, you can restrict that in such a way that only specific traffic paths are allowed.

A

Now,, this is very powerful, because effectively all we need to do is install the mesh, enablemutual tls and create the traffic permission.

A

And just like that,, we have zero trust security implemented across the board.

A

In kong mesh,, which is the enterprise offering built on top of kuma, that kong provides,, we can also, then, on top of all of these apply opa.

A

Policies that would allow us to even further determine what are the entitlements that our traffic.

A

Should enforce when generating requests from one service to another service.

A

So, with mutual tls and traffic permissions,, we can create those simple rules to determine what is allowed to consume.

A

Other services., but then with opa we can also, in a more fine grained way, determine what operations within those services we can.

A

Apply., all of this is being offered with a native interface that runs on kubernetes and virtualmachines.

A

All right,, so today we have explored that as we generate more and more micro services,, we generate more and more connectivity among them.

A

And, and this is a chance for us to improve the security of our systems by leveraging existing networking capabilities that the world has been using since.

A

Forever to assign identities to our services and then determine how those services are allowed to consume other services.

A

We've explored that trust is an exportable component on every system,, not just technological systems,, but also.

A

Human processes, like immigration at the airport.

A

Trust cannot be relied upon., we must have a passport or a virtual passport in this case that certifies the identity of every request.

A

So that, on top of that identity,, we can determine what is allowed and what is not.

A

And we looked at service mesh and kuma specifically to implement zero trust without having to worry about generating the certificate, setting up the infrastructure.

A

All comes out of the box with a few native resources that we can apply in order to have zero trust security across any environment,. Any workload, across.

A

Any cloud,, including kubernetes and virtual machines.,.

A

So, thank you so much. and you can always get in touch with the kuma community at kuma.io..

A

There is a slack chat that you can use to ask questions to get up and running.

A

There is a getting started on the website that explains how to start using the zero trust,, the security features and more that service.

A

Provides. and if you are looking into the enterprise offerings around service mesh, that kong provides,, you can take a look at kong mesh,, which is built on top of kuma.

A

And extends kuma with even more enterprise capabilities.