►
From YouTube: Cloud native authorization landscape
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
welcome
to
my
session
on
the
cloud
native
authorization
landscape,
I'm
jimmy
zolensky.
You
can
find
my
twitter
and
github
handles
on
screen.
A
So
who
am
I
full
disclosure,
I'm
the
co-founder
of
authzed,
which
is
the
company
behind
spice
tv
spice
dp,
is
an
open
source
database
that
computes
permissions.
A
So
while
I
don't
necessarily
have
an
agenda
today
to
promote
my
own
business,
what
I
am
doing
today
is
helping
people
understand
the
ecosystem
of
authorization
tooling,
so
that
if
they
find
out
what
the
right
tool
for
the
job
is,
they
will
find
spice
db
if
that's
the
right
fit
for
them.
Maybe
they'll
find
something
else.
If
that's
the
right
fit
for
them,
either
way
we
get
more
qualified
leads
and
the
whole
ecosystem
gets
more
qualified
leads
and
gets
more
education.
A
So,
with
that,
out
of
the
way
before
I
worked
on
authorization,
I've
actually
been
in
the
cloud
native
community.
Since
the
very
beginning,
I
used
to
work
at
core
os
which
got
acquired
by
red
hat
and
in
that
time
I've
both
been
in
software
engineering
and
product
positions
where
I've
had
a
pretty
large
impact
on
the
ecosystem.
I'm
currently
a
maintainer
of
the
open
container
initiative,
and
what
that
is
is
the
standards
body
for
containers.
A
I,
like
I
said
earlier.
I've
been
a
community
member
for
kubernetes
since
since
the
beginning
since
before
cncf
existed
as
a
first
employee
to
work
on
quay
container
registry,
which
is
the
first
private
docker
registry,
I'm
co-author
of
like
the
operator
framework
and
the
original
inspiration
for
a
lot
of
the
oci
artifact
work,
and
I've
also
worked
on
a
couple
of
their
projects
such
as
claire,
which
does
static
as
the
first
open
source,
static
analysis
tool
for
containers
as
well.
A
So
without
further
ado,
let's
cut
to
the
chase,
there's
just
too
many
projects
out
there
in
the
authorization
space
or
have
direct
implications
on
the
authorization
space.
I
pulled
a
new,
a
few
names
of
projects
down
from
the
cloud
native
landscape.
This
is
just
random
projects
from
the
security
section.
A
Some
of
these
are
general
purpose
authorization
tools,
but
it's
important
to
note
that
you
don't
necessarily
have
to
be
a
general
purpose.
Authorization
tool
to
have
impact
on
authorization
generally,
there's
lots
of
tools
that
are
very
focused
on
solving
one
particular
problem,
and
if
that
problem
is
your
problem,
congratulations
you've
found
like
a
great
solution
for
it,
because
it's
going
to
have
had
a
complete
focus
and
design
from
the
beginning
to
solve
your
problem.
A
So
a
lot
of
these
projects,
don't
necessarily
seem
like
they
might
be
authorization
specific,
but
they
actually
end
up
being
so,
for
example,
I
just
mentioned
that
previously
I
had
co-authored
this
project.
Claire
and
claire
is
a
vulnerability
scanner,
so
that
might
not
seem
like
it
has
much
to
do
with
authorization,
but
actually
one
of
the
key
use
cases
of
claire
is
to
prevent
folks
from
deploying
containers
into
production
that
have
known
vulnerabilities
so
in
the
abstract,
that's
effectively
authorizing
whether
software
can
actually
be
deployed
on
a
system.
A
So
you
can
kind
of
see
how,
with
this
broad
definition
of
authorization
and
various
data
sources,
you
can
find
complete
like
mixed
messaging
and
lots
of
confusion
in
the
ecosystem
and
lots
of
people
sharing
similar
marketing
terminology.
A
So
today
acknowledging
that
the
ecosystem
is
massive.
What
we're
going
to
do
is,
instead
of
enumerating
every
single
project
out
there
we're
going
to
try
to
establish
a
methodology
for
looking
at
projects
like
this.
That
may
be
general
purpose
that
may
be
very
specific
and
try
to
come
up
with
ways
to
determine
what
makes
sense
for
us
whether
it's
worth
adopting
whether
it's
worth
learning
more
about
basically
different
lenses
in
to
view
and
slice
and
dice.
A
This
super
large
ecosystem,
so
that
we
can
kind
of
consume
it
in
in
bits
that
make
sense
for
us.
So
to
do
so
we're
going
to
kind
of
break
this
down
into
four
different
steps.
Basically,
the
agenda
for
the
day.
A
I'm
sure
you've
probably
heard
some
of
the
terms
I'm
going
to
use
later
today,
I'm
also
going
to
have
a
focus
with
their
application
in
the
use
of
like
authorization
specifically,
so
I
might
actually
be
ignoring
certain
aspects
of
these
words
just
to
kind
of
explore
a
greater
concept
in
the
authorization
space.
So
with
that
you
kind
of
are
going
to
have
to
let
go
of
some
of
your
preconceived
notions
for
what
these
terms
mean
and
we're
going
to
like
start
from
the
very
beginning.
A
This
concept
in
the
real
world,
but
no
no
post
or
presentation
on
authorization
cannot
be
complete
if
you
do
not
start
from
the
beginning
and
remember
when
I
said
that
we're
gonna
throw
out
any
pre-existing
knowledge
here,
we're
gonna
start
from
the
very
beginning.
What
even
is
authorization
or
what
even
is
off
so
auth
is
actually
two
concepts
typically
composed
together,
but
today
we're
going
to
focus
on
the
latter,
which
is
authorization
rather
than
what's
typically
discussed.
Most
of
the
time.
A
The
former
authentication,
most
folks
are
probably
already
pretty
familiar
with
authentication.
The
authentication
ecosystem
is
pretty
mature.
There's
a
lot
of
big
companies
in
this
space.
They've
been
around
for
a
while,
it's
a
pretty
pretty
well
understood
concept
at
this
time,
but
actually
a
lot
of
the
the
things
in
the
authorization
space.
I
find
to
be
a
bit
confusing
at
this
point
in
time.
There
are
lots
of
different
technologies,
and
even
some
of
the
authentication
technologies
bleed
a
little
bit
into
the
authorization
space.
A
So
it
helps
to
kind
of
like
bifurcate
for
now
and
establish
what
these
terms
are,
and
that
way
we
can
kind
of
have
a
shared
vocabulary
when
we
want
to
talk
about
how
these
may,
inter,
inter
interconnect,
so
authentication
primarily,
is
about
identity.
It
is
asking
the
question:
who
are
you
and
then
typically,
it
also
has
to
do
with
verifying
that
you
are
who
you
say
you
are.
This
is
typically
seen
as
logging
in
in
user-based
systems,
but
it
doesn't
necessarily
need
to
just
be
logging
into
an
application
oftentimes.
A
A
What
can
you
do
once
you
have
been
identified
and
we
know
you
are
who
you
say
you
are
next,
we
need
to
determine
if
you
can
perform
a
particular
action
that
you're
trying
to
perform
or
be
in
a
particular
place
that
you're
trying
to
be
so.
I
like
to
use
the
word
permissions
for
this,
because
typically
people
are
building
permission
systems
when
they're
in
the
realm
of
authorization,
but
similar
to
how
authentication
can
be
both
users
and
software
silicon
authorization.
A
You
can
authorize
particular
software
to
access
particular
data
or
not
based
on
based
on
varying
aspects,
so
this
is
kind
of
the
bifurcation.
We're
going
to
move
forward
with
here
are
some
examples
in
the
ecosystem
for
authentication.
There's
a
cncf
project
called
dex
index
is
an
identity
provider,
basically
identity
providers.
A
A
These
are
all
software
that
you
might
be
using
at
your
your
existing
company
to
log
in
to
get
your
payroll
things
things
like
this
and
then
on
the
flip
side
of
this.
There
is
also
authorization
tools,
as
I
alluded
to
earlier.
I
work
at
a
company
that
builds
a
database
specifically
for
answering
authorization
questions,
so
we
are
purely
focused
on
answering
access
control,
a
very
popular
open
source
project
in
the
cncf.
A
It's
called
open
policy
agent,
and
this
is
a
policy
engine.
That's
used
for
a
lot
of
software
infrastructure,
so
that's
trying
to
get.
For
example,
what
resources
can
be
applied
on
your
kubernetes
cluster,
and
then
I
included
this
last
example,
which
is
meant
to
represent
libraries
that
people
use
to
build
applications.
So
pundit
is
a
library
in
the
ruby
ecosystem
and
flask
authorize
is
a
library
in
the
python
flask
ecosystem,
and
these
are
libraries
that
folks
use
to
build
in
their
web
applications
and
store
information
inside
of
their
database.
A
Their
relational
database
that
talks
about
the
access
of
the
users
in
their
system
or
or
anything
else
that
their
system
interacts
with.
So
these
things
don't
necessarily
need
to
be
standalone
projects.
A
lot
of
the
examples
I
gave
are
standalone
projects,
but
actually
even
libraries
that
you
build
into
your
application
and
kind
of
ad
hoc
systems
that
you
could
potentially
be
building
greenfield
yourself
at
your
own
organization
can
be
an
authorization
system
so
just
to
clarify.
A
Today
we
are
not
going
to
talk
any
more
about
authentication,
we're
going
to
try
to
focus
purely
on
authorization,
so
the
latter
so
access
and
not
identity.
Some
things
can
kind
of
get
murky.
So
I
want
to
make
this
clarification
now,
for
example,
oauth2,
which
is
a
very
popular
protocol,
that's
used
in
the
authentication
space.
A
It
actually
has
a
lot
of
properties
in
it
that
are
used
for
authorization,
and
because
of
that
there
is
lots
of
there's
lots
of
like
crossover
and
terms
that
will
be
shared
here.
If
I
do
bring
up
any
of
these
identity
protocol
protocols,
I'm
going
to
clarify
that
I
am
explicitly
talking
about
the
authorization
characteristics
of
them
and
with
that
said
now
we
can
move
on
to
focusing
on
how
we're
going
to
categorize
authorization.
A
So
there
are
these
two
buzzwords
that
are
quite
confusing
and,
as
I
said
earlier,
the
terminology
actually
comes
from
the
identity
space,
so
you're
going
to
have
to
relinquish
any
previous
knowledge.
You
have
about
these
terms
because
I'm
going
to
use
them
from
the
perspective
of
just
evaluating
the
authorization
ecosystem.
A
So
iam
is
a
term.
That's
used
a
lot
a
lot
of
the
time
you
can
see
it
in
cloud
providers
that
offer
iem
services,
people
can
refer
to
active
directory
or
any
of
the
authentication
systems
that
I
described
earlier
as
iam
products.
A
It's
a
fairly
catch-all
term,
but
the
duality
here
is
the
thing
I'm
going
to
focus
on.
So
I
am,
as
it
exists
in
most
deployments.
Today
is
typically
talking
about
what
your
employees
can
actually
do,
and
I
stress
that
this
is
the
focus
that
you
want
to
think
about
when
looking
at
authorization
products
is
typically
iam
software
and
folks
describing
their
projects
as
im.
Software
are
talking
about
restricting
your
employees.
A
So
no
longer
talking
about
your
employees,
if
you
are
a
bank,
this
means
you're
going
to
talk
about
what
a
person
can
do
to
withdraw
things
from
their
accounts
to
move
money
around.
These
are
the
type
of
interactions
and
people
you're
going
to
be
talking
about
as
opposed
to
people
within
your
actual
organization.
A
So
the
implications
of
having
this
split
is
that
if
you're
focusing
on
your
employees,
you're
not
going
to
be
hiring
and
firing
people
to
the
same
degree
at
which
folks
are
maybe
registering
for
a
very
popular
sas
product,
so
data
doesn't
need
to
necessarily
be
exactly
consistent.
If
you
fire
someone,
maybe
you
don't
need
to
update
the
systems
of
record
until
the
end
of
the
work
day,
for
example,
so
there's
not
necessarily
a
tight
boundary
on
when
things
need
to
be
updated
across
these
systems.
A
On
the
flip
side,
if
you
think
about
consistency,
you
might
have
to
ban
a
user
on
a
forum,
for
example
that
is
spamming
your
service
or
mining
bitcoin
on
your
service
and
in
that
scenario,
you're
going
to
want
to
have
some
form
of
immediate
percolation
of
permission
changes
in
your
system.
So
that
means
that
if
you
want
to
revoke
access
for
someone,
it
should
happen
immediately.
A
I've
used
the
term
bounded
consistency
here,
because
you
might
actually
want
only
certain
properties
to
be
immediately
reflected,
but
not
all
properties
in
the
whole
system.
So
perfect,
consistency
or
full
consistency
can
be
used
in
customer
im
systems,
but
also
as
a
performance
optimization.
Most
of
them
give
you
boundaries
around
this,
where
the
goal
should
be
to
have
boundaries
around
this,
so
you
can
talk
about
the
actual
requirements
that
your
system
actually
has.
A
So
then,
there's
also
coarse
grained
versus
fine
grained
between
these
two.
If
you
are
talking
about
the
employees
in
your
business,
you
might
be
able
to
get
by
with
talking
about
the
department
they
belong
to
or
the
team
they
belong
to,
and
that's
probably
good
enough
for
describing
whether
they
should
have
access
to
particular
things.
A
When
it
comes
to
customer
systems,
you
might
need
to
talk
about
access
to
particular
rows
in
a
database
or
a
lines
in
a
document.
It
can
be
very,
very
fine-grained,
and
the
difference
between
these
two
actually
has
a
very
large
effect,
because
a
single
user
could
be
a
part
of
10
million
groups
in
a
user
system,
and
that
might
be
just
a
normal
user
in
the
system,
not
even
a
special
case,
however,
in
if
that
was
the
case
in
your
business.
A
That
would
be
very
strange
that
someone
is
a
part
of
10
million
groups,
maybe
they're
the
ceo,
and
they
just
need
access
to
everything.
But
typically
this
is
not
the
normal
case,
and
most
employee-based
systems
of
record
have
just
very
basic
group
support.
These
are
the
types
of
things
you
see
in
systems
like
active
directory
and
what
the
identity
providers
can
support
out
of
the
box.
A
So
the
final
impact
that
these
customer
facing
versus
employees
facing
concepts
have
is
rigidity
or
flexibility.
So
in
an
iam
system
where
you're
talking
about
your
employees,
your
org
structure
is
unlikely
to
change
that
frequently
you're
you're
very
likely
to
have
some
kind
of
hierarchy.
A
However,
on
the
customer
side
there
are
various
domains
out
there.
There's
healthcare,
there's
finance,
there's
gaming,
there's
all
kinds
of
different,
basically
requirements
of
these
varying
domains
and
in
these
domains
they're
not
going
to
be
able
to
tell
their
users
or
their
data
that
they
have
to
conform
into
some
particular
hierarchy.
That
pre-exists
and
has
a
limitation
of
their
system
instead
they're
going
to
need
to
build
a
system
that
can
model
their
domain.
A
So
the
difference
here
is
that
in
the
cim
systems,
typically,
they
give
you
kind
of
a
blank
canvas
but
structure
to
paint
the
the
painting
of
the
world
that
you
want
to
see.
So
those
are
kind
of
the
the
deeper
implications
of
kind
of
just
thinking
about
the
who
and
without
further
ado,
we
will
talk
about
some
of
the
examples
of
these
systems.
So,
let's
run
through
some
of
these
things
that
are
in
the
cncf
ecosystem
that
you
might
be
familiar
with.
A
Oauth2
proxy
is
a
fairly
common
open
source
project
that
folks
use
to
secure
web
pages.
Additionally
teleport,
which
is
a
kind
of
system
that
does
similar
or
vpn
products
like
tail
scale.
These
are
all
considering
getting
employees
and
have
authorization
systems
that
reflect
that
when
we
talk
about
cncf
projects,
there's
the
open
policy
agent,
gatekeeper
or
kyverno,
which
these
are
systems
that
gate
access
or
ensure
certain
invariants
of
the
resources
that
you're
creating
on
kubernetes
clusters.
A
So
these
are
all
kind
of
fixated
on
kind
of.
Can
you
do
this
particular
thing
to
my
software
infrastructure
on
the
flip
side
for
customer?
I
am
using
the
previous
examples
that
I've
shown
before
there
is
spice
db,
which
is
a
database,
so
you
can
actually
write
a
schema.
That
kind
of
is
the
painting
of
the
picture
for
the
system
that
you
actually
need,
and
then
you
load
data
into
that
schema.
A
Once
you
have
data,
and
then
you
can
query
that
data,
so
that's
kind
of
how
that
one
lets
you
deal
with
the
flexibility
aspect,
and
then
we
have
obviously
library
systems
that
are
built
into
the
different
web
framework
ecosystems.
A
These,
let
you
basically
write
your
own
code
and
build
your
own
abstractions,
so
obviously
they
also
fall
into
the
customer.
I
am
fundamentally
building
web
apps
and
systems
like
these
you're
building
things
for
customers
typically,
so
that's
that's,
obviously
going
to
fall
along
those
lines
all
right,
hopefully
with
that
making
sense
to
everyone.
We
can
move
on
to
the
next
question
to
ask
and
the
lens
by
which
we
will
filter
the
ecosystem,
which
is
where
the
decision
is
being
made.
A
So
this
one
is
kind
of
a
little
interesting
because
where
has
some
implications
on
generally
how
the
data
you're
sourcing
impacts
your
system?
So
if
you
think
about
your
problem
domain
and
you
think
about
where
the
data
you
need
to
compute,
whether
someone
has
access
to
something
comes
from,
that
is
going
to
be
what
we're
going
to
focus
on.
A
So
there's
two
kind
of
splits
here,
there's
federated
and
centralized
so
federated
is
going
to
be
the
term
we're
going
to
use
to
describe
systems
where
the
data
or
computation
that
you're
using
to
get
access
to
a
particular
resource
is
coming
from
various
systems.
Maybe
you
have
to
actually
ask
an
api
of
a
business
that
you're
partnered
with
whether
a
user
has
access
to
a
particular
thing,
and
then
that
needs
to
be
then
joined
with
information
that
you
have
in
your
systems
as
well
to
determine
whether
they
have
access
to
one
of
your
resources.
A
So
this
can
be
either
the
sourcing
of
the
data
or
the
computation
as
well.
Maybe
you
have
to
reach
out
to
an
external
surface
and
they
will
perform
the
computation
for
you
and
just
tell
you
yes
or
no
and
you'll.
You
will
basically
take
their
their
resolution,
their
evaluation
as
truth.
So
that's
that
would
be
examples
of
federation
and
then,
on
the
centralization
side,
there
is
basically
saying
that
the
data
or
the
computation
that
is
going
to
perform
to
gate
access
is
going
to
only
live
exactly
in
one
place.
A
That
means
that
you're
not
going
to
be
reaching
out
to
various
systems.
You
know
where
all
the
data
is,
but
there
is
going
to
be
work
ahead
of
time,
making
sure
that
the
data
you
need
to
compute
these
access
requests
needs
to
be
in
this
place.
It
needs
to
be
in
whatever
format
it
needs
to
be
in
that
place,
so
that
that
is
going
to
take
effort
ahead
of
time.
Knowing
that,
okay,
when
data
is
created,
it
needs
to
be
created
in
this
location
so
that
access
control
can
happen
after
the
fact.
A
So
this
has
the
strongest
implications
on
consistency.
As
I
was
talking
about
before,
with
federation
effectively
you're
going
to
have
very
loose
consistency,
you
will
not
have
any
real
sense
of
time
in
these
systems.
A
lot
of
the
systems
that
are
federated
kind
of
are
purely
eventually
consistent,
they're
going
to
be
making
their
decisions
with
the
best
data
they
have
available
to
them
at
the
time.
A
That
may
not
be
perfect,
and
if
a
system
or
if
a
user
is
revoked,
for
example,
that
may
not
be
immediately
applied
to
any
of
these
systems,
it
could
be
an
arbitrary
amount
of
time
until
it
actually
gets
applied
to
your
system
or
multiple
pieces
of
software
in
your
system
might
not
even
agree
if
the
person
has
been
removed
yet,
and
you
can
kind
of
see
this
percolate
into
applications
that
are
using
federated
systems.
A
So
while
this
has
better
consistency
properties,
it
does
come
at
the
cost
of
having
that
data
stored
and
available
and
in
that
centralized
location.
A
So
some
examples
of
these
are
open
policy
agent.
So
a
lot
of
folks
run
open
policy
agent
as
a
side
car
next
to
an
application,
renault
and
kubernetes,
and
their
application
will
make
queries
to
the
open
policy
agent
and
then
get
responses
from
it.
But
the
data
that
the
open
policy
agent
is
using
to
commute
compute,
that
permission
is
typically
synchronized
or
sourced
from
some
other
location,
often
on
an
interval.
So
that
means
your
data
is
only
as
fresh
as
the
interval
which
is
being
refreshed.
A
This
can
work
great
for
data.
That's
not
changing
very
often
or
data
that
doesn't
need
to
be
perfectly
consistent,
so
there's
a
whole
class
of
use
cases
where
that's
totally
acceptable
and
probably
for
the
best
and
on
the
flip
side
of
that
centralized
systems.
A
All
right,
finally,
we're
reaching
our
third,
which,
if
you've
reached
this
point,
it
should
be
because
you've
probably
already
explored
your
problem
space
with
some
of
the
pre-existing
tools
that
you've
been
able
to
like
filter
down
to,
and
you
probably
know
where
the
pain
points
are,
because
this
one
is
a
little
bit
of
a
rabbit
hole
because
we're
gonna
discuss
how
the
decisions
are
actually
being
computed
and
what's
interesting
about
this,
is
that
it's
not
going
to
be
an
apples
to
apples
comparison.
A
A
Now,
policy
engines
are
basically
the
idea
that,
in
order
to
compute
a
permission,
the
user
should
write
a
program
and
that
program
will
be
executed
with
some
input
data
and
the
net
result
of
that
will
be
a
yes
or
no,
whether
a
user
has
access
and
then
that
that's
the
general
idea
of
a
policy
engine
and
the
kind
of
other
side
of
this
is
not
a
direct
comparison
to
that.
So
I'm
not
going
to
like
say
that
these
are
a
direct
comparison.
A
A
So
this
is
not
to
be
confused
with
something
like
rbac,
which
is
role-based
access
control.
You
can
use
reback
to
implement
rbac.
You
can
use
policy
engines
to
implement
rbac,
so
just
to
reiterate
we're
kind
of
talking
about
the
layer
deeper
right
now
we're
talking
about
the
implementation
details
for
building
general
purpose
authorization
systems.
A
So
you
might
be
thinking
like
oh,
but
I
only
need
r
back,
so
why
should
I
necessarily
care
about
this
this
layer?
A
Well,
the
answer
to
that
is
actually
one
of
kind
of
how
I
was
saying
earlier
how,
if
you
have
experienced
pain
points
already,
you
might
eventually
realize
that,
while
you're
building
your
existing
system,
you
actually
need
rbac,
plus
some
other
unique
functionality,
or
you
might
realize
that
some
of
the
default
behavior
in
your
system
is
not
typical
of
our
back
like
models
or
you
might
need
finer
granularity
than
having
just
roles
in
your
application,
but
like
90
of
the
time,
maybe
just
having
roles
is
fine.
A
So
now
you
kind
of
have
like
two
layers
of
fine
grain
access
and
general
purpose
access.
There's
a
lot
of
different
ways
that
you
can
kind
of
arrive
at
kind
of
like
wanting
to
peel
back.
Perhaps
you've
built
a
system
and
you've
realized
that
it's
actually
really
hard
to
iterate
on
and
you're,
going
through
security
audits
all
the
time,
every
single
time
you
need
to
make
changes
to
your
application,
and
that
can
be
painful
and
you're,
not
getting
reuse
of
kind
of.
A
A
So
what
are
the
implications
of
this?
I
kind
of
just
listed
a
whole
bunch
of
reasons
or
times
it
might
be
important
for
you
to
like
think
about
this
paradigm,
that
your
system
is
built
on,
but
I'm
gonna
kind
of
focus
on
these
two
two
aspects
here
now,
which
is
policy
engines,
are
often
federated.
A
The
decision
is
often
pushed
into
the
policy
engine
that
executes
and
the
policy
has
to
ex
like
exist
within
its
own
execution
of
the
the
program
because,
like
I
said
in
this
scenario,
policies
are
computer
programs
versus
in
relational
based
access
control
models,
you've
centralized
all
the
data
into
a
database
and
the
decision
making
is
actually
merely
a
query
to
the
data,
as
it's
laid
out
already
existing
in
the
database,
so
that
that
kind
of
forces
you
into
a
centralized
position.
A
A
That's
definitely
not
the
case,
but
definitely
these
paradigms
kind
of
influence,
design
choices
of
the
systems
that
are
going
to
lean
heavily
in
these
directions.
A
You
can,
for
example,
have
one
global
policy
engine
executing
with
all
the
data
in
that
for
various
applications
all
talking
to
that,
and
that
would
be
an
example
of
the
policy
engine
that
has
centralized.
But
by
and
large
that's
that's,
not
the
most
common
way.
A
You
see
policy
engines
being
deployed,
so
the
next
aspect
is
kind
of
the
federation
which
is
kind
of
tied
in
oh
sorry,
the
federation
of
data,
which
is
tied
also
to
kind
of
the
decision
making,
like
I
said
earlier,
you're
not
going
to
have
kind
of
any
kind
of.
A
I
haven't
personally
seen
any
distributed
policy
engines
where
policy
is
executing
in
a
whole
bunch
of
places
and
then
aggregated,
you
might
see,
data
being
accessed
and
federated
out
and
then
collected
back
into
one
central
execution,
but
yeah
then,
on
the
relational
side,
they're
you're
almost
exclusively
going
to
be
locked
down
into
a
centralized
model.
A
By
definition,
you
might
have
systems
that
are
sharding,
underneath
the
covers
and
kind
of
scaling
like
a
a
horizontal
scaling
database
might,
but
also
you
might
see
these
as
vertically
scaling
databases
like
your
typical
kind
of
postgres
postgres
relational
database
systems.
A
A
These
are
policy
engines,
you
load
facts
into
these
systems,
and
then
you
query
them
and
effectively
they're
declarative,
but
what
they
do
is
they
allow
you
to
compute,
yes
or
no,
based
on
inputs
that
you
provide
so
by
by
definition.
That
makes
you
a
policy
engine
once
again.
A
very
popular
addition
to
the
cncf
ecosystem
is
open
policy.
Agent
policy
is
in
the
name.
It
uses
a
language
called
rego,
which
is
very
much
so.
A
Data
log
inspired
and
then
kind
of
brought
into
the
modern
kind
of
cloud
native
ecosystem
to
make
that
more
approachable
for
folks
and
then
gandalf
is
a
system
internally
at
netflix.
That
is
actually
the
inspiration
of
open
policy
agent.
It
works
in
a
very
similar
fashion.
A
A
So
on
the
the
relational
based
access
control
side,
we
have
examples
once
again,
spiced
db,
which
is
actually
inspired
by
a
system
at
google
called
zanzibar,
and
so
these
this
is
basically
they're
taking
graph
database
concepts
and
specializing
it
very
specifically
for
the
application
of
computing
access
control.
A
On
top
of
on
top
of
the
system
that
google,
which
has
inspired
other
proprietary
systems
at
other
companies,
there
is
also
facebook's
implementation.
A
So,
if
you're
unfamiliar
with
facebook's,
prod
initial
product
or
meta's
initial
product
facebook,
it
effectively
is
a
social
graph,
it's
a
social
network,
so
it
makes
sense
if
all
of
your
data
is
based
on
relationships
such
as
this
person
is
a
friend
of
this
other
person.
It
makes
sense
that
access
could
access
control
for
such
a
system
is
also
storage
of
relationships
between
them.
This,
if
you're,
a
friend
of
a
person,
it
means
you
can
see
their
photos,
for
example.
A
So
you
can
see
from
that
example
that
actually,
if
you're
your
domain,
that
you're
working
in
naturally
falls
into
a
system
where
the
domain
data
itself
kind
of
looks
similar
to
one
of
the
particular
access
control
models.
It
might
make
sense
for
you
to
adopt
that
as
well
over
a
solution,
maybe
you're
more
even
familiar
with
or
one
that
might
have
other
trade-offs
are
properties
that
you
thought
were
important.
A
So
that's
a
lot.
It
may
not
be
things
you've
thought
about.
Maybe
it
is
things
that
you've
thought
about,
but
I
kind
of
wanted
to
close
with
a
couple
additional
thoughts.
There
really
is
no
silver
bullet
for
authorization
in
general.
In
this
space,
you're
going
to
have
varying
use
cases,
they're
going
to
need
varying
paradigms,
they're
going
to
have
various
requirements
for
consistency
and
scale
and
all
kinds
of
things,
and
it's
going
to
be
up
to
you
to
navigate
the
ecosystem.
A
I
tend
to
try
to
personally
avoid
using
a
lot
of
the
confusing
terminology
kind
of
what
I
said
earlier
when
I
was
using
authentication
versus
authorization.
I
prefer
to
lean
into
terms
like
identity
and
permissions,
because
you
can't
confuse
them
if
you
just
call
something
off.
It's
very
vague
and
people
might
not
fully
understand
what
you're
you're
trying
to
communicate.
A
A
It
really
doesn't
tell
you
anything
about
the
domain
whatsoever
and,
at
the
end
of
the
day,
you're
trying
to
solve
a
problem
typically,
so
the
primary
concern
you
have
is
your
domain.
And,
finally,
nothing
is
an
apples
to
apple's
comparison.
A
The
paradigms
for
building
a
system
building
general
purpose
authorization
systems
are
very,
very
different
from
each
other,
and
even
software
that
you
might
be
looking
at
to
solve
your
problem
can
be
very,
very
different.
If
there
is
a
special
purpose
piece
of
software
designed
to
solve
your
exact
problem,
then
it's
going
to
look
very
different
from
trying
to
solve
that
problem
with
a
general
purpose
paradigm
or
solution,
because
it
can
take
advantage
of
lots
of
domain
knowledge
to
optimize
or
take
shortcuts
or
sacrifice
particular
things
that
might
not
be
generally
applicable
to
other
systems.
A
A
A
So
as
a
as
a
final
kind
of
reminder,
you
should
always
ask
questions
and
let
your
use
case
guide,
you
don't
jump
on
any
bandwagon
for
any
particular
concept
in
this
space.