►
From YouTube: Implementing Authorization - Torin Sandall, Styra
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Implementing Authorization - Torin Sandall, Styra
Whether you build software for enterprises, mobile, or internal microservices, security is important. Standards like SAML, OIDC, and SPIFFE help you solve identity and authentication, but for them authorization is out of scope. When you need to control "who can do what" in your app, you are on your own. To solve authorization, you may be tempted to hardcode logic against SAML assertions, scopes, or X.509 certificate attributes. But, approaches like this lead to systems that are hard to understand and painful to maintain. This talk shows how to leverage the Open Policy Agent (which is used by companies like Netflix and Chef) to build a powerful authorization system on top of industry-standard authentication protocols. The talk showcases how decoupling leads to authorization solutions that are easier to understand while enabling fine-grained control over the app.
To learn more click here: https://sched.co/FuKQ
A
Test
one
two:
three,
okay,
I
think
everybody
can
hear
me
so
sorry
about
that.
We
had
a
little
bit
of
difficulty,
getting
the
display
hooked
up
yeah.
So
this
is
going
to
be
a
talk
about
implementing
authorization
and
my
name
is
Turin
I'm,
a
engineer
at
a
company
called
steerer
I'm,
also
one
of
the
co-founders
and
core
contributors
to
the
open
policy
agent
project.
A
A
That
don't
actually
contribute
to
the
core
value
that
they
want
to
provide
and
he
called
that
work
undifferentiated,
heavy
lifting
and
so
back
in
2006
undifferentiated
heavy
lifting
for
a
software
company
or
a
company
trying
to
build
a
SAS
offering
was
you
know,
trying
to
rack
servers
in
order
to
sell
widgets
online,
and
so
today,
in
2018
you
know
things
are
better.
You
don't
have
to
like
rack
servers
yourself.
You
don't
have
to
worry
about
redundant
power
and
whatnot.
A
You
can
spin
up
a
kubernetes
cluster
in
a
few
minutes
as
long
as
you
give
your
credit
card
to
the
cloud
provider,
but
I
think
that
today,
in
the
software
industry,
there's
still
a
lot
of
heavy
lifting
that
goes
on
and
I
would
argue
that
authorization
is
a
really
good
example
of
heavy
lifting
that
software
companies
do
all
the
time
now.
The
thing
about
authorization
is
that
it's
actually
really
important
and
basically
every
application
we
build
has
to
implement
authorization.
A
The
problem
is,
is
that
you
know
if
you
don't
get
it
right,
the
mistakes
or
the
mistake
can
be
very,
very
expensive
to
recover
from,
and
so,
for
example
like
if
you're
shipping,
an
application
to
an
enterprise,
you
better
make
sure
that
you
have
an
authorization
story
in
place.
Otherwise,
there's
no
way
that
the
security
and
IT
departments
at
that
company
will
deploy
your
software.
A
So
what
happens
today
is
that
you
know
software
companies
basically
bite
the
bullet
and
they
do
the
heavy
lifting
and
they
implement
authorization
from
scratch
every
single
time,
but
I,
don't
think
that
it
needs
to
be
that
way,
and
so
what
I
think
we
need
to
do
is
you
think
how
we
implement
authorization
I,
don't
think
that
we
should
have
to
roll
it
from
scratch
every
single
time
now
oops.
Why
is
that
important?
So
you
know
what
this
comes
down
to
at
the
end
of
the
day.
A
A
Authentication
is
the
process
of
verifying
the
identity
of
the
caller
into
the
system,
whereas
authorization
is
the
process
of
verifying
that
the
caller
has
the
permission
to
do
the
thing
they're
requesting
now
it's
important
to
keep
in
mind
that
you
need
to
solve
authentication
before
you
try
to
solve
authorization.
There
is
no
point
in
working
on
authorization
until
you've
solved
authentication.
A
It
doesn't
make
any
sense
to
write
rules
to
control.
Who
can
do
what?
If
you
can't
trust
that
you
know
Bob
is
who
bob
says
he
is
now.
The
good
thing
is
that
the
authentication
space
is
fairly
standardized,
so,
whether
you're
working
in
the
enterprise
with
a
standard
like
sam'l
or
you're,
working
in
the
consumer
space
with
you
know,
Oh,
IDC
or
you're.
A
Looking
at
using
spiffy
in
the
infrastructure
space,
there
are
existing
standards
that
exist
to
help
you
verify
identities,
and
while
these
standards,
you
know
represent
information
differently
and
they've
got
different
protocols,
they
all
do
the
same
core
thing,
which
is
they
verify
the
identity
of
people
and
machines
interacting
with
the
system.
So
authentication
is
all
about
taking
credentials
or
something
like
that
from
a
human
or
machine
and
then
verifying
them.
So
the
outcome
of
an
authentication
process
is
a
verified
identity.
A
Now,
in
addition
to
verifying
the
identity,
a
lot
of
authentication
processes
will
typically
include
attributes.
They'll
produce
attributes
as
a
result,
and
so
these
attributes
are
useful
because
they
provide
more
information
about
the
caller.
They.
They
will
also
tell
you
how
the
caller
authenticated.
So
maybe
they
used,
you
know
a
simple
username
password
or
maybe
they
went
through
a
multi-factor
authentication
process.
A
They'll
also
tell
you
when
that
authentication
context
is
valid
until
and
so
once
you
get
all
of
these
attributes,
you
can
use
them
in
your
applications
to
implement
authorization
checks,
but
one
of
the
problems
that
you
run
into
when
you
start
doing
this
is
that
you
discover
that
the
attributes
mannix
the
meaning
of
some
of
these
attributes
is
not
necessarily
well-defined.
It
goes
wave.
They
go
beyond
the
scope
of
the
specification
so
like
in
the
case
of
spiffy.
A
A
Administered
claims,
but
it
also
contains
claims
that
are
oil
standards
like
the
AMR
claim.
That
tells
you
how
the
client
authenticated,
but
the
meaning
of
those
some
of
those
claims
does
not
are
not
well-defined
and
that,
in
the
case
of
OID
CID
tokens
can
also
contain
custom
plans.
So
you
don't
even
know
the
universe
of
all
the
claims
that
can
possibly
exist,
but
beyond.
Just
the
the
universe
and
the
meaning
of
these
attributes.
A
There's
a
bigger
problem
and
the
bigger
problem
is
that,
at
the
end
of
the
day,
your
application
has
to
decide
how
identity
attributes
map
to
functionality
and
privileges
in
the
application.
So
even
if
you
could
enumerate
all
the
claims
and
all
the
attributes-
and
you
knew
the
meanings
of
them
and
they
were
all
well
defined-
you'd
still
have
this
problem
of
evaluating
them.
Inside
of
your
applications.
A
So
you
know
what
about
OAuth
right?
If
you
go
look
at
the
OAuth
RFC
you'll
see
that
it
calls
itself
an
authorization
framework,
so
you
know,
does
Olaf
solve
authorization
for
you?
The
answer
is
not
really
so
what
Olaf
is
really
good
at
and
what
it
does
really
well
is
it
enables
delegation
it
enables
you
to
grant
an
application,
the
ability
or
the
right
to
do
something
on
your
behalf
now
I
really
like
this
analogy
for
OAuth,
which
is
that
it's
like
power
of
a
turn
for
web
and
mobile
apps.
A
So
power
of
attorney,
you
know,
allows
you
to
grant
someone
else
the
right
to
do
something
on
your
behalf
right.
It's
like
to
sign
legal
documents,
for
example.
So,
for
example,
if
Bob
granted
Alice
power
of
attorney,
then
she
could,
you
know,
go
and
open
a
bank
account
in
Bob's
name
or
she
could
you
know
open
a
mortgage
or
something
like
that
at
a
bank.
A
Still
has
the
ultimate
say
so,
just
because
you
granted
an
application,
the
right
to
do
something
on
your
behalf
doesn't
mean
that
the
resource
server
is
going
to
allow
it
or
just
blindly
trust
what
the
application
is
requesting,
and
there
are
parts
of
OAuth
that
do
actually
help
drive
authorization
like
the
access
token,
but
again
how
that
access
token
gets
applied
is
outside
the
scope
of
OAuth.
They
don't
define
it.
They
say
the
methods
used
by
the
resource
server
to
validate
the
access
token
are
beyond
the
scope
of
the
specification.
A
A
Where
you
can
you
get
on
slash
salary,
slash,
Bob,
and
then
you
can
provide
some
potentials
and
and
then
it's
up
to
the
service
to
basically
decide
whether
to
allow
or
deny
that
request.
So
what
we're
going
to
do
is
look
at
how
you
can
implement
a
simple
policy
that
just
says
that
employees
should
be
able
to
read
their
own
salary
as
well
as
the
salary
of
anybody
they
they
report
to,
or
rather
that
reports
them.
A
So
this
is
one
way
you
right,
I
think
most
people
here
could
probably
make
sense
of
this
code.
You
have
some
application
code
and
some
authorization
code.
The
app
code
calls
into
the
authorization
code
and
says:
should
this
request
be
allowed
and
then
the
authorization
code
as
an
interface
that
says,
pass
me
an
incoming
request
and
I'll
return.
A
True,
if
the
request
should
be
allowed
or
false
if
it
should
be
denied,
and
so
in
this
case
it
checks
if
the
incoming
user
is
equal
to
the
employee,
ID
like
as
if
the
users
requesting
their
own
salary
and
then
it
also
checks
that
the
users
in
the
list
of
managers
for
the
employee
and
in
those
cases
that
requires
to
be
allowed,
otherwise
it
would
be
denied.
So
this
is
fairly
simple.
Is
the
job
done
here?
I,
don't
I,
don't
know
right,
I,
don't
think
so,
though,
because
this
code
raises
a
number
of
questions.
A
So
what
happens
if,
tomorrow,
someone
from
the
security
organization
comes
along
and
says
that
now,
in
order
to
access
sensitive
information,
you
need
to
make
sure
that
clients
have
gone
through
a
multi-factor
authentication
or
what?
If
someone
for
the
legal
department
comes
along
and
says
in
order
to
access
sensitive,
sensitive
information,
you
need
to
be
connecting
from
the
same
region
where
the
service
is
hosted
or
where
the
data
is
hosted,
or
how
do
you
delegate
control
to
your
end-users
right?
What,
if
the
customer
this
this
application
says?
A
Okay,
well,
I
want
HR
to
be
exempt
from
this.
This
rule.
They
should
be
able
to
see
all
salaries
all
the
time.
Well,
okay,
so
maybe
you
can
just
go
and
extend
that
authorized
function.
You
can
add
like
six
lines
of
Python
and
probably
implement
all
three
of
those,
but
now
how
do
you
roll
out
that
change
you've
just
written
six
lines
of
Python,
and
now
you
have
to
go
through
a
complete
rollout
of
your
application
right?
A
That's
that's
pretty
painful,
but
there
are
even
more
sort
of
challenging
problems
here
so
like
how
do
you
render
the
UI
that
this
application
serves
based
on
the
user's
permissions?
What
we've
done
here
is
we
basically
hard-coded
the
permissions
or
the
logic
behind
them
into
the
application,
so
you
can't
repurpose
that
logic
in
order
to
decide
which
components
to
draw
in
the
front-end
even
more.
Fundamentally,
though,
how
do
you
prove
to
somebody
that
the
policy
you've
implemented
is
correct
right?
If
someone
from
the
security
organization
comes
to
you
and
says,
have
you
implemented
this
policy?
A
What
are
you
going
to
do
you're
going
to
show
them
tests,
maybe
hopefully
your
tests
or
you're
just
going
to
show
them
the
code?
How
do
you
audit
the
fact
that
this
policy
is
being
enforced
and
then,
if
you
think
about
this
in
the
scale
around
the
context,
larger
organization
that
might
have
hundreds
or
thousands
of
services
deployed
written
in
dozens
of
languages
with
dozens
of
frameworks,
how
is
a
security
professionals
supposed
to
come
along
and
audit
and
make
sense
of
the
state
of
things?
A
Now
this
isn't
exactly
a
new
problem
like
we've:
we've
got
tons
of
existing
approaches
to
authorization,
and
so
what
I'm
gonna
do
is
just
sort
of
explain
some
of
the
common
approaches.
So
one
of
the
simplest
approaches
to
handling
authorization
is
to
create
an
access,
control
list
system
or
an
ACL
system,
so
ACLs
are
typically
denied
by
default
that
are
controlled
by
a
single
administrator
and
they
basically
allow
that
administrator
to
create
a
table
of
rows.
That
say,
this
user
can
form
this
action
on
this
resource.
A
So
ACLs
are
really
simple:
they're
they're,
easy
to
author
they're,
easy
to
like
understand
if
you're,
just
looking
at
one
or
two
of
them.
The
problem
is
that
in
a
large
organization,
this
doesn't
scale
very
well.
If
you
can
imagine
having
to
be
the
person
that
configures
ACLs
every
single
time,
a
new
employee
starts
for
every
single
service
in
your
organization.
You'd
probably
go
crazy
right.
No
one
wants
to
do
that.
So
there
are
ways
around
that.
So
one
example
is
role
based
access,
control
right
or
our
back.
So
what
our
back
does?
A
Is
it
at
a
fundamental
level?
Is
it
lets
you
group
users
with
roles
and
then
you
grant
permissions
to
those
roles
so,
for
example,
if
you're
building
a
payroll
app,
you
would
basically
say
that
you
know
HR
as
part
of
the
has
the
admin
role
and
they
can
do
and
see
anything.
Regular
employees
just
have
like
a
view
role
or
something
like
that
right
and
so
now
you
don't
have
to
you're,
not
tackling
the
scalability
problem
very
painfully,
but
sometimes
our
back
isn't
enough
and
you
need
something
a
little
bit
more
fine-grained.
A
And
so,
if
you
look
at
a
system
like
AWS,
I
am
you'll
find
that
it's
much
more
expressive
than
what
you
get
with
with
our
back
out
of
the
box.
So
AWS
I
am
has
a
notion
of
allows
and
or
deny
overrides
you
can
hang
allows
in
denies
off
of
users
and
groups
as
well
as
individual
resources,
and
then
it
has
concepts
like
negation
and
other
built-in
functions
that
you
can
leverage
and
then
going
even
further.
There's
this
thing
called
a
back
or
attribute
based
access
control.
A
A
A
Now
it's
nice
that
you
need
to
have
something
that's
easy
to
use,
because
it's
not
easy
to
use.
People
are
gonna
bypass,
it
they're,
gonna
figure
it
away
within
their
organization
to
get
around
it
and
then
you've
kind
of
defeated
you
the
whole
purpose
of
having
these
systems
in
place
in
them
at
all,
but
at
the
same
time
you
don't
want
to
have
to
build
a
new
system.
A
You
know
every
time
the
requirements,
change
or
every
time
there's
a
new
use
case
so
ACL
is
in
our
back
are
good
for
simple
problems,
relatively
simple
problems,
but
I
am
and
a
backer
are
better
for
more
complex
problems.
Now
the
thing
is:
is
that
today,
a
lot
of
the
time
when
we
pick
an
authorization
solution,
we
go
with
like
an
ACL
or
an
are
back
approach,
and
that's
because
it's
it's
relatively
easy
to
implement.
A
A
I
can
say
with
confidence
that
most
people
here
that
worked
for
a
large
organization
have
probably
had
to
deal
or
that
these
organizations
have
to
deal
with
all
kinds
of
policies
that
the
way
outside
of
what
ACL
is
and
are
back
and
I
am
can
deal
with
so
anytime.
You
have,
to
you,
know,
enforce
a
policy
based
on
time
of
day
or
based
on
the
the
source
address.
A
The
source
IP
address
or
based
on
some
kind
of
external
context,
then
ACLs
and
are
back,
are
no
longer
sufficient,
and
the
problem
is,
is
that
if
you
only
have
a
sales
and
are
back
at
your
disposal,
then
what
do
you
do?
There's
not
much
you
can
do
so.
This
is
what
we
set
out
to
help
solve
when
we
created
the
open
policy
agent
project.
A
So
there
are
kind
of
two
key
ideas
behind
OPA.
The
first
is
that
policy
decisions
should
be
decoupled
from
policy
enforcement.
You
don't
want
to
hard
code
policy
logic
policy
decisions
inside
of
your
service
because
it
because
it
can,
it
becomes
very
difficult
to
understand
that
policy
and
maintain
it
and
deploy
it
and
audit
it,
and
so
on.
A
The
other
idea
behind
OPA
is
that
you
should
use
a
high-level
declarative
language
to
codify
your
policies,
and
so
what
you
want
is
a
policy
language
that
allows
you
to
mix
and
match
these
different
kinds
of
models.
So
you
want
to
be
able
to
use.
You
know
ACLs
and
arbok
when
they
are
appropriate,
but
then,
as
your
use
cases
become
more
complex
as
you
have
new
requirements,
you'd
like
to
be
able
to
seamlessly
switch
over
to
a
more
sophisticated
model
like
I
am
or
now
at
this
point,
I
was
gonna.
A
A
A
You
can
take
oppa
policies
and
you
can
load
them
up
into
like
visual
studio
code,
for
example,
and
you
can
just
start
evaluating
them,
you
can
select
portions
of
them
and
ask
what
is
the
value
that
this
policy
would
generate.
So
this
is
an
example
of
a
Rago
policy
which
is
opus
policy
language
and
what
I
was
going
to
do
was
walk
through
a
simplest
scenario
where
you
know
suppose
you
have
this
this
pet
clinic
right
and
there
are
pet
owners,
and
there
are
pet
veterinarians
and
pet
owners
should
be
able
to.
A
You
know,
read
pets
and
create
pets,
and
veterinarians
should
be
able
to
read
and
update
the
details
of
those
pets
right
their
reports,
and
so
this
pet
clinic
has
two
users
Alice
and
Bob.
Bob
is
a
pet
owner,
Alice's
a
vet
veterinarian
and
then
the
pet
clinic
service
will
provide
certain
inputs
to
the
policy.
So
it'll
provide
three
things:
just
to
start
the
resource,
the
type
of
the
resource,
so
is
it
a
pet,
a
pet
object
or
a
pet
detail,
object
that's
being
accessed
the
action?
A
Is
it
a
read,
update
or
create
event
or
operation
being
performed,
and
then
the
identity
of
the
caller
so
either
Bob
or
Alice?
And
so,
if
you
were
to
try
to
list
the
pets
that
an
application
had,
you
would
do
a
get
on
slash
pets
and
provide
your
credentials
and
then
that
would
get
translated
into
input
that
we
provided
into
OPA.
A
And
so
then
the
service
would
query
OPA
and
ask,
for
example,
for
the
value
of
pet
clinic
allow
and
the
value
of
picked
when
it
got
allowed
would
be
computed
by
OPA
on
the
fly,
and
so
in
this
case,
what
saying
is
it
that
by
default
pet
clinic
God,
allow
is
false,
but
if
a
CLS
not
allow
is
true,
then
allow
it
also
be
true,
and
so
we
can
go
look
at
this
other
policy
here.
This
ACL
policy
to
see
what
would
happen
what's
being
done
here.
A
This
is
the
ACL
policy,
and
so
what
you
can
see
that
I've
done
here
is
I've
just
listed
all
the
actions
and
resources
and
users
that
are
allowed
to
perform
operations,
basically
right
there,
whether
the
action
resource
user
triplets
that
are
allowed,
so
bog
is
an
owner,
so
he
can
read
and
create
pets
and
Alice
is
an
owner.
So
she
can
read
and
update
pet
detail
or
she's
a
vet
for
veterinarian.
Rather
so
she
can
read
and
update
pet
details
right.
A
So
this
is
really
simple:
it's
only
27
lines
long,
but
if
you
had,
you
know
hundreds
of
thousands
of
users
and
many
more
operations
and
it
would
become
very
long
and
very
painful
to
work
with,
and
so
what
you'd
want
to
do
is
switch
over
maybe
to
an
are
back
model,
and
so
what
you
would
do
is
you
would
define
you
know.
Your
standard
are
back
objects.
A
We
defined
some
roles
so,
for
example,
there'd
be
an
owner
role
that
could
do
leads
on
pets
and
there'd
be
a
and
it
could
also
do
create
on
pets
and
then
there'd
be
a
veterinarian
role.
That
could
do
reads
on
pet
details
and
updates
on
pet
details,
and
then
you
would
bind
users
to
those
roles.
So
you
could
say:
Bob
is,
has
the
owner
role
and
Alice
has
the
veterinarian
role
right?
That's
pretty
simple:
I
think
everybody
can
follow
the
yamo
and
then
what
you
do
in
Opa.
A
Is
you
write
a
policy
that
can
interpret
that
data,
so
here
it's
a
little
bit
different,
a
little
bit
more
complicated,
but
it
basically
says
that
allow
is
true
if
role
name
is
in
roles
for
user
and
role.
Name
is
in
roles
for
operation,
and
then
we
defined
some
helper
rules
like
to
basically
find
the
roles
that
match
the
bindings
and
match
the
the
sorry
helper
rules
that
match
the
role
bindings
and
rule
definitions.
So
this
rule
is
basically
searching
over
all
the
role
bindings.
A
A
You
can
actually
provide
arbitrary
JSON
data
to
open
as
input
it's
not
coupled
any
domain-specific
model,
it's
very
flexible
that
way
and
then,
in
order
to
make
that
take
effect.
In
order
to
enforce
that,
you
would
go
into
your
top-level
allow
rule,
and
you
just
change
that
Ackles
line
to
say
our
back
dot
allow
instead
and
now
you've,
basically
transitioned
out
of
the
ACL
world
into
the
are
back
world
right.
A
So
I
can
just
actually
edit
this
whole
player,
just
as
clear
sure
so
you
go
in
here
and
you
would
change
this
to
our
bottle.
Ow
now
suppose
that
somebody
came
along
and
or
the
suppose,
there
was
a
breach
right
and
the
company
decided
that
you
can
no
longer
access
pet
details
if
you're
outside
of
the
corporate
network.
How
would
you
do
that
with
our
back
right?
A
Don't
usually
edit
policy
in
the
github
text
editor,
but
so
now
what
this
says
is
deny
is
true.
If
the
source
IP
is
not
inside
of
this
cider
network
and
the
input
resource
being
requested
is
pet
details
and
then,
in
order
to
make
this
to
take
effect,
you
would
just
go
here
and
say
sorry
allow,
if
not
deny
so
now
the
policy
says
basically
but
deny
by
default.
A
So
the
comes
up
a
lot
when
I
talk
about
oppa
the
pulse
agent.
Is
you
know
how
easy
is
open
to
use?
How
flexible
is
it
and
I've
never
run
into
a
use
case?
Where
oppa
wasn't
really
able
to
describe
the
policy
that
people
wanted
to
describe?
But
then
that
begs
the
question:
well,
it's
too
flexible.
It's
too
hard
to
use,
but
I
think
this
is
kind
of
a
bit
of
a
trick
question,
because
if
you
want
to
just
stick
to
simple
apples
and
simple
are
back
models,
then
you
can
do
that
right.
A
I
just
showed
that
and
oppa
will
handle
that
fine
it'll
actually
do
it
in
a
fairly
performant
matter,
like
it'll
it'll
are
a
manner
it'll
read.
It
already
are
back
decisions
for
thousands
of
roles
and
thousands
of
role
bindings
in
about
50
microseconds.
So
we
have
some
powerful
optimizations
inside
of
oppa
that
to
make
it
possible
to
do
that.
A
Okay,
so
the
second
this.
This
is
something
else
that
I
wanted
to
talk
about,
which
is
something
new
that
we've
been
working
on
in
oppa,
and
so
you
know,
we've
built
this
pet
detail
service
or
this
pet
clinic
service,
and
it's
you
know
it's
serving
requests
for
all
the
pets
and
it's
got
to
store
that
data
somewhere
right.
A
So
it's
probably
put
that
data
inside
of
a
database
and
then,
whenever
a
request
comes
in
to
like
list
the
pets,
it
runs
a
select
query:
it
returns
the
data,
that's
in
that
table,
but
so
far
we've
only
talked
about
policies
that
apply
to
the
incoming
data
right.
The
data,
that's
in
the
request,
all
we've
said,
is
that
you
can
say
you
know:
Bob
can
perform
get
on
slash
pets.
We
haven't
said
how
you
know
you
would
restrict
Bob
to
only
be
able
to
see
that
you
know
the
pet
that
he
owns
right
fluffy.
A
A
What
we
would
probably
usually
do
what
we
usually
do
is
we
go
into
that
service
and
we
extend
it
to
tag
on
a
where
clause.
To
that
sequel,
query,
and
now,
when
Bob
requests,
you
know
slash
pets,
he's
only
gonna
see
the
pets
that
he
owns,
but
now
we're
kind
of
back
in
the
state
that
we
were
originally.
Where
were
hard
coding
policy
decisions
into
those
services.
A
What
you
kind
of
want
to
be
able
to
do
in
the
policy
is
provide
constraints
over
those
queries
or
to
control
those
queries
to
some
extent
right.
So,
for
example,
if
a
new
regulation
came
out
that
said,
you
can
only
see
pets
from
the
region
that
you're
connecting
from
then
you
know
the
policy
could
influence
the
query
that
the
service
is
running
now
so
far.
A
What
we've
seen
is
that
you
know
what
our
request
comes
in
to
the
pet
details:
service
it'll,
ask
OPA
for
a
decision
right,
it'll
provide
some
input
like
the
method
and
the
path
and
so
on,
and
then
opens
gonna
crunch
the
policy
that
it
has.
It's
gonna
return
a
decision
like
allow
or
deny
back
to
the
service.
A
So
it
would
be
kind
of
difficult
to
implement
the
kind
of
policy
today
right
like
you,
would
need
to
somehow
get
the
data
from
the
database
into
OPA
and
then
ask
it
every
for
every
single
record
or
every
single
pet.
Whether
it
should
be
presented
wrong,
whether
it
should
be
allowed
to
be
seen
now,
and
it
turns
out
that
it's
actually
really
hard
to
do
that
in
a
way
that's
proposed,
like
performant
and
scalable
and
maintainable
and
correct
and
and
that
follows
that
the
applications
consistency
model.
A
A
A
A
Hopefully
we
can
get
past
the
point
where
everybody
has
to
re-implement
this
stuff,
all
the
time,
and
so
the
next
time,
you're
thinking
about
implementing
authorization,
maybe
think
about
it.
A
little
bit
differently.
You
can
check
out
the
open
policy
agent
online.
We
have
a
bunch
of
documentation
to
help
you
learn
about
it
and
we
also
have
a
number
of
integrations
with
all
kinds
of
projects
in
the
ecosystem.
So
it's
not
limited
to
just
API
authorization.
A
You
can
use
it
for
all
kinds
of
things
like
admission
control
and
kubernetes,
for
example,
you
can
even
use
it
at
the
host
level
with
Pam
and
SSH
and
sudo
if
you
want
to
lock
down
access
on
it
on
an
individual
machine.
So
thank
you
very
much.
We
have
a
slack
org
if
you're
interested
in
policy
and
an
opah
check
it
out.
The
code
is
online
on
github
and
yeah.
Thank
you
very
much.
I.
C
A
We
have
a
bunch
of
like
static
analysis
and
semantic
checks
that
you
can
run
on
the
policies
offline,
so
that
just
does
it
automatically
for
you,
but
open
also
has
a
test
framework,
so
you
can
actually
write
tests
for
your
policies
and
then
have
them
executed
and
verify
that
they're
correct.
So
it
turns
out
that
when
you're
writing
tests
for
open
policies,
them
they're
fairly
easy
to
write
it's
just
pure
logic
over
data.
So
let's
say
it's
actually
some
people
who
actually
said
it's
enjoyable
but
yeah.
C
B
A
A
Usually,
what
comes
in
the
input
to
OPA
is
like
the
path,
for
example,
it's
being
accessed
and
then
inside
the
policy
you
make
decisions
based
on
that
path,
for
example,
so
you
can
actually
supply
arbitrary,
JSON,
accurately
attributes
into
OPA.
The
path
could
be
one
of
those
and
then
you
could
route
based
on
that
yeah.