 Okay, so welcome everyone to our lightning talk, hardware backed security for multi-tenancy at the edge with Spiffy and Parsec. Let's quickly introduce ourselves. My name's Paul Howard. I'm here representing the Parsec project. I'm a solutions architect with ARM and I lead the team that's contributing to Parsec inside of ARM. So, Andres, over to you. Thank you, Paul. And I am Andres Vega. I am product manager for the Spiffy-inspired products, representing the products. And I happen to also work at VMware as a product line manager. Okay, cool, thanks. So what we're going to see today is a first glimpse and a first demonstration really of how Parsec can work in combination with Spiffy-inspire and how we can use the security and key management abstractions of Parsec in combination with the production identity framework of Spiffy to provide us with a multi-tenant security abstraction where multiple workloads can use hardware back to security to protect the private keys based on their own attested and proven identity. It's the first time we've shown all three of these CNCF projects working together to provide an integrated solution. So let's just quickly summarize what these projects are. Parsec is the new kid on the block. Parsec joined CNCF Sandbox just earlier this year and it's the platform abstraction for security. Parsec aims to create a uniform software interface to the hardware security of any platform making secure services like key storage and cryptography available to cloud native applications in a platform agnostic and language agnostic way. So application developers know they're getting the best available secure features of their platform like hardware protection for private keys but they get that without having to understand and code against all of the specs and APIs that are needed to store keys in say an HSM or a TPM. Parsec handles all of those details and then allows applications to just code against Parsec. And not only that but they can code against Parsec using their preferred programming language and using an interface that is simplified, fluent and sensitive to common use cases in key storage and security. And let me hand back to Undress to summarize Spiffy and Spire for us. Thank you, Paul. That is very interesting. So Spiffy and Spire, Spiffy really defines a set of interfaces, the APIs and the documents for proving, validating and obtaining service identities. Spire is the software that implements the Spiffy interfaces for establishing trust between different systems. Now, when we talk about trust that goes from securing the microservice communication automatically through application proxies, X519 certificates or JSON web tokens, it can help authenticate to common third-party services without relying on any API keys or embedded secrets. And it can also help build, bridge and extend service meshes across organizations without sharing any private keys. Back to you, Paul. I think you're going to talk to this one as well, Undress. I do intend to talk to this one as well. So bringing the projects together and an integration, Parsec is establishing the key store partitioning logic you see here at the bottom of the picture. Now, from a developer perspective, it is a platform agnostic experience. Nothing changes in their workflow. And from an application perspective, these being multi-tenant applications, neither application can see each other's keys. They're hard partitioned. All that is required is a reliable source of identity to tell one apart from the other. Okay, great. Thanks. And that's where Spire and Spiffy come in, of course. So for multi-tenancy to be a feature of Parsec, there has to be this reliable and verifiable source of identity. That source could be anything, in fact, and Parsec doesn't prescribe a single solution to that. But if our workloads are running in a Spiffy trust domain, then it absolutely makes sense for Spiffy IDs to be what Parsec uses to separate the clients and isolate their key storage. And all that's needed is the appropriate three-way integration between the application, and Spire and Parsec. Now, all Parsec client applications talk to Parsec through a client library, but it's linked in process. So if we give that client library the capability to consume a Spiffy identity in the form of a Spiffy verifiable identity document or an SBID from the Spire agent on the local machine, then the clients can pass that SBID to Parsec in the form of a jump token, which is added as an orth header onto the API request as it goes from the client's library into the Parsec service. And then the triangle is completed by a new Authenticator module that we add to the front-end of Parsec, which is going to see that incoming SBID and verify it using the trust bundle from Spire. So let's get to the demo. And before I run through the demo here, I just want to make a couple of shout-outs to some great people in the CNCF community who've helped to make this possible. So firstly, to my colleague at ARM, Ugg Devalon, who actually made the demo we're about to see. Also, Joe Ellis, who was the founding contributor of the CLI Parsec tool that you're going to see us using. And lastly, to Sabry Blackmon, who created the Rust Client Library for Spiffy that we're going to use here. Now, what you're about to see, we split the screen into these four quadrants and each one is showing a shell command session. They're all running on the same machine. So on the right-hand side, we have our services, Parsec lower right and the Spire service and the Spire agent running upper right. We've created a very simple minimal deployment here where both the service and the agent are running together on the same machine. And the services will run during the entire demo. We've got logging enabled so that you can observe what's going on in the services as we go through the demo. And then on the left, we have the two client windows and in these, we're going to use the Parsec tool, which is just a simple command line scripting interface for Parsec. And we're just going to go through some simple key management operations. Nothing more complicated than just creating, listing and deleting some keys. But the important thing we're going to show is that each one of those clients has its own key store. The key stores are isolated from each other because each client has a different Spiffy ID. Parsec is going to verify those IDs and partition the key store views so that neither of our clients is able to see the keys of the other. Okay, so let's start by spinning up the Parsec service. And then from one of the client applications, we'll just run a quick ping using the Parsec tool just to make sure that Parsec has been spun up and is healthy and agreeing to talk back to us. So there we go. And now upper right will spin up the Spire service. And then we will generate a join token from the Spire service, which we need to start the agent. And so now we're going to use that join token to join the agent to the system. Okay, and there we go. So we have the agent running there as well. So now we're going to register two Spiffy workload IDs for our two clients. We're going to do this based on the UNIX user ID of each client. So we're running each client as a different UNIX user. We're using the UIDs, 1002 and 1003. So in this really simple system, the only selector is going to be the UID. But of course we could have any number of selectors to map the workloads to their IDs. Okay, so both of our workloads now registered with their two different Spiffy IDs. So let's now go ahead, start interacting with Parsec from those two client windows. And we're just going to use the Parsec CLI tool here to run some simple key management operations. So first of all, we'll list the keys. And we get an empty list back to show that we're starting from a clean state. We haven't created any keys yet. So you can see the bottom right just there also. We'll highlight it just there. The Parsec has seen and validated the jump token that was passed to it and mapped it to its correct corresponding Spiffy ID which becomes a namespace for the key store. Okay, let's create a key now with the Parsec tool from that first client. Don't worry about the details of the key except that its name is Toto. Let's generate key Toto. Okay, so it's telling us that the Parsec key Toto was generated. You see some chatter there from the Parsec service as well. But now let's switch clients. In the lower clients, we're going to repeat that list keys operation. And you'll notice again that the key store is empty. The key we just created isn't listed. Now the reason it isn't listed here is because this is a different client, a different Spiffy ID and also it's a different namespace and so it's a different key store. This one is still empty. And just to labor that point, you'll also see that we can't delete that key either. If we try to delete it here, let's run a delete command. It's actually a destroy command. Let's run a destroy command for Toto. Okay, Parsec is now reporting that we're trying to delete a key that doesn't exist. So it is now ensuring that the second client cannot see or try to work with or do any operations on the keys of the first client. So let's go back to where we can see it. Let's go back to the first client top left and now destroy the key. Well, we list it first, show that it's still there and then we'll destroy it. And lastly, one final list keys to show the store is empty again. So there we go, it deleted successfully. And we're done. So you've seen two distinct Parsec clients using Spiffy Inspire for the identity management, Parsec for the key store management, using those Spiffy IDs to ensure that the key stores are kept separate. And that's it, that's the demo. It's very simple. We're just creating and destroying some keys, otherwise not doing anything interesting with them. But it very visibly demonstrates this principle of isolation using the Spiffy IDs as the namespace. And with that, let me hand over to Andres to wrap up the talk for us. Thanks Paul, you've said simple, but it is illuminating to see how we can do hardware backed security for multi-tenancy at the edge in a very simple but secure way, leveraging Parsec, Spiffy Inspire. If you would like to learn more about the projects, how they come together as well as the intricacies that there are to each of the projects respectively, we'd like to invite you to check the resources available you see on the screen. You will find the code repositories on GitHub for both Parsec as well as Spiffy Inspire. The respective Slack channels, if you have any questions, if you would like to share work that you're doing and it would you like feedback or the perspective of others, that's a great place to come join, exchange ideas, learn from others and collaborate with the community. And last, here are some links to the project websites for each of the projects where you will find documentation available. I hope that you find our talk informational and hopefully it's something you can get to try for yourself pretty soon. Thank you. Thanks very much.