 Hello everyone, welcome to KubeCon EU 2021 and thanks for joining my lightning talk. My name is Daniel Feldman and I'm a software engineer at Hewlett Packard Enterprise and today we'll be talking about securely bridging cloud native and traditional workloads with Spire. In a traditional organization, we implemented security through strong perimeters. We have network level devices like firewalls and VPNs that connect your users to the right resources. But as we add new services, new data centers, new clouds, new regions within one cloud, then this becomes too hard to manage and secure. Spire is the solution to this problem. With Spire, a single identity provider distributes secure identities to all the services within your organization. And then once each service has its own identity, they can establish secure connections. Now when I refer to identity, I mean two concrete things. Either a X509 certificate or a JOT. And they both have two different uses for establishing different kinds of secure connections between your resources. Now you've already heard me use the term Spiffy Inspire. Spiffy is the standard for implementing the service identity layer and then Spire is a specific implementation of the Spiffy standard. They're both CNCF projects, they're open source, there are many companies involved and you can join any of our meetings and contribute to any one of them. On the left, we've got a little bit of a timeline of the Spiffy and Spire history. This technology goes all the way back to the early 2000s at Bell Labs, where there we were developing service identity technology. Then Google developed something similar, Netflix developed something similar, Kubernetes came out in 2015 and immediately had the need for some kind of a service identity layer. So this goes way back. In 2017, Spiffy and Spire were introduced and then in 2018, very early on, a couple of big hyperscalers including Uber, TikTok, and Square adopted Spire as their service identity layer. Now in 2021, we're seeing growing adoption of both of these technologies. So let's go through a quick summary of how Spire works. First of all, there are two components. There's a Spire server and a Spire agent. Now, when the agent starts up, its first job is to prove its identity to the server. So it provides some bit of information that allows the Spire server to verify its identity. And then the Spire server can go out to cloud APIs like AWS, Azure, Google Cloud, can go out to the Kubernetes API and verify the identity of the Spire agent. Then once the Spire agent's identity is verified, we go through a different step called workload attestation. And in workload attestation, the agent checks the identity of the workload. So the agent is talking to Kubernetes, it's talking to Docker, it's talking to the Linux kernel, and it's verifying the identity of the workload process using those operating system and platform primitives. And then it's giving it the right identities according to your organization's policies. So this is all pretty straightforward when we're talking about one cluster. The key idea of Spire is you can have one Spire server that's talking to agents throughout your organization on different platforms, different clouds, different Kubernetes clusters, and they're all talking to the same Spire server, all getting the same policies, and then all distributing identities in a uniform format. Then once every workload has its own identity, they can establish secure connections using a variety of different protocols. So that's the lightning talk. If you have any questions, you can visit us at spiffy.io. You can read the spiffy book. There's the URL. The book is called Solving the Bottom Turtle. You can also join our Slack workspace. I'm on Slack all day, spiffy.slack.com. That's the best way to get questions answered quickly, or you can email me at the address on the screen. Thanks for attending my lightning talk.