Cloud Native Computing Foundation ServiceMeshCon North America 2020, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Service Mesh Security in a Nutshell - Venil Noronha & Manish Chugtu, VMware, Inc.

Description

Service Mesh Security in a Nutshell - Venil Noronha & Manish Chugtu, VMware, Inc.

Security is one of the greatest challenges in the cloud-native world today. Service meshes promise several benefits including better connectivity, and observability, and most importantly security. Securing a cloud-native service involves securing it at several levels i.e. at the perimeter (ingress/egress gateways), when accessing other services, when persisting data, when processing requests, etc., and using a service mesh one can address several of these issues in a consistent and maintainable manner. In this talk, we will present some of the key patterns that one can use for securing cloud-native services when working with north-south and east-west traffic. We will talk about available TLS choices (passthrough, mTLS, etc.), AuthN/AuthZ constructs, JWT support, and extension mechanisms within Envoy/Istio that you can leverage for building customized policy frameworks. We will also discuss application security in the context of multi-cluster service mesh deployments. Come join us!

A

Thank you all for joining us today. My name is vanilla and I work with manish on transit service mesh at vmware, and today we will be talking about some security patterns in the context topic service mesh to begin with here is a very simple system where a user is sending requests to a service and those are being routed into the cluster through the ingress gateway. Now the english gateway then forwards. These requests to a destination service like the user service or the location service, and these can in turn make requests to each other.

A

The user service here is also storing data in the database, while the location service accesses a third party api and therefore those requests are being routed outside of the cluster through the iges gateway.

A

Let's now look at how we can secure the ingress using some of these patterns. The first pattern here is very simple: it's called authentication with tls.

A

What we do here is that we provision a certificate for the english gateway and these are programmed into the ingress gateway by the cluster administrator or the managing mesh, and the user can use these search to perform.

A

Tls communication with the ingress a slightly enhanced version of this, is authentication with mtls, where we also have a certificate for the requesting user, and you can think of this user as some sort of a mobile client or a service that we want to establish trust on and therefore we have search for both the user requesting a particular endpoint and the gateway itself.

A

The third pattern here is called passthrough at the ingress, where the tls is not terminated at the ingress itself, but it is forwarded to the destination service, in this case the user service. So the user is sending requests and the english is looking at the sni header and forwarding these requests to the destination service.

A

And the challenge here is that, in this gateway cannot do path based routing, because it only looks at the s header and not the request itself.

A

The fourth pattern here is external authentication.

A

Here what we do is we embed certain tokens, like a jaw token or some other kind of a token, in the user's request and the ingress gateway can then forward these tokens to a third party identity provider, which can then verify these tokens and return a response to the gateway and the gateway can then consume this response and forward or deny the request based on whatever the identity provider response pattern.

A

Now that the request enters has entered the mesh, we can look at some of these mesh workload patterns which we can use for securing the services within the mesh.

A

The first pattern here here is called permissive mtls. What this means is that the location service here, which has this setting, enabled, will accept both mtls traffic as well as plain text traffic.

A

So the user service in this case is sending plain text requests to the location service which is okay and it accepts those, and it will also accept any requests coming from a source service that our mdl is encrypted, and this pattern actually allows you to migrate. Your workloads from a plain text, mode to mtls.

A

For example, the user service here can now migrate into mtls by having its own cert provisioned by the ca in the mesh or some some other ca, and now you can also have strict mtls between these two services.

A

This basically means that you cannot have plain text coming in communication between these two services.

A

The third pattern here is called workload: authorization where you essentially perform r back, so we want to prevent access on the database service from any service. That's not really a verified source. In this case, we want the user service to access the database service, but not the location service. We can use the namespace or some service labels. We can look at the ip address or we can even look at the the service account on these services and enable these are back policies.

A

The next pattern here is end user authorization. Here, what we do is we again look at the jot token in the incoming request and the english gateway can validate and forward these tokens to the destination service, and now the destination service can have certain rules.

A

For example, in this case, we want the claim, in the job token, to at least match principal user here, and such requests coming from this particular user will be allowed at the location service, because the principle here is matching, but in the case of the user service we don't allow such requests, because the user only has a claim of principal user, but we require principal admin for the user service.

A

Last but not the least, this is a very interesting pattern where you can extend these sidecar proxies using web assembly, and what this means is that you can create your own custom plugins or you can have custom policies built into these sidecars and the incoming traffic can then be validated and authorized based on custom attributes.

A

Now that the traffic has entered the mesh it's time for us to look at some egress gateway patterns,.

A

So, as the requests are leaving this mesh, you can totally deny such requests by just enabling a flag that says um registry only in in the case of istio, where all the side, cars will deny all end points outside of the mesh, and only the ones that have been registered in the registry will be allowed access.

A

The next pattern here is called tls pass through. What we do here is we have tls origination done at the location service and the egress gateway is simply doing a pass through.

A

The next pattern here is kind of interesting, because security administrators can easily apply this on the egress gateway. So even though the traffic within your meshes plain text, all the traffic leaving the cluster can be encrypted using tls using this tls origination at the egress, and the last pattern here is mtls origination at the igris, which is very similar to the tls origination.

A

Just that we will also verify verify the destination workload.

A

Now I will hand it over to manish who will be talking about some advanced patterns in service mesh.

B

Thanks reynold, for going to an example to show how service mesh provides security at various levels, whether it's to do with certificate management or authentication at an end user level, or between two services within the mesh or authorization to control access to the services.

B

But what comprises of an application? These days is a little complex than the example that we talked about. Usually it is a set of services which are not only deployed and communicating within a single cluster, but across multiple clusters, clouds or even infrastructures.

B

So how do we extend service mesh? And how do we secure communications between services across clusters, for example?

B

The two common patterns that we see are that ingress and egress gateways through which the communications happen are mutually authenticated and the traffic is encrypted between them. The traffic between the services to the gateway within each of the clusters may or may not be encrypted.

B

The second pattern that we see is that services themselves are mutually authenticated across clusters. In this case, the gateways are configured in the pass-through mode and routing is done based on sni.

B

In both these cases, though, there is a requirement of a common group where the local cas on individual clusters now act as intermediates.

B

This is normally done by some kind of automation or an external global controller which manages and extends the service mesh now getting back to within the mesh. When we talked about how we can define find vein, our back day back by utilizing the workload identities provided by the mesh or the intrinsic attributes that have either been released through the transaction or gathered by inspecting the traffic at every hop.

B

We're also seeing a pattern where the service mesh capabilities are being extended to derive more intelligence, using third party proxy filters or plugins or analysis tools which enable use cases like laugh thread, detection or even compliance checks.

B

This helps in defining advanced authorization policies which not only take into consideration the intrinsic service attributes like we talked about, but also take into consideration the whole security posture of the complete and doing transaction, which is comprised of user attributes in the data. That service is accessing view of the user threat and anomaly detection and in the compliance level of the resources that participate in this transaction.

B

This kind of enables service mesh to do dynamic and continuous risk assessment, and we can see how it evolves: security towards a continuous risk based zero trust model. With that we come to the end of the presentation. Thank you so much for joining and for your attention, and we hope you found the session useful.