 Thanks for the introduction, I'm honored to be here talking to you guys, the topic for the next 15 minutes or so is going to be how we aspire at Nginx and F5 and the CRD that we developed as part of that work. My name is Faisal Manmin. I work at F5, F5 acquired Nginx, the open source web server that I'm sure a lot of you guys are familiar with, that acquisition completed about a year and a half ago now at this point. So now we are the Nginx business unit within F5. That lovely little girl there is my almost five-year-old daughter. My agenda for today, first I want to talk about how we aspire at Nginx and F5 and the value that we've gotten from the software. And then talk about the CRD that we push back to the community and the reasons for creating that and the value that's provided to us. And then a demo of that CRD in action and then we want to talk a little bit about what we're going to be doing going forward. So what we aspire for is we implement it or integrate it rather within our service mesh offering. So we recently about a month ago put out our service mesh offering that uses Nginx as a sidecar proxy in data play. And as part of that offering, we deploy Spire and we use Spire for a lot of different things within our service mesh. The original use case for Spire and why we started investigating in the first place was for NTLS. So we use Spire to distribute the certificates that all our sidecars then use to do secure communication with one another. We use Spire at the identity level as well. Spire provides the identity for each of our sidecars and then we allow the administrator to specify policies based on that identity to limit who can talk to who. So service A can talk to service B but not service C, for example. So a lot of that complex policy we support and we run that all through Spire with data plane enforcement by Nginx. We use Spire to manage our webhook certificates. So Spire works really well for that use case that we use the Spire certificates and then we use Spire and the agent of course to rotate the certificate as well as the CA bundle within the validating webhook configuration so that helps keep the webhook certificates fresh. And of course we also use Spire for our API server certificate and that's this little white box right here. So our API server is what handles for example our mutating webhook that ejects the sidecars and what also pushes out the policy to our sidecars so it's a big component in our control plane and of course we need a certificate to protect that and for that certificate we rely on Spire to distribute it and rotate it for us. So we use Spire to a lot of different points within our service mesh. So moving forward, as part of this work we created a CRD for Stiffy. CRDs are very ubiquitous of course within the Kubernetes world, they're very versatile, very useful tool for extending Kubernetes and providing additional integration points with Kubernetes. And so we've been able to leverage the CRD framework to better integrate Spire with Kubernetes. So why use a CRD? And so this the CRD that we developed as part of the Kubernetes workload register, if you remember from Augustine's presentation earlier he mentioned that there was a new CRD mode that was released as part of Spire 0.11.0 so that's what this is. So a lot of benefits you get from the CRD, my favorite one is the kubectl integration so looking at that YAML code in the gray box right there, you should see a lot of the standard fields if you create Spire entries on the Spire server with the Stiffy ID, the parent ID, the selectors. So with the CRD you can now define those as a YAML file and then kubectl apply them, kubectl edit, kubectl delete so you can manage the full lifecycle of Stiffy IDs, apply a registration entities right from the kubectl command line. We support auto generation of Spiffy IDs as well so you can have the Kubernetes workload register auto issue certificates based on pods being created and then clean up the Spire server when they're deleted. We do parenting of the Spiffy IDs to the node and so that gives an extra level of security that the particular Spiffy ID is tied to that node so you can use that workload on a different node that is not authorized to run on. We add DNS names to the certificates and that was actually our main reason here for developing the CRD is that Dengenex as part of MTLS certificate verification on the client side requires that the server certificate have a DNS name so we needed that DNS name populated in an automated manner and so the CRD system along with the endpoint reconciler really worked nicely for that use case. It's fully event driven so it's very resource efficient and as I mentioned earlier it's a standards based solution CRDs are just a standard way to extend Kubernetes and it's nice that we're able to plug into that type of framework. With that I'm just going to go into a demo of the CRD in action so I'm going to switch to my desktop here and so our demo here is built on the simple PSAT example here that's available within the Spiffy GitHub repo under Spire examples okay it's simple PSAT so if you go here there's a nice little quick start for PSAT and so what I'm going to do is build on this PSAT and I have a quick start guide available right now it's in my fork but we have a PR open to merge this upstream but so I'm going to go over here so first thing is here so I'm just starting off with just the Spire server and agent deployed in this case I have a genome cluster so first thing I'm going to do I'm just going to my quick start guide and supply a set of the animals and nothing out of the ordinary here we need to apply a cluster all a config map validating rubber configuration and of course the actual custom resource definition so I go ahead and apply all that and that goes through the next thing I need to do is update our Spire server stateful set so our Kubernetes workload registrar runs as an additional container within the Spire server stateful set pod and so what I'm going to do here is go ahead and update that stateful set and so now if I go kukut I'll get pods minus and Spire we'll see here that it's deleted the the old Spire server pod but just one container now we're creating a second one that takes a minute or so to set up so while that's running through I was just going to show you the apple file that I was going to apply so here we have just a very simple spiffy ID parented here to just the Spire server parent and has a few selectors default namespace name of the pod whatever and that can be whatever your pod name is and of course just some standard spiffy ID so now I'm just going to quickly make sure that everything is up and running so now we see here that there's two containers now running within this pod one is the Spire server of course one's the registrar that does all the logic of taking on the CRD and converting that to Spire administration entries so now I can go kukut I'll apply minus F S YAML and you can see that YAML is created and I can go kukut I'll get spiffy IDs and we can see here that my new spiffy ID was created like you can do the you know kukut spiffy IDs minus YAML and we can see that you know Kubernetes of course adds a bunch of stuff to it but the spec is the same as YAML and one thing we do is we add the entry ID so this is the corresponding entry on the Spire server so that gets added to the custom resource in the status field when the actual entry is created and one other thing I can do I'm just going through my quick start guide here is I can just verify on the Spire server that in fact the entry was created I copied too much sorry I copied a little bit too much there there we go and so from you know the YAML file we did kukut I'll apply and the end result of course is an entry gets created on the Spire server and I can of course kukut I'll edit spiffy ID my dash dash spiffy ID so I can edit it I can say you know for example you don't want to change the ID on a like test I want to use test here and I can go ahead and save it and I can go look at the Spire server and I can see that it's the same exact increase of the entry ID is identical but that we have a new spiffy ID deployed so so that's the the crd inaction I'm just going back to my slide deck looking forward so I mentioned that we have a PR open and so what this PR does it simplifies the configuration of the registrar so a lot of the feedback I got the initial version that we put out was that it was too complicated because it has a validating webhook and that validating webhook needs a certificate so we did as I went back to the drawing board how we can remove that requirement and so now we're going to use Spire itself to populate the certificate for the validating webhook so that greatly simplifies the configuration and we're combining that PR with with that click start guide but I put up there so it makes it very easy for you guys to test this out and and see how it works for you we're looking into SAT attester support so right now the the registrar just supports PSAT but a lot of our sales engineers use kubernetes platforms like kind or the built-in docker for mac kubernetes were whatever reason we're not able to modify the api server configuration so so supporting PSAT is not not so possible on those platforms so we're looking into SAT attester support to get a broader range of platforms supported we're looking to add more dns names to certificates so right now we're just adding just the two the name of the pod and the name of the service associated with the pod but we want to fill that in with a full set of dns names available and the last thing we're looking into is updating to use the latest set of spire apis that was just recently put out with put 11.0 and if you want to try it out that link is kind of long but we're going to send out the slide decks afterward i'd love for you guys to try it out let me know what you think is it good is it not good do you like it do you not like it um any feedback uh it's definitely welcomed all right thank you guys for your time i really appreciate it and um let's see if there were any questions oh great thank you so much facial especially for the demo as well any questions for facial so far i thought i saw one or two but i don't see yeah maybe they message you privately um if you can just double check too i know a few of the attendees have been um doing private questions too a bit great you might have had other slides but not sure what's the best place to direct folks to take a look at the code there it is sorry it's it's um i got some question here so have you have you looked at service have you looked at service meshes like istio uh kuma etc so of course we have looked at at all those um you know as part of making our own service mesh solution right why do we why should we add to it already crowded space where there's like a million service mesh offerings um it's our initial effort was to try to plug it into istio and use engine access it's like our proxy within istio but that that effort um had a lot of complications with it and so we just decided at some point that it it'd be better um to create our own our service mesh offering and and our main differentiation with our service mesh offering is that we're trying to make it uh more open so if you saw with our little block diagram we had brafana prometheus spire obviously the reason i'm here talking today so it's very very much using a lot of the open source components that you guys are familiar with you're also trying to make it very simple very easy to deploy very easy to use so those are our two key differentiation points as to why we're creating our own um i think thank you for sharing the link in the chat window um and and and festival you're around right if people have questions they can slack you or they can put in the chat window correct yeah i'm around slack me on the stiffy slack i'm in there and and i'll be monitoring um this chat window the rest of the day thank you guys appreciate the appreciate the time thank you so much