 Thank you all for joining us today. My name is Vanil Naruna and I work with Manish on Tanzer Service Mesh at VMware. And today, we will be talking about some security patterns in the context of a 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 Ingress 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. 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 Ingress Gateway. 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. What we do here is that we provision a certificate for the Ingress Gateway. And these are programmed into the Ingress Gateway by the cluster administrator or the managing mesh. And the user can use these certs to perform 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 certs for both the user requesting a particular endpoint and the Gateway itself. The third pattern here is called pass through 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 Ingress is looking at the SNI header and forwarding these requests to the destination service. And the challenge here is that the Ingress Gateway cannot do path-based routing because it only looks at the SNI header and not the request itself. The fourth pattern here is external authentication. Here, what we do is we embed certain tokens like a Jot 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 responds back to. Now that the request 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. The first pattern 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. 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 are MTLS encrypted. And this pattern actually allows you to migrate your workloads from a plain text mode to MTLS. 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 other CA. And now you can also have strict MTLS between these two services. This basically means that you cannot have plain text communication between these two services. The third pattern here is called workload authorization, where you essentially perform our 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 service account on these services and enable these RBAC policies. The next pattern here is end user authorization. Here what we do is we again look at the JOT token in the incoming requests and the English gateway can validate and forward these tokens to the destination service and now the destination service can have certain rules. For example, in this case, we want the claim in the JOT 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 principal 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. Last but not the least, this is a very interesting pattern where you can extend these sidecar proxies using WebAssembly. 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. Now that the traffic has entered the mesh, it's time for us to look at some egress gateway patterns. So as the requests are leaving this mesh, you can totally deny such requests by just enabling a flag that says registry only in the case of Istio where all the sidecars will deny all endpoints outside of the mesh and only the ones that have been registered in the registry will be allowed access. 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. 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 mesh is 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 egress which is very similar to the TLS origination, just that we will also verify the destination workload. Now we'll hand it over to Manish who will be talking about some advanced patterns in ServiceMesh. Thanks Venom for going to an example to show how ServiceMesh 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. 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. So how do we extend ServiceMesh and how do we secure communications between services across clusters, for example? The two common patterns that we see are that in-depth 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. 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. In both these cases though, there was a requirement of a common group where the local CAs on individual clusters now act as intermediates. This is normally done by some kind of automation or an external global control which manages and extends the ServiceMesh. Now getting back to within the mesh, we've talked about how we can define fine-grain R-back and A-back by utilizing the workload identities provided by the mesh or the intrinsic attributes that have either been relayed through the transaction or gathered by inspecting the traffic at every hop. We've also seen a pattern where the ServiceMesh capabilities are being extended to derive more intelligence using third-party proxy filters or plugins or analysis tools which enable use cases like WAF, thread detection or even compliance checks. The cells 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 end-to-end transaction which is comprised of user attributes, the data that services accessing view of the user, thread and anomaly detection and even compliance level of the resources that participate in this transaction. This kind of enables ServiceMesh 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.