 Good to be here back in person. So today we're going to talk about a couple of things. We're going to be talking about workload identity. We're going to be talking about multi-cloud. And more specifically, we're going to be talking about the multi-cloud access problem and how we're going to solve this with workload identity and technology such as Spiffy, Spire, and Tonya. So before we go ahead, a little quick introduction. My name is Brandon, and I'm here with my colleague Marius. And we are both from IBM Research. And today we are going to start by telling you a bit more about workload identity, how it works in a cloud provider. We're then going to bring this into multi-cloud context. And we're going to talk about solutions that work today and some of their limitations. And then we are going to introduce this notion of a universal or organization-wide identity of which we have a really cool demo for you. So we have a lot of content to dive into, so let's go ahead. So let's first introduce the concept of workload identity by looking at the anatomy of a workload identity within a context of a single cloud. So every cloud provider handles workload identity in a similar way. So each of them has an identity provider that comes in the form of a rule of trust or certificate authority. This certificate authority then issues identities through the form of usually some kind of infrastructure service, such as for AWS, for example, would be the AWS metadata service. So we then have a workload that's running on, let's say Kubernetes or OpenShift. This container that wants to access a service, such as a database, what they have to do is then they have to talk to the service to obtain a workload identity that comes in the form of usually X519 certificate or JWT token. They then present this to the identity and access management on the top of the cloud. And because the cloud is well integrated with itself, it's able to authenticate the workload identity and provide access seamlessly. So now let's talk about this in terms of multi-cloud. In this scenario, we have an organization example where we have three different clouds. If IBM cloud, we have a zero and AWS in blue, green, and yellow respectively. So we notice that if a workload kind of lives within its own silo, we don't really have that much of a problem. And in fact, within a single cloud, I am identity and access management is pretty much a solved problem. However, the difficulty comes in when we want to do multi-cloud access, when we want to access a resource from one cloud from a workload in another. Example of this is on the access and AWS S3 bucket from a workload in IBM cloud. So let's talk about how this is done today. So the first method is using long-lived credentials. This is probably something that most have done before myself included. And what this involves is, for example, if I want to access Azure Cosmos DB as a resource from IBM cloud, what I would do is I'll go up to the Azure service, say, please create an API key for me or some long-lived credential. And myself as an administrator would take this API key, which is just a bunch of bytes. I'm going to create a Kubernetes secret. I'm going to mount it into my workload, and my workload will then be able to access the service. So this technique is great, because it's very simple. It's really easy to get started. Unfortunately, it comes with several caveats, so one of which is we are using a long-lived credential. That means that it's very difficult to measure risk. If there's an incident that happens, it's difficult to measure the blast radius. The second part of this is that as we saw, we had to trust an administrator or components, such as myself, in order to handle these highly privileged credentials. And therefore, we are putting a lot of trust in a single admin or single component, which in compliance cases can lead to a lot of complications. So the next method of doing this is through Cloud Federation. The idea behind Federation is very simple. It means that we want to teach an IM system for one cloud how to interpret and how to authenticate identities from another. This is usually done by protocols, such as OIDC, or taking the trust bundles or certificate authorities, and then moving them to the next cloud. And this is great, because we are still using the short-lived credentials from the cloud. We don't need administrators or any intermediaries that come and handle these credentials. Awesome, talk's over. Unfortunately, this is not the case. So there are several problems with Federation today. So the first is that Federation support kind of varies within the clouds. If I want to access a GCP resource from AWS with Google Cloud's identity pool service, this can be done fairly easily. However, if you want to do the opposite, this is a fairly involved process. And this blog post linked here actually describes what you need to do. You need to install a bunch of things in your Kubernetes cluster, and so on. So besides that, secondly, each cloud does workload identities or defines workload identities slightly differently. So every cloud provider has its own identity scheme. It may contain a bunch of attributes. It may contain policy IDs, security group IDs, and things like that. The issue with this is that some of these fields may not have meaning in other clouds. For example, AWS security group IDs, when we see it from an IBM cloud perspective or a zero perspective, don't really have any meaning. And what this results in is it becomes difficult to manage identities or to create meaningful access policies across clouds within the organization. And lastly comes the problem of scale. So we are doing cloud to cloud Federation. So we can see that, for example, just with three individual clouds, if we federate all of them, we end up having to maintain six different trust relationships. And this is not even considering what happens if one cloud provider decides to add something into its identity scheme, or decides to change some attributes of its identity. So to be able to solve this problem, we don't have to look too far to draw inspiration. In fact, if we ask ourselves, if we look at user identities and ask ourselves, how do we address the problem of user identities? And the answer to that is done organization-wide or globally. When we think about a user, John, for example, we don't think about John as John AWS, John IBM cloud, John GCP. We think about John from development, he's a funny guy, you know, he has access to these bunch of clouds, right? And so the question is, why don't we treat our workflow identities the same way, right? Applications and services are after all organizational constructs, right? Why are we married to this idea that workflow identity has to be tied to the platform? So how do we do that with workloads? So to do this, we say we wanna have a universal or organization-wide workflow identity. So what this means is that first, I need to define an identity scheme for my entire organization. So why identity scheme? In this example, we take from the Spiffy book, we can see it has the name of the organization, it has a region, so maybe we can use compliance or compliance controls, whether it's dev staging prod and also the department or the project in which the workload belongs to. Another part of creating an organization-wide workflow identity is you wanna really minimize the points of federation so you have a single point of federation. So this is great because it helps reduce risk of misconfiguration because operators only need to deal with one scheme and they only have to deal with one federation point. So now that we want this, how do we go about doing it? And we're gonna introduce this concept of a zero trust workload identity management platform. I know zero trust is like a very overused word. In this case, when we say zero trust, we just mean that everything's authenticated and tested throughout. So what do we need out of this platform in order to make universal workload identity work? So first of all, we need to be able to define what the identity scheme is. We need a way to enforce identity scheme throughout our organization. It's also as important that we make sure that workloads get the correct credentials and the workloads with the correct credentials really have been attested and we can prove that it is there who they say. And last but not least because after all, we wanna alleviate the management problem. We wanna have a single point of federation to all the cloud services. And how we're gonna do this is we're gonna use Spiffy, Spire, and Tonyak. So, all right, I'll give you a bit more. There we go. Awesome, so let's meet the technologies. So these three projects are all CNCF projects under the Spiffy umbrella. We have time to go too much in the detail, but so Spiffy, first off, is the secure production identity framework for everyone. It is kind of like the identity spec. It defines how workloads can securely obtain the identities. We have Spire that is the implementation and implementation of Spiffy. In this case, it provides the zero trust associations of the workloads and the infrastructure as well as together with the OIDC discovery service provides a final federation. And last but not least, we have Tonyak which is a control plane slash UI for Spire and together with the Kubernetes workload registrar, it provides a way to define the universal workload identity and foster. So our claim is that if you install a zero trust workload identity management platform and you kind of exercise this notion of organization-wide or universal workload identity, you're gonna get all the great stuff that we talked about and in addition to that, you're gonna be able to centrally manage as well as audit all your workload identities. So with that, I'm gonna pass it on to Marius who is gonna show you a really cool demo. Okay, thank you, Brendan, for the great... So let's take a look at our hypothetical scenario of several Kubernetes clusters and they are deployed in different clouds. We have Microsoft here, Amazon, IBM cloud. Then we deployed workloads that need to access the S3 storage bucket. So we will demonstrate that using universal workload identity, this task is very simple and very secure. So first, we need to stand up the identity management service with Spire and Tornyak to manage all the organization workloads and all the identities in the cluster. Then we deploy Spire agents as demon sets with one agent per each node in every cluster. Then every agent is attested with the Spire server. For attestation, we are using cloud provider-specific plugins or attestation that is based on Kubernetes platform. This solution is giving us zero trust attestation for underlying infrastructure. Next, we use the Kubernetes workload registrar that automates the process of creating universal workload identities for all the workloads in the organization. All the agent attested workload identities can be easily viewed and managed from one location, which is the Tornyak interface. Once we have the universal identity schema using the open ID to federate these identities, we can use this for federating across all the clouds. Now we can create and manage policies that control access for the all organizational workloads for access to storage, for example. So in our quick demo, we will show you how to enable the identity provider in Amazon, how to set up the policy and role for guarding the access to S3 storage buckets. And then we'll demonstrate the workload running in IBM cloud that is requesting the universal SPIFI ID for itself from the agent and then using this identity to request access to the storage. So here's the example of the universal workload identity that we use for our organization. It's composed of the trust domain that represents the organization, the name of the region, cluster, namespace, service account, and pod name. So here's just the example. Just for fun, we use the open shift in SpaceX that is running in US East region. The cluster name is TSI Cube 01, default namespace, and Elon Musk service account. So now we can define policies that would guard access to the S3 storage. So in this example, we want the region to must be in US location. We can use any Kubernetes cluster. However, the namespace must be mission and service account Elon Musk and the pod must start with the Mars mission name. Okay, so let's do a quick demo. Good? Okay, so let's start with the Tornaq interface. So if you look at the navigation bar, we have a management for clusters, agents. We can list and manage the entries. There is a section for server information and the Tornaq dashboard. So let me just go to the clusters. And here we go. We manage six different clusters and they are deployed in different locations, different clouds. So for example, we have here Amazon. This is Azure and there are a few in IBM cloud. Some of them are OpenShift and others are just the native Kubernetes. Okay, if we click here on Tornaq info, you can see that this spire server is defined with node attesters. And right here we have one for Kubernetes. There's one for Amazon and Azure. Okay, if we click here on the dashboard, oops, sorry. When we click here on dashboard, we can view here agents, workloads and all the clusters. So let's go to one of the clusters. We're going to use the TSI cube 01, which is in IBM cloud. Right here, details. And here we go. We have three nodes with three different agents. They are all attested, you can see here. Let's look at the entries. So there is one entry here. This is the workload registrar that automates the entries for all the workloads that would be created here. Okay, so before I show the demo on how we create the workloads and get the access, let me just show you quickly what we've done on Amazon site. So here is our Mars bucket. It's called Mars spire. And there is a special file called Mars TXT, which is the sensitive file that we want to protect. So this is what we want to govern. Okay, so next we go to identity management for Amazon. And right here, I'm going to just copy this guy here. Okay, thank you. Okay, so we're going to create identity provider. So let me just click on provider. Open ID, collect type. I'm going to use the URL of the spire server. Good thumbprint, okay, here we go. It works. We define the audience. Let's say my S3, I guess that's it. Add the provider, okay, done. So we just created ourselves identity provider. So let me look all of them, you see all of them. Okay, this is the guy, SpaceX O3. Okay, so we've done this already earlier. So let me show you how we define policies. So there's one X05 that we would be using further. So let's click on the roles. Okay, there's a role called Mars mission. Okay, what the roles do? They basically tie the policies with the identity provider. So let me show you how the policy looks like. Come on, all right. So there's a policy that defines read access to the Mars spire bucket, the one I showed you earlier. And let's look at the trust relationship for this identity provider. Here are the conditions. So the conditions that we defined for this experiment are following. It has to be OpenShift, SpaceX organization. The region must be US. So it has to begin with the US prefix and the cluster name, Mars, I'm sorry, mission, namespace, Elon Musk, service account and Mars mission, the pod name, okay? So we've done here. Now let's go to the cluster. So this is the blue cluster. This is the IBM cluster. So from here, let me show you there's nothing running yet. All right, so let's create Mars demo. Okay, so what we just did, we created a service account, Elon Musk, and then deployed a Mars mission on this account. All right, it's running right here. Okay, let's now get inside. And we have just a quick script because I don't want to talk and type at the same time. So let me just show this demo script. So the first operation, we're going to retrieve the JWT token, which is basically the identity of this container. So let's do that. And here is the identity in a text format. Let's take a look at edit. So we have an OpenShift space X, that's the domain, that's the organization. Region is running in US South, cluster name, TSI Cube 01, namespace, mission, Elon Musk as the service account and the pod name. Okay, so in theory, that should comply with the policy that we created earlier. And this chunk over here, that's the JWT token. So let's retrieve this guy into a file. All right, it's done. Now we can invoke the call to AWS to copy the file from this backend. So let's do this. As you can see, we are using the role Mars mission. We passed the JWT token that was captured a minute ago and we just simply asking for a file and copy it locally. So let's see if it was delivered, it's done. Let's just look what's inside. And here you go. You have a recipe for the concentrated dark matter from the Rick and Morty series. Okay, so before I go, I would like to show you quickly that we could now go back to our super cool Tornyak. Okay, here we go. Where was it? The clusters, TSI QoPo1. Okay, and here you go. This is new identity that was created. You can see, you can easily see it from Tornyak and so are the other ones. Okay, back to the presentation. Okay, so in our demo, you could see how easy it is to get identities in one place from all the multiple clusters, multiple different clouds, and one policy allows access enforcement for several dynamically created workloads. In fact, in our multicluster organization, if you invoke the same calls in any of the clusters, you should get exactly the same results in the theater, assuming that policy complies with the identity of the workload. Okay, so we also have a demo that shows the same concept, but this time using Vault and for retrieving secrets from Vault. So in interest of time, I suggest going to the recording that will be listed at the end of the presentation. So just to summarize, the universal zero trust workload identity runs on everything that supports Kubernetes. It strengthens the security by executing cloud provider specific attestation, as well as the platform attestation, and it can support different identity mechanisms like IAM, key clock, open standards like open ID using consistent universal identity schema. So Brandon, back to you. I'm just a little bit before we end. So the project that you saw the UI is Tonyac. This is something that Mariush and I started working on pretty recently. We are both maintaining it, but we are also looking for more maintainers. They are not IBM as well, have the governance. It's fairly, it's still in development. So there's a lot to do that it's going really fast. There's a lot of cool things too that we're gonna work on, such as integrating with the policies as well as aggregating logs. We're open to a lot of feedback. Tell us what you think, as well as if you like what you saw in the demo that Mariush gave, we have help charts to kind of like help you redeploy the whole thing, as well as we have a bunch of YouTube videos that kind of show a little bit more than what we have time to share today. So if not, yeah, let's start shepherding our cloud native cattle. And I think there is one talk that's after this around talking a little bit more about how to define those 50 IDs. If not, thank you very much.