Omri Gazitt, Aserto | KubeCon + CloudNativeCon North America 2023

This is Textron tv. Hey there. Welcome back.

C**n here, 2023 in Chicago, Thai Town. So we're having a great time. First day of the conference.

It's really going well. Lots of us, lots of people, very well attended. And uh, as we said, having great conversations here on Textron tv, including with our next guest, uh, AMRI Gazette.

Gazi Gazi. Gazi. Thank you.

Yeah, with Erta. Wake up, man. It's good to talk with you.

We chatted before, but it's been while. Yeah, yeah. Nice to be chatting with you.

So, well first of all, kind of tell us a little bit about Serato and kinda what you guys do, and then we'll get into some good stuff. Absolutely. Serta is a cloud native authorization platform.

So we set out to solve authorization. And you know, my background has been in cloud native technologies, you know, from, you know, 15, 20 years ago at Microsoft and at HP building products like OpenStack and Cloud Foundry, and you know, at Microsoft Azure. Uh, and as an industry, we focused almost exclusively on the identity part and not so much on the access.

Well, identity now is a solve problem. Access, not so much. And so, I mean, authentication isn't enough.

You'd think, you know, so most people like a layman audience, you know, they basically go, but it's all off. Right? It's all off.

And you go, well, there's actually two parts to off authentication is proving that you are who you say you are. You know, passwords or biometrics or magic links. A lot of different ways of doing it.

Now, two factor, but mostly a solve problem, right? And authorization is now that you're logged in, what can you do in the context of the application? What permissions do you have?

What roles do you have? And so that has no standards, no developer services. It's kind of the wild west.

Mostly what people do is they bake a lot of like spaghetti logic inside of their application, And they think it's the directory's gonna solve all that for 'em. And not really. I mean, that's more identity.

Exactly. Maybe there's some access rules in it, but not certainly across the entire cloud platform or application. That's right.

I mean, ironically, back in the days of active directory, I used to be involved. I used to run the, the project and Azure active directory. Is That was you?

Oh, okay. Yeah, I know that's, it's our fault. It was easier back then because at least you had users belong to groups, LDAP groups.

Yeah. And then you would basically authorize based on what group the user was a part of. Today, there's no such thing.

There's no like global place where all of these roles and direct, you know, and groups and users are stored. So that's the problem that we're trying to solve. So talk to us a little bit more then.

How do you, how does that, what does that look like in today's cloud world? I remember the active directory days. Yeah, yeah.

Uh, kind of, sort of, it's been a while, but, so what does it look like today? I mean, where do you start? What do you have to then put in place as opposed to go roll your own, build it, build your own?

Right. So today, basically every microservice has to kind of hand roll its own. And a, a lot of teams we're now seeing like, that are basically intent on treating this as a cross-cut concern.

And the reason for that, you know, primarily is security and agility. So security, um, broken access control is the number one issue on the oasc top 10 list. oasp is the organization that does web application security.

And so they basically have determined that a whopping 94% of the applications they test have some form of broken access control. I can imagine. So these organizations are like, not no more, like, we can't deal with this anymore.

Every time we have a breached identity, you know, like the, you know, it wreaks havoc in our systems. Think about how, how do you test that, right? Writing exactly a test plan to go through every permutation of everybody's account And do that.

And the problem is that do that, it's it's application logic. So 20% of all the logic that application developers write are all these spaghetti logic if statements and switch statements. So what's the process?

The first pro, the first thing you need to do is extract all that logic, kind of take it out of the application and express it in its own domain specific language. And that's where cloud native technologies come in. So we have a project called Open Policy Agent that's primarily used in infrastructure scenarios, like how to protect your Kubernetes cluster, what's called Kubernetes admission control.

There's a project called Gate Gatekeeper that's based on opa. What we've done at a Serato is we've created a different open source project called Topaz, and it brings OPA as a decision engine, but then makes it possible for you to actually build API and application authorization using that same open source technology. So for example, if you wanted to go build something like Google Docs, right?

And so you're, for example, you know, an owner of a document and you wanna share that document with me as a viewer, well, you could basically assign it to me directly as a viewer, or you could basically say, well, I'm gonna make the, you know, engineering group a viewer on this document, actually, I'm gonna make it a viewer on the folder and I'm gonna put all these documents in the folder. Well, that's pretty complex to build. That's how Google built its authorization model, and they extracted their own service out.

It's called Zanzibar. And so what we've done is we've made it really easy to build Zanzibar style authorization models that support RAC and sharing, resource sharing, and we've bunched it up with OPA as a decision engine. So you get the best of both worlds policy as code.

So you write an authorization policy in a domain specific language and policy is data. You get to express these relationships between subjects, users and objects, like documents or folders or things like that. And we'll evaluate all that stuff for you.

It seems like also you would be able to have some, uh, auto trail on changes over time, right? Instead of this stuff embedded in the app and nobody knows why that changed. That's exactly.

Or that it changed, Right? That's one of what we call the five laws of authorization. So we'd say the first one is you extract your, you know, like authorization as a cross-cutting concern.

The second one policy, you know, policy based. Third one is fine grain, fourth one is real time. Fifth one is centralized decision logs.

Why? Because, you know, not just for audit audit trails and compliance, but also for forensics. Yeah.

Right? So if you have a breach identity, what did they do in the application? Well, if you log every decision that each one of these microservices has made, now you have like basically a trail to follow, you know, your security team can look at it and say, ah, this breached identity was able to do this, this, and this.

Um, you know, before we were able to find it and cut it off. And so all of that stuff is critical. That's what we call the five laws of authorization.

Just like, uh, a linuxy admin, you know, wants to see privilege escalation. Yes. How did it happen?

Who did it? What's the, you know, backtrack into How that occurred. Exactly.

And now you wanna do it for applications, not just for the operating system, not just for the infrastructure. So if you take all that code out, mm-Hmm. What replaces it?

Is it API calls to a cloud service? You said it's open surface, you're open, open source, you're running an instance of this in your, in your data center. How Does that work exactly?

So that's the one of the precepts that I was talking about. Real time authorization is the critical path of every application request, right? So you can't take a hundred millisecond network agency to go to a, uh, an internet hosted server across the internet from you just to know whether, you know, Mitch can actually read this document.

Like that's just not gonna work. And so you have to have the authorizer deployed right next to your application. And that's what our topaz open source project is.

It's an authorizer, it's distributed as a, as a, as a docker container, but you know, it's ultimately, it's just a binary that you can run anywhere. And so it makes lightning fast authorization decisions based on local data, but then you want a control plane that manages the lifecycle of the policies, all of the data and the decision logs. And that's what a Serta brings to the table.

So we have a distributed systems architecture where all the authorization happens locally, but all the policies and the data and the decision logs are managed centrally. Okay. Is the local stuff like cashed also data that's relevant to things happen there?

Exactly. Okay. So that's exactly, that's where you get the speed.

Yeah, that's right. So the control plane is responsible for refreshing all the data, making sure that the authorizers have the latest up to the minute data up to the second data, and then the authorizers can make a decision based on local data, and they can make it in a millisecond, literally as fast as a millisecond. So security, I mean, every security person's probably thinking, okay, so in our domain today, it's like, get in, move laterally, move up into the directory.

Right? Exactly. In this kind of a world, how do you, how do you battle against or protect against that kind of a, uh, an approach to attacking this?

So The idea is to really adhere to the principle of lease privilege and the approach of fine grained authorization goes hand in hand with that. I like to say there is no zero trust without fine grained authorization. If you're still resorting to like, basically assigning the, these course grained over-provisioned roles to your users, you're not really kind of fixing the problem.

But what you need is a fine-grained access control system where you're not just a viewer or an editor or an admin for the entire application. You may be like an owner of a resource in that application. And so you don't need over provisioning, you don't need to be able to see every resource to have owner level access to this resource.

Fine grain access control is what gives that to you. And so if we really wanna solve the, the, you know, kind of access control issues, the broken access control issues that are just pervasive, we have to go with a fine-grained approach. Okay.

Interesting. It, it, it would also be the case that the fact that you have a kinda local agent running in a container pretty limited in what it can do, right? I mean, it's caching, it's making API calls back to, you know, the control plane.

Uh, a lot of what's happening is in the control plane, the data behind it. Exactly. So your attack surfaces really just locally Exactly.

Until you, unless you can try to figure out where that is what it is and how to get to it, Right? I mean, you have complete isolation. The authorizer is essentially read only with respect to the data that it has.

You could basically have it, once it gets all of its commands from the control plane, you can't mess with what's in it, right? So it'll literally, you can turn off the ports that allow you to write any data or policies into that container. So the attack surface is essentially reduced down to just making authorization calls.

Um, and since it's read only, you can't really attack it. And our, the control plane is hardened on our side. So, you know, by having that separation between the control plane and the data plane, you've really vastly reduced your overall surface area that you have to secure.

And maybe you mentioned this to me earlier, I'm, or I had a brilliant flash probably you mentioned. It is, you know, one of the things about doing an application logic uhhuh is it's in memory. Yes.

Right? Yes. And if you're doing switches and yes.

Things like that to control what features people can level of con granularity, great. Just getting memory Mm-Hmm. Put a few bits and now I can do whatever I want.

If it's going through now, I don't determine that in my code Mm-Hmm. This gives me the result of yes, no, what the privilege is, right? Yeah.

And so that really enables that separation of duties. So application developers no longer have to like, worry about writing all this authorization logic, like 20% of their code, 20%. I mean, like imagine the opportunity, it's About free, right?

And all that stuff. We write all that authorization logic we wrote no bugs in that. Exactly.

No bugs at all. I mean, those broken access control, you know, vulnerabilities, we don't know how they got there. Yeah.

The Last Person. But it ease the application developer from worrying about that. And instead you can give it to a, a security professional and security engineer.

And they can now reason about the entire surface, you know, area all that logic, authorization, logic is now extracted, expressed in a domain specific language. You can reason about the entire surface area of the, the authorization of, of the application. This may not be a fair comparison Mm-Hmm.

But I remember the, uh, active directory's day, well, the LDAP days too Yeah. Of figuring out, designing how you're structure and how you're gonna do all that. That was a big chore.

That was a lot of work to get all that set up. Yep. So you could start to then, you know, whether it's file server access or applications or whatever, what does it take to set this kind of a infrastructure up?

Great question. So, you know, I talked about, you know, fine-grained, uh, policy-based real time. That's really kind of like functionally, um, what we support in Topaz and aer.

But from a non-functional perspective, we'd like to say fast, flexible, easy. So fast authorizations in under millisecond flexible, we support every authorization model. So rback, aac, reback, all the backs and we run in every cloud, right?

So very flexible and easy to your question is falling off a log easy to integrate into your applications. So what we have is SDKs in every language, not just, you know, kinda low level GRPC or rest SDKs, which we do have of course. Uh, but higher level SDKs where we'll build middleware.

You know, that makes it really easy for an application developer to add authorization with a single line of code, right? Sometimes even just a few characters of code you initialize, you know, the middleware, you place it in the dispatch path of the application, you know, using an attribute, you know, if you're in Python or, or Ruby or using, you know, like a express jss, you know, route handler, uh, middleware or, you know, in go Lang middleware. So whatever the language is, we'll use the idio idiomatic way of integrating into that language.

So it makes it super easy for developers to do the right thing. Uh, what we like to, we used to say back when I was at Microsoft, we used to say helping developers fall into the pit of success Despite themselves. Despite themselves, right?

Exactly. Yes. How, how about data, you know Mm-Hmm.

Data and access controls. Is that part of this world too? Absolutely.

So if you think about fine-grained access control, it's really about access control to resources. And so rather than saying, you know, a course grained role, you know, you're an admin admin over what Exactly, over everything. You know, like, you, like most applications and you know, most enterprises that I know, you know, you may have a role within a department, but not a role across all the departments.

And so, for example, you know, if I have data that's restricted to a certain department, I wanna write a rule around that. I wanna be able to say, um, I'm an admin, but only in the context of these resources, this data. And so we have a lot of folks with that use case.

Um, you know, I would say, uh, financials, um, you know, InsureTech, health tech, all of those types of, um, organizations have pretty strict rules around data, you know, uh, personal health records, for example. You really need to adhere to, you know, a pretty, uh, you know, a pretty lockdown set of rules in order to be compliant. And so how do you do that?

Well, you write fine-grained access control policies, and so this goes hand in hand with regulated industries and so on. Yeah. Auto trails and all those good things.

Exactly. How about if I have an existing directory Mm-Hmm. Of whatever kind, LDAP or whatever Yep.

Infrastructure. I'm using a cloud service. Yep.

Um, I imagine you have to integrate with that, you know, do LDAP interface or some other inner, So yeah, I mean that's connectivity. That's, that's another core part of, you know, so we have the open source project Topaz, but you know, core part of the commercial value prop is integrate with everything, right? So, you know, we have connectors to auth zero, Okta Azure Active directory, you know, ldap, uh, kognito, Google Workspace, pretty much anything where you want to get authorization data, so data about your users or groups relationships between them.

We can import all of that stuff into our system. So you can keep it, the, the source of truth can still be active directory or ldap, and we'll bring all that data in and then you can write your authorization policies in terms of that data. And we solve the hard problem of getting that data in and then distributing that to all the topaz authorizers that are sitting in your cloud right next to your applications.

Cool. So last question. I can think of a bunch of others, but last question is, you know, it's the age, the month, the quarter of generative ai, right?

And everybody's talking about large language models and domain specific and vector databases and all those things. Um, has that become part of this? What's the access control look like for those things?

Or is that kind of still getting sorted out for ai, generative AI kinds of implementation? Yeah, It's a great question. And a lot of people are really worried about, you know, how do I make sure that my proprietary data doesn't end up leaking exactly.

Into, you know, some training system that sucks it in and, you know, how do I know where it goes? Like, so that is, you know, clearly a problem that the industry faces. When I think about the applications of AI to access control, I actually get excited about maybe something that feels a lot more mundane than, you know, generative LA large language models, just the problem of anomaly detection.

Mm-Hmm. Right? So you have basically a set of, you know, like authorization decisions that were made, and all of a sudden I find out that Mitch somehow approved an order in Salesforce in the, you know, in the, in the sales system.

How did that happen? Mitch is an engineer. Mm-Hmm.

Huh. That Has rep privileges engineer. Exactly.

That may be an issue. So I can actually run all of this data through, you know, kind of like, you know, a training system that will then like assign a risk score to whether Mitch, that particular operation should or shouldn't happen. And I can decide whether to allow it in real time or if maybe that's too slow for me.

At least I have that for posterity getting flagged and then causing the security team to go look at their policies and say, how did that happen? Yeah. Should Mitch really have had access to this HR system?

Should Mitch really have access to editing his own salary? And, uh, you know, oh, I think that's a good idea From Mitch's perspective. Sure.

You know? Yes. But, you know, maybe not for the, the hr, But kind more generally though, it's really incident incident response Yes.

Kind of process, Right, exactly. Getting access to that information. So that's the thing I get excited about with, with respect to applying AI to, uh, authorization.

I think there are much more low hanging fruit than just saying, I wanna be able to express in English, you know, some, uh, authorization rules. Yeah, of course. That will come.

You know, one thing that we worry about is authorization really tends to be something that we care deeply about from a security perspective. So we don't trust our systems to auto generate those rules. And that's why I think that it's going to be a little while before organizations are comfortable with people just expressing rules, you know, in, in, in English.

Yeah. You also don't want to halluc hallucination happening exactly when you're, you're writing your rules. So talk to the folks that tell 'em where they can download the open source, try things out, kick the tires.

com/aer. That's spelled ASE RTO dash dev, a assert dev slash topaz. And Topaz is a great project.

You can use that on your own, you know, without basically connecting it with anything else. We have a great set of tools for getting you started. It's one of the few open source projects that has a built in console, like a management console.

So we essentially give you all of the goodies for free. But then if you wanna scale that for your entire organization, you have multiple applications. You wanna express authorization policies, you want to practice policy as code, you wanna centralize the decision locks.

com comes in. A certo is the control plane that allows you to scale all that to your, the, the entire size of your organization. So start with a single project with open source and then graduate gradually, you know, uh, expand that to your entire application.

All right. io. Right?

com, actually. com. com.

We're the real Deal. Wow. You're the, you're the first gin.

Thank you much for stopping by. And, uh, great progress. A lot of things much have happened since you and I have chatted, so It has, it has, It's good to hear.

That's good stuff. Yeah. Good luck.

com and uh, like I said, you could start out with open source and kind of go from there, you know, just some experimentation, build little things, prototypes, apps, et cetera. So we are coming back with more folks for you to hear from, with, uh, great technology stories, uh, also kind of their experiences in the cloud native world. So please stay tuned.

We'll be back in a few minutes.