Sam: What is sort of the right way
to do it that will lead in a good
user experience for your customers?
Right, not just about like, what is good,
you know, how can you implement this in
a way that gets off your roadmap, but
like, what do we think would be truly
like, delight your customers with?
Corey: Welcome to Screaming in the Cloud.
I'm Corey Quinn.
My guest today on this promoted episode
is brought to us by our friends at Oso.
And what else is brought to us by Oso?
That's right.
Their CTO and co founder.
Sam Scott.
Sam, thank you for joining me.
Sam: Hey Cory, thanks for having me.
Corey: Oso makes it easy for
developers to build authorization
into their applications.
With Oso, you can model, extend,
and enforce your authorization
as your applications scale.
Organizations like Intercom, Headway
Product Board, and PagerDuty have
migrated to Oso to build fine grained
authorization backed by a highly
available and performance service.
Check out Oso today at OsoHQ.
com, that's O S O H Q.
com.
Instead of starting at the beginning,
because that makes way too much sense,
I want to pick up on something that
I noticed about your background.
Specifically, you have
a PhD in cryptography.
Which, uh, my, my biggest takeaway from
this was always called Schneer's Law.
Which is, as Bruce Schneer famously said,
anyone can invent an encryption algorithm
that they themselves cannot break.
The takeaway, of course, is
don't roll your own cryptography.
And the other thing I try
never to get involved with is
rolling my own authentication.
So you have a PhD in cryptography
and now you work for a company
that does authentication.
Are you just like effectively hanging
out with a bad idea bear or something
and coming up with these ideas?
What is your life like?
How did you get into this position?
Sam: I mean, someone's
gotta solve those problems.
And I, I, I, I like the hard problems.
It's, those are my fun ones.
I, I will have to correct you
immediately with the misconception
that almost everybody makes.
We work on authorization,
not authentication.
Corey: Excellent, excellent.
And I want to begin with an
even dumber question then.
What is the difference between the two?
Sam: So authentication is
typically about identity.
Like who are you, right?
You, username and
password, single sign on.
Like, how does the other person,
the other side of you know, some
interaction, know who you are?
That's like the authentication piece.
Authorization is normally what comes next.
Like, now that I know who you
are, right, you're Corey in some
domain, I know you belong to some
organization, like, okay, now I know
who you are, what can you do, right?
Can you research such documents?
Do you have access to certain features?
Things like that.
Corey: In other words, great.
So when I start, uh, having too much to
drink on a plane and ranting, like, you
don't know who I am, I'm Corey Quinn.
And they'll say, yes, we
know exactly who you are.
No, you're not allowed to fly the plane.
Sam: That is exactly right.
Yeah.
Corey: Got it.
I somehow don't imagine that's going
to be making it into one of your, uh,
one of your slide decks anytime soon.
But no, it's, it's an interesting problem.
And someone that I once worked with in
the early days of my career pointed out
something that at the time I, a, uh,
wet behind the ears 20 something who
of course knew better, scoffed at it.
But they said that ultimately every,
every security and networking job
in its final form becomes about
identity and access management.
And I laughed and I laughed and He was
really onto something in hindsight.
Sam: Yeah, uh, I mean, basically
what you're summarizing is how I
found out my PhD was worthless.
Have you heard the expression,
turtles all the way down?
Corey: Oh yes, the world stands,
what was it, what's the expression?
There's some mythology that
said, oh, the entire world
exists in the back of a turtle.
Plausible as anything else.
So what's the turtle standing on?
Another turtle.
It's turtles all the way down.
Sam: Exactly.
And so the same thing is
true in, uh, in security.
And this is kind of what I found
out with, with working on like
interesting cryptography, which is,
so I know some of the stuff I did
was around like, how do you make
sure that like data was encrypted?
And like, if the keys change, you need
to rotate them and so on, so on, so on.
And like, there was definitely some like
interesting technical problems to work on.
I had a lot of fun and
built some fun mounts.
When you get to, like, the, in practice,
what is hard about keeping data secure,
it's like, who has access to your
keys in KMS, in Amazon KMS, right?
Like, you can get those keys.
If you can get the keys,
it's game over, right?
It doesn't matter what encryption
standards you use and how frequently
you're rotating your keys.
It's a, oops, I wrote a, I wrote
an access control rule that let
somebody get access to the product
encryption keys and now it's game over.
And that's kind of where the
authorization piece comes in, right?
It's like, you know, are you
making sure that the right
people have access to the right?
Things.
Maybe not the bottom title, but
it's definitely a pretty low one.
Corey: I know they're not the same thing
as you just corrected me on, but I, I
can't shake the feeling that I'm not
the only person that makes that mistake.
Take AWS as a terrific example.
Please, take it.
Take it somewhere far away from here.
The problem that I have is that by
authenticating that I am me to my
AWS account, the only way that is
expressed is in the form of credentials.
And ideally short lived ones
because I'm not a complete lunatic.
There's no distinction to my mind between,
yes, I have the credentials to prove
I'm me, and also by extension, by being
me, I therefore have access to do the
following number of horrifying things.
Sam: Yeah, deeply, deeply
coupled related problems.
Right.
So it's the kind of the one you
described, like, you know, I, you know,
I authenticate, identify who I am.
And like, I belong to, I'm inside of an
AWS organization or account, and that's
going to give me access to a bunch of
things by probably by default, right?
Like almost every app in the world
is going to have some amount of
like authorization that's maybe not
expressed very explicitly as like, this
is authorization happening right now.
But it's just a.
Okay.
Cool.
You know, when, you know, when you
go and read the database, you filter
by an org ID or something like that.
Like that is, that is
authorization, but it's kind of.
implicit, it's like woven in, but
it starts getting more and more
interesting when you start getting
to more like more complex, fine
grained versions of that, right?
So sure, you've done, you've done some
of basics up front, you've identified
you, you've put in your credentials, you
get access to some things, but your AWS
account probably has a ton of IAM rules
describing the precise resources that
you have access to at any given time.
In fact, if you do things correctly,
and, you know, maybe I've coined
the best practice, you might not
even have access to things directly.
You might have access to assume
a role, and that role might
grant you access to things.
And that is another really good
example of, like, authorization.
It comes up everywhere, like,
role based access control.
The general idea being, instead of
just describing what Quarry can do,
I say, well, Quarry has this role,
much, much like other people in this
organization do, and they can all
collectively do the same kinds of things.
Corey: Now, that's exactly what we
do, and in most accounts that I have,
that role lets me assume administrator
access, and the reason being is that
I've always viewed AWS accounts as being
the ultimate trust boundary, because it
doesn't matter if you just have developer
rights and can never touch the things
in the production side of that account.
Things like service quotas,
there's no way to restrict those.
So suddenly you, you run out
of a script that runs a muck.
You're not going to be able
to suddenly auto scale in the
production side of the environment.
So there has to be that
boundary there somewhere.
But we, I do this through
IAM Access Identity Center.
The source of authentic, the source
of identity is Google workspaces.
And then I wind up assuming roles based
upon my group membership inside of that.
And that gets me most of the way there.
There are then additional roles,
we assume, in client accounts
where, surprise, I don't want to
be able to break things there.
So, it tends to be very narrowly scoped
to begin with and we can scope that
further when we have customers in
particularly sensitive environments.
We, like, do not break production or
you're not allowed to save money anymore
has always been our, the thing that
we've observed in our client accounts.
But being able to assume those
roles correctly and make sure that
the right people who are working
the right account have access.
We don't just grant, oh, everyone
here can have access to everything.
We, for a small company, we do a
remarkable amount of segmentation just
because I, I've worked in regulated
compliance heavy environments before.
You want to keep the sensitive
stuff as narrowly contained as you
can because then you don't really
have to worry about access at all.
outside of those things.
Well, okay.
We have to make sure that all
the discussion of the sensitive
client stays within a, uh, a
given bounded area of Slack where
only certain people can access.
Great.
So we codename everything and then
it's a lot easier just because in case
someone slips, we aren't suddenly now
having to deal with data breach issues.
Sam: Right, exactly.
And so like building, building an
authorization system is all around.
I guess enabling users of your own
product to be able to support the
flow to make the most sense for them.
And with something very like platformy,
like in like an Amazon, right?
Like naturally, you're going to
want to give your users a lot of
flexibility so they can tailor
things to exactly how they're setting
things up and building things.
But in a lot of cases, while you maybe,
you maybe want to give people like minimal
configurability, you want to just give
them the typical path they would take and
not think about it too much, for example.
So it's kind of a wide spectrum.
Corey: Yeah, it's a, because the problem
that I've found, and this is where I start
to get political on it, so you'll have to
bear with me, but I've been saying for a
while that Google is number one when it
comes to security, and AWS is number two.
And Azure is, did not finish,
they're at the kids table eating
crayons, as they're going to do.
Terrific.
And the reason behind this
is the usability approach.
By default, anything in a Google
Cloud project can talk to anything
else in a Google Cloud project.
That works terrifically well for me,
and disastrously for people at a bank.
But by the time you're a bank, you
have an InfoSec team that can disable
that behavior, and build in a, uh,
leased access model, which is great.
Microsoft The danger of the AWS approach,
and I gave a conference talk recently
at an event that Wiz threw that it was,
it was about an actual screenshot of
something I have hanging out in my code
build environment where I have four or
five different policies assigned to it.
And the last one that I added
was administrator access.
And there's a to do to go
back and fix this later.
And this was in 2018.
I have not yet gotten to do that yet.
And it's because you try to
do something, it doesn't work.
You expand, try again, doesn't work.
And if you're doing this through
something like CloudFormation,
each iteration takes an hour.
So great.
By the time I was finally,
right, it was the hell with it.
I just want this to go.
That's the problem with
continually failing to get the
right permission dialed in.
So you just say, just, just go
ahead and give it to me everything.
I'll deal with it in my own time.
Sam: Yeah.
You're, you're, you're
appreciating the client, yeah.
Much like how roles can be this
like pretty convenient authorization
abstraction to like group people together
based on similar things they do together.
These are all admins, right?
Like similarly on what I think about
as like the resource management side,
like the entities you have access
to, having that ability to just
like group things into some kind of
hierarchy with like orgs and projects.
It's like such a simple model for
you to wrap your heads around, but
like, it gets you so far, like as you
described, just being able to do that
level of like opinionated structuring
of missions goes like a long, long way.
Corey: Yeah, I'm very interested to see
how these problems evolve because what
we're currently doing is not sustainable.
Clearly, it's not.
And Uh, the thing that I figured out
as I went down this path early on when
I started doing this independently is
I turned my nose up at anything that
would look like Arba, rba C or SSO
because I was independent and I already
have a great SSO thing that works.
It's called One Password.
I stuff all of my passwords
into it and things are great.
The where this starts to break down is
when you start dealing with other people.
How do you validate that?
Everyone is using one
password, for example.
Well, when you mandate SSO, that
solves some of these things, and you
have a single choke point to wind up
controlling access and enforcing MFA
and the like, whereas having to play
whack a mole at other environments.
That was something that I found
to be extraordinarily challenging,
and I wish I'd done a bit
differently setting out to do it.
Yeah, in that it's, it's nice to
be able to have a single dashboard.
When I bring someone on as a contractor
to work on a project, for example,
there are certain levels of granularity
to permissions that they should have.
And they vary from
contractor to contractor.
Having a catch all contractors
group doesn't work.
It has to be, okay, are they
a contract cloud economist?
Okay, great.
Which accounts are they working on?
Make sure they only have
access to those accounts.
They still need access to shared
stuff internally, but they probably
don't need access to, for example, the
employee portal and so on and so forth.
And in each one tends to
be these bespoke things.
And honestly, if I'm being
direct, what we'll see is great.
We just have a pattern that we
apply to most contractors that
start based on the template that
we built from our first contractor.
Sam: Yeah.
I think the world you're kind of.
Getting towards here
reminds me a lot of SAML.
Corey: SAML, OAuth, SSO, these terms
are, these terms are inter, uh,
interact, uh, I guess, interact inter
replicably, just between things.
All the documentation for all of these
things, in my experience, presupposes that
I have a directory management background.
Everything would assume I know what an
OU is, which, okay, great, not everything
lends itself to the OU model, especially
when those OUs are not hierarchical, and
it becomes an obnoxious, painful problem.
Sam: Yeah, absolutely.
I mean, I think the thing that's
nice about SSRM Secure is because it
creates, as you say, it creates that
like pretty clean, convenient choke
point where it's like, as an, as an
implementer, I don't really need to
care too much about how you authenticate
like somebody else, your, your IT admin
decided how someone should authenticate.
And like, once you're in and
authenticated, like I can kind of
continue on and do, you know, do,
do the stuff that I care about.
When you get into like trying to do that
or an authorization standpoint, I mean,
like you described by bringing in Google
workspace groups to use those to determine
which roles you can have access to.
That's when you end up in like the
gnarliest of gnarly, like federation
problems where yeah, you're talking
about three or four different
standards, protocols, specifications
to implement to get that data.
Nobody does it in the same way, even
though there is technically a standard.
And then you need to go and use
Implement an interface inside your
app that lets your users configure how
they want to connect those different
pieces of information up and decide
what they can do with it, right?
Like, I'm out of breath just
trying to talk about it.
I know there is It's like, it's like
that classic, you know, XKC cartoon,
like I'm just going to create a new
specification to standardize over
all these things and build that one
and then we have another new one
Corey: and so on.
Congratulations, you just
built the latest standards.
No, no one, no one sets out trying
to build something bespoke and
unique, like, ah, we're going
to build a unification thing.
And unfortunately, it just doesn't work.
Sam: It's a thing for us, like, I think.
It's, it's, it's, you know,
it's kind of a two sided problem
in both of which are hard.
Like it is both hard to build a like
authorization system that allows you
to kind of bring in arbitrary external
data and let people configure that and
manipulate it into how they want to do
authorization inside of the product.
Like that side of it is already
hard, let alone the like abstraction
or unification of the like, you
know, where that data comes from.
And so at least for us, that also
like, we can make progress on solving
the first of those two problems.
And we make it easy for
people to implement.
Cool, I have groups from Google
Workspaces and I want people to be
able to use that inside of my products.
We can make, we can solve
that half of it at least.
Corey: That's the painful part.
That's the thing that's hard,
in my experience, to get right.
It's the, it's always the new thing
suddenly turns that, turns everything
you've been doing on its head.
And I think at enterprises, this gets
a lot easier because there aren't
that many new worlds left to conquer.
Uh, you, you are not the first person
who tries to expense a rental car
at a company that has 2, 000 people.
But when you're 10 people, maybe you
are when you grew during a pandemic.
So, I'm curious to know, on
some level, what, what is it
that you folks do, exactly?
I mean, so why should I use, why should I
use Oso to wind up solving these problems?
Because you already have some compelling,
uh, stories, like, well, honestly, our
logo is a bear and we're named after
the Spanish word for bear, so, terrific.
The puns are going to be there for
days, but that, that drifts a little
bit too much into my personal la bears.
What are the, what are the
reasons that you exist?
What is it you solve for
customers that hurts?
Sam: Yeah, so the reason that
we exist is, I think there
are probably two main reasons.
So, so first of all, something that we
just observed is that people have been
reinventing this wheel of authorization
again and again, like every single
company they went to, they've spent
like six months, 12 months, you
know, multiple years re implementing
authorization within that company.
Like, how do people, you know,
how do people get access to
stuff inside of this product?
Rebuilding.
You know, organization roles,
user groups, rebuilding, you know,
the ability to share things with
people and give them access to it.
Everyone's just like rewriting this code
again and again and again from scratch.
And so it just kind of seemed like
one of those, those obvious problems
that like, what if that was just a
company that could solve that for you?
So that is like that side of it.
We just like help take that
implementation away from people.
I know like, I love authorization.
I think it's a super interesting
problem, but I don't think like every
company in the world wants to be
authorization experts and crush it.
And so I think it's one of
those problems that's like.
A really good fit for people to
like outsource somebody else.
I think the other half that maybe
touches on some of what we've just
been talking about, which is people
don't really, people don't really
talk about authorization a lot.
They don't think about it a lot and like
talk about what is good authorization,
a bad authorization, or like have
compared, you know, AWS IAM, you know,
Google Cloud Approach much in depth.
We have, but we have like a lot
of opinions on like what is the,
what is sort of the right way to
do it that will lead in a good
user experience for your customers.
Right.
Not just about like, what is good,
how can you implement this in a
way that gets off your roadmap?
But like, what do we think would be
truly like the light your customers
when it turns, when it comes to
being able to do authorization?
And so those are kind of like two of
the big problems that we help solve
people take this piece of implementation
work that your team would otherwise be
spending, you know, potentially years on.
And we do it for you as a service
rate, but we, we kind of almost
work as like a partner with a lot
of customers, like a design partner
with a lot of customers of like.
You know, okay, what, you know, what
are your customers trying to do?
And like, can we, can we leverage the
patterns that we've seen to help guide
you on like, making that not suck?
Corey: There, it feels like there's
a Goldilocks story here, as in, um,
if nothing else, t shirt sizing,
you must be at least this tall
to ride slash get value from Oso.
And I'm wondering, is there a,
like, is there a sweet spot that
you have for customer profiles
around customer, about company size?
Or company level complexity, I should say.
Sam: Yeah, there definitely is.
Um, I mean, in the length of time,
there's a thing we'll address where
every single person under the sun
should obviously use OSO, right?
Like, that's, we're a venture
backed company, that's our
mission, kind of thing.
But it's true that like today, I think
where we see our sweet spot is kind
of two main categories of people.
People who are maybe going up
market, they're going after larger
enterprises and they're realizing
that they're getting like a ton of
sales requests, like, Hey, to use your
product, like we need to be able to
segregate access within the market.
different teams or within
different groups, right?
Like we have sensitive data in, you
know, this group of working on this
other group shouldn't get access to.
And like, we'll see this a
lot of companies will start
getting this request, right?
It's no longer enough that you log
in and you have access to this, the
organization that that is sufficient.
We need to start getting
things more granular, right?
So like companies that hit that
point with, you know, and it's,
that's normally around like the size
of customers they're going after.
That's like a really good one.
Corey: No one is excited by the
prospect of building permissions,
except for the people at Oso.
With Oso's authorization as a service, you
have building blocks for basic permissions
patterns like RBAC, REBAC, ABAC, and the
ability to extend to more fine grained
authorization as your applications evolve.
Build a centralized authorization
service that helps your developers
build and deploy new features quickly.
Check out Oso today at osohq.
com.
Again, that's O S O H Q dot com.
When I wound up working at my first
startup, I was their first non developer
technical hire, which is always a weird
place to find yourself in, but I wound
up picking up a lot of good patterns
that I carried with me forward from that.
One of them was that when our auditors
showed up, because we were in the payment
space, they asked us like how they
authenticated to the Wi Fi, it's like,
oh great, the password is on the wall.
And they stared at me.
Like, uh oh, that's not gonna
be good, like, okay, so what,
where's your active directory?
Our what now?
Like, I'm sorry, this
is not a Windows shop.
And they said, okay, let me distill
this down for you in very simple terms.
Once I'm on the Wi Fi, what
does that grant me access to?
And the answer was the internet
and that printer over there.
They're like, wait, Okay, but from
the office, you can wind up then
getting special access into other
things, like, no, that sounds like
something an insane person might do.
We wind up instead either using a VPN
if we're trying to get into something
sensitive, or, more commonly, every API
endpoint is hardened, and we authenticate
with signed requests on all of them.
And they're like, I've
never seen that before.
And it's, yeah, the reason we
did it is because everything that
did the traditional gateway stuff
was really expensive and we'll,
we'll see how this works out now.
Apparently it's called Zero
Trust or BeyondCorp and everyone
pushes it as a best practice.
And during the pandemic, we saw the VPN
concentrators and a lot of enterprises
started melting out of their racks
when everyone used them at once.
But that was a.
But it was sort of an
interesting, almost by accident.
It's easy to sit here and say,
Oh, because I was a visionary.
No, because I was cheap and
didn't really know any better.
Sam: No, I see that
pattern playing out a lot.
It does remind me of like an interesting
or important clarification I want
to make, because I think probably I
take this difference for granted, but
it's probably not one that everybody
does who's listening to this.
The kind of thing you're talking about is
sort of internal company authorization,
maybe like even like infrastructure or
platform authorization, like within.
You know, for us to be like, within Oso,
what, what, what do I have access to?
Like what, you know, AWS
service can I access or like,
which products can I access?
And, you know, which
can I get to the email?
Can I talk to the printer?
Stuff like that.
That's all like internal to the business.
What can you get access to?
The authorization that we
typically focus on is for companies
building B2B SaaS products, right?
Like you're building a.
And let's say GitHub, it's an
example we use a lot, right?
You're, you're building GitHub.
What authorization do
you let your users do?
Like how, how can, you know, how do
people authorize and get access to
things within the GitHub products, right?
Like you can access GitHub organizations,
you can maybe access certain repositories,
I can set roles at different levels
within an organization that means
you can push to repositories or not.
Like, so for SaaS products like a GitHub,
we're helping implement that kind of
authorization within that product.
Corey: It's almost like you're
skipping ahead in my notes as far
as things I wanted to talk about,
because this is exactly where
we're headed with the conversation.
Because one thing that AWS did, or
Amazon did, in the early 2000s, which
I thought was great, is Bezos passed,
by decree, the idea that every company
talks to each other via hardened
APIs with the expectation that those
things can become public at any time.
And that caused some great things,
and some terrible things too.
Like, it turns out when you holistically
talking to each other as humans, You
wind up with travesties like the billing
system, but that's neither here nor there.
The painful part, though, is that
I think comes from a lot of cases
where companies treat internal
authorization versus customer
authorization as very different things.
And there are times you can't escape it,
but increasingly as I get older, that
feels more and more like an anti pattern.
I think it's because the idea that
Once you wind up with a trusted network
or a trusted inside group of people
who are employees, you on some level
wind up with a M& M style security.
You've hardened the perimeter
and then you no longer feel
the need to wind up defending
anything inside of that perimeter.
Now, in many cases, this is a good thing.
There's a reason that Slack
doesn't have a block button.
It's because you, you, that's it.
I've had enough.
I never want to hear from those
bastards in accounting ever again.
is all well and good, but you can't
really have a functional business when
that's the kind of thing that happens.
Whereas I never want to hear from
these people in public again who say
mean things about me on the internet.
Ahem.
Okay.
That's a bit more understandable.
For some reason, I've always had the
impression that Treating employees
as once you're in the in group
you're in is a security misstep.
Sam: I think I understand.
So you're saying like when you're building
a product, like you're building, you're
building something in GitHub, like you
shouldn't, you shouldn't treat employees
access to things within GitHub the same
as external people access to GitHub.
Corey: Yes, now maybe there are
permission groups that can only
apply to people who have a GitHub
employee flag set in their profile.
But the way they log in, the way
that identity gets passed out, should
absolutely not be a sidecar system.
Now, yes, you need a break glass way
for them to get access to things.
If, if that identity system is what
breaks, you'd better have a way
to get in and fix that quickly.
But as a standard
operating procedure, yeah.
Going in the front door the way
that your customers do, uh, first
means you don't have to build
and maintain separate systems for
this that are going to diverge.
And two, when there are customer
side issues with this, you'll see
them because they impact you as well.
Sam: Yeah, that's a really great point.
And that one is a, I mean, just the
reason people don't is like, it's hard to,
it's really hard to implement that well.
Because to do so you need to
have a authorization system
that's like flexible to handle.
You know, potentially suddenly users who
can have access to like multiple accounts.
And like, as we kind of spoke about
right at the beginning, like the
easiest thing to do is use hard code.
Someone logs in and they only have
access to the account they belong to.
If you now suddenly have like a support
user who needs to go and like debug a
customer account and they should get some
limited access to that customer account.
I'm just like, that's suddenly
like undermined, like the
entire way that you implement
authorization inside your company.
And like, it requires you like
implementing all kinds of like hacks
and workarounds to make that happen.
Something called, like,
impersonation, right?
The ability for, like, a customer support
person to be able to, like, impersonate
a user so they can kind of see what
they would do and get access to some
things that they would get access to.
Doing that well basically requires
you having, like, a lot of extra
code to kind of, like, handle
these different special cases.
And it ends up just doing, it just
ends up being a different code
path, just in a different way.
Or you need to have like a very
sort of powerful, generic, flexible
authorization system that can treat,
Hey, can this user access this other
thing as a generic question, regardless
of like how they get access to.
And so like, yes, 2D Moses porn,
like we support that kind of
situation, like really nicely.
You treat all users the same.
You can have a user with a global
admin, super admin case, right?
You're like, can I just say startup?
And you say, yeah, I don't know.
I said everything.
You have a global super admin,
they can access everything.
But like over time, you can implement
things like, you know, support agent can
get access to this customer's account.
If the, you know, if there's an open
support ticket for that customer and
they've been assigned to it, right?
Like you can start writing like
very granular logic that where
the sweet spot is or that like
internal custom support person.
There's like zero friction to them
seeing the things they need to see.
Oh crap, I'm assigned a ticket,
it's fine, I go to see that
customer, I can see all the things.
But they don't suddenly have access
to like every company under the sun.
Corey: Yeah, that, that's
where it gets weird.
Sam: Yeah, that's, that's
where it gets, gets a bit
concerning and strange, exactly.
Corey: And even in the areas of the,
of the, uh, internal infrastructure
where every employee has access
to stuff, there are things you
want to be very guarded about.
Even my business partner, the CEO,
does not have access to, uh, writable
to any of the audit logs, for example.
I do at the moment, but I, as far as
I can, they're not mutable, but there
are, I know ways around these things.
But again, I, I own the company.
What am I going to do?
Does I do this against myself?
But there, there will be ways that we
wind up sharding that in the future.
Sometimes at clients, what I see is
we go into optimize their AWS account,
and there's a carve out, sometimes
a separate organization, sometimes
a series of accounts, because people
with access to one are not allowed
to touch the other, which great.
Awesome.
Usually that's the security boundary,
and you take a look at it, it's less
than 10 percent of spend, so great,
awesome, let them do what they're
going to do, we'll work around them.
I love seeing that pattern.
Sam: You know, and it reminds
me, going back to the turtles
analogy, I said authorizations
are quite the bottom turtle.
The bottom turtle in my mind is lawyers.
Because ultimately all of these
technical approaches, right, at some
point there's going to be some layer
at which like you can't guarantee
that nobody can ever do a thing.
Generally at that point, that's where
lawyers come in or auditors where you, you
know, sign a document saying or a policy
saying that I do not do these things.
And if I do, like, please
hold me accountable to it.
So, like, yeah, you're right.
Like, at a certain point, you have
to have, like, some boundary where
somebody can break glass, do a thing,
but generally, yeah, you write a
policy, and you let lawyers enforce it.
Corey: One of our early, uh, attorneys,
uh, who, uh, one of the first generals
counsel we had here, was, uh, probably
sort of better understanding of defense
in depth than most, uh, security people
I know, and his advice was very simple.
Uh, he's like, do not lose your shirt in
business, Here are four things you do.
Use them in this order.
Step one, be a nice person.
People don't want to sue their buddy.
Two, have good contracts
for when that breaks down.
Step three, have insurance so
that this covers these things
when that turns against you.
And step four, have a legal entity
so you don't lose your house when
things completely go to custard.
That's the shell.
Use them in that order.
And yeah, that's the way to
think about these things.
Because if you just go out there and
say, Oh, we don't need contracts or
insurance or legal entity because I'm
a nice person and everyone likes me.
That's not going to work super well.
Let me rephrase.
That works super well until one day,
all of a sudden, it very much does not.
It's like, I don't think the
house is going to burn down,
but I have fire insurance on it.
So one last question I have before we
call this an episode for you, which
is that I'm trying to understand
what your adoption looks like.
I have to imagine you get no green
field environments, because I
have an idea I'm going to build
something and see if it works.
No one's thinking about security on
the first step for that, unless it's
a security company, in which case They
think about security sooner than most,
but still not soon enough to suit how
most people think about these things.
There's always some means that people are
using to authenticate and then validate
that they have authorization to do things.
How do you roll out in an
environment where things are,
I guess, Already pre existent.
Sam: So first of all,
like, you'd be surprised.
There are a lot of, there are a good
amount of people who they start a
company and they had so much pain
from authorization previously and they
knew that it's going to be important
to them because they're in, yeah,
security or health tech or fintech
and they're like, you know what?
I want to get this out of the way
before we do anything else because I've
seen how bad it can be if you wait.
Well, that does happen as well.
But coming back to your, to your
question though, like, you know,
how do, how do people like it, maybe
adopt this incrementally or migrate?
Um, there's kind of a few parts to this.
So one, like what we often, what we often
kind of help people do, um, is adopt this
incrementally by like implementing the net
new functionality they care about, right?
So maybe it's, maybe they're migrating
from monoliths to microservices and
they want to start seeing like, how do
I have an authorization microservice?
Like we'll help them do that
part while maybe keeping the
existing stuff running as it is.
It might be a case of.
You know, they've already got multiple
services and they've, you know,
they're, they're rolling out a new,
a new service that requires a new
functionality and some new capability.
We'll say, okay, like, let's just
implement it into that one new service.
Let's do that new stuff that you
couldn't previously do that was going
to take you, you know, have a long,
you know, six months, 12 months in
your roadmap to like roll out that
new, you know, sharing capability
before you had this new microservice.
Like, we'll help you do that piece on
one service so you can kind of see it.
See the patterns and then we
can like gradually stop bringing
over the old stuff over time.
Corey: I lied to you.
I did have one more question I wanted
to get into and I'm worried of how
this might wind up shaking out.
You recently wound up rolling
out something called distributed
authorization and the reason I'm nervous
to talk about it is I'm concerned it
might be some blockchain horseshit.
Sam: Well, yeah, no, don't worry.
It's not,
Corey: would've been awkward otherwise.
Sam: Yeah.
The cryptography and my PhD has
zero to do with the log chain side
of crypto, which is why I had to
call it PhD in cryptography, not
PhD in crypto, which makes me sad.
But yeah, no, so dis distribute
authorization, uh, it's, it's something
we're pretty excited about because
we've been kind of wanting to release
it since the beginning of starting oso
like four or five years ago of like
how we think authorization should work.
It's called distributed authorization as
a contrast to centralized authorization.
So like historically, people, if
they want to have some kind of like
consistent way of doing authorization
across the company, across multiple
services, they put everything in a
central microservice, um, all of the
authorization logic, they put all the
data that's necessary, which can often
end up being like a lot of data, right?
It's, you know, all of the All of
the user data and the roles they
have, it's in all the resources
you want to have access to, right?
And in Google Cloud, right?
It'd be all the projects and
all the resources and all the
projects they belong to, right?
All of that data gets like shoved
into this like central service
and you have an API that says,
can I use a do it thing or not?
That was kind of the old way.
It was kind of painful because it really
went against, you know, the, Microservice
best practices of how you like you
ideally want to kind of decouple and
draw good boundaries between services.
It had this like horrible coupling
where you're synchronizing and
sending all your data centrally.
But it was kind of the only way
to get a consistent authorization
implementation at like a large scale.
What we've done with distributed
authorization is we've basically made
it possible for people to integrate a
consistent authorization implementation
into individual services while
leveraging the data those services
already have and own and manage.
Microsoft Mechanics www.
microsoft.
com So rather than going through this
process of like synchronizing and
sending all this data centrally, you
can just like roll out authorization
in one of those services, leveraging
the data you already have.
Corey: Doesn't that dramatically
increase the attack surface?
You wind up effectively without the
central source of truth that you are,
that you are guarding on some level.
You, like, ignoring the split brain
problems of distributed systems and
in fact how you establish quorum.
Uh, I guess you could
read one Paxos for fun.
Why not?
You have a PhD in this
sort of thing anyway.
It'll be fine.
No, what I'm trying to figure out is, does
that mean that you have to be a lot more
guarded as far as, uh, there's no longer
a central, uh, I guess crown jewel area.
Suddenly everything becomes a
theoretical tax point, doesn't it?
Sam: Not really.
I mean, in, like, in the sense that
with a central service, you can
already, like, forget to call the API
or just ignore what the API tells you.
Like, you're already trusting that the
services enforcing the authorization
are actually going to check your
service and do something with it.
Like, there's already
that amount of trust here.
I think, though, there is an
interesting distinction, which is
the, so the logic for who can do
what in this world still lives inside
that central authorization service.
You have one place to look at the logic.
You have one place to
audit who could do what.
It's mostly just the data piece
that is now being deferred to,
like, handle inside the database.
So, like, when I actually go and fetch
a list of, kind of, servers that you
have access to, based on projects it
belongs to, that might just happen in
the database that you have already built
rather than inside the central service.
So there's, like, just a little
bit of, like, weather processing
happening that's different.
And in both cases, you're still
getting a full audit log of the
authorization that took place.
So we know, so right, like every,
every time someone goes and makes an
authorization call, or all the servers
that I can, I can, I have access to, we'll
audit log that that request took place.
Like who, what was the user, what
they're trying to do, and what was
the data that we would have gone and
looked up to answer that question.
Corey: That makes sense.
I have to imagine that's rather
compelling for people who have bought
into your vision of, of authorization.
Sam: Yeah, I mean, this, this feature came
from a lot of, you know, feedback from
customers who really, people really want
this, like, I want to put authorization
behind an API, I want to call that, I
don't want my teams to go and re implement
everything from scratch every single time.
That's the thing they're
trying to get towards.
But forever, like for a long time, it
came with this like big cost of, okay,
but to do that, you just go around to
every single team and tell them, here's
how to get the data into the service
so that it can do those things for you.
And so I think like removing that whole
part of the conversation, I think is,
is like pretty exciting for people.
They can now go to that team and be
like, Hey, can We have taken care
of that authorization thing for you.
You don't need to think about
permissioning and roles and
groups and all that kind of stuff.
We're just going to give you a library
that you implement, client library and
API that you're going to implement, like,
integrate into your app, and you're good.
You're done.
We've got it.
We're going to audit things,
we're going to review things,
like, don't worry about that.
You can just, like, carry
on and do things happily.
Which I think will really change how
people think about adoption authorization.
Corey: I look forward to seeing
how this winds up evolving.
Thanks for taking the time
to speak with me about it.
If people want to learn more, where's
the best place for them to find you?
Sam: Yeah, well, so yeah,
thank you for having me here.
And, I mean, all this
information is at osu.
hp.
com.
Uh, from there, there's like a
couple of paths you can go down.
We have a ton of educational content for
developers, like Authorization Academy.
Um, if any of this kind of, you
know, if we went too fast, I
know I speak pretty fast, you can
kind of read that stuff in depth.
You can go and just start trying
out the OSO product for free.
Like, you know, there's just this,
you know, an unlimited free trial
you can just sign up for and try out.
That's awesome.
Uh, and we also have
like a Slack community.
If you want to like get into a bit more of
a discussion and you're kind of thinking
through some thoughts, but you have not
talked about them, we've got a safe space
for you to talk about authorization.
So you can find all that from postHP.
com.
Corey: And we will of course, put
links to all of that in the show notes.
Thank you so much for taking
the time out of your day to
have this conversation with me.
I, I really appreciate it.
Sam Scott, CTO and co
founder at Oso security.
This promoted guest episode of Screaming
in the Cloud has been brought to us by S.
A.
M.
E.
And I'm cloud economist, Corey Quinn.
If you've enjoyed this podcast,
please leave a five star review on
your podcast platform of choice.
If you've hated this podcast, please
leave a five star review on your podcast
platform of choice, along with an angry,
insulting comment that makes sure to start
with the phrase, Don't you know who I am?