Cloud Native Computing Foundation Cloud Native Security Conference North America 2021, 30 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Service Authentication - Tokens or Certificates?- Marc Boorshtein, Tremolo Security, Inc.

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Service Authentication - Tokens or Certificates?- Marc Boorshtein, Tremolo Security, Inc.

The audience for this talk is anyone that is interested in rolling out a services infrastructure. Authentication is generally offloaded to the infrastructure, rather then handled by individual services (or at least it should be). In addition to the daunting number of decisions to be made at the service layer for configuration, authentication is often one of the hardest because it bridges both technology and business requirements and control of decisions may fall outside of the implementer’s ownership path. Having a roadmap for how to choose the right mechanism can either free or hamper implementation and future expansion because it is so foundational to the security of a service.

A

Thanks dan, uh so we are going to talk about service authentication and specifically um how to choose whether or not you're going to use tokens or certificates in your authentication, real quick who am I, like dan, said: I'm the cto of tremolo security um got 20 years of identity management. Experience uh big, you know fortune 100 companies, governments, um you know various vendors.

A

Over the years I've been working with kubernetes since 2016 wrote a lot of documentation around open id connect, worked on implementing authentication the dashboard and in most recently in kiali and co-author of kubernetes and docker and enterprise guide.

A

So enough about me. uh So when we're talking about whether or not we're going to use tokens or certificates inside or to authenticate your services start by asking yourself a few questions, you know first off, does your service use end user data? Some services are service to service. Some services are used by end user applications and a lot of that will dictate uh the easiest way to go for authentication.

A

um How much is automated? uh If you're not automating, at least something, then you should probably take a step back and think about how you would automate it, because trying to do this stuff manually is going to get you into a lot of trouble.

A

How complex is the network a lot of times when we start talking about certificate, authentication versus token authentication? A big thing to think about is how close is your authentication point for the certificate to the actual system that it's protecting and then? Finally, how does a transaction span multiple service calls? You know most complex services are more than one call you're, not just gonna, say: okay, call this one service get your answer back you're done often you'll call one service, they'll call two other services to get the job done.

A

Does the transaction span that do you have to be able to get user context across those services?

A

That makes a big impact on which way you decide to do your service authentication.

A

uh So this slide's really the biggest slide. I'm actually gonna see if I can get rid of the make it a little easier for me. um No, no, maybe not! Oh, am I still sharing. I am not shoot.

A

Try that again, all right cool, um so uh this particular side is really the one that you want to pay the most attention to it. It brings together a lot of the information on comparing and contrasting certificates and um uh tokens when we're talking about uh certificates. You know the big strength of the certificate. Is you have no secret going over the wire very, very secure when you do it correctly?

A

um You know a big benefit. There is the fact that uh you're you're, you know you're generating your private key you're generating certificates getting trusted your your service doesn't need to know anything about that private key. There's, no shared secret. You look at tokens. The big strength is its ability to be able to move across networks easily you're able to say, okay, here's my token doesn't matter how complex the network is.

A

The other big thing that's great about tokens is that it can generally include identity, claim information in it, so you're able to uh put, for instance, user context, information group information, perhaps transactional information that can all be verified, so you don't have to go back to the source in order to get that data.

A

Now, when you're, looking at the drawbacks of these two methods with certificates, the biggest drawback is one that security that I mentioned only comes. If you do it the right way and by right way I mean you're, generating a private key in a secure store, you're generating a public key and a certificate signing request that certificate signing request is getting signed properly and then re-imported using something like istio or other service meshes where this is done for you. That makes it a lot easier.

A

If you're doing you know generating a p12 file and then downloading it chances are you're not doing it correctly. So doing that correctly is very, very difficult.

A

Another aspect of certificate authentication that can be much harder is revocation checking. Certificates tend to be very long-lived because you don't have that secret going over the wire, and so with that long-lived credential, there's a chance that that credential has been revoked that certificate's been revoked. Well, there are only three ways, really two ways: honestly that are standards-based, that you can do that either you're checking, what's called a separate certificate, revocation list might be pulling it from a file system or ldap or you're querying ocsp.

A

A very old protocol to check to see whether or not the certificate is still valid um kind of a flaky protocol truth be told, and it can be very problematic. So if you have the the certificate in order to do it securely, you need to make sure that you're generating it securely. You also need to make sure that you are checking for revocation. That revocation part is very hard to do in most instances with tokens.

A

The big drawback is, you have to have send that secret over the wire, so whether that secret is um a really well-built cryptographic secret or um a really poorly built, you know hand encrypted secret, doesn't really matter. The fact is it's going over the wire, so if somebody gets a hold of that token they're able to use it without having any other piece of information, there have been attempts to build standards to to bind a token to a connection.

A

They had one a couple years ago that microsoft was really pushing didn't, really go anywhere. Chrome decided to take it out of its own implementation.

A

um So uh you know that that's always been the biggest issue with tokens is: how do you protect that secret over the wire? uh The biggest way to mitigate that risk is to have very, very short-lived tokens. So if your token's only alive for a minute chances are by the time the attacker gets a token figures out what it is figures out, what they can use it for it's already expired. So that goes back to the automation piece about why automation is so important for your security.

A

And then the other major drawback for tokens is that doing a proper service to service exchange can be really painful. uh There is a specification that lets you do it. It's called the oauth 2 token exchange. I just probably I'm still wearing my mask. Sorry, the os2 token exchange it's doable. It works very well, but it's something that you need to know how to do inside of your code. Inside your token.

A

The big risks with certificate authentication boiled down to are you using it properly and then how far away from the application is the certificate.

A

So, when you're doing something like istio, where you know you've got that side car, that's validating the certificate for you right up against your pod, that's really great, because there's very little distance between your certificate validation, your applications, the fact that it's just injecting some identity data as headers is not a big deal. If, however, your certificate validation point is, you know four proxies up, and now you just have some standard contact information going through these proxies there's no way to validate it.

A

That becomes a real security risk at that point, that anybody can inject that information along the way you can't really track it from level to level.

A

The major risk for tokens is going to be the fact that it is a bearer token, it's a something that goes across the wire somebody catches that somebody logs it by accident. That's where you're going to run into issues.

A

So food for thought, while you're looking at which one to choose, don't be afraid to mix and match there may be scenarios where you're going to start off. Let's say you have an application that application is going to talk to your services.

A

That part might be token based because it's really easy for a web application to work with tokens. Users aren't generally going to have certificates. There are some instances where that's not true, but for the most part your users will have tokens, they won't have certificates, but then, once you get into your infrastructure, maybe you then switch from certificates or from tokens over to certificates. That's perfectly valid to do that. Transition just make sure you're logging, it keeping track of it.

A

Things like that service meshes and api gateways are really important, and the line has gotten fuzzier and fuzzier over the last couple years as to whether you'd use a service mesh to do authentication or an api gateway, but whichever one you choose and I'm not going to say, one should be used over the other. It's going to really depend on your situation.

A

Don't do it alone, don't try and reinvent the wheel, because chances are, it will go horribly wrong and it, I kind of say, like inventing your own authentication systems like inventing your own crypto. Don't do it. um There are a lot of standards out there with thousands of hours of peer review.

A

Thousands of implementations, um you know, stick with those standards, the you know they might not be perfect. uh You might not think it suits your need or the what you want, but chances are the terrible documentation for those systems is really what the problem is.

A

A

Some links and resources a couple of blog posts that I've written about certificates versus certs for the api server specifically and then using tokens in pipeline authentication just gets into the real nitty d gritty detail of how service accounts work.

A

And then this blog is written by a friend of mine, alex ellis he's the author of open, faz and inlets, and this blog is really interesting because it talks about using uh uh oidc with tokens from github action. So using github actions to securely call.

A

Open fads he based it off of a new release of a tool that lets you use, github actions, oidc to call gke resource and the great. This really shows both the um the benefits and the risks of using tokens, because in this one example, you're able to both generate tokens across different mediums.

A

But at the same time, that means secrets are going over the wire, so you're getting better security by not having a secret stored locally, but then you're still getting a security boost. Because now, okay, I'm running my github action. But I don't have to generate a secret in order to use gke.

A

uh And then, finally, some shameless self-promotion say hi on twitter.

A

If you are looking for an identity provider, we make open unison, open source identity provider, deploys writing to cates, and then our book kubernetes and docker and enterprise guide. That's it thanks. Thanks, so much mark.