18. Anders Eknert, Developer Advocate at Styra, On Evolved Authorization

Welcome, everyone, to another episode of the Security Podcast in Silicon Valley. Today, I'm joined by Anders Eckert from Styra. Thanks, John. It's great to be here.

Anders brings to the table a lot of great experience. I always love like non-traditional backgrounds. And so to help our listeners out a little bit, do you want to explain what Styra is as a company and that open source project that's behind it? Yeah, sure.

So Styra is the founders of the open source project, the Open Policy Agent or OPA, which is an open source general purpose policy engine. So basically it works by based on policy you provide it, you ask it questions and it gives you back answers. It's an oracle in that way. An oracle, a policy-based oracle providing decisions and answers to whatever questions users or services or other types of clients might have.

So policy commonly determine whether like a piece of infrastructure can be deployed to an environment, whether a user should be allowed to do action X or Y in some environment or in some system, or whether a Kubernetes resource could be deployed to a cluster based on any data provided as part of the input, which is often the resource itself. But it could be basically any kind of data, like the time of the day or the weather outside or whatever you can imagine. That's pretty much what OPA does. Thank you so much for that.

And OPA, just so our listeners know, is entirely open source. You can deploy the entire stack yourself. It has a great developer community behind it that helps drive it forward so that you get the advantage of the full-time developer team with none of the overhead, just for that one component. And everyone there is excited to do the right thing.

I know that I've contributed just a little bit to OPA in a past life. Yeah, no, when I was at Pure Storage, we actually used OPA to help us to help make our systems decide whether or not someone had the authentication and authorization to access specific production machines. And we wanted to drive all of that with a policy. And so the open policy agent lended itself really nicely to that use case.

And we ended up building it and it fit really nicely with the rest of our integration. And then after we had done all of that with the, just that open source project, we noticed that there was a company behind it, Styra. And at which point we saw the demo, we saw the GUI, we saw all of the testing features and the change lifecycle management that's get stuffed into Styra. And I ended up leaving Pure Storage before that discussion ended.

But I remember being really impressed and I wasn't expecting it and had nothing but great things to say about the engineers that I did have a chance to work with over at Styra. Nice. Yeah, I can, I'm obviously biased, but. .

. You're biased, but I'm a little bit less biased because I have no stake in Styra. So I just wanted to share that. Yeah, what I can say is my story is pretty similar.

I used to work for a company, Biznode, which is a big like provider of data to various like governments, governments, organizations and corporations. And we were gonna out there looking for some way to solve authorization. We had a distributed environment, like pretty much all environments are these days. So we had about six or 700 services and we wanted to solve authorization in a unified manner.

We didn't want like the way we did it before was pretty much each team came up with their own way of kind of solving authorization. Some ways were better than others, of course, but eventually they were all different, which made it really hard to work together across team boundaries and so on. And more importantly, it made it pretty much impossible to audit what was going on because these authorization decisions, they tended to get logged. Sometimes they got logged, sometimes not.

And when they got logged, yeah, whatever other logs were published or sent, which differed between all the teams and all the components. There wasn't a way to audit, which was like a hard requirement for us. Then we traveled down to Spain that summer. I think that was KubeCon EU because incidentally in Spain this year as well.

So we got down there and it wasn't for the purpose of finding an authorization engine, but that was really what we did. That's where we kind of opened up our eyes to OPA. So we got back, did a little proof of concept. We implemented authorization for a few microservices.

And then we just rolled from there. And then once we had that in place, we saw, okay, we can use this for Kubernetes as well. We can use this for infrastructure. We could use this for so much more.

So we could just go from there. And yeah, eventually, I too found out about Styra because after a while, like our Opa cluster or clusters of Opa's running in our environment just grew and grew. So eventually we found that like we were going to need some way of managing this across like this large environment. So we either we build something or we'll see if there's something better out there.

And that's pretty much how I found out about Styra. And yeah, I worked with them for a while. We eventually, we kind of got on board as a customer. And yeah, I guess I had too much fun.

So eventually I was like, the grass was greener on this side of that. So here I am. Amazing. So we basically have the same story, except you ended up working for them.

Yeah, and you're not yet. Yes. Okay. I like the enthusiasm.

I appreciate that. And that's awesome. Do we think of Styra as a security company or is it more of B2B change lifecycle management company? Maybe those are the same sorts of things, a security company is a lifecycle risk management company.

Yeah, I guess there's no like clear cut definition. Yeah, at least I tend to think of us as a security company. I do too. Yeah, I do too.

I really see that. It's in your DNA. It's in the experiences that I had with your developers and the open source project. And I know for myself, security has always been a great passion, but maybe you'd be willing to share your story of how you got into security.

Yeah, for sure. So the first, it was actually, I've been to this company Bismal twice. The first time I was there, I was in a team where our like task or main objective was to provide an identity solution for the company. And so, yeah, we kind of got involved in all these standards around identity, like OAuth and OpenID Connect, the SCIM standard for like user provisioning and so on.

And eventually I got involved in and I started working for a vendor in the identity space and that's security, which is kind of a little witty name. They have like Curity and it's, they're very heavy on the Java or on Java. So they have, and in Java, when you provide like a package name, you have these kind of reverse way of specifying a URL. Since it's a Swedish company, it's SE, it's the country code.

So it's SE. Curity. Wow, that's cute. Okay.

Yeah. Someone gave that a lot of thought. So for our listeners, this is spelled C-U-R-I-T-Y, Curity. Yeah, that's right.

That's right. So it's SE Curity. So I spent almost two years there working with all these standards, learning the ropes around identity and so on. But an interesting aspect of identity, and I think like for most of these identity companies, is that they're very like, they're very strictly scoped to identity.

And whenever we'd have customers who were asking like, okay, so now we have this token, we got like a JSON web token or something to prove identity. What do we do with that? That's obviously authorization. And we were all like, nah, that's really not our concern.

That's not our business. Eventually I got curious, like, what if it was my concern? Or what are people doing with these tokens? Or how are they, how do you solve the authorization problem?

So I kind of planted something that eventually led me here. So let's talk about like the problems that these two companies are solving just a little bit. The authentication problem, I always think of that as the answer to the question, who are you? That's right.

I should just like one answer to that question. And if you're authenticated a user, it's usually goes back to a person, but you can also do that for a service or even a particular device or an instance in the cloud or a node on Kubernetes or whatever. It's like the answer to the question, who are you? And then the other question, the other problem is the authorization, or sometimes called authZ for short.

And what's that one? Yeah, that's a good question. Like I've been here now for a while, but it's part of, it's part of the fun. Like I don't.

Again, it's pretty strictly scoped, but it's also very well defined. You have all these standards to your like disposal. While authorization for so long, it's been like, there's been really no standards. There's been no, like, none of these big vendors in the security space have really cared for that until a few years ago.

So it's been like the wild, it's been like the wild west pretty much, where like as compared to identity where everything is like super well defined, there are standards everywhere, and you don't really deviate from those standards. So in that sense, like, it's great to work with standards, but they're also limiting in terms of creativity. And yeah. Yeah, because of AuthZ is the answer to the question, what can you do?

I often find that those are business driven. And so that's why I think OPA is pretty powerful because you have your own internal definition of what a policy is, and you can, you just throw it into GitHub and now you have your change management under control for your policies, and you can go back in time and see like what decisions were made for what groups of folks, not just individual folks. If you want to make decisions based on individual folks, you can do that, but it's all just a policy at that point. And the policy says whether or not you're allowed to do something or not.

Like you mentioned in the beginning in Oracle. Yeah, for sure. But I think while your identity, that's pretty much, it doesn't really change if you move across organizations. Like your identity is pretty much, like you said, who you are, maybe what position you're in the company, maybe some roles, and so on.

But on the authorization side or the policy side, that's all, there's really no rules there. It's all determined by that organization or whoever is going to design that authorization system. So it's often, it's way more flexible. It's way, it's way easier to do it wrong as well because there aren't really these guidelines for how to do it.

I think, yeah, OPA tries to be, or tries to provide, or doesn't try to hinder this really, but it allows you to have your policies reflect on the needs of your organization or the needs of your team. So whether it's good or bad, there's certainly room for mistakes compared to having a strict standard to follow. So OPA is that you have this policy language, it's called Rego. So you define your policies.

Oh, it's called Rego. Oh, I've been saying it wrong all of these. I've been calling it Rego. Yeah.

I'm so happy that you have corrected me. I actually did that too. So someone corrected me, but yeah, it's apparently pronounced Rego. And yeah, it's a.

. . Is it a Swedish word? It's not.

Oh, Styr is a Swedish word. Yeah, it definitely is. It's one of the founders, so Styr, it's like Finnish origins, and he took that word with him when he founded a company. So it's pronounced Styr in Swedish, which means pretty much steering or to govern or to steer.

That's really appropriate. It's really appropriate. I love that too. But Rego is actually the reason, is the reason that, you know, we jumped on OPA back in Pure Storage.

That's where all that flexibility comes from. Yeah, it's really flexible and it's designed to model the way you talk about a real-world policy or a policy is basically a set of rules, which is obviously, that's what a policy is in the real world too. So you define these rules and based on data that you have available or like organizational rules or so on, and then you query OPA for decisions based on these rules. So you might say something like, I'm, this user is a doctor trying to access like the medical journals of this patient.

Should this be allowed or, and OPA would provide that decision. So OPA itself doesn't do enforcement. So it doesn't really do anything with that later. It just tells you, this is my decision, and now you do what you want with that.

So the way you choose to enforce that, obviously that's going to be highly context specific. So, but it's a nice separation of responsibilities. I have this philosophy in engineering just in general for systems. Any systems that can be separate should be separate.

And so I really always appreciated the separation of here's where the decision is made. And then what you do with it is your higher level business, whether you want to block an incoming API request or not sign a token or print an error message or even display different things, like it doesn't really matter. And the nice thing about centralizing where all of those decisions are made is that you get consistent decisions across your entire ecosystem. Yeah.

And let me tell you, that is a difficult thing to do when you have an org of 50 or more engineers and everyone is heads down trying to meet their deadlines and making great contributions to your ecosystem of software. If you're writing software, you don't want 50 different types of decisions being made in 50 different types of ways, all trying to get the same sort of behavior you want. One thing that's going to help everyone make the decisions that they need to make in their business logic. And an awesome tool to help sort of corral everyone in an org, the page row.

Yeah, definitely. On that same topic of separating concerns and separating responsibilities, like another core tenet of OOPA is, of course, the decoupling of the policies themselves and the kind of lifecycle of the policies that you kind of break out of your applications and move elsewhere so that you, yeah, for example, you can deploy updates to policy without having to recompile or redeploy your applications. So the policy lifecycle is kept separate from that of your application code, which is another great benefit when you start to see like hundreds of services or thousands of services. And that was always a pain point for us before when I used to work in integrating authorization.

Yeah, I could imagine. I've had very similar pain points myself, too. So maybe you would be kind enough to share with us and all of our listeners, what was the best day that you've had so far on your entire journey at Styra? Oh, yeah, that's probably an easy one.

We just had a kickoff kind of event in California, which was, well, it was my first time in California, but I think more than that, it was the first time meeting all colleagues. I kind of started, yeah, pretty much when COVID outbreak, so it's been two years at home. So that was a great thing, like kind of meeting all the good people I've been working with for all this time and also all the people who joined since I did. Yeah, that definitely tops it.

Very nice. That sounds like an awesome day to celebrate. And so what about what has been your worst day at Styra so far? Yeah, I wouldn't say there's been like one worst day, but I think like in my role as a developer advocate, it's a kind of creative process, blogging or doing like documentation, talks, so on.

I think as in any creative process or any kind of creative effort, you can, you have bad days or you have good days. And sometimes you have bad weeks where you can just, you just sit and stare at your like your docs or whatever it is you're working on. And there's really not much of value coming out, which is frustrating. And yeah, so I wouldn't say there's been like one worst day, but when you can add, when you're into that kind of a period like that, that Those are draining.

That could just, those are definitely draining. Yeah, for sure. Okay, so how about what's your favorite interview question? If you interview folks, do you do interviews?

Yeah, I do interviews. We're hiring a developer advocate even, so. Oh, you're hiring a developer advocate. All right.

We are. So if you know anyone, just send them my way. We got the word out now on the podcast. So if any of the listeners are interested.

That's great. I, you know, I don't, I can't say I have one specific question, but I think like, like talking about pretty much the things you did now, like what's a good day or what's a bad day or like good experiences working with what kind of tended to work in the past and what did not work. And then try and determine whether that would be a good fit for the team and so on. I don't really believe in trying to put anyone against the wall in an interview situation.

This. Yeah, exactly. I think that's like. So I try to kind of tend to try and keep the conversation as casual as I can.

But yeah, it's obviously, hiring is hard. It's so hard. But I think at the end of the day, it's like, it's just personality and would this person be like work in this group dynamic and so on. Nice.

No, I love that. It's important, I think, to sort of melt the tension, like in an interview especially. And my hope always is the candidates, when I'm doing the interview, the candidates are interviewing me as much as they're interviewing. Yeah, definitely.

It's much prefer a conversation over a monologue. Yeah, exactly. It's just, it's more enjoyable, I think, on both sides. And it actually helps both sides significantly because then you can pick up like better signal of whether or not it's going to be a fit on the company side, but it's also really important that it's a fit on the individual side too.

Yeah, of course. So empowering that person to be able to make the best decision for themselves too. And I get that. That's what we do.

That's what Opa does. So we should too. Yes, exactly. It's an oracle that says whether or not something is good.

Yes, allowed or no, not allowed. Yeah, we're not really at the point yet where we can have Opa doing the interviews, but who knows, at some point. No, no, maybe at some point in the future, you'll pivot into the AI space and you'll be doing the interviews and all sorts of flying airplanes and all sorts of other things. At the end of the day, what is life except for a series of decisions that we make?

And if you just want to punch in the policy that you want to live your life by, it could be a very interesting B2C product too, right? Yeah. Okay, we're in the deep end. We're way, way out in the deep.

Okay, so maybe actually speaking of like forward-looking ideas, a serious question for you. Like when you look into the future and you see Styra out there and you Opa, there's definitely a future for these projects. But what is one other tool that you see out there in the future that you wish someone would just sit down and build already? A problem that you faced that needs a lot of its time to solve it.

Oh, it's in the security space or in any space? Oh, any space. This is very open-ended here. All right.

Yeah, I'm gonna drop out of the security space for a bit then. Like for luxury, it's a very personal and a need or want, really. But I think like, I kind of, I tend to like these apps where you rate things, but there are just so many of them. And they're all like, they all have their own problems and some of them are better than others.

But there's one, I have one app for rating like restaurants. There's one for beers, one for wine. There's, and there's, I just wish there was one app where I could rate like anything and I could get that data out of there to see like my history, what I rate. I know it's a bit of an unusual request here, but yeah, that's the, I guess that's the thing like I miss the most on my phone.

Yeah. Yeah, I hear you. I'm constantly, I live in San Francisco and so I'm constantly, I'm also plant-based. And so it's a little bit tricky to, because you want to make sure that the place that you go is going to have at least like a couple of options for you.

So I'm constantly like looking at reviews and searching people's review, like, because when a reviewer leaves comments, like you have a much better shot of getting like the broad truth, but then Yelp only can go so far and there's other things out there. So I totally resonate with. I think it has better ratings, you know. Yeah, and even like the simple things, like if you go grocery shopping, there's always 20 of anything you can imagine.

There's like 20 things to choose from and you have no idea which one is, which one do people like? And there's really no good way of finding out. So I think that there's a lot of potential there. Or even, hey, I really like this place.

What other places do people that really like this place also like? Yeah, exactly. Exactly. There's, yeah.

And it doesn't appear to me to be like, this isn't a hard problem. It's just somebody just got to do it. It's time and it's energy and it's work. And I'm sure there's a lot of tricky things underneath the hood as soon as you open that.

Oh, for sure. It's not a weekend project. That's for sure. No, maybe not a weekend project.

But if anyone has that entrepreneurial spark, it could be a couple of nights and a couple of weekends, perhaps. Yeah. Yeah, let's hope. Let's hope someone hears this.

Oh, there'll be, there's definitely people that will be hearing this. Anders, would you like to leave our guests with any parting? Oh, yeah, that was probably the hard question here for this interview. Yeah, of course, if you haven't tried OpenPower, I'd definitely recommend doing so.

There's a pretty good resource from Styra. It's called the Styra Academy, where you can learn the ropes and how to get started. And of course, if there's any questions, concerns, or whatever, I'd be happy to help with that. That's like what I do pretty much.

We'll put your email in the podcast notes. That sounds great. No, thank you so much, Anders. It's been an absolute pleasure to have you on the show.

Thanks, John. I really enjoyed being here. And thank you to all of our listeners for tuning in to another episode of the Security Podcast in Silicon Valley. Thanks, everyone.