Cloud Native Computing Foundation Production Identity Day: SPIFFE + SPIRE 2020, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Introduction to SPIFFE by Kelsey Hightower

Description

Keynote: Introduction to SPIFFE by Kelsey Hightower

Kelsey will be taking a look at SPIFFE and SPIRE from a beginners point of view and through a set of live demos demonstrate how to leverage SPIFFE in your own applications.

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

A

Awesome well for me, it's been uh for me: it's been a great learning opportunity. You know I am not an expert in this particular space or this particular domain. Even um like most of you I have to you know: security is just a part of the job, there's no way to escape it. So I take every opportunity to dive a little bit further. So what I'm going to try to do today is just take a beginner's look at this whole spiffy thing I remember when the project was announced.

A

I didn't know what the hell they were talking about, but somehow it's found its way into things like istio, and I see it popping up in other systems. So, like you all, I'm curious to why so one thing that I did I'm going to share my laptop and there probably won't be a lot of slides, I'm just going to walk you through kind of a similar approach that I took for understanding things like most people.

A

I just went to the spiffy website and it's a universal control plane for distributed systems or identity control plane for distributed systems. So, in order to really understand that you have to kind of look at the whole package like spire is one good implementation where you know it gives you the full suite of things for trusting workloads, assigning their identity and doing all the things to give you a complete system. But I was always curious about like how does it all work?

A

So for me, I kept digging a little deeper and the documentation is fabulous by the way. So, whoever is on the documentation team here, someone should give you a virtual high five. You've earned it so clicking through here.

A

One thing that has been a challenge: I've been doing this for about 15 years and whether you're talking about minting ssl certificate or doing tls, mutual off or some other form of authentication or credentials. It's been real hard to identify services in a way that scales well across multiple systems and we've all tried it throughout our careers.

A

But when spiffy came out, it seems very complex and I'm pretty sure I may be oversimplifying things, but here's the thing that made it click for me once I really took the time to understand what is a spiffy id naming. Things is hard, but the way they've chosen to go about identifying the service so we're going to get to a couple of things. One is: what is a service identity?

A

How do you give one to a service and then how do you use it throughout the system? Those are the three things that I'm most interested in as a beginner, so the spiffy idea is the thing that kind of made it click for me. uh One is I asked myself: can it really be this simple?

A

Can it really be as simple as this string? Spiffy is the kind of url. Then there's this trust domain like example.org and then the workload you're talking about it could be your payments workload. It could be your api or it could be a calculator app that does add functions but either way, they've simplified. This whole thing down to string, and this string has a lot of information that it can communicates very succinctly. This can actually help you make work with different applications and different domains. You can have different service polls, you get the idea.

A

So looking at this simple string is I ask myself like what do I do with it? Wouldn't it be crazy if just any app could take this string and give it to another app and say: hey trust me. This is who I want to be that typically doesn't work. You need to kind of earn your credentials. So how do we do that?

A

How do we trust- and I may be getting some of the terms wrong, but it seems like bootstrapping trust and security is one of the hardest things to do, because at some layer you have to trust something or someone, and for us we're going to choose to trust something.

A

So we understand this string, but now we've got to figure out how to create them and hand them out to applications or workloads that deserve it. Now, if you're using spire and there's going to be plenty of talk throughout the rest of the day about spire, they have a really good implementation of doing this. By making sure only the right workload gets the right spiffy id, but we're going to roll things by hand just so we can get a little bit deeper in details of how it would work.

A

So just like most good projects, there's a lot of documentation about the details. So what most people do is when they think about spiffy. You can embed them into a tls certificate if you use something like istio and you're doing tls mutual auth, where app a wants to talk to app b, well, app a can present its ssl certificate and have a spiffy id embedded in one of the subject. Alternative names and that's cool because then proxies and other tools can extract that and decide to trust that you have that identity.

A

And let you do things in this case, though I'm actually sitting behind a proxy that doesn't allow tls mutual off. Actually, I've made things a little bit harder for myself. I'm actually running inside of a serverless platform called cloud run, no kubernetes, no vms, none of the environmental things that I'm used to. If I was doing on some vms, this would be a whole lot easier to solve, but I'm not so. I have to solve this problem in a slightly different way.

A

I'm not going to be able to use x509 or tls certificates for this I'm actually going to have to use a jot token. The nice thing is they actually have a specification of how to actually embed a spiffy idea, trying to remind people we're talking about a string.

A

That's your identity, but we need to mint one only for the workload that's supposed to have it in a way that other workloads can trust. So with that I'm going to use what they call a s, fit or secure verifiable identity document, and you can use certificates or, in this case a jot token. We've all used them before.

A

I'm going to show you how that works underneath the covers, but basically what we want to do is we want to create a jot token, and if I go through their documentation, they have things about certain claims and, if you're not familiar with dot tokens, basically I can put in who this particular token is for who should be able to receive it and also who's holding it, and that's going to be that spiffy id and a spiffy id will be actually what we call the subject right.

A

So we're going to embed a spiffy id into one of these job tokens that we just can't go and give them to everyone. So who do we trust? I can't trust the workload damn you're not going to trust you, but maybe I can trust the cloud provider and that's what I've done.

A

I'm going to speed things up quite a bit here, because we only have so much time, but basically I have a container running as an off service, but I've named it jwtsvid, that's the service and the way it works is if I take a workload and give it a google chat token.

A

What I can then do is map a set of spiffy ids to google cloud service accounts. I'm going to show you how that works. Real, quick, so first thing I'm going to do. Is I've deployed this service into the cloud? The thing I want to do now is: I want to get a token from it, but in order to get a token, I have to prove my identity by getting something that this off service trusts. So I have a little command called get token and what it does is it gets my gcp project.

A

I get the url of the cloud run service you can see here, so I know who to exchange this other token with and then I'm just going to use the google cloud command line tool to generate an id token, I'm going to impersonate the service call calculator. So basically, what I'm doing here is. I have a calculator app that can call a back-end to add some numbers for me, but the ad service only wants to allow only a calculator to do it now. What I don't want to do is rely on google service accounts.

A

The thing is those only work for things that understand how to verify them with google, but you might want to run things on vm or on-prem. So this is where this whole spiffy thing becomes super important, it's pretty portable across all the cloud providers. So what I'm going to do is I'm going to generate an id token by calling the the google cloud iam service and I'm mimicking what I would do in a deployed application.

A

So once I get an id token from there, I'm going to pass that id token to the serverless off service and see what comes back so we're just going to run this really quick called git token and again, I'm getting iam token id token and I'm going to use it to connect to the serverless application and what that service application is going to do is going to mit me a token now when I call this command. If everything is working, come on internet guides move a little faster.

A

You can see, I'm impersonating this account and I'm getting back a token. So let's look at this token now what I'm about to show you is dangerous. So don't be doing this in production with your real tokens, but for this example token it's okay, I'm going to go to jwt.io and I'm going to post this token now be careful, there's a header, the actual jot token and the signature. These can be replayed if you do this with the live token, to get access to resources. But this is for testing. So I'm not too worried here.

A

You can see the contents of the payload. I could verify this using the private key from this particular service, but you're, seeing here that when I authenticated, I got back this audience. That means I can actually pass it to the addition service and then the issuer is my off service running in my domain and look. It gave it a subject back of spiffy hightower labs calculator.

A

Now one thing we're going to do is I'm going to show you how I actually made this work? Well, there's a couple of things so bin I'm going to run a command and I'm going to show you my registry. So in my custom implementation, that's minting tokens. I also implemented a in-memory registry and the way it works is I can actually send registry entries up to a in-memory database. So basically the registry basically says for this given id.

A

This is a google im service account id the audience should be x and the spf id should be y right. That's how it works. So all I'm doing is saying give me your service account.

A

I have a mapping that maps this calculator iam service account. You can see its unique id and I will find that unique id in the registry and if I don't no tokens for you, so this is an easy way for me to map jot tokens using something that I trust. So I verify the dot token from google make sure it was issued by google verify the public key and then extract the subject from the google service account and mint a new token with those attributes like we see here so great.

A

We have that first part of the puzzle solved. We have a third party, we trust google cloud's iam service.

A

Now you have a token in your hand, and now you have an identity that others can trust as long as they trust my certificate so quickly we're going to move up really quickly. Here we have a certificate and how do I get the certificates?

A

Well, if you know anything about jot tokens, you know that that off service can also serve up the public keys that can be used to verify things or you can embed that public key. So here, I'm following the spiffy documentation saying that the use of this public key is for validating svids and here's the public key that you can verify that this was signed by this off provider. Now, one last thing you got to do here, so we set up the first two stages.

A

Next thing we got to do here is figure out. How do you use it? What's the purpose of having this identity, if you're not going to use it for anything when you think about service mesh and all the features you want to do, and most security models they're all hinged on ids? Who are you, then? What can you do, and this is when we bring in something like open policy agent- and this is the last component of the demo, so what we can do with open policy agent?

A

Let's see if I can screen my screen down here and what opa allows us to do is basically do auth z for what we can do with this identity. So I know who you are, but what can you do? So if you look at this, I have a package for this is a rego file. Don't worry about the syntax. Now just know it's a way for me to communicate policies. I also have an open policy agent running as a serverless app.

A

So here it is, it's running in a container and cloud runs serverlessly and I've populated it with this policy that I'm going to walk you through. So by default, I'm going to deny everything, but when you make a request, you can say hey from your application. So let's say you were the ad service. You would go off to the backend and say: hey open policy agent. Here's some metadata about my request.

A

I'm going to do something interesting here, I'm also going to pass the token when I put the token into the request to open policy agent open policy agent can verify that token. It can also decode that token extract the header, the payload and the signature.

A

The nice thing about this is: I can use that information in the token, in that jot token, with the spiffy id to make policy decisions, do I allow you to add the numbers that you're requesting so from my service? I need to put in some data and what I'm going to do with my input data I'm going to check for some matches. Is this a post request?

A

Is it at the add path?

A

Is the audience for me the addition service was it issued by the off service, and again I should validate the private key here and then also down here is: is this the calculator app for the high tower labs domain?

A

If all of those things are true, then I'll respond either yes or no, and we're going to do the last piece here, I'm going to show you what it looks like I'm going to use curl to do this, so we can get a clear picture now. I could have deployed all the apps to do this, but I want to give you a peek at how this works underneath the covers.

A

So one thing we can do here is validate a request, so assuming that your app was presented with that jot token, we saw earlier what you would have to do inside of your application is you would have to craft the input data again, the method, the path and the token, and then what I'm doing here is basically getting the url to the open policy agent service and then what I'm doing is I'm authenticating to the open policy agent service.

A

I know that can be a bit confusing, but I'm not going to keep that thing wide open for various reasons and then the next thing I'm going to do is pass in this request.

A

So the way that request looks like on my file system is basically a post, the method, the path and the token I'm going to submit this, and let's see what response we get then and we'll do a validate request. Again, I'm simulating the addition app assuming that the calculator front end is calling it so we'll run this now and what should happen is I should get a response from the backend, so it's saying, hey method is get or allow equals.

A

True uh method was git path was add, and here's this token, so I know we're getting low on time. So I'm going to stop here, but basically this shows you full circle, one. We have a root of truss. In this case google cloud iam.

A

We have a custom service, that's minting jot tokens by trusting service, account tokens and mapping them to a registry id and yielding back a job token that meets the spiffy requirements. That token now can then be used with other systems that can also delegate off z to back ends like open policy agent. I'm going to stop there see if we have any questions, and hopefully that kind of explains this thing at a high level. For you all.

B

Hi everyone, um if you have any questions at this point, please feel free to put them in the chat window or raise your hand for kelsey. Thank you so much kelsey for doing this.

A

B

Like one or two takeaways, you'd like to.

A

Leave folks with.

B

A

Learnings yeah, so I think for me I can see you know. I work at a cloud provider, I'm working at google cloud and I think about the spiffy id actually taken off in a big way.

A

We already support it in tools like istio and our service mesh technologies, but I can imagine us adding maybe one day a spiffy id to go with those id tokens, and maybe you won't have to exchange them anymore or the other way would be if you're, in a serverless environment, where you can't necessarily control ahead of time- and maybe you don't want a pull model where your app is exchanging one token for another, you might be able to push things like into a secret.

A

So if you're in the kubernetes space, I would encourage you just to look at tools like spire. That does all of this, for you with way more robustness, but I think there's going to be a world where, if this thing takes off, I can see almost every tool being able to trust this identity, and it's actually a lot simpler than I thought before. So I'm hoping more systems integrated natively. So we can all standardize on what a service id actually means.

A

B

Go ahead, amen, yeah, I was going to just say I think people message you directly privately, so I don't see those questions.

A

I'll read one so here's one: how do you know that iem token can receive the token for the off calculator? So when I deployed I'm gonna, I think I'm still sharing my screen right yeah. So when I deployed this jwt off service, I had to do a few things. One is. I said that when I deployed it that it must not allow wide open, authentication, so services off bin deploy.

A

So the first thing is, I don't allow authentication by default. The next thing is that means you have to present me a google cloud iam id token right. You have to get that from the metadata service once you do that. I also have another thing that says I granted um permissions to the calculator service account to be able to even invoke this jwtsvid service. So this is an iem policy where I have a binding that says if a caller were to present a jot token signed by this service account, it can invoke this function.

A

So if you don't have one of those ids or service accounts or jot tokens, then you're going to get rejected at the google cloud load balancer. It won't even let you make a request so then, when it flows to the auth application, I can also validate there.

A

I can take that jot token and use google's public certificates to also validate it and then once it's validated, I can then extract the id because that's going to be in the subject field of the id token, and then I have my own internal registry right and all I'm doing to add things to the registry are just um all I'm doing here is just basically collecting enough data about the service account id and I'm just posting it again by authenticating to my off service, so checks and balances end to end.

A

I think we've got time for maybe one more or two.

B

Yeah, I think so um I don't see anything chat live here. Do you have? I think you had one more question in there about.

A

Our picture diagram, so let me go here, uh there's a couple yeah so service, so the architecture diagram. I think this turned out to be a pretty good demo, so I am going to publish this whole thing on github, it's in a private repo. Now but I'll add the architecture diagram and some of the trade-offs I'm making and what you'll find in that github repository most of the code is already there there's a custom, jose implementation of jws and also all the keys.

A

One thing I tried to make it easy to do also is to make sure that this works in a real world. So if you ever have to validate these tokens across other systems, I do implement most of the standards so that you can actually verify these using the public keys that you can get from the auth back in we'll spit this one out here in a second and so that'll, be on github soon and maybe I'll tweet out when it's done so I'll just say, hey my spiffy demo is now on github.

A

You can go run it yourself. The next thing is, um is the toku is the token issue or something we have to build ourselves and if not, if we're not on a managed cloud or in a pre-print on-prem kubernetes offering right. So if you're using spire, it's going to do a good job of dealing with, probably you know, x509 certificates, tls mutual auth is probably the path you want to go if you're on prem, with kubernetes just go, get spire and certs that way, that will probably be much easier than what I'm doing here now.

A

I'm not sure aspire supports jot tokens at the moment. So if you have a use case similar to mine, we're going to be going through a low bouncer that won't be able to handle tls mutual off the way to think about. This is maybe something like ping identity or off zero. If they allow you to have some metadata where, when you authenticate, typically, what you can do is you can set custom fields using some kind of template that when you return back a response, they'll have a jot token.

A

So, ideally, most of the standard tools for minting jot tokens should work. You just got to make sure that those tools are configurable based on the original identity, whether it's basic off or some other factor, then you can actually say hey based on that identity. Here's what should be in these fields when I return a jot token, so my guess is standard. Things will work, but if you're not using jot, go check out spire and do it. Oh, it turns out that spider has support for both x509 and jot.

A

So I actually spent the whole night when I can just use that. But look I learned a whole bunch in the process spiffy the hard way, I'm so happy along with you. Thank you very much. Kelsey.

B

Yeah we are, uh we have time for one more question: kelsey, which one can you answer? First.

A

All right so well, so the next one I'll end with this one, how is multi-cluster and federation supported in this kind of use case? So I think this is what this whole thing is about. One thing: that's nice about x509 in general, it does allow each of the servers to have a certificate signed by authority. We trust and we can trust lots of authorities. If you look at your, you know your tls certificate bundle for cas on your file system.

A

You'll, see that there's a lot of bundles in there that you trust what we're doing here with spiffy is giving some you know very similar technique of using these federated trust models. This is what jot tokens are already good at. This is what x, 509 certificates are already good at.

A

So when you start thinking about multi-cluster and federation, what we're doing is we have this detached way of saying here's, a bunch of public keys inside of our clusters, give them to your app, so they can actually trust things and then, when that jot token shows up, you may not necessarily need to call out to another service. You can actually use your public key or something like open policy agent that is configured to be able to decode and verify these tokens, and that's going to give you that decentralized, federated method.

A

But again the smart thing that they've done is just leverage existing things that already work in a federated and distributed manner.

B

Great, thank you kelsey. I think we're right on time, but we could take a short question if you want- or we can just send you these questions, maybe you can give your responses and we can post in the in a doc in the community.

A

Yeah, so do that and I'll answer one more since we have one more one more minute or so so can we use an app in one cloud to talk to an app in another cloud using spiffy as a single trust provider, and I think that's where things get super interesting, because in my off service I could trust multiple identities, multiple backends. This is something that spire does really well. It gives you a universal way of saying. I trust all these things so imagine if you're using spire spire can be configured to trust, amazon's metadata service.

A

So when you get your identity document from amazon's metadata service, so you're running on a vm, you can exchange that or use that to get a different token or x 509 certificate and I can use a whole different trust model inside of gcp. But at the end of the day you end up with these identity documents that are standardized that keep a common spiffy id, so maybe you're all in the same domain, even across multiple cloud providers. You can look at that domain to say, hey we're all in the same app domain slash.

A

This is your app. I can trust you to do these things, so it really helps us to kind of normalize the differences between the different cloud providers and then have a standard thing that we can all rely on, whether we're in multiple clouds or on-prem.

A

B

Think it just started to take off.

A

Hasn't it yeah, I mean yeah, there's people that are already using this. You see this, it's a hidden thing, the bad thing about it. It just works. So this is why there's no hype train! That's! Why there's probably not a bunch of 10 000 people conferences, it just works so much that most people kind of take it for granted that this kind of complex problems being solved in a very clever and simple way.

A

I think that's why most people may not talk about it but guarantee you that it's there and I think it's actually taken off in a way that will become. I don't know you may not ever realize it, but you should learn about spiffy ids.

B

Right awesome, kelsey. Definitely thank you so much for your effort and time and.