►
From YouTube: How Netflix Is Solving Authorization Across Their Cloud [I] - Manish Mehta & Torin Sandall, Netflix
Description
How Netflix Is Solving Authorization Across Their Cloud [I] - Manish Mehta & Torin Sandall, Netflix
Since 2008, Netflix has been on the cutting edge of cloud-based microservices deployments. In 2017, Netflix is recognized as one of the industry leaders at building and operating “cloud native” systems at scale. Like many organizations, Netflix has unique security requirements for many of their workloads. This variety requires a holistic approach to authorization to address “who can do what” across a range of resources, enforcement points, and execution environments.
In this talk, Manish Mehta (Senior Security Software Engineer at Netflix) and Torin Sandall (Technical Lead of the Open Policy Agent project) will present how Netflix is solving authorization across the stack in cloud native environments. The presentation shows how Netflix enforces authorization decisions at scale across various kinds of resources (e.g., HTTP APIs, gRPC methods, SSH), enforcement points (e.g., microservices, proxies, host-level daemons), and execution environments (e.g., VMs, containers) without introducing unreasonable latency. The presentation includes a deep dive into the architecture of the cloud native authorization system at Netflix as well as how authorization decisions can be offloaded to an open source, general-purpose policy engine (Open Policy Agent).
This talk is targeted at engineers building and operating cloud native systems who are interested in security and authorization. The audience can expect to take away fresh ideas about how to enforce fine-grained authorization policies across stackthe cloud environment.
About Manish Mehta
Manish Mehta is Senior Security Software Engineer at Netflix, Los Gatos, CA. He has designed and developed solutions around secure bootstrapping, authentication (service and user), and authorization for cloud-native infrastructure. His professional interests and expertise are cyber security in general, and specifically in security solutions anchored in cryptography. He holds M.S. and Ph.D. in Computer Science from Univ. of Missouri - Kansas City and has authored several research and conference publications.
About Torin Sandall
Torin Sandall is the technical lead of the recent open source Open Policy Agent (OPA) project. He has spent 10 years as a software engineer working on large-scale distributed systems projects. Prior to working on the Open Policy Agent project, Torin was a senior software engineer at Cyan Inc. (acquired by Ciena Corp.) where he designed and developed core components of their SDN/NFV platform such as modelling languages as well services for resource orchestration and topology discovery. Torin has recently given talks on policy-related topics in Kubernetes at ContainerDaysPDX and LinuxCon Beijing as well as the Kubernetes Community Meeting and the Kubernetes SF meetup.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
My
name
is
Manish
Mehra
I
am
a
security
engineer
at
little-known
company
called
Netflix,
and
my
projects
I've
been
there
for
about
four
years,
and
my
projects
involved:
secure,
bootstrapping,
PKI
secrets,
management,
authentication
and
authorization.
Authorization
is
something
you're
going
to
talk
today
of
co-presenter
turin,
hi.
B
A
Right,
let's
get
started
so
before
we
start
talking
about
the
main
topic
here:
I
want
to
just
get
some
background
definitions
out
of
my
way
using
an
example.
So
let's
say,
if
I'm
trying
to
send
a
request
to
my
bank
and
say
transfer
$1,000
from
account
X
to
account
Y.
In
this
particular
case,
the
bank
is
going
to
perform
two
steps,
one,
it
is
going
to
first
verify
the
identity
of
the
requester.
That's
me
that
that
is
what
we
call
an
authentication
and
then
verify
that
the
requester.
A
This
identity
is
authorized
to
perform
the
requested
operation,
that's
authorization
or
Z.
Now,
for
some
of
you,
it
may
be
really
obvious,
but
I
cannot
tell
you
how
many
times
I
get
into
conversations
where
people
confuse
these
two
things
and
then
the
conversation
goes
nowhere.
So,
hopefully
I
start
off
with
this
background
definitions,
so
we're
going
to
talk
about
bullet
number,
two,
not
one
all
right
now.
One
more
thing
I
would
like
to
say
is
these
two
steps
do
not
need
to
be
tied
together.
They
do
not
need
to
happen
within
one
system.
A
They
could
be
completely
decoupled.
In
fact,
I
will
go
one
step
further
and
say
if
you
tie
them
together
sooner
or
later,
you're
gonna
lose
your
flexibility.
If
you
have
interested
in
that
statement,
you
meet
me
afterwards.
I
can
go
into
deeper
conversations
there,
so
some
more
background
about
Netflix's
architecture.
So
this
is
a
very,
very
simplified
high
level
view
of
Netflix's
architecture.
A
There
are
customers,
we
have
our
bag
back
hand,
we
are
a
cloud
provider
partners
and
then,
of
course,
the
CD
and
that
basically
stores
your
movies
and
shows
that
gets
you
the
bytes
as
quick
as
possible
to
your
TV.
Now
we
are
going
to
focus
on
this
big
empty
box
today,
which
is
our
back-end
that
runs
all
our
control
plane.
What
we
have
there
is
a
CI
CD
pipeline
container
orchestration
system,
workflow
management
systems
which
are
very
similar
to
kubernetes.
A
If
you
in
in
many
ways
and
I,
think
this
morning
you
probably
caught
dance
keynote,
she
she's
the
director
who
manages
the
team
under
spinnaker.
So
these
are.
These
are
all
the
systems
that
basically
drive
and
launch
all
the
applications
and
workloads.
Then
we
have
these
applications
that
are
basically
some
sort
of
API
gateway,
personalization
account
management,
key
management,
legal
encoding
of
movies
and
all
those
things,
and
then
we
also
have
some
sort
of
bad
jobs
or
periodic
on-demand
tasks
which
are
run
in
containers
through
our
container
management
system
called
Titus.
A
A
This
all
looks
simple
and
not
maybe
not
too
different
from
your
setup,
but
then
things
get
challenging
when
this
happens,
they
want
to
talk
to
each
other
right.
Of
course,
there
are
other
interactions
where
applications
go
and
talk
to
the
cloud
provider.
Resources
like
you,
know,
storage
in
case
of
AWS.
It
will
be
s3
or
database
or
queueing,
but
we
are
going
to
today
focus
only
on
that
the
interaction
within
within
the
control
plane.
A
So
all
these
applications,
all
these
services
are
hosted
by
us
and
controlled
by
us
now
when
they
don't
want
to
talk
to
each
other.
You
want
to
make
sure
that
they
have
an
opportunity
to
decide
who
gets
to
talk
to
them
at
what
level.
So,
of
course,
as
I
said,
we're
not
talking
about
authentication,
a
lot
of
people
say
when
you
have
Network
reach
ability.
That's
all
we
need.
You
have
network
reach
abilities.
That
means
somebody
is
authorized
to
talk
to
you
not
really
so.
A
First
of
all,
that's
not
authentication
and
authorization
is
definitely
not
so
what
you
want
to
do
is
you
want
to
go
much
granular
level,
not
just
the
network,
reach
ability,
but
for
I'll
give
an
example.
So
what
if
one
of
these
services
is
a
rest-based
service,
then
you
want
to
control
exactly
who
gets
to
cal
call
what
rest
endpoint
right.
A
So,
let's
define
this
kind
of
problem
like
I,
just
give
an
example
of
rest,
but
it
doesn't
mean
anything
because
this
is
a
very,
very
diverse
back-end,
where
we
have
rest
based
services,
G,
RPC,
based
services.
There's
some
services
that
have
their
own
custom
binary
protocol
has
nothing
to
do
with
any
standardization.
So
how
do
you
solve
ODS
e
problem
in
a
world
like
that?
A
Where
you
have
such
a
diverse
set
of
services,
they
have
random
different
protocols
that
they
use
the
random
different
resources
that
they
host
and
is
being
called
by
people
and
services
right.
So
if
once
you
do
that,
and
you
try
to
solve
that
problem,
you
have
to
first
define
that
problem
and
with
this
kind
of
diversity
it
feels
very
general.
So
the
only
best
thing
I
could
do
with
that
kind
of
problem
at
hand
was
come
up
with
this
definition.
A
We
need
a
simple
way
to
define
and
enforce
rules
that
read
something
like
this
identity.
I
can
or
cannot
perform
operation
Oh
on
resource
are
for
all
combinations
of
I/o
and
are
in
your
ecosystem.
That
sounds
like
boiling
an
ocean
right.
However,
this
problem
needs
to
be
solved
because
if
you
have
any
subset
of
this,
I
io
and
R,
and
then
you
have
one
solution
for
that:
you're
gonna
end
up
having
nine
solutions
in
your
ecosystem
and
luscom
visibly
and
control
completely.
A
So
that
was
not
an
option.
We
had
to
have
one
system
that
would
take
if
not
100%,
like
majority
of
your
combinations
of
IO
and
R.
That
is
identities
of
operations
and
resources.
Now,
just
before
you
start
building
something
like
this,
you
have
to
have
your
guiding
principles
and
requirements
in
place,
so
we
wanted
to
make
sure
that
we
write
down
all
these
things
before
we
actually
propose
something.
A
Now
in
this
environment,
when
they
have
their
ownership
of
their
own
service,
they
are
also
required
to
define
who
gets
to
talk
to
their
service
at
what
level.
So
if,
if
a
solution
is
not
giving
them
that
kind
of
freedom,
it's
not
going
to
fly
in
a
company
like
Netflix,
so
first
thing:
first,
we
have
to
make
sure
that
the
solution
works
with
the
company's
culture.
A
Second
resource
type.
As
I
mentioned,
we
don't
have
one
resource
type.
We
don't
have.
We
don't
want
to
just
do
a
solution
for
rest
services
or
JRPG
of
services.
So
remember,
I'm,
talking
about
random
stuff
here,
not
even
rest
and
G
RPC,
as
in
some
sort
of
API
cause
I'm
talking
SSH
access
to
so,
for
example,
if
you
have
a
VM
and
you
need
a
CH
access
into
a
system,
SSH
becomes
your
resource
right.
So
it's
not
just
the
API
call
is
SSH
so
identities,
a
lot
of
identity.
A
Authorization
system
that
you
will
see
around
there
mostly
are
back
and
they
are
LDAP
based
or
you
know,
some
sort
of
ad
based
the
the
problem
there
is
now
you
have
to
have
accounts
and
mostly
most
of
those
systems
are
designed
for
users.
But
here
you
have
incoming
identities.
That
can
be.
Users
and
users
can
also
be
like
full-time
employees
contractors,
and
then
you
can
have
software,
which
can
be
bad
jobs
which
can
be
containers,
running
services
or
some
of
the
VMs
running
services.
So
all
these
collars
need
to
be
identified
and
supporting
underlying
protocols.
A
Now,
if
you
go
back
to
your
queueing
theory,
a
little
bit,
if
your
authorization
decision
on
every
request
to
put
or
get
from
a
Kafka
topic
takes
more
than
one
millisecond,
you
are
thrashing
you're,
you
you,
you
went
over
your
service
rate
right.
That
means
your
authorization
decision
has
to
be
made
in
sub-millisecond,
otherwise,
you're
not
even
serving
right.
So
in
this
particular
case,
can
you
even
think
about
an
authorization
decision
that
requires
a
network
roundtrip?
A
You
cannot
so
some
of
these
things
you
had
to
be
considered.
Flexibility
of
rules,
I
think
this
is
where
touring
we'll
talk
more
about,
but
once
you
have
all
these
resources
today,
you
know
your
use
cases
today,
but
that
doesn't
mean
you.
You
know,
and
you
can
predict
everything
that
is
going
to
come
next
week.
A
So,
if
your
rule
engine
or
if
your
the
way
you
write
your
policies,
is,
is
hard-coded
and
does
I
actually
allow
you
to
write
it
in
a
way
that
it
feels
more
like
a
language,
then
you,
you
can
really
restrict
yourself
in
future.
So
we
wanted
to
make
sure
that
flexibility
of
rule
is.
Is
there
and
the
last
one
I
call
capture
of
intent?
What
I
mean
by
this
is
basically
when
people
are
self
served,
they
tend
to
make
mistake:
they're
not
malicious.
They
just
didn't
have
their
coffee
right.
A
They
think
they
did
something,
but
that's
not
exactly
what
they
actually
ended
up.
Writing
in
policy.
So
is
there?
Is
there
any
way
to
basically
make
sure
that
we
give
them
the
freedom,
but
not
enough
rope
to
hang
themselves?
So
this
is
what
we
came
up
with
where
I
think
I
would
say
at
this
point.
We
will
go
one
by
one,
but
look
at
service
a
on
the
bottom
left
and
service
B
on
the
bottom
right
service.
A
A
is
a
VM
that
is
running,
is
application
code
and
you
see
a
little
box
called
G
agent
and
on
the
right
you
have
a
pod
which
has
application
code
and
another
container
in
the
same
part,
which
is
authorization
agent.
So
let's
look
at
this
architecture,
one
by
one.
What
happens
so
here
you
have
policy
portal
where
engineers
or
developer
team
team
members
go
and
go
write
their
own
policies
for
their
own
services.
A
It's
a
UI
based
system
and
they're
able
to
create
policies,
delete
policies,
reorder
the
rules
inside
the
policies,
and
then
there
are
sometimes
we
have
to
give
some
override
mechanisms
to
you
know.
Some
critical
teams,
like
you
know,
say
cops
and
for
insects
and
and
stuff
like
that,
and
all
the
policies
are
version
and
stored
in
the
database.
Now,
sometimes
you
have
to
write
policies
based
on
data.
That
is
not
necessarily
in
coming
from
your
request,
its
from
external
data.
A
Now,
for
example,
let's
say
if
you
had
a
rest-based
service
and
you
say,
slash
admin
/
anything
is
only
accessible
by
owner
of
this
app.
Now,
in
that
particular
case,
you
need
to
find
out
who
the
owner
of
a
given
app
is
that
mapping
between
app
and
app
owner
is
coming
from
some
external
source.
So
in
this
case
it
could
be
application.
Ownership,
database
right
or
another
example
is
okay.
I
had
this
application,
and
this
application
is
only
meant
to
be
used
by
finance
team.
A
Okay,
who's
in
the
finance
team,
that
information
about
user
verse
and
finance
team
needs
to
come
from
somewhere
else,
probably
employee
management
database.
So
now
you
are:
writing
all
these
policies
and
you
need
facts,
source
of
truth
for
all
this
information
and
needs
to
come
from
somewhere
else
so,
depending
on
in
future,
how
many
different
types
of
policies
you
write?
A
You
may
have
fetch
data
from
multiple
sources,
so
we
have
a
concept
called
aggregator
whose
job
it
is
to
basically
fetch
all
this
data
from
different
sources
and
keep
it
fresh,
then
there's
a
concept
of
distributor
which
basically
pulls
all
the
policies
and
related
data
from
aggregator
and
keeps
it
hot
now.
The
difference
between
aggregator
and
distributor
is
distributor
is
fairly
scalable,
because
it
keeps
everything
in
memory
you
can
slice
and
dice
it
and
put
it
in
different.
A
Let's
say
cloud
provider
account
for
security
and
stuff
like
that,
and
then
you
have
these
distributors,
as
the
name
says,
starts
distributing
all
these
policies
and
relevant
data
to
the
authorization
agents.
Now
what
happens
is
the
authorization
agents
are
able
to
then
synchronously
download
all
this
information
and
keep
it
hot?
So
you
see
the
red
arrows
right.
There
are
the
what
I
call
hot
path
where
the
request
comes
in
to
the
application.
It
is
going
to
the
authorization
agent
and
come
back
with
the
answer
now.
A
I
mentioned
something
about
the
latency
see
here
that
we
are
not
making
a
network
round-trip.
The
authorization
agent
is
sitting
on
there.
It's
right
there
in
case
of
part,
it's
still
probably
like
right
right
next
to
each
other,
so
you're
not
spending
a
real
network
round
term.
Now,
if
you
do
mean
little
bit
into
the
agent
itself,
it
has
two
parts
like
hot
path
and
the
a
synchronous
part
so
hard
part
is
the
gray
part
where
you,
the
application,
is
making
a
request
for
authorization
decision.
A
Whatever
request
you
received,
for
whatever
resource
is
going
to
pass
that
information
to
to
the
Aged
attitude
to
the
policy
engine
you
see
here
we
are
using
open
policy
agents.
Engine
Torian
is
going
to
talk
more
about
it,
and
then
we
have
a
slow
path
or
a
synchronous
path,
which
is
the
blue
path,
which
is
downloading
all
this
information
periodically
from
distributors
now.
This
is
all
like
architecture
in
T.
So
let's
take
a
one.
A
Can
concrete
example
in
a
familiar-looking
setup,
alright,
so
think
about
a
very,
very
simple
rest-based
payroll
system,
and
it
basically
has
only
two
rest
endpoints
that
it
exposes
one
get
salary.
Second,
update:
salary
right
now
you
want
to
write
an
authorization
policy
for
this
particular
app.
This
is
what
you
want
to
write.
Employees
can
read
their
own
salaries
and
then
salaries
of
anybody
who
reports
to
them
right.
A
So,
in
this
case,
let's
say:
Bob
reports
to
Alice
now,
when
Bob
reports
to
Alice
Bob
is
able
to
get
it
his
own
salary,
but
Alice
is
able
to
get
her
own
salary
and
then
Bob
salary.
This
is
what
you
want
to
achieve.
Then
you
want
to
have
report
generator
bad
job,
some
bad
job
kicks
off
every
I,
don't
know
week
a
weekly
basis
and
write
some
sort
of
country,
some
numbers
you
want
to
give
that
report
generator
app
permission
to
read
anybody's
salary.
A
So
you
want
something
like
this
get
charlie
start
and
then
you
have,
let's
say
performance
review
app.
That
is,
you
know,
I,
don't
know
kicks
it,
yearly,
six
monthly,
whatever
your
company
does
and
goes
and
updates
that
salary.
Of
course
you
don't
want
to
give
access
to
employees
to
to
write
and
post
their
own
update
salary.
So
you
say
all
right:
only
that
application
has
access
to
the
post
API
at
this
point,
I'm
going
to
have
handed
over
to
Turin,
who
will
explain
how
all
this
magic
happens
within
OPA.
B
What
I
also
really
like
is
this
desire
for
a
general
purpose,
solution
that
solves
for
all
of
these
different
combinations
in
a
holistic
way
across
the
stack,
and
so
this
is
what
we
set
out
to
do
when
we
created
the
open
policy
agent
project,
so
the
open
policy
agent
or
OPA,
as
we
like
to
call
it-
is
an
open
source
general
purpose
policy
engine.
What
that
means
is
that
you
can
take
OPA
and
you
can
apply
it
to
any
system
at
any
layer
of
the
stack
and
what
you
get
when
you
use
OPA.
B
Is
this
purpose-built
engine
that
you
can
use
to
offload
policy
decisions
to
so
the
idea
or
the
way
this
would
work?
Is
that
say,
you're
building
this?
This
service
that
exposes
an
HTTP
API.
Well,
you
would
take
that
service
and
you
would
integrate
it
with
OPA
to
execute
a
query
against
OPA
when
it
wants
to
enforce
access
controls
over
who
can
access
or
who
can
do
what
via
the
API.
B
I
said
it's
lightweight,
and
the
reason
for
that
is
because,
basically,
all
of
the
policies
and
data
that
OPA
uses
for
evaluation
are
kept
in
memory,
so
it
doesn't
introduce
any
kind
of
runtime
dependencies
at
deployment
time,
so
it
doesn't
depend
on
an
external
database
or
an
external
service,
or
anything
like
that.
Everything's
cached
in
memory
now,
in
addition
to
the
the
core
evaluation
engine
that
OPA
gives,
you
OPA
also
provides
a
suite
of
tooling
that
you
can
use
to
develop
your
policies
locally.
B
So
it
gives
you
like
an
interactive
shell
to
experiment
with
and
debug
policies.
It
gives
you
a
test
framework
to
codify.
You
know,
unit
tests
over
it
over
your
policies
and
so
on
now
the
core
thing
that
OPA
gives.
You,
though,
is
this:
is
this
high-level
declarative
policy
language
and
we
call
that
language
Rago
and
what
Rago
does
is
it
gives
you
the
ability
to
write,
express
policy
as
code,
and
so
what
that
looks
like
when
you
use
Rago,
you
write
a
bunch
of
rules
in
this
declarative
language
and
they
answer
the
rules
exist.
B
To
answer
questions
or
make
decisions,
like
you
know,
can
user
X
perform
operation
Y
on
resource
Z,
so
we
thought
we
would
do
is
step
through
this
example
that
minish
set
up
and
show
how
you
would
use
OPA
to
enforce
it.
So
the
policy
in
English
is
fairly
simple.
It
says
that
you
know
employees
are
allowed
to
read
their
own
salary
and
then
any
button,
and
then
they
can
also
read
the
salary
of
anybody
who
reports
to
them.
B
So
let's
look
at
how
you
would
actually
use
/
to
enforce
this
so
when
you're
using
open
to
enforce
policy,
what
you're,
mainly
thinking
about
doing
is
writing
rules.
They
make
decisions
over
some
data
and
the
language
that
OPA
gives
you
to
do.
That
is
purpose-built
for
writing
policy
and
reasoning
over
arbitrary
data,
and
the
reason
for
that
is
because,
when
you're
thinking
about
policy,
what
you're
thinking
about
is
data
and
logic,
and
so
what
you
really
want
is
a
language
that
lets.
B
So
you
can
understand
this
rule
or
you
can
read
it
as
basically.
Allow
is
true
if
the
input
method
matches
get
and
input,
dot
path,
matches,
get
salary,
ID
and
input
user
matches
ID.
Now.
The
interesting
thing
about
this
example
is
that
that
ID
value
is
actually
a
variable,
and
so
that
variable
is
going
to
be
bound
when
oppa
evaluates
the
rule
to
a
single
value
across
all
of
those
expressions
and
so,
for
example,
in
the
in
the
second
expression.
B
B
Okay.
So
now
we're
going
to
add
another
rule
called
allow
again
to
handle
this
second
case,
where
someone
is
requesting
the
salary
of
an
employee
who
reports
to
them,
and
so
this
rules
can
have
exactly
the
same
structure,
we're
going
to
match
on
the
path
and
match
on
the
method.
But
this
time
we
need
to
do
something
a
little
bit
different,
and
so
the
input
data
to
the
policy
engine
would
be
exactly
the
same.
B
So
the
third
expression
looks
up
the
management
chain
for
a
given
user
and
then
the
fourth
expression
searches
over
that
management
chain
to
see
if
the
input
user
is,
is
a
manager,
ok
and
so
at
this
point,
we've
actually
codified
the
entire
policy
using
OPA.
But
there
are
a
couple
other
things
that
I
want
to
point
out
before
I
head
back
to
Manish.
So
the
first
thing
is
that
in
this
case
we
have
this
logic
that
determines
whether
or
not
one
user
is
a
manager
of
another.
B
And
while
it's
relatively
simple,
you
may
want
to
have
this
logic
reused
throughout
your
policies,
and
so
you
don't
want
to
duplicate
it.
You
don't
repeat
yourself
all
the
time,
and
so
what
you
want
to
go
to
do
is
share
and
reuse
that,
and
so
to
do.
That
OPA
gives
you
the
ability
to
compose
policy,
and
what
that
means
is
that
you
can
basically
take
logic
and
you
can
split
it.
B
You
can
factor
it
into
separate
rules
or
separate
functions,
and
then
you
can
call
those
rules
or
functions
from
from
other
rules
and
functions,
and
so,
in
this
case,
we're
going
to
do
just
that.
We're
going
to
take
the
the
check
to
for
manager
for
managers
and
we're
going
to
pull
that
out
into
a
separate
function
that
will
return
true.
If
a
is
a
manager
of
B
and
then
all
you
do
is
just
update
the
original
rule.
B
The
second
thing
I
want
to
point
out
is
that
OPA
is
completely
resource
agnostic,
so
it's
not
coupled
to
any
domain
specific
model,
and
this
is
the
main
reason
why
we
can
say
that
its
general
purpose,
because,
regardless
of
whether
or
not
you're
writing
policy
over
HTTP,
api's
or
Kafka
or
SSH,
it's
all
just
data
to
Opa
Opa
doesn't
care
matter.
It's
all
just
data.
B
So,
for
example,
we
have
integrations
and
we've
shown
how
you
can
use
it
to
enforce
admission
control
policies,
workload,
placement
policies,
management
policies,
rights,
elevation
and
more
now,
to
do
that,
you
don't
have
to
start
from
scratch,
because
we've
got
a
bunch
of
great
tutorials
on
the
website
and
we
have
a
number
of
pre-built
integrations
that
you
can
use
out
of
the
box
for
projects
like
kubernetes
and
docker
and
sto.
And
of
course,
we've
got
many
more
coming.
B
A
All
right,
thanks,
Tori
so
oppa
is
amazing,
has
a
lot
of
flexibility
and,
as
you
saw
some
of
the
policy
snippets,
it's
not
that
hard
from
syntax
perspective.
However,
we're
talking
about
a
company
like
Netflix,
which
has
hundreds
of
teams
here
and
then
they
remember,
go
back
to
the
original
requirement
of
self-serve.
So
I
have
to
make
this
system
self,
sir.
So
these
teams
are
very
competent
and
everything,
but
sometimes
they
forget
their
coffee.
So
I
really
don't
want
them
to
write
any
complex
looking
code.
A
So
what
we
had
to
do
was
basically
make
sure
that
that
their
life
is
as
easy
as
possible
when
they're
starting
to
write
their
policies.
So
what
we
ended
up
doing
where's
take
two
steps.
So
first
step
was
we.
We
built
a
UI
on
top
of
this
OPA
language,
so
the
complexity
of
the
language
is
hidden
from
them.
A
So
I'll
give
you
an
example
here
for
the
it's
an
animated
thing:
I,
don't
know
if
it's
very
visible,
but
this
is
the
UI
that
does
the
exact
same
thing
as
underneath
it
basically
converts
the
UI
action
into
OPA
policy.
So
in
this
particular
case,
all
I'm
doing
is
saying
that
this
post,
endpoint
is
only
accessible,
should
be
only
accessible
by
performance,
review,
application
right
and
then
that
this
is.
This
is
what
people
this
is,
what
I
call
capturing
intent.
Their
intent
is
to
just
allow
this
particular
application.
A
This,
hopefully
very
intuitive
UI
allows
them
to
do
that
without
making
much
mistakes
and
then,
if
I
make
a
second
example
of
the
get
salary
endpoint,
it's
slightly
more
complex
because
has
more
than
one
rules
has
more
than
one
rule,
because
you
have
employee,
then
you
have
manager,
and
then
you
have
the
report
generator
application.
So
in
this
particular
case
you
have
three
rules
and,
as
you
see,
the
animation
is
trying
to
do
very
similar
stuff.
That
OPA
was
showing
is
just
that
it's
in
UI
format
right.
A
Fortunately,
in
this
particular
case,
all
these
three
rules
are
not
overlapping,
so
order
of
those
rules
won't
matter.
However,
the
the
way
we
write
policies
is
basically,
if
you
have
ever
had
pleasure
of
configuring
IP
table
in
the
past.
You
basically
have
all
these
specific
rules
at
the
top
and
the
generic
rooms
at
the
bottom,
so
you
can
catch
everything
here.
A
So
one
more
thing
we
had
to
do
was
yes,
this
is
good
and
dandy,
but
it
still
doesn't
actually
answer
the
question:
did
you
capture
the
intent,
because
the
intent
is
only
with
the
person
who's
actually
making
these
rules,
so
they
know
in
plain
English
what
they
wanna
achieve,
but
they
don't
actually
know
exactly
what
they
did
is
going
to
perform,
what
they
think
they
did
right.
So
the
second
step
we
took
was
basically
we
built
in
unit
testing
mechanism
in
this
UI.
A
A
This
test
should
pass,
so
you
can
have
positive
use,
positive
unit,
S
or
negative
unit
test,
and
then
before
you
actually
save
your
policy
and
it
gets
pushed
into
product
production,
it
will
run
all
the
unit
tests
and
only
when
this
they
pass,
your
policy
will
be
updated
in
the
production.
Now
what
happens
is
policy
is
written
six
months
later.
A
Somebody
wants
to
go
and
add
one
rule
to
it
and
they
completely
forget
all
all
the
intents
that
they
had
six
months
back,
so
these
unit
tests
will
save
their
day
because
the
unit
tests
are
saved
with
the
version
of
that
policy,
so
all
the
as
soon
as
you
update
the
policy.
All
these
unit
tests
that
you
had
thought
about,
they
will
run
before
they.
A
A
Let
me
build
on
top
of
the
UI,
so
just
to
summarize
everything
here,
we
basically
have
this
very
diverse
back-end,
which
has
all
these
services
that
are
reusing,
random,
different
protocols
and
have
all
these
different
resources
that
they
host
and
they
have
clients
that
look
like
people
and
jobs
and
and
and
viens
bad
jobs
running
in
containers
whatnot.
So
we
had
to
first
solve
your
authentication
problem,
which
we
did
and
then
once
we
had
that
we
had
to
make
sure
that
the
the
authorization
system
is
flexible
and
extensible.
A
Now
latency
was
also
a
big
deal,
so
we
I
think
Tory
showed
some
numbers
from
opus
perspective
and
when
we
did
our
own
benchmark,
this
was
basic.
Policies
could
easily
be
done
in
less
than
0.2
milliseconds
so
which
works
for
Kafka.
If
it
was
for
Kafka.
For
me,
it
probably
works
for
all
the
other
services
at
this
point
inside
Netflix
at
Netflix,
calcio,
dating
coordinating
updates,
is
very
hard.
A
So
if
you
had
like
any
kind
of
hard-coded
rule
mechanism
and
not
using
language
based
evaluation,
engine
you're
going
to
have
really
hard
time
overtime
to
push
out
any
sort
of
updates.
Once
you
have
language
based
system,
it
is
very
easy
to
support
new
kind
of
use
cases
and
then,
obviously
for
being
culturally
successful
in
a
company
like
Netflix.
Your
solution
has
to
provide
something
that
is
goes
well
with
freedom
and
responsibility
so
having
a
self-serve
system
with
a
good
UI
and
good
guardrails
will
actually
make
this
project
very
interesting
and
successful.
A
So
in
closing,
I
would
say
that
something
that
you
wanna
take
away
is
authorization
is
the
fundamental
security
problem.
It
is
not
new
to
cloud
by
the
way
it
just
cloud
just
makes
it
more
interesting,
because
the
way
it
works
and
if
you're
not
there,
yet,
if
you're
not
there,
solving
this
problem
yet
you're
gonna,
be
there
soon
all
right.
You
can't
just
wish
this
one
away,
because
you
know
in
the
in
our
parents
days
you
had
network
security.
That
was
enough
and
definitely
not
enough
in
in
cloud
environment.
A
What
I
would
say
one
more
time
is
that
if
you
are
going
to
tackle
this
problem,
try
to
see
how
you
can
have
a
comprehensive
solution,
rather
than
some
hodgepodge
of
nine
different
authorization
systems
in
your
back
end,
because
the
end
of
the
day
they
don't
talk
to
each
other.
You
don't
have
a
common
place
that
you
can
go
and
have
some
visibility.
It's
going
to
be
really
messy,
and
then
you
have
open
source
projects
like
OPA
that
you
can
make
use
of.
A
In
fact,
I
came
to
know
about
openly
like
earlier
this
year,
and
this
I
I
knew
my
requirements,
but
as
soon
as
I
saw
that
I
could
switch
my
requirement.
Even
if,
let's
say
a
language
is
not
Turing
complete,
it
doesn't
mean
that
it's
not
good
enough.
It's
still
a
language
right,
so
you
you
should
use,
go
around
look
for
open-source
projects
and
make
sure
that
if
it
fits
your
requirement,
you're
you're
able
to
get
there
faster
and
the
last
one
I
would
say.
Is
you
don't
have
to
build
this
alone?
A
Like
you,
this
problem
is
not
necessarily
new,
so
a
lot
of
people
are
thinking
about
it.
There's
a
very
young
community
called
Padme.
They
had
actually
a
session
earlier
today.
So
if
you
are
interested,
maybe
you
should
get
involved
in
community
so
that
you
can
solve
with
other
people,
and
you
may
even
end
up
learning
something
more
about
this
problem
and
you
may
find
some
more
use
cases.
You
may
not
have
thought
about
all
right,
so
thank
you.
So
much
I
think
we
can
take
couple
of
questions.
B
A
A
A
A
So
I
should
have
mentioned
that,
so
the
question
is:
does
the
distributor
pick
up
only
set
of
rules
to
send
to
an
agent?
So
we
from
day
one
we
designed
this
system
in
a
way
that
not
only
it
sends
the
very,
very
specific
rules
and
only
things
that
applicable
to
you,
but
the
updates
are
Delta
updates,
it's
not
sending
everything
anything
that
just
change.
Only
those
things
are
sent
over
the
wire.
Otherwise
this
will
just
become
a
mess
you're
right
by
the
way.