 Fantastic thank you for joining us everyone as I was saying before this is the spiffy spire maintainer talk So spiffy inspire our two different cncf projects spiffy is a standard for doing workload identity and spire is a Reference implementation of that standard, but it's not the only implementation that's out there So the two of us both work on both the spiffy inspire projects at different times and have for a couple of years We're both on the steering committee for the project along with many other people who couldn't make it here today But we're here to represent the project and discuss what we're working on Collectively as a as a group lots of different projects. So Andres, yeah once a shout out for the great community effort and publishing the spiffy book the book was authored two years ago Peak pandemic the group came together over the course of two weeks Strong collaborative effort people coming from different perspectives different levels of experience and familiarity with the project Implementers adopters Folks who are helping do developer relationships around it people who had Build the project to provide a end user focused guide on all the different considerations for going from zero to production and scaling up I encourage you to Check the book online at spiffy.io slash book We also have printed copies here at the event at the control plane booth on the expo floor We are narcissists and we need a pressional slides for each of us. So Dan you talk a little about yourself, but once more Sorry about that. Yeah, Daniel Feldman. I Work at Sentoma up until very recently two weeks ago. I worked at HPE But we decided to do a startup based on workload identity with a couple of other folks from HPE Recently in the open-source world. I've been working on a six-door integration for spiffy inspire SDO support Better database client authentication And something called the Federation hub, which you will hear about soon, but isn't isn't really available yet But like I said, I just I left my day job to do a startup based on all this stuff And I can talk about the startup later if anyone's interested I'm slightly more of a narcissist than him So I need to put more things in there even though he has accomplished a whole lot more interesting things My day job is at control plane where a cloud security consultancy headquartered in London with offices in New York, New England We do audit pen testing professional services all around threat-driven analysis of cloud native components. I Am a member of the spiffy steering committee I'm also one of the four of now six of this point Technical leaders for the cloud native security advisory team Some of my published works include the spiffy security assessment spiffy inspire The due diligence for moving the projects through the life cycle not the life cycle, but the progression from sandbox incubation graduation If you're involved with a project and would like to learn what that entails I'm happy to have a conversation with you after this chat if you have any questions Through tax security I was also one of the authors of the software supply chain best practices and the secure software factory reference architecture Both of these documents are found and the tax security repo If you have been thinking around how to do workload identity but apply it to the supply chain I'd encourage you to to check this two guides excellent resources That's a little bit of the scope that that we are going to cover But yeah, certainly except for the six-door update, but certainly something I encourage you to check that out for guidance and recommended practices So recap why spiffy inspire and for a few how many of you Run spire today Show of hands Okay, how many of you have not heard of spire until you Okay, so you're new to the project And we have folks in between so the motivation for the projects that stems from Observing the evolution of software architectures and the evolution of the efforts around securing this growing systems growing in elasticity Glow growing in scale high rates of fluctuation of refactoring There's a larger number of software components that encompass distributed systems and It's no longer feasible to take a perimeter-based approach with this advent of the cloud native renaissance There's a strong need for zero trust We can no longer trust most of the software running in our company or the suppliers often times we cannot even trust our fellow employees, so we must take a Verification approach That's automated. That's API driven to assert the identities of every single component of the system and also Anything else that that component may communicate with We talk a lot about zero trust before I go to the next slide if you have a zero trust initiative or mandate a strong Foundation of workload identity is critical. You cannot attain a zero trust outcome unless you have fine-grained identities that have been determined with certainty and Unless you have a clear picture of all the actors all the system actors in an application call chain All the objects and their relationship between them. You cannot make zero trust assertions From a business perspective the promise of cloud has been developer productivity and operational efficiency Many companies particularly in highly regulated sectors haven't necessarily attained that why? Because security stands in the way Compliance is stands in the way Systems are black boxes and people in infosec third-party auditors don't necessarily have the means To look inside and see what is what? It's all it's all fairly opaque, so changing changing the notion of identifiers and Having once again that very crisp understanding of all the different objects all the different components the moving parts it's crucial to be able to inform the organization and also as as Maintainers as developers we invest a lot of time. Well, how do I teach my app TLS? How do I manage key material? How do I distribute that key material if I need to rotate it? How do I go about that? These are well understood tasks, but they're quite cumbersome, so there's a need to automate That security and offload it as a function of the platform Then we we talk about access control traditional access control and we go about well Parameter security and firewalls are not enough in these architectures But for most part we still go under the predicament of proof of possession Over recognition technology So if this system as a holder of this shared secret or this API key We authenticate it but High-profile breaches of recent times a common denominator of the entry vector has been Exfiltrated cryptographic material a leaked key moving away from long-lived secrets to a short-lived cryptographically verifiable identity solves that problem of If you're using a secret store to protect your your key material How do you how do you secure that you need to encrypt it, right? And you need a decryption key for that But how do you protect that decryption key you put it yet in another secret store and it's turtles all the way down Ultimately you end up writing the keys on paper and you go to your bank and put it in an actual fiscal vault So how do we move away from that? And so that we can read in a scan the code finger-printed Perform multifactor authentication, so we know it's provenance. We can profile it to understand what shape what size For it to transition for something we've never seen before in the system. Therefore should have no access to something that okay I see what it is Therefore here. It's its level of access more meaningful way to reason about authorization From that while we said we we have to be better about this. Let's just specify in the community What are what are the set of interfaces? APIs and documents that we will use to prove validate and obtain this workload identities that we're after and Then the spire is the software of those of specification the software that implements those of specifications So you can run that in Kubernetes you can run that on your cloud provider You can run that on-prem on different platforms And heterogeneous systems Dan so take us a little bit back of like how was the prior art and how did we arrive there? Sure? Thanks, Andres. I think you'll notice that I talked a lot faster than Andres and probably a little less organized So the history of submit the inspire goes way back we The the original thing that was very similar to spiffy inspire was that was a research project at Bell Labs around 2002 called Bell Labs factotum Which essentially did the same thing they wrote a number of research papers. It was built into their plan 9 operating system Then around 2010 a lot of those Bell Labs people ended up working at Google and Google got hacked by by someone People speculate it was the Chinese government who even knows But Google had a very strong mandate to encrypt everything so they developed this thing called the low overhead Authentication system inside Google. I haven't worked at Google, but I hear stories from people who have worked at Google which essentially was taking this this Bell Labs encryption and Putting it across all the Google infrastructure across Gmail across Google calendar Whatever their their cloud platform was at that point, which I guess wasn't GCP quite yet, but Then Around 2014 2015 you said you started to see other companies with that The ideas from Google because Google wrote papers. They didn't actually Open source any of this stuff at that point, but they wrote a bunch of papers They wrote a bunch of blog posts and you started to see other companies like Netflix and Facebook adopting the same approach of having a common authentication layer between all their different services that All their different data centers all their different applications So Netflix had one called Metatron, which again, they did not open source, but they wrote papers They wrote blog posts. They did presentations at at technical meetings And Google did another big marketing push called Beyond Corp around 2015 where we're again They basically were advertising that hey, we have encryption between all of our services We don't have a single VPN like a traditional company We have separate encryption layers between between every single service in our entire infrastructure Again, they didn't open source it. They just talked about it. They talked about the idea But of course normal companies are in Google had a much harder time implementing things at that kind of scale Now the the real beginning of the spiffy project was a presentation by Joe beta at glue con Does everyone know who Joe beta is? He actually started the Kubernetes project slightly before this So Joe beta did this presentation at glue con on the need for a common authentication protocol between all kinds of different Services that would be running in infrastructure and the need for it to be open source and an open standard that anyone could use so at the at the time Google marketing they were kind of calling Their cloud product Google infrastructure for everyone else G. I. F. E Giffy, yes, Giffy So so they took that that acronym And Joe took that acronym and kind of changed it a little bit and said secure production identity for for everyone Some more trivia if you look at the logo the colors are hex zero zero beta beta zero zero Yeah, so we snuck in we snuck in a few references to that early history And then 2017 2018 that's when Andres and I and a bunch of other people in the project Started working on on the spiffy inspire projects as part of CNCF Started as a startup. We got acquired We all went to different companies, but we're all basically working in the same community now under under different corporate umbrellas and Then 2020 the projects went to CNCF incubation stage and then 2022 Andres was largely responsible for this Getting it through the graduation stage in the CNCF ecosystem and we were one of the first projects post-cuban eddies To to officially graduate so we're at the highest level of maturity within the CNCF ecosystem And now we're here Cool so What do you actually get if you run this you get a few things and sorry about the extra bullet point there that we didn't prove And says nothing That's some oversight So our software is better believe us like we're a lot more strict with it So you get cryptographic material rotation and the lifecycle management of it We talked about well, how do I copy this thing here if I am running a cluster of a million machines That's running Times hundred that containers so automating all of that lifecycle management this revision rotation Also as a byproduct you get TLS for free drop it So mapping that back to compliance requirements encryption of data and motion for free Not very expensive not very expensive as a transaction and software Now You also reduce the likelihood the probability of a breach in case Something cannot Verify its claim of what it is the workloads attempting to impersonate it will not Get a spiffy identity also in the event that That identity wherever to be leaked We talked about these being short-lived the utility of that if it's five minutes Turning around and attempting to construct an attack with a key that will expire in five minutes It's quite quite a video game that you're playing at the hardest insane level. It's extremely difficult And with this key material ultimately, it's not just about Cross authenticated workload to workload. Let's say pot pot or a service to another You can use this to connect to many different systems. You can use it to call a database and Rather than presenting a username and password you modify the grand table for an X 509 With a sand that matches that of the spiffy identity If you're running Kubernetes on a cloud provider You can call the cloud provider authorization API and exchange it let's say in the case of AWS You have an I am role binding against the spiffy ID. You can use it to receive an SDS token So your pod can now authenticate to any other AWS service With that you having to handle any of that workflow yourself entirely transparent fully automated A spiffy as a spec we talked about those different API some documents Superquit run through the spiffy ID is the representation of the service name So that has a schema of spiffy colon slash slash the trust domain which is modeled for the top level root of trust and Then an identifier that you can choose whether it's opaque. It's something that follows a Organizational convention where it's something that's derived from if it's Kubernetes could be namespace service account Workload name You get the s-fit which is the identity document that's actually used to prove that identity To any other service that you're communicating with the workload API, which is the interface from which attestation occurs identities get retrieved and cross authentication Then happens the flow between the different workloads the bundle is the bag of keys for cross authentication and then spiffy federation if you're doing interesting things like cross cluster and PLS and Istio Or you're doing on-match off-match authentication Or let's put it high-level picture your company Just acquired another company or just onboarded a new business partner rather than Throwing down a dark fiver or setting up a VPN You can cross authenticate by sit over a public network by simply exchanging public key material Quick view of a typical spire deployment That implements those spiffy specs. There's a server. There's agents that run in every node This could be a virtual machine. This could be verb metal. It could be a A a node and a container orchestration platform You have the workload API and then you have your different processes that may or may not be Containerized that are calling that workload API The sole purpose of the agent is just exposing that interface to the running workloads Then there's the attestation Workload comes up for the first time and it has a little bit of an existential crisis says whamma Okay, we'll help you figure that out Let's call the instance metadata API For what the top provider not knows so the security group the availability zone All the different metadata we corroborate if that matches the policy Great if it's running on Kubernetes, we call kubelet what namespace what service account token We call synchronously. We're interrogating the kernel what pit what sgid What does the what else does the kernel know about this? We call the container runtime and ask for environmental variables labels image ID and if all of this criteria matches Only then there's a assurance of an identity. There's a little bit more of a workflow of like a Certificate sign request and bringing it back, but at a high level of At a high level view that that's pretty much it there is a number of multinational organizations and Large companies in different countries that are known end users that have pushed the boundaries of the project and Pushed us to meet their requirements Companies that run up to a million nodes and kubernetes Large spy deployments. There's different. There's different topologies that help support that through Federation through nesting a little bit outside of the scope of the of the discussion But yeah, those are some of the notable names that have also helped us advance the project Number of integrations, I'm gonna leave it up on the screen. There's there's more than just these Are some of the most notable ones that we keep track. We're like the project the projects have come back and said hey Put us down as a reference on on the spy repo. So a lots of interesting work and extensions happening through these And yeah with that let me The purpose of the sessions really catch you up some of you are new but catch you up with what are some of the most interesting Updates milestones we have attained Executed against the roadmap and a little bit of a preview of what's in the radar To come sweet. Thanks, Andreas Yeah Thanks, Andreas. That was a really good overview of what we're doing and hoping to accomplish with this 50 spire projects We've got about 15 minutes here to go over all the things that have happened in the last Almost six months since the previous QCon. I probably can't cover all of them in a whole lot of detail but at least they can Mention the projects and mention the names But the the big event right before the last QCon was the graduation from CNCF That was the the number one biggest event That means we're at the highest level of maturity and we get a lot more support from the CNCF as a graduated project Then we did as an incubating project which is fantastic just in terms of marketing tech help They've made us a really nice new website. You should check out the new website if you haven't already And that was all CNCF and I'm really grateful for their help with that But in terms of technical updates since the last QCon I think this was also actually technically a little before the previous QCon, but TPM integration Spire well actually I have a slide on that one specifically so we'll go into that in a minute But a trusted platform module you probably know this if you're like me and you have a lot of old computers around your house Windows only works with a new trusted platform module. You've probably encountered that if you've tried to use a computer older than about two years and That's forced the entire industry to integrate TPM modules into all their hardware Spire now can work with those TPM modules Which is fantastic Istio integration. I also have a slide on that specifically But very exciting Istio is another you know very mature graduated widely used project from CNCF So any integration we have with Istio is incredibly important six-door integration Very very important helm charts I did not make a slide on this one specifically because I didn't know what to say because we we should have had helm charts two years ago We were a little late on that But we now have official helm charts that are in the artifact hub Which is the central place for all CNCF projects to put their home charts that was only within the last couple of weeks Marco who I don't know if he's in the room right now, but he's at the conference and is hanging out at the spiffy booth a lot He did those helm charts did an amazing job. They're so good. They support a wide variety of different configurations Yeah, he worked incredibly hard for the last And Windows support also I did not make a slide on Windows support specifically because I didn't know what to say Specifically about Windows support, but we support Windows now There's a large gaming company Computer game company that really needed Windows support. I won't say which one, but they really needed Windows support So we got we got that together for them and then credential composers That's my last slide and I'll talk about that in a little bit more detail at the very end of this work in progress We have we always have a thousand different projects going on a lot of them are actually more research projects Which is where I would say confidential compute is I don't know if anyone's familiar with The confidential compute it's the idea that you could have a virtual machine. That's totally isolated from the hypervisor level We we actually are funding a research project with some university students to To experiment with with applications for confidential compute inspire There's a couple different ways you could put those things together I won't go into all the details, but there will be some academic papers coming out in in journals Yeah There's a company here called scone which does confidential compute and we actually are working closely with argue from scone No, okay We're working with scone other German company that does confidential compute APIs and Libraries flexible federation That's something I've really been championing Again more of a research project at this point, but it will result in something it just may take a little bit of a time But basically we have we have point-to-point federation between spire servers right now But we don't have any idea of like a central federation server Rust spire, there's a there's always a rust mafia in every open source project, right? Well goes memories, but rest is a lot faster. I actually have one user right now Actually, we should talk about this but who wants to be using spire on some very small embedded devices So so rust may make some some sense there and Cloudflare workloads again. That's That's something that we're working on Okay, TPM integration we can we can do a little bit of a dive into this but we At one of the huge contributors to the spire project is HPE. I'm actually wearing HPE jacket right now HPE obviously that makes a lot of servers the servers have TPM modules HPE was very very interested in how do we Do secure authentication between workloads that are running on physical bare metal servers or virtual machine servers? So essentially every system that you can buy right now has some kind of TPM chip It doesn't have to be an HPE chip. I mean they're all use the same chips basically But we want to have a chain of trust established from the hardware level You know dating back to when the hardware was manufactured Then we can sign a certificate the census certificate that the workload gets to use And and that can go through spire. So so it's a common certificate hierarchy And some of those certificates can be rooted in trust at the hardware level And then others of them could be could be coming from Amazon. They could be coming from the cloud They could be coming from Whatever whatever source you want, but they'd all be speaking this common language With a certificate that's in the same hierarchy So This is this is essentially an architecture diagram that the server Does a proof of possession to check that the agent has a certificate that was signed by TPM And then it does this thing called a proof of residency, which is essentially verifying that the TPM still has the signing certificate that generated the The certificate that was proved in the proof of possession That there are more detailed to architecture diagrams on our website. It's actually very very complicated There's a lot of steps in this process the A question I get a lot and one I had myself when I started working on this is AWS, GCP, Azure, VMware, Hyper-V They all support VTPM as now Virtual TPM modules that are implemented in software. So I thought, you know, hey, this is great We don't need to do attestation based on the hypervisor anymore. We can just all use VTPM It's it's a mess. VTPM is different between every platform. They're not all compatible at all So that didn't work out We did a lot of research into that though TPMs can also prove device state. So in addition to providing a signing certificate, they can prove the state of the device at a particular time There's several different open-source projects Some of them are part of CNCF. Some of them are not Witness does proof of device state at the time of a build. It's an amazing project. I encourage everyone to check it out It's one of the most technically impressive things I've I've ever seen honestly Very very cool stuff Yeah, those guys are geniuses. I love that project Parsec, they're sponsored by ARM. They are Basically doing what you would expect ARM to do, which is really good compatibility with ARM hardware And then there's a project called KeyLine that I didn't put on here. That's a CNCF project. It also does that It's a flexible system for proving device state at a particular time and then it's actually integrated with Spire IBM sponsors that and they I understand they use it in production for IBM cloud, which is super cool So you can prove the state of the IBM device that that booted up at a particular time So, oh and my very last bullet point on this one We used to have this thing where we did not work very well with IoT devices Because Spire would issue a certificate and then you'd use that certificate to get a new certificate And then you'd use that certificate to get a new certificate And if that chain was ever broken because maybe it's a car and it's sitting in a garage out of battery for a month or something Then you could just never reattest So it wasn't a problem for data centers, but it was a big problem for offline IoT devices But TPMs let you work around that And we support that now so over the last even just the last couple of months I think we're a lot better suited for IoT edge use cases than we used to be Particularly with the Parsec integration Primary Parsec use cases and we have multi-tenant workloads running on the edge How do you provide isolation of the material? so sort of Rest co-resident workload is not able to access those and it provides a very neat abstraction layer whether you're running an ASA and a TPM search the water protocol for it and it Blurs a lot of those differences providing a common abstraction Thanks, Andrews Istio integration we have been talking to Istio since day one Istio has baked into it some compatibility with the Smithy protocol because Literally the same people were working on early versions of Istio and and early versions of Smithy Spire So the connection is really deep Up until last year, I would say the integration potential was maybe not the greatest Because Smithy was issuing certificates. Sorry, Istio was issuing certificates and Smithy was issuing certificates And they weren't really connected. They were in the same format They all the same fields filled in but they weren't really compatible in all the ways we would expect them to be Istio can now just ask Spire for certificates and then Spire gives it a certificate and then Istio uses it At the node level as it's certificate. So then you have an Istio deployment a spire deployment and then and then your workloads And your Istio proxies would be getting their certificates from spire and you get all the attestation possibilities that that come out of Come out of spire all the plugins all the all the functionality of spire built into Istio And this is really fantastic actually just found out that Solo's new service mesh glue fabric is a commercial thing so They won't be doing any open-source presentations But it actually uses spire internally as its certificate authority as well and and that they're sort of a Istio company And actually Yeah, actually It's a meal sponsored that project, so I'm very very grateful And yeah, this is all supported in Istio one three, it's not very well documented yet. We need to work on that Um Yeah, we're working on better integration with Istio, but This was so critical There were so many companies that couldn't use spire because they use Istio or they couldn't use Istio because they use spire It was a big mess So I'm really glad we have this working now, and we do need like I said, we need better documentation We need to polish up some some finer details of how to make them interact really well, but Yeah, it's cool stuff, I'm really proud of this project so and then the Last technical side here six door integration. This is Six doors a big complicated project of its own I'm not going to explain all of six door from the very beginning, but the basic idea of six door is that you're signing containers. Oh You're signing here says artifact Yes So Six door lets you sign containers using short-term credentials And then spire can verify the signature that comes from six door So it's a signature document that comes in its own format straight from six door But we can verify that signature before granting you a specific Spiffy identity and that's an incredibly powerful tool because that means now my workloads I Can verify that they came out of my build system I can verify that they came from an individual developer if it's a workload that came from red hat or suce They're both six door signing everything they produce now So I can verify that it really came from red hat or it really came from suce or in the future Eventually, hopefully everyone will be using six door signatures and every company will will give you a container that's signed with six door And you'll be able to verify its real identity before allowing it to get a spiffy identity and That really locks down your environment. It really prevents a lot of different types of attacks that could potentially occur There are other ways to accomplish similar things using admission controllers, etc. But This is way better. This is far more robust But if you want to like model this to other platforms and extend that great functionality and assurance This what the six door integration is and there's so much energy and interest and enthusiasm about six door Like I said, red hat and suce are already really supporting it a hundred percent And for every vendor will in the very near future. I think it has that that level of enthusiasm and interest So the fact that then you can take that six door data and use it to prove runtime identities Is really an incredible powerful incredibly powerful combination There are tokens. This is what I'm actually spending the vast majority of my time on but I can't go into that much detail We only have a few minutes left But basically spire can issue job tokens Already that's been functionality for several years now job tokens are pretty limited So the main use cases that you can access AWS API is GCP API is using those job tokens You may have seen a presentation yesterday AWS now support certificate authentication with spire So that's even even better than job tokens that GCP isn't quite there yet and And those drop tokens. It's really nice to be able to pass your spiffy IDs through ALB is that kind of thing? It's kind of a useful Secondary feature of spire, I would say but we're running into the limitations of jobs It's job is just it's not that detailed a standard and it there's a lot of degrees of freedom and It's not obvious how to do certain things within the job standard So doesn't have attestations there kind of differences in fields like we were trying to authenticate to confluent recently and Confluent expects certain things to be in a job that we couldn't provide very easily A big one is lack of call stack tracing. So if I have a job Then I send it to another service and I send it to another service At each stage the job is completely new. There's there's no Additional information that's ever added to a job because it's not possible within the job So there's some other token formats map runes and biscuits and those are very cool advanced token formats That are more academic research projects at this point. They're not really in in wide use Seto, which is Kind of a rewrite of the job standard. I also not really in use. I would say we're we're talking Enthusiastically to all these different projects and learning as much about them as we can and figuring out how to do these firefits And we had a presentation at IETF Yokohama Japan Was it was a couple weeks ago maybe three weeks ago? Evan Gilman talked all about all about this subject in a lot of detail. That's reported. It's online in the IETF Website And you can definitely look at that. He also didn't capture that. It's on the spiffy website I can you say something about the use case or authorization? Yeah, sure. Basically the more information you can fit in the job the more you can use for authorization So people are using these advanced authorization rules engines like OPA, Kyberno If you don't have any information to do your authorization, though, that's not useful. You need a bunch of data in your token Like this request came from Netherlands. It came from the riot convention center IP address It was issued originally to Daniel and like all these details and then you can use those to make advanced authorization rules But if Dennis and the Netherlands have the bar Yeah, maybe it should be that tonight Yeah, we need a proof of proof of sobriety, right? Okay Credential composers. This is a new feature inspire Basically, this is a plug-in interface lets you change all the details of a credential before issuing it It's a plug-in interface so you can do whatever you want in it We don't have any official plugins right now, but you can you can easily add a plug-in So if you need like if you need an audience field or you need to get rid of a unique ID field that doesn't work with something This is like basically a very key compatibility feature and I'm so glad this is inspire Andrew Harding worked on this for a year. I think I'm really glad this functionality is there And you can just add a new plug-in if if if spire doesn't meet your needs You can add a new plug-in and it will change the credential and that it will meet your needs And no other product on the market has this so I'm really grateful this is there All right Oh Yeah Thank you ever. Thank you Resources the product official website. There's a Google groups mailing list wouldn't use that a whole lot the week No, we're not really using that slack And the product repository we also have a booth and the product section We're gonna be there throughout the day There's not no one else besides us, right? Yeah, it's just us hanging out at the spiffy booth, but I was answering questions 8 a.m. To 5 p.m. All day yesterday Lots of people are using this stuff and a lot of people have questions about how they can use it in the future also slack It's very very active. It's over a thousand members Lots of questions all the time if you the best thing to do if you don't understand something is Just ask a question on slack and and you'll get about 10 replies in the first 10 seconds day or night It's very very active Spiffy community days. We've done this in different places of the world. That's something of interest to you to build community exchange information You're Netherlands or any other country in Europe. We're happy to support you with that. We also make Stream those virtually so you can draw from wherever you are in the world So yeah, it's an eye out for the calendar. They're outside of the Linux Foundation conference circuit and schedule. We try not to compete with your attention while you're here Oh, and there's six fire every other week We have just a it's usually a 15 to 30 minute meeting People join the ask questions and they also do presentations about what they're working on and inspire how they're applying this stuff Very active community. It's a great way to meet everyone. It's it's on zoom So you can just join from home and it's pretty quick And I organize that one Whether whether you like it or like bumping into some things or sharp edges I think we smoothen those for the most part that if you have a particular quarter case or something that Perhaps a use case we haven't considered Or even if it does need support get it started. All right. Well, thank you very much everyone And I'm not sure if we have time for questions within the session. Do we have any any time left? Oh, okay We have time. All right There are two things in the cloud native world that are mutually exclusive today, which are confidential containers and and sidecars I asked Confidential containers guys, how do you support sidecars? And they say, I don't know and asked the sidecars I look at how you're going to support the confidential containers and they said, I don't know Yes, so there are two mutual things in the cloud native world which are confidential containers and Sidecars Both sides they they say, I don't know about the other side how they are going to support it And I think the spiffy inspire might be the glue To that because you work with the Istio guys you work with confidential containers Did you consider contributing the workload API to the Linux kernel? Assuming just assume that every process could make a system call give me my identity I think you could do great things for this Okay, so the the core of the question was if I have a confidential container, how do I get it? How do I get access to the workload API because? Clearly spire can't authenticate the details of the container because it's confidential, so we would need some kind of kernel support We do not have any kernel support If you think back to that history slide the plan 9 operating system did include Support for workload identities that are issued by the kernel or well, it's equivalent of the kernel But that's not in Linux and that would be a wonderful idea I will mention that to the the PhD student researchers who are working on that topic because I think there's a lot of potential there but I honestly I Don't think we've discussed that within the project. It's also two different world views colliding of where do you place your trust? Is it a bottoms-up model where you? Don't trust your developers, but you trust the hardware or Is it a top-down where you place trust and your developers and you follow a zero trust that works model where you think well We can't really trust the medium or the hardware the hardware Might the top of rack might be backdoor The router might be backdoor Someone splice the fiver and there's a man in the metal attack So we're gonna place trust and the developers and the workloads as opposed to like moving up But it does bring up it does bring the update intersection and there's been advances and to make concession We wanted to and we have not thought of contributing to the kernel It does like light bulb moment for me something we should definitely consider and chat more about Hendrik. Thank you Yes, please Niels, how's it going? Good. How are you pretty good? Thank you Glad to be done So you mentioned that the JWT's have like super nice attributes that you can use for authorization and With s bits you kind of like you have hierarchical information about Stuff and you could probably hack key value pairs into that that as of it, but like You mentioned that useful and I agree with you, but I don't know how to properly do this with Like I'm not a spy or user, but I'm a heavy as a user. Okay Yeah What's how are you what what implementation of spiffy? Do you make use of so for once if you and then there's another system? That's basically We run by our own. We basically just issue certificates that have an estimate and we validate that with your eye measures Yes, fascinating. You want to talk about the jaw-thread model then? This is core focus of the company's just started Yeah, so I mean that's a really good question Which is how do I use jobs to perform advanced authorization? And the first thing is You will need to use something that that can add lots of data to those jobs Because Istio can't right now. So either we're going to improve Istio or you can switch from using Istio native certificates Despire certificates that are that are integrated with Istio, which is really it's just one configuration option That's really easy to set up once you already have spire going so the company where we're gone is is adding a Chain of attestations to the jobs and I can't talk too much about commercial stuff because this is an open-source meeting But I would be happy to talk about it later But if you look at biscuits or macaroons, what we're doing is essentially very similar That and there are tokens that have a chain of additional data Appended to the token and each step is signed using a Signature scheme that allows appending a new signature And there's several different. There's like Schnorr signatures. There's different cryptographic algorithms that allow appending to a signature Each step of the way as a connection goes through your infrastructure So validation of that chain would mitigate for a malicious manipulation of the job Any stage at any stage in the infrastructure and that's that's really what a lot of different people not just me are going for But it's all early stage. There's a lot of academic papers. There's a lot of blog posts There's not a lot of implementations yet. So does that answer your question? We don't have to do like a deep back and forth, but How you could add attributes there or if that's not or if that's like combination between JVT or mtls that's your goal I don't know that you can make use of mtls on the basis of Jots you can do on a x509's there's a I want to say rfc 8903 I might have it off for like client-bound access making use of of Jots But you're translating for x509's to what one point, but if you have TLS termination Well, the x509's not making it past that. Yeah, the simple answers you have to use both because mtls protects the connection Jot protects the individual requests So if you're using gRCP gRPC or HTTP 3 or HTTP 2 you have a lot of requests inside one TLS connection So the TLS connection isn't really useful for validating requests at all The TLS connection could be open for 10 minutes and have four million requests go through it So you actually can't really use the TLS to validate requests or do authorization And and yeah, it is rfc 8903 it's a standard way to exchange a certificate for a job and People are talking about implementing that there's no rfc. There's like you said There's not a lot of implementation yet, but we're working at it. Let me come back on the actual number I think we may be off by a one one digit. Oh Yeah, the the title is client-bound access OAuth client-bound access mtls. I'll find it for you Thank you. Great question. What questions do we have in the back? Nothing in the back of the room metal the room thoughts complaints Yeah, we can take complaints as well. Yeah All right, it's really cool to see all the energy and enthusiasm here You know people were coming up to me at the booth and and saying they use spire and and they were huge companies that I didn't know We're using spire, but like huge companies that ever was heard of I don't know if I can say their names Probably not but there are some very very large companies that were not on the list because they have not been public about it But they're using spires the business for their infrastructure security if permissible by your company policy We would love to hear from you. We have different channels venues Where we can do webinars we can like do a little case study Polish it. Yes, Neil, please question me. Oh, so I work for elements health and be very large healthcare companies North America, so it was great working with Dan Feldman and Andrews embarking on zero trust spire since few years ago. Given that we deal with large Healthcare data and personal information. So one of the questions I have is what's the More observable the observable the monitoring side of things for spire So the the first answer is we do not have enough observability yet Initially, we were very very hesitant to add a lot of observability because we were afraid of leaking security confidential data At this point I think we've reached the point where we just need a lot more data going upstream to some kind of observability interface and we do already have telemetry and obviously we have logs a Lot of different companies have written basically wrappers around this spire log and telemetry output to try to deduce facts about what's going on right now, but If an attestation fails that means either two things one is you configured something wrong or two You're getting hacked and either way. I want to know about it I want that to ping my phone probably if I'm a DevOps guy at a big company and right now That's very hard to accomplish because we were nervous about leaking security confidential data to the public but We really need that and that's definitely something to be aware of It's a definitely an area for there. There are nascent conversations Beyond observability to forensics with certificate transparency Lots of work from Google there also for the purpose of audits in the event of a breach and understanding the actors once again perhaps from intersection with things like wrecker and Append only logs where you could record configuration state of a system and whether that matches or deviates from the policy intent and Be able to answer audit questionnaires, but at the same time and in a sock be able to see And model the behavior of the system in real time Great questions Neil if you haven't heard of Eleven's health fortune 20 company fortune number 20 Second largest healthcare provider in the United States early adopters of the project Sunil has led the charge deposited a lot of faith and then been like wealth of great trust and really like Pushed his along led the path paved the road He's here. He's gonna be at the security village talking about Zero trust use cases if I can get a round of applause for for Sunil for pushing us forward and setting the direction Cheers with that while I hope you enjoy the rest of your coupon then I have to go Yeah, see you around. I'll be up front if anyone wants to talk just about spiffy inspires. All right