 Hello, everyone. My name is Ryan Turner and I'm a software engineer at Uber and a maintainer on the SPIRE project. And today I'm excited to talk to you about some updates with the projects and that I'd like to share from the last time we got together at Production Identity Day in North America in November of 2020. So first, I'd like to just share some statistics about the project as of early September this year. This is between last Production Identity Day and this September. So we've released 11 new versions of SPIRE in that time. We've deployed out 49 new features into the repo and 59 bug fixes and improvements. And a total of 339 pull requests were merged in the last year. And this is just awesome. This is like way up from last year. So it's super exciting to see the growth and momentum of the projects and in total we've had 48 contributors over the past year. So that's really great. That's also up from last year. So thanks everyone who has been active in the project and contributed new pull requests. Those who have filed issues, you really drive the direction of the project forward and we're really all appreciative of that. So I'd like to just highlight the folks who have contributed in the last year. These are all the users who have committed something to the SPIRE repo since last Production Identity Day. So huge props to all these people and we really appreciate all your contributions and keep them coming. So this year we were really focused on trying to release a 1.0 version of SPIRE. And a 1.0 version for us as maintainers of the SPIRE projects really signified a stable and secure release that really showed that the project solves a core use case that applies to many organizations in the software industry. And we felt like coming into this year we had really found a real momentum of the project and found that a lot of organizations were interested in SPIRE. And so we felt like the project was getting to a stable enough place to make this symbolic gesture, if you will, of 1.0 being the next release of SPIRE. So early this year, back in about February, we were considering trying to release 1.0. In the meantime, we had actually commissioned a security audit of the project to just make sure that we didn't miss anything. And it turns out there are a couple of vulnerabilities that were discovered as part of that security audit. And I'll talk a little bit about those in a little bit. But basically, once those vulnerabilities were reported, we sort of had to reevaluate our direction and make sure that we were achieving the objectives that we had laid out for a 1.0 release. So back in March, we actually released several versions of SPIRE to patch some of the security vulnerabilities that were reported as part of the security audit. And that took place in March. So in April, we were looking at all of the pending contributions, all the pull requests that were open. And there were a lot of things that folks from the community wanted to contribute. And we didn't want to hold those things up artificially just to try to release something that was called 1.0. So we decided to merge most of those changes into a couple of point releases on the 0.12 major release branch. And those constitute the 0.12.2 and 0.12.3 releases in April and May of this year. And once we had time to let those releases kind of be out in the wild for a little bit and give users an opportunity to use them and report any issues, we felt like around July, it was a good time to actually declare this project a 1.0. And so we actually did release a 1.0.0 version of SPIRE in July of this year. So it's a huge accomplishment for the projects. And we're just excited to see where it goes from here. And hope that it kind of fuels the adoption for the next wave of users who might potentially find benefits from adopting SPIRE. So earlier I mentioned that there were these security releases that came out earlier this year. And I'd like to just kind of talk about what prompted those releases. So we actually commissioned a security audit to a firm called Tier 53. They're a really great reputable security research firm. And they started looking into the project around February of this year. And they did a full like in-depth white box analysis of the project. And so they were really looking through the source code and all different kinds of potential attack vectors. And in general, the project was found to be pretty well designed in their words. But there were a couple of vulnerabilities that they found. And this was all focused on the 0.12.0 release, which was the latest release at the time. But they were performing the audit. So there were one high and two medium vulnerabilities that they discovered. And we took these vulnerabilities very seriously. They were initially only reported back to the maintainers of the SPIRE project. We have a security vulnerability reporting process, which is described in the GitHub. And essentially, these kinds of security vulnerabilities we ask anyone who finds them to send an email to the security email address that we have on the GitHub repo, which gives the maintainers an opportunity to evaluate whether or not there is a vulnerability and what the potential impact of that is, as well as developing some patches to try to fix those vulnerabilities and figuring out what affected versions are out there. So these are the two vulnerabilities that we filed CVEs for. You're more than welcome to go on to the GitHub repo. We've published GitHub security advisories for both of these vulnerabilities, which describe the issues in a lot more depth and also refer to the fixes, which were applied to all the affected versions. So I'll just briefly cover what the vulnerabilities were that the audit uncovered. So the first one here, legacy node API allows impersonation. So there is an existing set of APIs that came out before the current V1 API layer, which was introduced in late last year. And one of those APIs was called the node API. This was something that the Aspire agent used to attest itself to the Aspire server. In a sense, prove that it's a valid agent in the infrastructure. And there was one path available where if an actor was able to obtain an agent SVID, meaning it was able to successfully attest to the server, it could potentially request SVIDs for identities that it wasn't allowed to serve based on the registration metadata registered in Aspire server. So that was one of the vulnerabilities. And then the second vulnerability was around spiffy ID paths. So spiffy IDs, as you probably know, if you're familiar with spiffy, they are designed as URIs. So in the URI specification, there's no restriction on like Unicode characters or selected characters that are like punctuation marks and such, that those kinds of characters can be represented through this percent encoding mechanism. And it turns out that it's really hard to uniformly handle those kinds of sequences in URIs across different languages, across different libraries. And so there were some inconsistencies with how those URIs were being handled. So effectively, we decided to amend the spiffy specification to disallow the use of Unicode characters as well as restrict the ASCII characters that could be used to a limited set to try to prevent these sort of issues where like spiffy IDs could be interpreted in multiple ways depending on the URI library or implementation used. So as I said, we released new versions with fixes for all these vulnerabilities. And we published the results of the vulnerabilities and patches into the Spire GitHub. And if you're interested in reading through the audit itself, that is also published as a PDF on the readme file for the Spire repository in GitHub. Okay, so I want to kind of walk through the releases in the last year and just highlight some of the notable accomplishments in the project. So let's go ahead and start with the 0.12.0 release, which came out last December. So as I mentioned before, Spire introduced a whole new set of APIs called the V1 APIs, which just brought a lot of more consistency to the API design across the board. And so those APIs effectively replaced the initial set of APIs in the 0.12.0 release. So Spire started using all of those APIs internally. We also introduced significant improvements to the agent sync operation, which to describe that in a little more detail, the agent sync essentially, it's an operation where the agent very frequently every five seconds requests all of the registrations that it's eligible to serve identities for on the host it's running on. And that operation used to take a lot of time with a larger number of agents or a larger number of registrations in Spire, because it was using dynamic database queries that were not very efficient. So we optimized this whole procedure using an in-memory cache and the server, and that really sped up the time that it takes to fetch all of this data that the agent needs to be very predictable. And then we also introduced support for the Envoy SDS V3 API in Spire Agent. So that brings our compatibility to latest versions of Envoy. And then in March of this year, this is when we released all of the security fixes that we just talked about. And then in 0.12.2, this was released in April of this year. And some of the noteworthy things to point out here, there was a new server key manager plugin created, which uses AWS Key Management Service. So this allows you to manage all of Spire's private keys and signings and a key management service and AWS. There was also a new plugin added for the Spire server to use GCP CAS as the upstream authority. So it allows you to chain to CAS managed chains of trust. And then in 0.12.3, there was support added into the Kubernetes workload registrar for registering workload entries in Spire that need to federate with other trust domains. And this was released in May of this year. Okay. And then the big one is 1.0.0, which was released in July of this year. So a lot of things went into 1.0.0. One of the major things that happened was that there was a big refactoring of how the Protobuf definitions are managed in Spire. Previously, Spire used to be a single repository with two Go modules. One was the core Spire module. And the second was a Protobuf module. So any API clients could take dependency on that Protobuf module. That Protobuf module contained Protobuf definitions for both the API layer as well as plug-in SDK Protos. So it was kind of overloaded with a couple of different things. So we decided to refactor that into separate GitHub repositories for those API and plug-in SDKs. And those are called Spire API SDK and Spire plug-in SDK. And those are both in the SPIFI organization GitHub. We also added support for versioned plugins. So if we need to change the plug-in interfaces in Spire, we have an effective way to do that now through versioning. There's also support added for a cert manager upstream authority plugin. So if you wanted to use cert manager as your chain of trust for the upstream for Spire, that's now possible. There's also new commands added to the Spire server CLI for banning agents and counting some of the resources tracked by Spire like agents and entries and bundles, which used to be kind of an expensive thing to calculate if you had a larger scale deployment because you had to list all of those resources and all their data, which could take a while and was kind of intense on the database. Now this is kind of an optimized command, which does that all in the database doesn't require transmitting a lot of data. There is a new authentication method added to the vault upstream authority plugin in the server to use Kubernetes-based authentication with service count tokens. The server now supports the latest configuration for the Spiffy Federation feature, which was added last year. And the Spire agent can now provide trust bundles to unregistered callers via a new RPC, which was defined in the Spiffy workload API spec. So if you have workloads which need to verify SBIDs, but themselves don't really need to use SBIDs for authentication to other workloads, you don't need to register those verification workloads anymore in Spire. You can use this unauthenticated unregistered API to just obtain the bundles. Also on the server and the agent now implement the standard gRPC health service, so this improves the health check story for Spire. In 1.0.1, we added an LDV ID-based TPM node attester plugin, which basically uses a proof of possession and proof of residency challenges to verify that host is issued by or has a TPM that's issued by a trusted vendor. So this improves like private cloud kind of attestation if you're using TPMs. And then we've also had node attestation for AWS VMs across multiple AWS accounts using AWS IAM role assumption. In 1.0.2, we added an experimental support for defining authorization policies in the server using OPA. So this kind of changes the mechanism that the server uses to authorize inbound callers. There's also audit logging added to the server API layer, so all calls to server APIs are now audit logged. Support for the SPIFI certificate validator was added to the Envoy STSV3 API and Spire agent to enable federated SPIFI authentication. And there were also support added to the Kubernetes workload registrar for identity templates for SPIFI ID paths. So you can now dynamically generate SPIFI ID paths based on attributes of Kubernetes pods, for example. All right. And just want to quickly go over what's coming next. So in the near term and medium term, we're looking at it continuing to simplify the experience in Kubernetes to make it more turnkey. And this applies to both how SPIRE is deployed as well as the way that registrations are created for workloads in Kubernetes. We want to continue to focus on how we can support workloads which don't run in an environment where a SPIRE agent can run. In the classic example, this is like a serverless environment like AWS Lambda. There is ongoing work to provide a new API, which allows like a trusted process to delegate the, to delegate S-FIDS to other workloads running on the same host. In the past, this has only been contained within the SPIRE agent, but now we're allowing like trusted proxies, for example, to be able to do this kind of issuance of identity as well. We are looking to provide a new API to programmatically configure federation relationships. We're exploring ways that we can do better verification of binary signing to use things like TUF, for example. And then we want to provide ways to connect to GCP, using secretless authentication with OIDC federation. And in the long term, we're looking at how do we effectively do key revocation and forced rotation, identity, also secretless off to Azure with OIDC federation, continuing to iterate on our health check subsystem and improve our error messages to be more actionable. So that's all I had today. Thanks for joining and have a great production identity day.