 Hello, everyone. My name is Ryan Turner, and I'm a software engineer at Uber and a contributor to the Spire project. And I'm excited to talk to you today about some of the extensions and integrations available with Spire and how you can leverage those to distribute workload identity in a uniform way across your environments. So first, I kind of want to just touch on some common integration challenges that I think many of you probably relate to. So you may be using multiple environments and those may be private or public clouds. They may be on-prem infrastructure. You could be running in a variety of environments. You may have your own in-house tooling that is proprietary and not open source. You may have some open source tooling. You may be using cloud native tooling. So all these different systems are in play. You may have a mix of legacy and cloud native applications. So things that are designed to run natively in one public cloud or potentially that run a Kubernetes cluster, or you may have legacy workloads which don't use these newer technologies yet. And so how do you actually provide identity to all of these kinds of environments and applications? And how do you enforce uniform authentication across all your remote procedure calls, which would be happening in your microservice ecosystem? So I am excited to tell you that Spiffy Inspire can provide consistent, strong identity and help you solve your identity needs in all of these use cases. So what are we going to talk about today? First, I'd like to just give a brief overview of what Spiffy Inspire are for those who are not too familiar and just kind of talk about some of the terminology that we'll be using throughout the talk. Then I'm going to go into some of the integrations that Spire provides and some of the external systems that Spire can integrate with. Then I'm going to talk about different ways that Spire can be extended and the kind of functionality that you can customize in your deployment of Spire. Then I'm going to talk about downstream integrations. So how Spire can be used once it's up and running in your environment, how you can actually enforce authentication across your ecosystem with Spire-issued identities. And then I'm going to open up to Q&A at the end. So let's go ahead and get started. So first of all, what is Spiffy? Spiffy is the secure production identity framework for everyone. So it's a cool acronym. What it really is though is that it defines three key things. One is an Identity Fire format, which is called a Spiffy ID. And this is a URI-based format which has a scheme component that just is called Spiffy. And then you have this trust domain concept, which is a logical way to organize identities in an organization. And then some path which has no semantic value, but something that you can define for your unused cases to distinguish different workloads from other workloads in your system. Then the second part of the specification, it defines an identity document standard. So how does this identity get represented? And this is what we refer to as an Svid. So that stands for Spiffy Verifiable Identity Document. And that comes in two different forms. One is an X509 certificate and another is a JSON web token. And then the third part of the Spiffy specification is this workload API, which talks about how to retrieve and issue Svids throughout an environment. Next, what is Spire? So Spire is the Spiffy runtime environment. And it's an open source implementation of the Spiffy specification. So it implements those identity primitives that are defined in the spec. It is essentially a control plane of what we'd like to call an identity plane for a managing distribution and rotation of identities throughout an environment. And it's designed as a scalable distributed system, which is intended to meet the needs of large environments and with many applications and microservices running concurrently. So just quickly want to talk about what is the architecture of Spire. At a high level, there are two components in Spire. There's a server and an agent. The server is responsible for managing identity registrations and issuing identities through the form of an S-FID, an X509, or a JWT. So it's essentially a certificate authority, which provisions these identities and two different agents that run throughout an environment. So this agent component is the second component of Spire, which talks to the server and requests different identities that it can manage on the host. And so how does the user workloads come into the picture here? So the workloads will connect to the workload API, which was defined in the Spiffy specification. And in Spire, it's exposed as a Unix domain socket today on the host. And so that the Unix domain socket is publicly available to anything on the host and the workload connects to it. And the agent tries to identify what that workload is and match it against a set of registrations that it's authorized to issue identities for. If any of those identities match the workload that is trying to receive an identity, then those identities are distributed to the workload over the workload API. So I just want to show like a big picture here. There's a lot going on. The details are not super important here, but I just want to kind of hammer home that Spire can really be versatile and work in a variety of environments here. So I'm just showing like one example. Maybe you have deployments in different private and public clouds. So here I have pictured an AWS deployment where you have Kubernetes cluster with some nodes running different workloads. And those workloads are Docker based workloads. And so in that environment Spire can function. It has a Spire server deployed in the Kubernetes cluster. And then there are agents which are deployed on all the nodes in that cluster and the workloads connect to those agents on those nodes. Maybe you also have a deployment in Microsoft Azure for example. And in Azure you're just using it as more of an infrastructure as a service platform. So you're not really doing things in necessarily a cloud native way, but you have workloads running there in virtual machines. So Spire also supports this kind of use case. And so here imagine you have some virtual machine running Spire server, which is, you know, addressable and routable from other virtual machines in that environment. And then the agents on different virtual machines can connect to the server and receive the identities for the workloads that run in those VMs. And they could be a variety of different kinds of workloads and Docker maybe or maybe they're just native Unix processes. And then similar story here for on-prem. You may just have bare metal hosts running in a data center. And so how do you manage Spire there? Well, Spire can also work there. You can have different hosts running Spire server. And then you can have agents running on the hosts in your infrastructure. And again, you can support a variety of these workloads. So it's very adaptable. So I want to talk about what are the different types of integrations available with Spire. So really, we can categorize these into two different buckets. One is integrations that enable the operations of Spire. So this is controlling some of the key functionality and behavior of Spire and some of the security properties as well to meet the compliance requirements that you may have or your own internal requirements. And then so really that's all about getting Spire up and running. That's just how do I manage Spire and make it work in my infrastructure in a secure way that I'm comfortable with. The second part here is how do you actually consume Spire issued identities in a way that's seamless. So ideally not every workload needs to implement their own integration with Spire just to get their identity and get bootstrapped. Maybe that works in a small environment where you just have, you know, very few number of services or applications and you can make those code changes and all of the services to get identity. But as you scale further up and you have more and more services in your environment, that becomes very difficult to manage. And so how do we actually propagate these spids across remote procedure called boundaries and provide secure authentication across our service requests. And then how do you use spids outside of your own ecosystem for requests to external services. So I'm going to talk a little bit about how you might be able to do that as well. So first operations integrations, what are some things that we might want to control with respect to house fire functions. So one is that you may have in your organization already some public infrastructure likely you do. And that might be a public web PKI chain to some well known trusted CA on the internet. Or it might be a private PKI. So you may have your own root CA and your infrastructure or your organization, and you have processes around how it's managed. And maybe you want to manage all of your workload identities in your environment, such that they're all chained to this PKI. So this is a very common integration point with Spire. The integration point we have to consider here is we have this distributed system architecture where there are agents running across different hosts VMs, virtual nodes throughout an infrastructure. So how do we securely identify those agents and the nodes that they're running on so that we can trust those agents with the identities that Spire server will distribute. So this is all about kind of linking your host identity system to Spire and establishing that bridge of trust. Next, another key integration here is how you manage your identity registrations. So this is something that we call host categorization. So this enables creating identity registrations that we call node alias registrations. And essentially what these node alias registrations are for are to give you logical groupings of registrations per host or maybe for a group of hosts. So that identities are not globally available throughout your entire infrastructure you may scope those identities to certain nodes running in your environment. So this is about providing the host system additional metadata to be able to create these kind of node alias registrations for grouping registrations. Another key functionality we might want to control is key management. So how Spire maintains its own private keys, its CA private key, how it does signing operations and those kinds of things. Another important integration point here is how workloads are securely identified in the system. So how does the agent actually determine that a given workload is something that is trusted and has a registered identity in the platform. So we call this workload attestation and Spire. And so this is all about querying runtime attributes of a workload to identify it against a set of registrations already inspire. And then lastly, there are some event hooks. So you may have some downstream processes or downstream storage that you may want to link different key events inspire to some workflows or, you know, storage. And so this is kind of providing these hooks so that you can plug into the event lifecycle of different things that happen inspire. So how does this all work. So Spire has this plugin framework, which it uses throughout all these different operations, and these plugins are defined with interfaces in protocol buffer language. So these plugins kind of are grouped into two different categories. There's like built in plugins and those are plugins that are natively available inspire. So if you go to play Spire with, you know, today from the latest release you'll get a set of different plugins that you can configure. And so you just need to specify in your configuration file for the server and the agent what plugins you want to use in your environment. So these are external plugins, which are things that you can develop or things that you can source from the open source community. If other people have already developed a plugin for specific operation that you are interested in you can leverage that using this external plugin mechanism. And the way that this plugin framework works is it links like the core business logic of Spire to these plugins over a GRPC interface. So that's what enables both the in memory and external plugins. And these plugins are all designed on top of this framework called HashiCorp Go plugin. And that's a pretty commonly used plugin system available in Go and is used widely in HashiCorp and by other projects in the open source community. So I have a little link to the reference for that project later on in the slides if you're interested in looking into that more. So I want to kind of just touch on what are the different plugin types for each of these components we talked about inspire the server and the agent. So this is just kind of intended to be an illustration I'm going to dive into all of these different plugin types more detail here coming up. This diagram is slightly outdated in that the plugin on the left there the data store plugin doesn't exist anymore so you can kind of ignore that part. And there should also be a notifier plugin in here as well but overall these are the plugins that are available today in the server. There's the key manager and upstream authority, which is kind of how you link to your PKI. And I'll talk about that later. And then these node plugins called Notetuster node resolver, which are used to authenticate notes in your environment and also label them with different key metadata. The agent has its own set of plugins available as well. And these are the three that are supported today, the Notetuster, which pairs with server Notetuster plugin, the workload tester plugin, which identifies workloads that connect to the work with API in the host. And then the key manager, which also manages the private keys and signing operations agent. So upstream authority is the first plugin I'll talk about here. And this applies to spire server. So this is how you control the integration with spires certificate authority to the chain of trust that you may already have in your organization. And so this authority who establishes an interface. It establishes an interface that allows spire to chain to upstream certificate authorities. It also allows spire to publish GWT signing keys that it has generated or and publish those to some third party store. It also can handle the certificate signing requests for the spire CA. So if you want to avoid or off avoid that signing operation happening in the spire server process itself, or you want to offload that to some other system, you can do that. These are the available built in plugins today. There is a way to provide an upstream trust bundle and private key on disk that's kind of like the simplest way to get going. You can also use some third party secret stores for this as well. And the services that we support natively today are AWS PCA and AWS secret manager. We also support hashi corp vault natively and spire is also an additional plugin that supported so you can have this nested spire deployment where you have kind of a central spire that manages children spire deployments. And all those children spire deployments chain up to some root spire deployment. So if you want to handle everything with inspire you can do that as well. The next type of plugin here is the node attester. And this applies to the server and the agent. And this is something that implements kind of a challenge response protocol. So you can define how the agent provides an app station material to the server to prove that it's a trusted node in the system. And that could be a physical node like an actual bare metal host, or it could be a virtual node, like a Kubernetes node or a virtual machine running in your on-prem or public cloud wherever. So this defines the bridge of trust between your host identity system and spire. So this is how you authenticate nodes in your system. And so that these are the different plugins which are supported right now. We have native plugins for AWS Azure and GCP virtual machines. And these generally all work by querying a local metadata endpoint in the virtual machine and using a trust and first use security model to provide that identity metadata to spire server and spire server can authenticate that and I'll show you an example of flow of that after this slide. Some of the other plugins that are supported today are joined token. This is essentially a one time pre-shared key that you can generate and you provide that key to the agent and then the server knows about it because it was the one that generated the key. And so that's just a simple way to authenticate a node. There's also native integration Kubernetes. There's a couple of different ways this can work. One is through projected service account token, which is kind of the recommended way. There's also kind of a more legacy plugin for service account tokens, which is the older wave providing a node identity in Kubernetes. And we also have SSH and X509 proof of possession plugins as well. So if you are running on bare metal and you have some other host identity system like an SSH certificate authority and or maybe some out of band X509 host identity, then you can use those as a station material as well. So here's an example of how the node attester works for AWS. So when the agent comes online, its node attester plugin is configured here to be AWS and that AWS plugin reaches out to the AWS instance identity service on the host. And that provides some identity to the agent, which is signed by AWS using its private keys. And so server can will receive that identity from the agent and it'll validate that it was a valid identity provided by AWS. And if it's able to validate this successfully, it will return an X509S to the agent, which represents the identity of the agent. And then the agent is then authorized to manage identities and distribute identities to other workloads on that host. So node resolver is the next plugin here. And this kind of it comes from the attestation flow, which I just showed you. So once that attestation completes in the server, you can configure these node resolver plugins which append additional metadata about those nodes inspire. And so why would you want to do this. So the reason why this becomes useful is because it allows you to define registrations inspire that act as node aliases which serve as kind of a parent of different workloads that you want to group together on a specific subset of hosts. So you can control these aliases kind of at the node level and say like post A is able to serve identities for workloads one, two and three and host B is able to serve identities for workloads four, five and six, etc. So this gives you some controls to actually manage where identities are distributed throughout the system. So here's kind of like an example of how you might do that. So if you look at the top registration here, this is a node alias registration, and you see it's Biffy ID is for my domain slash host slash a so this is we're calling this host a and her infrastructure. And the selectors here are appended by the node resolver which I, let's say I've created some node resolver in this example it's called my fancy node resolver. And so it depends this selector which says, Hey, I know something about this host, it's called host a so I'm going to give it this selector. So what this means is when an agent comes to retrieve its identity registrations from spire server. It's first going to be matched against this node alias registration, and then any registrations which are specifying this register this node alias registration as its parent will also be sent back to that agent. And so we can define these workloads with parent IDs of spiffy my domain host a for workloads and B. And then that allows us to scope only the and B workload identities to this host a. So next is a workload attester and this is an agent side plugin. And so its responsibility is to reach out to some trusted authority and interrogate it for some process selector metadata that we can use to match against registrations in spire server. So what are some example authorities that we trust inspire might be an operating system kernel like the Linux kernel, it might be some sort of orchestration platform. And so here are the examples of the plugins that we support today, we support Docker and Kubernetes and Unix based workloads. So workloads that are just native processes on a host. And so this is how the workload attester flow works at a high level just to give you an idea. So at the top here this green box is your workload, and it connects to the workload API running on the next domain socket by spire agent on that host. That work really API basically has one API which says give me an identity. And so that's what the workload calls. And it says I'd like an SFID to identify myself to other actors within my system. The spire agent then uses this workload attester system and looks for all the configured workload attester plugins that it has, and it interrogates each of those external systems to try to discover attributes about this process that's running Kubernetes workload attesters configured on this particular agent. And so both of these are interrogated, and we find some selectors from each of them through the Linux kernel and through the Kublet API. And so those give us some additional metadata and based on that metadata we translate that into something called a selector, which is part of an identity registration inspire. And so if the registrations ends if there's any registrations inspire, which match the set of selectors returned from these third party systems then we can issue an identity for this workload, based on that registration. Next is a key manager plugin here, and this applies to the server and the agent components. So this is responsible for managing the private key operations and storage of private keys throughout spire. And so some of the key things that we want to manage here are the private key generation, so how it gets generated what kind of a key it is. And then also doing things like computing digital signatures on different identity documents that we may be something we may want to offer to a third party system. And so are the built in plugins today for the key manager or the disk and memory plugins. So you can store the keys on disk, which allows you to retrieve them on the host after the server or the agent. You know, goes down and then comes back up it can retrieve its identity back from disk memories and other options if you want to just keep the keys and memory. That's also possible. And then the last plugin here we'll talk about is the notifier plugin. And this is a server side plugin today. What this does is it publishes notifications of different key operations in spire, and it currently is only used to publish trust bundle events so when a bundle is changed, you can publish that new bundle out to some third party storage. So the plugins that you're supported here today are Google Cloud Storage or in Kubernetes bundle, where you can write out this bundle some to some external storage. You can actually implement a spire plugin. So say maybe like you have some use case that is not solved by these built in plugins and you need to extend spire for that case. So what you would need to do is in the GitHub repository for spire. There are these plugin interfaces defined at this proto spire location. And then under that there's an agent in the server directory, and then different plugin types underneath that. So for whatever plugin that you need to implement, you would find that interface for the component that you're trying to extend, and you would implement that interface. And then you would add config stanza and whatever component that you're implementing the plugin for. So this is kind of one example like let's say you have a custom node attestor plugin, and you have called this my node attestor. This is kind of how the config might look in whatever. And but I guess in this case node attestor applies to both server and agent. So here the node attestor is specified by its name which is called node attestor my node attestor. So there are three key things to point out here. One is, you have a plugin command, which is a path to the binary on the host that the spire server inspire agent processes can launch. And then you can optionally provide a shot 256 checks from of that binary, so that you can know that that binary is something that you expected and not something that's been modified on the host. And whatever data is required for that plugin you can provide in this plugin data section which is customizable for whatever plugin that you are implementing. Okay, so I want to quickly touch on also some downstream integrations so this is kind of second category of integrations that we're talking about here. So once you have spire up and running how do you actually use these identities effectively. A very common paradigm now is this idea of the service mesh, where you have these proxies which manage the network connectivity routing between different services in your environment. And you know, center, you know the logging and, you know centralized operations of authentication things like that. So spire actually has a native integration with on boy. It implements the on boy secret discovery service it's called sds. And so that's implemented by the spire workload API today. And so what this means is you can transparently enable mutual TLS and using on boy through on boy configuration. So when you have a spire deployment up and running all you have to do is add this additional configuration which is documented and spot spire documentation and you can get mutual TLS up in your environment. Another example here is how do you use an svid outside of your own infrastructure. So if you have external services which are part of your environment which is probably pretty likely. If that supports open ID connect Federation, you can set up Federation with inspire and supports Federation. And so there's an example that has been put together it's pretty cool that actually shows how you can authenticate to AWS management API is using svids. So in this case it's using a JWT svid. And there's more links later on for all this. So what are some future extensions we're considering there's a proposal going out currently called an agent list mode where you're able to request spire should identity directly from the server, as opposed to from the agent. So this kind of enables things like the serverless use case where you don't have like a dedicated node where the process is running. It's something that you know comes up and it's transparent to you you don't have control of that node entirely. And then we also have started exploring some integrations of the patchy data projects so in that Hadoop kind of ecosystem. There's curve roast based identity so how do we translate the curve roast based identity into spiffy identities and make that coexist in this environment with spire. So to conclude here. We showed how spire can be extended for different use cases and bring identity to complex environments that may have a variety of proprietary or open source or cloud native tooling. And we showed how this plugin model inspire enables you to develop your own internal proprietary extensions or open source extensions that other people can consume as well. And so here are the links to reach out to the community we'd love to hear from you if you have input on any potential future plugins or if you have questions about some of the existing plugins or what's available. We're very happy to engage with you further. So thank you very much for attending this talk and we'll turn it over now to Q&A.