Access Policy Management at Cloud-Scale with Anders Eknert from Styra
Cloud CommuteJune 07, 2024
1
x
15
00:24:5422.81 MB

Access Policy Management at Cloud-Scale with Anders Eknert from Styra

The podcast episode of simplyblock's Cloud Commute features Chris Engelbert interviewing Anders Eknert. They discuss Anders' background and current role at Styra, the company behind the Open Policy Agent (OPA) project. Anders lives and works in Stockholm, Sweden, and has been involved with Styra for about three and a half years. He shares how his previous work led him to OPA due to a need for managing complex authorization requirements across diverse environments.

Styra, founded by the creators of OPA, focuses entirely on the OPA ecosystem. They offer two main products: Styra DAS (Declarative Authorization Service) and an enterprise version of OPA. Styra DAS helps manage OPA at scale, providing a control plane for policy management, lifecycle, and auditing. The enterprise OPA offers enhanced performance, lower memory usage, and direct integrations with data sources.

OPA itself is a policy engine that enables policies as code, allowing for decoupled and centralized policy management. Common use cases include authorization and infrastructure policies, where OPA acts as a layer between services to make policy decisions. The discussion highlights the importance of treating policy like any other code, allowing for testing, reviewing, and versioning.

Chris and Anders also discuss the functionality of OPA from a developer's perspective, explaining how it integrates with services to enforce policies. They touch on the broader benefits of a unified policy management system and how OPA and Styra DAS facilitate this at scale, ensuring consistency and control across complex environments.

If you have questions for Anders, you can find him here:

Styra and the Open Policy Agent can be found here:

The Cloud Commute Podcast is presented by simplyblock (https://www.simplyblock.io)


01:00:00
And of course, a

01:00:01
benefit of that is like,

01:00:02
we're not giving up on code.

01:00:04
Like we still wanna

01:00:05
treat policy as code.

01:00:06
We wanna be able to test it.

01:00:08
We wanna be able to review it.

01:00:10
We wanna work with all of these

01:00:11
things like lint it

01:00:12
or whatnot.

01:00:13
We wanna work with all these good

01:00:14
tools and processes

01:00:15
that we kind of established for

01:00:18
any development.

01:00:20
We wanna kind of

01:00:21
piggyback on that for policy

01:00:24
just as we do for anything else.

01:00:27
So if you wanna change

01:00:28
something in a policy,

01:00:30
the way you do that is

01:00:31
you submit a pull request.

01:00:33
It's not like you

01:00:34
need to call a manager

01:00:35
or you need to do

01:00:36
submit a form or something.

01:00:38
That is how it used to be, right?

01:00:40
But we wanna, as developers,

01:00:42
we wanna work with

01:00:44
these kinds of things

01:00:45
like we work with

01:00:47
any other type of code.

01:00:52
You're listening to simplyblock's Cloud Commute Podcast,

01:00:54
your weekly 20 minute

01:00:56
podcast about cloud technologies,

01:00:57
Kubernetes, security,

01:00:59
sustainability, and more.

01:01:01
Hello everyone, welcome back to

01:01:03
this week's episode

01:01:04
of simpleblock's

01:01:05
Cloud Community Podcast.

01:01:06
Today I have a guest with me that

01:01:08
I actually never met

01:01:10
in person as far as I know.

01:01:12
I don't think we have.

01:01:14
No.

01:01:14
Maybe just say a

01:01:16
few words about you,

01:01:18
where you're from, who you are,

01:01:20
and what you're working with.

01:01:22
Sure, I'm Anders, I live here

01:01:24
and work in Stockholm, Sweden.

01:01:27
And I work as a developer advocate

01:01:30
or a devrel lead even

01:01:33
for Styra, the company behind the

01:01:35
open policy agent

01:01:36
or OPA project.

01:01:39
So I've been here for, I think

01:01:41
it's three and a half years

01:01:43
or so.

01:01:45
Before that I was at another

01:01:46
company where I,

01:01:49
and that's how I got kind of

01:01:50
involved in the OPA project.

01:01:51
We had a need for a

01:01:54
solution to do access control

01:01:56
or authorization

01:01:57
across a very diverse

01:01:59
and complex environment.

01:02:01
And we had, I think we had

01:02:04
development teams

01:02:04
in 12 different countries.

01:02:06
We had seven different

01:02:08
programming languages

01:02:10
in our cluster and it

01:02:11
was just a big mess.

01:02:14
So our challenge there was how do

01:02:17
we do authorization

01:02:18
in that kind of environment?

01:02:19
And without having to go out to

01:02:22
all of these teams

01:02:23
and try and

01:02:23
coordinate development work

01:02:25
with each change we need to do.

01:02:28
So that's basically how I got

01:02:29
involved in the OPA projects.

01:02:31
OPA emerged as a good solution to

01:02:35
our problem at that time

01:02:36
and yeah, all these years later

01:02:40
and I'm still here

01:02:41
and I'm having a lot of fun.

01:02:43
All right, cool.

01:02:45
So you mentioned Styra, I always

01:02:47
thought it was Styra

01:02:48
to be honest, but

01:02:49
okay, fair enough.

01:02:50
Yeah, no, the Swedish

01:02:51
pronunciation would be Steera.

01:02:53
So you're definitely right.

01:02:55
It is a Swedish word, which means

01:02:58
to steer or to navigate.

01:03:01
So...

01:03:02
Oh, okay, yeah.

01:03:03
So you're absolutely right.

01:03:05
I'm just using the

01:03:07
Americanized, the bastardized

01:03:11
pronunciation.

01:03:12
That's fair,

01:03:13
probably because I'm German

01:03:15
that would be my initial thought.

01:03:18
And it kind of makes sense.

01:03:19
So in German it would probably be

01:03:20
"steuern" or something.

01:03:21
All right, so tell us a little

01:03:23
bit about Styra.

01:03:24
You already

01:03:25
mentioned the OPA project.

01:03:27
I guess we're coming

01:03:27
back to back in a second,

01:03:30
but maybe a little bit

01:03:30
about the company itself.

01:03:32
Yeah, sure.

01:03:34
So Styra was founded

01:03:35
by the creators of OPA

01:03:39
and the idea, I think like, so

01:03:43
that is like the main thing.

01:03:45
Like everything at

01:03:45
Styra revolves around OPA

01:03:47
and I think it always has

01:03:49
and I'm pretty sure it

01:03:50
always will to some extent.

01:03:55
So Styra, what

01:03:55
Styra does is we create it

01:03:58
and we maintain the OPA project.

01:04:01
We created and

01:04:02
maintain a lot of the things

01:04:04
you'll find in the ecosystem

01:04:06
around OPA and Styra.

01:04:09
And also of course we're a

01:04:10
commercial company.

01:04:12
So there's two products that are

01:04:15
all both based around OPA.

01:04:18
One is Styra DAS, which is a

01:04:19
commercial control plane,

01:04:21
which allows you to

01:04:22
manage OPA at scale.

01:04:25
So like from the whole kind of

01:04:27
policy lifecycle.

01:04:30
And then there's an enterprise

01:04:31
distribution of OPA as well,

01:04:34
which has basically a whole

01:04:36
different runtime,

01:04:38
which allows it to

01:04:39
consume much less memory,

01:04:43
evaluate faster, connect to

01:04:44
various data sources and so on.

01:04:46
So basically both the kind of the

01:04:49
distributed component

01:04:50
and the centralized component.

01:04:53
Right, okay.

01:04:53
You mentioned OPA a few times

01:04:55
that I think you already mentioned

01:04:56
what it really means,

01:04:57
but maybe we need to dig into that

01:04:59
a little bit deeper.

01:05:00
So I think OPA is

01:05:01
the open policy agent.

01:05:04
And if I'm not

01:05:05
mistaken, it's a framework

01:05:06
to actually build policy as we

01:05:10
call it policy as code.

01:05:12
That's right, that's right.

01:05:14
So yeah, the idea

01:05:16
behind OPA is basically

01:05:17
that you define

01:05:20
your policies as code,

01:05:23
but not just code as like any

01:05:25
other code running

01:05:26
or which is kind of coupled to

01:05:29
your applications,

01:05:30
but rather that you try and

01:05:31
decouple that part of your code

01:05:34
and move it outside

01:05:35
of your application

01:05:36
so you can work

01:05:37
with that in isolation.

01:05:40
And some common use cases could be

01:05:42
things like authorization.

01:05:44
And I mentioned before this need

01:05:46
where you have like a

01:05:48
complex environment,

01:05:49
you have a whole bunch of services

01:05:51
and you need to

01:05:52
control authorization.

01:05:54
How do we do authorization here?

01:05:56
How do we make

01:05:57
changes to this at runtime?

01:05:59
How do we know what authorization

01:06:02
decisions got logged

01:06:03
or what people did in our systems?

01:06:06
So how do we do auditing of this?

01:06:09
So that is one type of policy and

01:06:11
it's a very common one.

01:06:13
But it doesn't stop there.

01:06:16
Basically anywhere

01:06:16
you can define rules,

01:06:19
you can define policy.

01:06:22
So other common use cases are

01:06:24
policy for infrastructure

01:06:26
where you want to say like,

01:06:28
I don't wanna allow odds to run in

01:06:31
my Kubernetes cluster

01:06:32
unless they have a well-defined

01:06:35
security context

01:06:36
or if they don't allow like,

01:06:42
mounts of certain types and so on.

01:06:45
So you basically define the rules

01:06:47
for your infrastructure.

01:06:49
And this could be things like

01:06:50
Terraform plans,

01:06:52
Kubernetes resource manifests,

01:06:54
or simply just JSON

01:06:55
and YAML files on disk.

01:06:58
So there are many ways to,

01:07:00
and many places where you might

01:07:02
want to enforce policy.

01:07:04
And the whole idea behind OPA

01:07:05
is that you have

01:07:07
one way of doing it

01:07:08
and it's a

01:07:08
unified way of doing it.

01:07:10
So there are many

01:07:10
policy engines out there

01:07:12
and most of them, they do this for

01:07:14
one particular use case.

01:07:16
So there might be a policy engine

01:07:18
that does authorization

01:07:20
and many other that does

01:07:22
infrastructure and so on.

01:07:24
But that all means that you're

01:07:26
still gonna end up

01:07:27
with this problem

01:07:28
where policy is scattered

01:07:29
all over the place.

01:07:31
It looks different, it logs

01:07:32
different and so on.

01:07:34
While with OPA, you have one

01:07:36
unified way of doing this

01:07:38
and to work with policy across

01:07:40
your whole stack and organization.

01:07:42
So that is kind of

01:07:43
the idea behind OPA.

01:07:45
So that means if I'm thinking

01:07:47
about something like

01:07:48
simplyblock being a

01:07:50
cloud native block storage,

01:07:51
I could prevent services from

01:07:54
mounting our block devices

01:07:56
through the policies, right?

01:07:58
So something like, okay, cool.

01:08:00
You mentioned authorization, I

01:08:02
guess that is probably

01:08:04
the most common thing

01:08:05
when people think about

01:08:06
policy management in general.

01:08:09
What I kind of find

01:08:10
interesting is, in the past,

01:08:13
when you did those

01:08:14
things, there was also often

01:08:16
the actual

01:08:17
policies or the rules for

01:08:20
or permission

01:08:20
configuration or something.

01:08:22
I was already like a

01:08:23
configuration file,

01:08:24
but with OPA, you

01:08:26
kind of made this like

01:08:27
the first first class spot.

01:08:29
Like you

01:08:30
shouldn't be in your code.

01:08:32
Here's the framework that you can

01:08:33
just use drop into

01:08:35
or drop before your

01:08:36
application, I think, right?

01:08:37
It's not even in the

01:08:37
application itself.

01:08:40
No, I guess it

01:08:41
depends, but most commonly

01:08:42
you'll have like a separate policy

01:08:44
repo where that goes.

01:08:47
And of course, a

01:08:48
benefit of that is like,

01:08:49
we're not giving up on code.

01:08:51
Like we still wanna

01:08:52
treat policy as code.

01:08:53
We wanna be able to test it.

01:08:55
We wanna be able to review it.

01:08:57
We wanna work with all of these

01:08:58
things like lint it

01:08:59
or whatnot.

01:09:00
We wanna work with all these good

01:09:01
tools and processes

01:09:03
that we kind of established for

01:09:05
any development.

01:09:07
We wanna kind of

01:09:09
piggyback on that for policy

01:09:11
just as we do for anything else.

01:09:14
So if you wanna change

01:09:15
something in a policy,

01:09:17
the way you do that is

01:09:19
you submit a pull request.

01:09:20
It's not like you

01:09:21
need to call a manager

01:09:22
or you need to do

01:09:23
submit a form or something.

01:09:26
That is how it used to be, right?

01:09:28
But we wanna, as developers,

01:09:29
we wanna work with

01:09:31
these kinds of things

01:09:33
like we work with

01:09:34
any other type of code.

01:09:36
Right.

01:09:37
So how does it look like from a

01:09:38
developer's point of view?

01:09:40
I mean, you can

01:09:41
use it to, I think,

01:09:43
automatically create credentials

01:09:45
for something like Postgres.

01:09:48
Or is that the DAS tool?

01:09:52
Do you need one of the

01:09:53
enterprise tools for that?

01:09:56
No, yeah, creating

01:09:57
credentials, I guess,

01:09:58
you could

01:09:59
definitely use OPA for that.

01:10:00
But I think in most cases,

01:10:03
what you use OPA for is basically

01:10:05
to make decisions

01:10:06
that are either most commonly

01:10:08
they're yes or no.

01:10:09
So should we allow

01:10:11
these credentials?

01:10:12
Would be probably a

01:10:13
better use case for OPA.

01:10:17
No, we should not allow them

01:10:18
because they're not sufficiently

01:10:20
secure or what have you.

01:10:23
But yeah, you can

01:10:24
use OPA and Rego,

01:10:26
the policy language

01:10:27
for a whole lot of things

01:10:28
and a whole lot of things

01:10:29
that we might not have

01:10:31
decided for initially.

01:10:33
So as an example, like there's

01:10:35
this linter for Rego,

01:10:37
which is called Regal that I have

01:10:39
been working for

01:10:40
on for the past year or so.

01:10:43
And that linter itself

01:10:44
is written mostly in Rego.

01:10:46
So we kind of use

01:10:48
Rego to define the rules

01:10:50
of what you can do in Rego.

01:10:53
Like a small exception.

01:10:54
Yeah, yeah.

01:10:56
There's a lot of that.

01:10:56
All right.

01:10:57
I mean, you know that your

01:10:58
language is good

01:10:59
when you can build your own stuff

01:11:02
in your own language, right?

01:11:04
Exactly.

01:11:05
So coming back to

01:11:07
the original question,

01:11:08
like what does it look like from a

01:11:09
developer's point of view

01:11:10
if I want to access, for example,

01:11:13
a Postgres database?

01:11:15
Right.

01:11:17
So the way OPA works,

01:11:19
it basically acts as

01:11:20
a layer in between.

01:11:22
So you probably have a service

01:11:24
between your database

01:11:25
and your user or another service.

01:11:28
So rather than having that user or

01:11:31
service go right

01:11:33
to the database, they'd query that

01:11:34
service for access.

01:11:36
And in that service, you'd have an

01:11:38
integration with OPA,

01:11:39
either with OPA

01:11:40
running as another service

01:11:42
or running embedded

01:11:43
inside of that service.

01:11:45
And that OPA would determine

01:11:49
whether access should be allowed

01:11:50
or not based on policy

01:11:52
and data that it

01:11:53
has been provided.

01:11:55
Right.

01:11:56
Okay, got it, got it.

01:11:57
I actually thought that,

01:11:59
maybe I'm wrong

01:12:01
because I'm thinking

01:12:02
one of the enterprise features or

01:12:04
enterprise products,

01:12:05
I thought it was its own service

01:12:08
that handles all of

01:12:09
that automatically,

01:12:10
but maybe I

01:12:10
misunderstood to be honest.

01:12:13
So there are, as you

01:12:14
said, there's OPA enterprise

01:12:16
and there is DAS, the declarative

01:12:19
authorization service.

01:12:21
Yeah, yeah, that's right.

01:12:24
You got it right.

01:12:24
I remembered right.

01:12:26
So maybe tell us a

01:12:28
little bit about those.

01:12:29
Maybe I'm mixing things up here.

01:12:31
Sure.

01:12:33
So I talked a bit about OPA

01:12:35
and OPA access to

01:12:36
distributed component

01:12:38
or the decision point.

01:12:39
So that's where the

01:12:41
decisions are made.

01:12:42
So OPA is gonna tell the user or

01:12:45
another service,

01:12:46
should we allow this or not.

01:12:48
And once you start to

01:12:51
have tens or twenties or hundreds

01:12:54
or thousands of these OPA's

01:12:55
running in your cluster,

01:12:56
and if you have like distributed,

01:12:58
a distributed environment

01:13:00
and you wanna do like zero crusts,

01:13:02
microservice

01:13:02
authorization or whatnot,

01:13:04
you're gonna have like a hundreds

01:13:05
or thousands of OPA's.

01:13:08
So the problem

01:13:10
that Styra DAS solves

01:13:13
is essentially like, how do we

01:13:14
manage this at scale?

01:13:16
How do I know what version

01:13:18
or which policy is deployed in all

01:13:21
these environments?

01:13:23
How do I manage policy changes

01:13:26
between like dev,

01:13:28
test, prod and so on.

01:13:31
But it kind of handles the whole

01:13:34
policy lifecycle.

01:13:35
We talked about testing before.

01:13:37
We talked about

01:13:38
things like auditing.

01:13:40
How are these things logged?

01:13:41
How can I search these logs?

01:13:44
Can I use these logs

01:13:45
to replay a decision

01:13:48
and see like, if

01:13:49
I did change this,

01:13:50
would it have an impact on the

01:13:51
outcome and so on?

01:13:54
So it's basically the

01:13:55
centralized component.

01:13:57
If OPA is the

01:13:57
distributed component,

01:14:00
Styra DAS provides a

01:14:01
centralized component

01:14:02
which allows things

01:14:04
like a security team

01:14:05
or even a policy team to kind of

01:14:07
gain this level of control

01:14:10
that would previously be missing

01:14:12
when you just let

01:14:13
any developer team

01:14:15
handle this on their own.

01:14:17
So it's a little bit

01:14:18
like fleet management

01:14:19
for your policies.

01:14:21
Yes, that is right.

01:14:22
Okay, that makes sense.

01:14:25
And the DAS specifically,

01:14:29
that is the management control or

01:14:31
the management tool?

01:14:33
Yeah, that it is.

01:14:34
Okay.

01:14:35
And then the enterprise OPA

01:14:37
is a drop-in replacement for OPA

01:14:40
adding a whole bunch of

01:14:42
features on top of it,

01:14:44
like reduced memory usage,

01:14:47
direct integrations

01:14:47
with data sources,

01:14:49
things like Kafka

01:14:50
streaming data from Kafka

01:14:52
and so on and so forth.

01:14:54
So we provide commercial solutions

01:14:57
both for the centralized part and

01:15:00
the distributed part.

01:15:01
Right, okay.

01:15:02
I think now I remember where my

01:15:05
confusion comes from.

01:15:06
I think I saw OPA Enterprise

01:15:08
and saw all the services

01:15:10
which are basically

01:15:11
source connectors.

01:15:12
Okay, now it makes sense.

01:15:14
Yeah, okay, got it, got it.

01:15:15
So I think you already mentioned

01:15:17
Kubernetes before,

01:15:20
but how does that work in the

01:15:24
Kubernetes environment?

01:15:25
I think you can, as you said,

01:15:26
deploy it as its own service

01:15:28
or run it embedded

01:15:28
in microservices.

01:15:30
How would that

01:15:31
apply together somehow?

01:15:34
I mean, we're cloud podcast.

01:15:36
Yeah, of course, of course.

01:15:38
So in the context of Kubernetes,

01:15:41
there's basically two use cases.

01:15:43
Like the first one

01:15:43
we kind of covered,

01:15:45
it's authorization in the level,

01:15:48
like inside of the workloads.

01:15:50
Our applications need to know

01:15:51
that the user trying to do

01:15:53
something is authorized to do so.

01:15:57
In that context, you'd normally

01:15:58
have OPA running

01:15:59
as a sidecar or in a gateway

01:16:03
or as part of like

01:16:05
an envoy proxy

01:16:06
or something like that.

01:16:07
So it basically

01:16:08
provides a layer on top

01:16:11
or before any requests is hitting

01:16:15
an actual application.

01:16:17
In the sense of user operated.

01:16:22
Yeah, exactly.

01:16:23
So on the next

01:16:25
content or the next use case

01:16:28
for OPA and Kubernetes is commonly

01:16:30
like admission control,

01:16:32
where Kubernetes

01:16:33
itself or the Kubernetes API

01:16:35
is protected by OPA.

01:16:38
So whenever you try and make a

01:16:40
modification to Kubernetes

01:16:43
or the database etcd,

01:16:46
the Kubernetes API

01:16:47
reaches out to OPA to ask,

01:16:49
like should this

01:16:50
be allowed or not?

01:16:51
So if you try and

01:16:53
deploy a pod or a deployment

01:16:56
or I don't know, what have you,

01:16:59
what kind of resources,

01:17:01
OPA will be provided at resource.

01:17:03
Again, it's just JSON or YAML.

01:17:05
So anything that's JSON or YAML

01:17:07
is basically what

01:17:10
OPA has to work with.

01:17:11
It doesn't even know,

01:17:12
like OPA doesn't know what a

01:17:14
Kubernetes resource is.

01:17:15
It just seems like

01:17:16
here's a YAML document

01:17:17
or here's a JSON document.

01:17:20
Is this or that

01:17:21
property that I expect,

01:17:23
is it in this JSON blob?

01:17:27
And does it have the

01:17:28
values that I need?

01:17:31
If it doesn't, it's not approved.

01:17:35
So we're gonna deny that.

01:17:36
So basically just

01:17:37
tells the Kubernetes API,

01:17:39
no, this should not be allowed

01:17:41
and the Kubernetes

01:17:42
API will enforce that.

01:17:44
So the user will

01:17:44
see this was denied

01:17:46
because this or that reason.

01:17:48
So that means I can also use it

01:17:50
in between any

01:17:51
Kubernetes services,

01:17:53
everything or anything deployed

01:17:55
into Kubernetes, I guess,

01:17:57
not just the Kubernetes API.

01:17:58
Yeah, anything

01:17:59
you try and deploy,

01:18:00
like for modifications,

01:18:02
is gonna have to pass

01:18:03
through the Kubernetes API.

01:18:05
That's a really

01:18:07
interesting thing.

01:18:08
So I guess going back to the

01:18:10
simpleblock use case,

01:18:11
that would probably be where our

01:18:14
authorization layer

01:18:16
or approval layer would sit,

01:18:19
basically either approving or

01:18:21
denying the CSI deployment.

01:18:24
Yeah.

01:18:25
Okay, that makes sense.

01:18:27
So because we're

01:18:29
already running out of time,

01:18:33
do you think that,

01:18:35
or well, I think

01:18:36
the answer is yes,

01:18:37
but maybe you can elaborate a

01:18:39
little bit on that.

01:18:40
Do you think that

01:18:41
authorization policies

01:18:42
or policies in general

01:18:43
became more important

01:18:45
with the move to cloud?

01:18:47
Probably more people have an

01:18:48
access to services

01:18:50
because they have to,

01:18:51
something like that.

01:18:53
Yeah, I'd say like they were

01:18:57
probably just as important

01:18:58
back in the days.

01:19:00
What really changed with

01:19:03
like the invent of cloud

01:19:04
and this kind of

01:19:05
automation is the level of scale

01:19:09
that any individual

01:19:10
engineer can work with.

01:19:13
Like in the past, you'd

01:19:14
have an infra engineer

01:19:16
would perhaps

01:19:17
manage like 20 machines

01:19:19
or something like that.

01:19:21
While today they could manage

01:19:22
thousands of machines

01:19:25
or virtual machines in cloud

01:19:27
instances or whatnot.

01:19:30
And once you reach

01:19:32
that level of scale,

01:19:33
there's basically no

01:19:34
way that you can do policy

01:19:37
like manually, that you have a PDF

01:19:40
document somewhere

01:19:41
where it says like,

01:19:42
you cannot deploy things

01:19:44
unless these conditions are met.

01:19:46
And then have engineers sit and

01:19:49
try and make an inventory

01:19:51
of what do we have here?

01:19:53
And are we all compliant?

01:19:54
That doesn't work.

01:19:56
So that is basically the

01:19:59
difference today

01:20:00
from how policy was

01:20:02
handled in the past.

01:20:04
We need to automate every kind of

01:20:06
policy check as well

01:20:08
just as we automated

01:20:09
infrastructure and so with cloud.

01:20:12
Yeah, that makes sense.

01:20:13
I think the scale is a

01:20:15
good point about that.

01:20:18
It was not something

01:20:19
I thought about it.

01:20:20
I thought in the sense or my

01:20:22
thought was more in the sense

01:20:23
of like you have

01:20:24
probably much bigger teams

01:20:25
than you had in the past,

01:20:27
which also makes it

01:20:28
much more complicated

01:20:30
to manage policies or

01:20:32
make sure that just like

01:20:34
the right people have access.

01:20:37
And many times have to

01:20:39
have this like access

01:20:41
because somebody

01:20:42
else is on vacation

01:20:43
and it will never

01:20:44
be removed again.

01:20:47
We all know how it

01:20:48
worked in the past.

01:20:50
Yeah, yeah.

01:20:51
Now, and another difference I

01:20:53
think like today

01:20:55
compared to 20 years ago is like,

01:20:58
at least when I

01:20:59
started working in tech,

01:21:00
it was like, if you got

01:21:02
to any larger company,

01:21:04
they're like, "Hey,

01:21:04
we're doing Java here

01:21:05
or we're doing like .NET."

01:21:08
But if you go to

01:21:09
those companies today,

01:21:10
they're like,

01:21:10
"There's gonna be Python.

01:21:12
There's gonna be Erlang.

01:21:13
There's gonna be some Closure

01:21:14
running somewhere.

01:21:16
There's gonna be like so many

01:21:17
different things."

01:21:19
This idea of team

01:21:20
autonomy and like teams

01:21:22
and deciding for themselves what

01:21:24
the best solution

01:21:25
for any given problem is.

01:21:27
And that is, I love that.

01:21:29
It's like, it makes it so much

01:21:31
more interesting

01:21:32
to work in tech,

01:21:33
but it also provides

01:21:37
like a huge challenge

01:21:38
for anything that

01:21:39
is security related

01:21:41
because in anything

01:21:41
anywhere where you need to

01:21:43
kind of centralize or have some

01:21:45
form of control,

01:21:47
it's really, really hard.

01:21:48
How do you audit something

01:21:49
if it's like in eight different

01:21:51
programming languages?

01:21:52
Like I can barely

01:21:53
understand two of them.

01:21:55
Like how would I do that?

01:21:57
How to make sure that all the

01:21:58
policies are implemented

01:22:02
if policy change happens.

01:22:04
Yeah, you're right.

01:22:04
You have to implement it in

01:22:05
multiple languages.

01:22:07
The descriptor language for the

01:22:09
rules isn't the same.

01:22:11
Yeah, that's a good point.

01:22:13
That's a very good point actually.

01:22:16
And just because time,

01:22:20
I think I would have like a

01:22:21
million more questions,

01:22:22
but there's one thing that I

01:22:24
always have to ask.

01:22:26
What do you think is

01:22:26
like the next big thing

01:22:27
in terms of cloud, in your case,

01:22:30
authorization policies,

01:22:33
but also in the

01:22:33
broader scheme of everything?

01:22:37
Yeah, sure.

01:22:39
So I'd say like, first of all,

01:22:41
I think both

01:22:42
identity and access control,

01:22:45
they are kind of slow moving and

01:22:47
for good reasons.

01:22:48
There's not like there's gonna be

01:22:50
a revolutionary thing

01:22:51
or disruptive event that turns

01:22:55
everything around.

01:22:56
I think that's

01:22:59
basically where we have to be.

01:23:01
We can rely on

01:23:02
things to not change

01:23:05
or to update too

01:23:06
frequently or too dramatically.

01:23:11
So yeah, what would

01:23:14
the next big thing is,

01:23:15
I still think like this area where

01:23:18
we decoupled policy

01:23:20
and we worked with it consistently

01:23:22
across like large

01:23:23
organizations and so on,

01:23:24
it's still the next

01:23:26
revolutionary thing.

01:23:27
It's like, there's definitely a

01:23:30
lot of adopters already,

01:23:32
but we're just at a start of this.

01:23:35
And again, that's

01:23:36
probably like organizations

01:23:38
don't just swap out their like how

01:23:41
they do authorization

01:23:43
or identity that could

01:23:45
be like a decade or so.

01:23:48
So I still think

01:23:49
this policy as code

01:23:51
while it's starting to be like an

01:23:54
established concept

01:23:55
that it is still

01:23:57
the next big thing.

01:23:58
And that's why

01:24:00
it's also so exciting

01:24:01
to work with in this space.

01:24:03
All right, fair enough.

01:24:04
At least you

01:24:04
didn't say automatic AI generation.

01:24:08
No, God no.

01:24:11
That would have been

01:24:12
really the next big thing.

01:24:14
Now we're talking.

01:24:15
No, seriously.

01:24:17
Thank you very much.

01:24:18
That was very informative.

01:24:20
I loved that.

01:24:23
Yeah, thank you for being here.

01:24:24
Thanks for having me.

01:24:26
And for the audience, next week,

01:24:29
same time,

01:24:30
same podcast channel,

01:24:32
whatever you wanna call that.

01:24:34
Hope to hear you again

01:24:37
or you hear me again.

01:24:38
And thank you very much.

01:24:41
The cloud commute podcast is sponsored by

01:24:43
simplyblock your own elastic

01:24:45
block storage engine for the cloud.

01:24:47
Get higher IOPS and low predictable

01:24:48
latency while bringing down your

01:24:50
total cost of ownership.

01:24:51
www.simplyblock.io