 My name is Amin Kinabi. I work in the VMware and the standalone Tanzu Kubernetes Grid. I'm the Tech Lead for the compliance node and for Windows offering as well. Today, I'm going to speak about the GRPC Security and Service Mesh in particular in the Istio service. I have like 20 minutes and I figured out this is not much time to cover the entire presentation, so I have a few demos that I will skip. But you can download the representation in the sked.com and see the demo live later. For that end of today, I will start talking about the Mesh and Zero Trust Security and how Zero Trust is something that was adopted by the entire cloud native ecosystem as a standard. Then I will talk about Spiff and Service Identity. We'll look at the Spiff specification and Spark implementation inside the Istio. We're going to the Istio, Istio has traffic specifically for GRPC. We'll take a look in the evolution double quotes or the latest things that are happening inside the Istio. We'll go in the GRPC Proxeles. We saw like the keynotes before. There are some things going on in the Proxeles side as well, and we're going to go in the ambient mesh. That's where I'm more involved in research more, and we hope we can conclude this in the time. So introduction here, the Mesh and Zero Trust. So why does it matter? Istio provides security features that are battle tested. It mitigates like the external and external, internal as an external threats that you have in your platform, in your architecture or enterprise. Service Mesh can give you ownership and authentication and authorization layer, and they are the couple from the development experience. And you are using this kind of architecture. Istio provides audit protecting. So it gives you protection against no repudiation. You can have logs and you can have metrics that proves your service was accident. With all these capabilities, you have like a strong GRPC functionality or architecture that complies, compliant with the Zero Trust security specification. So what is in the end of the day, the Zero Trust security thing that everyone is talking about? There's some Gardner conversation before all this stuff that started this movement, but the main pinpoint is this NIST Paper SP800207, and the Zero Trust model assumed that our attacker is presenting our enterprise on the environment, and you are responsible to secure all the pieces, all the assets inside your architecture because you don't trust anyone. Like in real life. So it enforces the principle of least privilege for network and applications, and it's not a single architecture, but as guiding principles for workflows, system design and operations. Zero Trust and service mesh and CNIs and all these products and vendor are not silver bullets. You just find like best practices and good guides on how you can implement this kind of architecture. So it's not a product that will define how you protect your system. It's like a lot of factors that you gather and with the best practice give you the correct protections. If you get the spec and you get this paper, you have some interesting principles of Zero Trust. I highlighted some ones that match with this presentation. The first one is four. The item four is access to resources determined by the dynamic policies and may include other behaviors and environmental attributes. So the policies according to the specification are set by subject or the entity that's performing the action. An action, the action that's been performed by the subject and a target, the object that the action has been performed upon and a condition. So this is like basic traits that you need in your policy and is defined by the principles by the spec. Other point that the 50 point here is the enterprise monitors and measure the integrity and security posture of our own and associated assets. One important and interesting part is the auxiliary components. So you have not only your Zero Trust model and architecture, you have auxiliary components that creates and enhance the protection and they include line enterprise, public interest structures, CMs, threat and intelligence feeds, networking and system logs, active logs, all these other components that came up and make your architecture more secure. So if you read the documentation like the spec, you can see they define two main pieces in this diagram. And this is not a coincidence that these two implements this because it's like a full telecom control plane data plane model that Kubernetes implements as well. They define this as a policy decision point or PDP where your control plane or is to be in this case allows you to insert via the CRDs or manage the entire data plan is like the brain of your architecture. So is to be makes this role of policy in giant and policy administration. The other side of this is the data plan where your proxy has like an envoy in the traditional architecture and you can consider these as a PEP and this is responsible for enabling monitoring and managing the connection between the enterprise research and the subject that our policy will be applied in the as they're going to see in the front with the connecting like and being managed by the ECD, ECD and envoy communicate by the XDS protocols, a bunch of protocols that they communicate translate like these policies and other things like secrets and routes and how you configure dynamically your envoy and in your data plan. Cool, that is one part that's important here. That's the core of what every everyone is using nowadays. I think Google Clouds implementing a lot of things in the Spiffian side as well. So Spiff is like a service identity. This is like the core of how we start to identify our services. So you have your general PC workload and Spiff is a way for you to identify how your workload is identified by other peers. Spiff you use the Spiff ID. That's the format of Spiff ID. You have a trust domain. You have a workload identifier and you can, you have like two ways to change the information across your cluster. You have like X509 certificates and then you have job tokens. You can use like both E2S traffic or NordSoft traffic using these two ways of identifying it with the Spiff ID. Good news is that the envoy needs to use the Spiff for mutual TLS authentication and this is transparent when you start to use in this thing. So when you are you install E2Nior closer, you have like an authentication, an encryption and authentication by default for the peers that are connected on the services that you have on inside your cluster. Okay, so Spiffy is the specification. You can get like, there is a good book around on the Spiffy website and the Spire is the implementation of that. So someone implemented this Spire outside the entire issue thing but E2Nior implements their own Spire based on the Spiff implementation. So the Spiffy authentication, the attestation works for both node and the workloads. Those are the two things that you need to attestate or authenticate. These pieces are plug-able, the servers and the agents are plug-able. The first thing that goes is the node attestation. It's required for the agent to authenticate and verify itself when connected to the server. And the second is the workload itself that you need to pass an authentication in the Spire server API. This is a more complex example. So we have like, you have like two proteins in the corners and the middle you have the backend and you have this in VoIPROX in the middle of them doing this filtering and applying and having these policies where you can identify what each workload is and which one is authorized to access. In this example here, you have an open regular implementation here, filtering of like, okay, do you have a valid path? Is this a request method? And you have like Spiffy ID for this particular service that you are allowed to access. It's like the initial implementation in the website, you can see the example, you can download these and run your kind cluster and understand how these pieces works. So after that the evolution, I don't know if this evolution, the history is the evolution, but you can have another implementation of VCU service mesh. And there are some options for us here in this service mesh to be compliant with this zero trust architecture. So the first thing is the continuation of the JRPC Proxolas. So the JRPC Proxolas as the other keynote was talking, you have like this library inside your own Go code. So you have like a data plane inside your own application. You don't need the proxy, you don't need an envoy anymore. And this is pretty cool. There are some advantages, but you still need to bootstrap a file and you still need the issue agent to get this information on how to connect your control plan, how you're going to connect your control plan and do the XDS conversation. The trait here is that a logical resides in the application for the control plan connection. The other thing that's going on with the serverless, with the sidecar less ambient mode here is like, you can handle all the traffic east-west without invoying the middle of that. So if you see this diagram here, you can have like is to CNI that bring up these up-tables rules and all the traffic that's inside this node is passed by the Zetano. So Zetano is a Rust demo set that runs on each node and this gives you layer for capabilities. It doesn't give you layer seven capabilities, but at this point you have eight bone traffic encryption from one side to another. You have MTLS, you have a specie ID, you have like basic authorization without any sidecar or any invoying in the game. If you want to improve like your layer seven capabilities and like filtering your own JPC policies, you can add a waypoint. An endpoint is still an envoy, but it's not like a sidecar injected in the web hook mission. When you will start your workload, you can or cannot use the layer seven proxy. So you can decouple and then if you want, you can run a deployment and you can scale this by namespace or service account instead of like having one one-on-one option. All right, so how does authentication and authorization on these two works? CRDs, so install your CRDs, you manage your CRDs and you have like four authentication, have this pure authentication CRD where you can set the mode like everyone that's being in the match needs to be strict and needs to use that. And in the authorization side, you can filter out by the policies that we saw in the beginning. So you have like the target in the selector of the match label. You have an action is allow or deny. You have the subject that's generating these, you have the principle that's generating these and you have a condition where you can filter if these rules applied or not. So in this example here, we have a service and you have a method and everything that's coming from GRPCA is allowed to pass through this selector. The selector is there for the waypoint proxy. I don't think we have the time for the memory. Let's go to the good part. So I set up here, I set up here, I need to close or kind closer locally, bring up some workloads on that. That's an example of the workloads. So what I did is like I go into one of the workloads and start to GRPC crawl for the other server. So you have here like a server, a service called GRPCB and you have this dummy server stream. And then I will apply this policy. So I have GRPCA and GRPCB and they are connecting each other via GRPC. And then I'm applying authorization policy in one of the waypoints. So this label is directly for the waypoints, not passing to the workload. And I have this principle saying, okay, everything that's coming from GRPCA going through the dummy server stream, service and method. And I need to enable the reflection because I'm using the reflection behind the scenes as well for this, this app. I apply this policy and I say everything that's coming from GRPCA, it's fine. It's good to go. So I go to GRPCB and do a request for the GRPCA and this, okay, our back access denied. You cannot go from GRPCA to GRPCB. GRPCB to GRPCA. So go over and SH into the GRPCA and go to the GRPCB and you can access that. So you're filtering by your method and you are GRPCCrolling the other side with the correct information. So let's say I changed my method here in the service and say real server is the allowed part. Go back in my GRPCA that is allowed to do the request by the subject and do try to do a request again for the GRPCB and now I have an access denied because I'm at this point filtering the layer seven GRPC methods. I roll back again. So if I roll back again, you can access this back. So concluding the presentation here, I did some tests in the consumption that is like some ratio testing, load testing validation where you can do requests and have some interesting results like super fast. Even if we are talking about like 1.9 milliseconds for like a thousand requests per second on a simple GRPC call. That's fast in most of the case. This is the traditional sidecar. We have like an employee running here for the layer four Z tunnel. We are talking about 300 microseconds. What's ridiculous? And for the JPC ProxsOS server, we are talking about 200 microseconds. Picking the right price for you. We have like those two modern ways to do things in the GRPC side and are mostly integrated with Istio. ProxsOS in the Istio side is still experimental. So if you're interested that, I think the traffic director is a better choice because it's GA already. But as you saw, it's much faster. The consumption footprints is lower. It's the couple from the control plane but couple in the code. The couple from the data plan but couple in the code. And the ambient mesh is another solution that's getting some traction nowadays. It's pretty interesting. You have more integration with Istio. Can be a good choice if you are looking for like metrics and more traffic controls and other features. That is, shoot out to Vladimir that helped me create the content. And that's it. Thanks. Hello, this is Sumanth. Have you done the testing with the traffic director similar results? Like, is there a difference with Istio? I think it's a good place for you to look around. They have a good answer about that. Thank you. And the demo you showed, is that open source or something we can try? It's on my YouTube channel. I'm maintain a repository with this make files. Make like a make file thing for Google. And then you can run all these steps. Buy yourself some kind. You just need kind. You put in the kind and K9. And one other question. So identity here at authorization, I saw that one. So how did the server identity? Is it using spiffy-based identity for the service identity? Yeah, it's by the foe. Istio gives you this by the foe. Every time you get a workload, it gives you this identity for your workload, both in ambient mesh with outside cars and the side car part. Wonderful. Thank you. So for the authorization part of it, I saw the configuration file for Istio, right? Will this be translated into an Authosy understandable policy or how does that work? This is a CRD that's translated automatic for this airbag. So this, without this part here, without the... This part here, that's layer seven. This Zetano is still can parse from only the subject. You can do layer seven on Zetano. You can do everything on Waypoint and Envoy. And you can do everything on gRPC Proxolas as well. This will be translated to gRPC Proxolas in Istio experimentally. And the enforcement happens at the gRPC server itself? No, it happens in the layer before that. So you have, in this ambient mesh, you have this Waypoint part here, that same point. It happens here, or Zetano, it happens here. This is a REST process that's running in the node. And the Proxolas, it happens in that application. Thanks. Hi. I would like to know how is the service account passwords being managed if there is any on... Password? If there is any on the Waypoint proxy? There is no password for this service account. So this is something that's cool because if you have permission, you can impersonate the service account, right? In the namespace. So the isolation is by namespace. And this is super dangerous because like, after you have this policies, everything integrate, and then you hold this namespace, you can create and replace an existing service account for your phone if you have permission to create this phone. Understood. Thanks.