►
From YouTube: Deep Dive: Open Policy Agent - 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
Deep Dive: Open Policy Agent - Torin Sandall, Styra
As OPA adoption has grown, it has been applied to a variety of use cases like microservice API authorization, admission control, risk management, and more. In each case, OPA is used to render a definitive decision policy decision that is represented as a JSON value like "true" or "false". Earlier this year we added Partial Evaluation which gives OPA the ability to return conditional policy decisions in the form of simplified policy statements. This session explains how Partial Evaluation works and how you can integrate it into your services. The session is aimed at existing users (or people already familiar with OPA) who are interested in applying OPA to new usecases like data filtering and end-user authorization.
To learn more: https://sched.co/Grdg
A
A
So
anyway,
what
I'm
gonna
do
today
is
kind
of
jump
into
how
opal
works
and
to
do
that.
What
I
want
to
do
is
just
set
up
a
little
bit
of
an
example.
So
this
is
like
a
hypothetical
architecture
for
an
online
retailer
that
sells
pet
supplies
or
things
like
dog
food
to
people
over
the
internet,
and
so
there
are
kind
of
two
personas
that
are
that
are
involved
in
this.
So
there's,
there's
Bob
he's
a
customer.
A
He
likes
to
login,
to
pets,
calm
and
purchased,
dog
food
and
cat
food
and
so
on,
and
then
there's
Alice
and
Alice
is
a
customer
service
rep.
She
kind
of
answers,
questions
that
bob
has
and
she
also
debugs
problems
in
the
system
when
Bob
can't
order
pet
food,
and
so
we've
built
this
backend
for
pets.
Comm
following
you
know
a
micro
service
architecture.
So
we
have
a
service
that
handles
payments
and
a
service
that
handles
user
accounts
and
and
promotions
and
notifications
and
all
these
things
and
we
we
run
our
own
database.
A
We
run
Postgres
for
account
data
and
promotion
data
and
we
also
leverage
some
cloud
services
like
s3,
and
you
know,
notification,
services
and
so
on,
and
so
sometimes
Alice
has
to
you
know,
access
these
services
to
figure
out.
What's
going
on
and
to
you
know,
handle
customer
queries
and
the
problem
with
that
is
that
today
she
has
full
access
in
the
system
right,
so
she
can
just
open
up
her
terminal
and
start
executing
API
requests
against
payments
or
accounts
and
whatnot
there's
like
no
protection
in
place.
They
do
authenticate
those
requests.
They
do
check.
A
Right
again,
this
is
not
ideal,
so
what
we
want
to
do
is
kind
of
put
some
guardrails
into
the
system
to
prevent
these
kinds
of
things
from
happening
right.
So
this
is
like
an
example
of
a
policy
that
people
might
want
to
enforce
right.
They
want
to
say
that
support
staff
can
view
customer
data
if
they're
assigned
to
an
open
ticket
for
that
customer
right.
So
this
helps
us
put
some
guardrail
in
place
that
you
know
Alice
can
still
do
her
job.
She
can
still
support
Bob,
but
she
can't
you
know,
do
anything
right.
A
So
we've
got
a
little
bit
of
protection
in
place
now
in
order
to
do
that.
What
we
have
to
do
is
go
into
all
of
these
different
components.
These
parts
of
the
system,
these
services
and
basically
implement
authorization
right.
We
need
to
write
code
that
checks.
Whether
alice
should
be
able
to
do
the
thing
she's
asking
to
do,
and
so
you
might
decide
to
do
that
by
just
writing.
A
You
know
code,
you
might
go
to
the
payment
service
which
is
written
in
Python
and
add
the
check
there
and
the
account
service,
that's
written
in
Java
and
add
the
check
there
and
so
on
and
so
forth
right.
The
problem
with
that
approach
is
that
it
raises
a
number
of
questions
right.
So
what
happens
when
the
policy
changes
right?
A
What
happens
when
InfoSec
or
compliance
or
the
legal
department
comes
along
and
they
say
now
you
have
to
check
you
know
the
geographic
region
that
alice
is
connecting
from
or
you
need
to
check
the
device
that
she's
connecting
on
or
you
need
to
do
something
based
on
the
current
time
of
day,
like
she
shouldn't
be
looking
at
Bob's
account
outside
of
work
hours
right.
So
how
do
you
handle
those
kinds
of
changes
to
the
policy?
A
Moreover,
what
happens
if
bob
says
that
he
wants
to
have
some
kind
of
control
over
the
permissions
that
are
granted
to
his
data
right?
How
do
you
delegate
control
over
the
policy
to
your
end-users?
How
do
you
roll
out
policy
changes
when
they
need
to
get
updated?
How
do
you
leverage
external
context,
how
you
pull
in
data
from
an
external
data
source?
Like
a
you,
know,
a
ticketing
system
or
page
your
duty,
or
you
know
ad
and
so
on
right,
but
then
there
are
even
more
fundamental
problems.
A
So,
for
example,
how
do
you
test
that
your
policies
are
actually
implemented
correctly
right?
If
you
have
hundreds
of
services
written
in
dozens
of
languages
using
all
kinds
of
different
protocols,
running
in
containers
and
VMs
and
bare-metal
and
server
lists,
and
whatever,
how
do
you
actually
know
that
you've
implemented
this
policy
correctly
across
this
wide
range
of
Technology?
A
A
So
the
goal
of
the
project
is
a
unified
policy
enforcement
at
in
any
service
in
any
system
at
any
layer
of
the
stack,
and
so
we
started
the
project
in
2016
and
today,
three
years
later,
we
have
quite
a
few
people
using
the
project.
Companies
like
Netflix
chef,
Medallia,
State,
Street,
Intuit
and
Capital
One
talked
yesterday
at
the
intro
session
about
how
they're
doing
admission
control
in
kubernetes
with
OPA,
oh,
and
so
we
have
all
these
companies
using
OPA
for
a
variety
of
different
use.
A
A
Well
at
the
core
of
OPA?
There's
this
idea
that
policy
decision-making
should
be
decoupled
from
policy
enforcement?
Ok,
so
if
we
were
gonna
go
build
the
account
service,
we
would
have
to
implement
an
API
right
that
allows
people
to
view.
You
know
user
account
information,
and
so,
if
you
wanted
to
look
up
the
account
information
for
Bob,
you
would
do
a
get
on
slash
accounts,
slash
Bob,
and
then
you
provide
your
credentials
now
when
that
happen.
A
So
if
it
wasn't
allow
it
would
continue
processing
the
request
normally
if
it
was
a
deny
that
it
would
reject
the
request
right.
So
this
is
this:
is
it
this
is
at
the
fundamental
level.
This
is
what
oppa
is
helping.
You
do
now
it's
important
to
keep
in
mind
here
that
the
service
can
be
any
number
of
different
kinds
of
you,
know,
services
or
components
or
parts
of
the
stack
right,
so
it
could
be
a
container
Orchestrator
like
kubernetes.
It
could
be
an
api
gateway
like
kong.
It
could
be
sto
envoy.
A
It
could
be
Linux
Pam
at
the
host
level
right,
protecting
SSH
and
sudo
access
on
the
machines,
or
it
could
be
something
around.
You
know,
message
broker
or
a
database
or
something
like
that
right.
So
these
are
actually
all
examples
of
projects
and
services
that
we
have
integrations
with
today.
Now,
that's
why
we
call
it
general
purpose
now
in
order
to
make
that
happen.
A
In
order
to
realize
this
goal,
we
made
certain
design
decisions
when
we
started
the
project
and
one
of
the
fundamental
design
decisions
was
that
the
attributes
that
you
provide
to
OPA
can
actually
be
arbitrary,
JSON
data,
so
you
can
provide
arbitrary
or
any
JSON
value
to
OPA
when
you
execute
a
policy
query.
Similarly,
the
decisions
that
OPA
generates
can
be
arbitrary
or,
and
you
can
generate
any
JSON
value
from
your
policies.
A
Okay,
so
in
a
simple
authorization
case
you
might
generate,
you
know,
allow
or
deny
represent
that
it's
true
or
false,
but
in
like
an
admission
control
use
case,
you
might
need
to
generate
like
a
complex,
structured
object.
That
represents
the
admission
webhook
response
now.
Obviously,
the
policy
needs
to
be
able
to
apply
meaning
to
the
input.
A
The
attributes
that
are
coming
in
it
needs
to
know
that
that
input
is
a
pod
spec
or
a
deployment
or
an
API
or
attributes
representing
an
API
request,
and
similarly,
the
service
needs
to
know
how
to
interpret
the
result,
meaning
like
true
maps,
to
allow
and
false
maps
to
deny,
but
on
its
own
OPA,
doesn't
really
care.
All
it
sees
is
JSON
coming
in
JSON
being
evaluated
and
JSON
going
back.
A
A
Ok,
so
what
I'm
gonna
do
here
is
switch
over
to
my
BS
code.
Ide
and
I
have
a
policy
here
that
I've
written
in
opus
policy
language.
So
this
is
an
example
of
a
policy
written
in
Rago,
which
is
a
purpose-built
declarative
language
for
answering
the
kinds
of
questions
that
you
have
to
address
all
the
time
when
you're
working
with
policy.
A
So
the
way
that
you
can
kind
of
understand,
this
first
rule
is
as
follows.
So
allow
is
true
if
input
method
matches
get
an
input,
path,
matches
accounts,
user,
name
and
input.
Subject:
user
matches
user
name.
So
in
order
for
allowed
to
be
true,
all
of
the
statements
in
the
body
need
to
be
true.
Okay,
so
opens
gonna
basically
and
those
expressions
together
in
order
to
decide
whether
or
not
the
request
should
be
allowed.
The
second
rule
is
is
similar.
A
It
says,
allow
is
true
if
input
method
matches,
get
an
input,
path,
matches
accounts,
user,
name
and
input.
Subject,
groups
contains
customer
service
and
input.
Subject:
user
matches
tickets
of
user
name
of
underscore
of
assignee
so
again
the
statements
and
the
bodies
of
the
rules
get
ANDed
together
and
then,
in
this
case,
if
either
of
the
allow
rules
were
true,
then
the
request
will
be
allowed.
If
neither
of
them
matched,
then
the
request
would
be
denied.
A
A
In
this
case,
what
that's
doing
is
it's
looking
up
context
that
would
be
cashed
inside
of
OPA.
That
represents
the
open
tickets
in
the
system,
and
so
I've
got
some
data
here,
some
JSON
data,
and
this
would
just
basically
be
loaded
into
OPA.
So
you
can
see
it's
just
JSON,
it's
organized
hierarchically.
It
basically
sets
up
a
mapping
of
users
to
open
tickets
for
those
users,
so
here,
in
this
case,
bob
has
two
open
tickets.
A
A
Okay,
now
one
of
the
nice
things
about
opus
policy
language
is
that
because
it's
written
in
this
declarative
fashion,
you
can
actually
just
query
it
and
you
can
dry
run
it
and
you
can
ask
questions
of
it
in
your
development
environment.
So,
for
example,
right
now,
I
can
just
select
the
allow
rule
and
evaluate
that
and
right
now,
it's
true.
The
reason
why
it's
true
is
because
I've
set
up
some
input,
data
to
use,
and
so
right
now,
I
have
basically
a
request
for
Bob's
account
on
behalf
of
Bob
right
and
so.
A
Allow
should
obviously
be
true
if
I
change
the
the
user
to
Alice
and
I
rerun
that
query
now
the
decision
is
false
right.
She
should
not
wait.
Oops
yeah
wait
a
second,
that's
not
what
I
was
expecting.
Oh
right,
because
I
don't
have
the
customer
service
group
on
our
subject.
Okay,
that
makes
sense
good,
but
you
can
also
select
other
parts
of
the
policy,
so
you
can
actually
select
just
arbitrary
parts
here.
A
So
if
I
said,
like
data
pets,
pet
store
tickets
and
I
evaluate
that
you
can
see
that
it
just
produces
the
value
that
open
would
see.
When
it's
evaluating
the
policy.
Now
you
can
do
even
further
than
that.
So
I
can
actually
just
select
parts
of
this
rule.
I
can
select
the
first
expression
in
the
first
rule
and
evaluate
that
and
sure
enough.
The
answer
is
true,
because
the
input
method
is
get
but
I
can
also
select
the
entire
rule
body
or
even
just
subsets
of
it.
A
A
So
there's
no
way
that
oppa
can
find
a
way
to
prove
that.
Allow
should
be
true
if
I
go
back
and
I
switch
this
to
Bob
and
I.
Really
again,
all
three
statements
are
true
and
that's
why
it
would
be
allowed
okay.
So
how
do
you
actually
integrate
with
overwrite?
This
is
great.
This
is
like
a
development
environment,
but
how
do
you
actually
use
oppa?
A
So
what
I
have
here
is
a
simple
program
written
and
go,
and
I'm
gonna
show
how
how
you
can
kind
of
integrate
oppa
as
a
library.
So
if
I
run
this
program
right
now,
it's
just
waiting
for.
Oh
it
actually
is
gonna
complain.
It's
gonna
say
that
it
needs
some
bundle
and
within
open.
We
have
this
concept
of
a
bundle.
A
A
So
it's
waiting
for
me
to
give
it
some
input,
and
so,
if
I
just
type
garbage,
it's
gonna
complain
that
it's
not
valid
json,
but
if
I
give
it
like
the
number
10,
which
is
a
valid
json
value,
it's
gonna
evaluate
the
policy
with
the
number
10
assigned
to
input,
and
so
obviously,
in
that
case
the
policy
does
the
decision
is
deny
right,
there's
no
way
that
the
number
10
can
satisfy
all
of
those
constraints
in
those
rules,
but
I
actually
have
some
other
inputs
here.
That
are
a
little
bit
more
interesting.
A
So
this
is
a
person
request
from
Alice
for
Janet's
account
right,
she's
not
assigned
a
ticket
for
Janet,
and
in
this
case
it's
missing
the
customer
service
group,
so
it
would
get
denied
for
that
reason
as
well,
but
just
to
drive
the
point
home
in
that
case
it
gets
denied.
So
how
does
this
actually
work?
Well,
it's
not
that
complicated.
A
Actually,
so,
when
you're
embedding
open
as
a
what
you're
doing
is
you're
interacting
with
this,
this
Rago
package
that
it
exposes
so
Rago
is
the
language
and
it's
a
high
level
api
that
you
used
to
evaluate
policies,
and
so
what
this
programs
going
to
do
is
it's
going
to
load
the
bundle
off
disk,
it's
gonna,
instantiate,
opus,
compiler
and
storage
layer.
These
are
like
data
structures
that
are
used
during
the
evaluation
process
and
then
it's
going
to
decode
the
input
that
I
provided
over
standard
in
and
then
it's
gonna
construct.
A
This
Rago
object,
that's
gonna
get
used
for
evaluation,
and
so,
when
you
construct
the
Rago
object,
you
pass
in
things
like
the
compiler
and
the
store
and
the
input.
And
then
you
also
provide
the
query
that
you
want
to
run
so
in
this
case
we're
asking
for
the
value
of
allow
and
we're
binding
it
to
a
variable
called
allowed.
A
Now
there
are
other
inputs
that
you
can
bribed.
You
can
provide
things
for
like
tracing
and
profiling
and
metrics
and
so
on
and
instrumentation,
but
in
this
case
we're
just
basically
providing
the
the
core
necessities.
And
so
then
you
run
evaluation
and
you
interpret
the
result,
and
so
in
this
case,
if
there
were
no
results,
if
the
policy
decision
was
undefined,
we
would
just
bail
out,
we
would
say,
there's
there's
an
error.
The
reason
for
that
is
because,
in
this
case,
we've
said
that
the
default
value
for
allow
is
false
right.
A
So
if
there's
no
other
value,
that's
coming
back
from
one
of
these
rules,
it
should
use
fault,
it
should
send
back
false,
and
so
if
there
are
no
answers
coming
back,
then
that's
it.
That's
an
error.
You'd
rely
with
like
a
500
or
something
like
that,
but
otherwise
you
just
look
at
the
value
of
the
allowed
variable,
and
so,
if
it's
true,
you
interpret
that
as
allow.
If
it's
false,
you
interpret
that
as
deny
okay.
A
Oh
it's
complaining
about
the
fact
that
I've
got
duplicates
because
I
had
that
bundle
created.
So
if
I
run
that
again,
you
can
see
that
the
tests
are
passing
right
now,
which
is
great,
but
you
can
go
further
than
that.
You
can
actually
tell
what
parts
of
your
policy
are
being
hit
by
these
tests.
So
if
you
run
you
can
compute
the
coverage
and
have
that
visualized.
A
A
If
I
go
back
into
the
policy
and
say
I
disabled,
the
the
part
that's
based
on
context
based
on
the
tickets
and
I,
save
that
and
rerun
it
now,
you
can
see
that
we're
never
actually
exercising
the
second
rule
fully
right,
so
we
never
made
it
to
the
last
line
on
the
policy
right.
So
with
OPA.
You
know
you
can
use
the
policies
in
every
ways
right.
You
can
obviously
use
them
at
enforcement
time,
but
you
can
also
dry
run
them.
A
So
the
first
use
case
that
we
started
looking
into
earlier
this
year
is
around
data
filtering,
so
suppose
that
the
pets
comm
business
is
doing
great
and
we
want
to
expand
to
help
you.
You
know,
keep
track
of
your
pets
right
now,
keep
talking
of
their
health
right.
So
we
create
a
service
that
that
stores.
A
So
whenever
you
ask,
for
you
know
the
pets
that
you
you
know
should
see
the
pet
details
service
is
gonna,
go
and
actually
get
a
query
against
its
database.
It's
gonna
select
star
from
pets
and
that's
gonna
return,
a
bunch
of
records
that
go
back
that
ultimately
go
back
by
the
API,
and
so
the
question
becomes
what,
if
we
want
to
enforce
a
policy
that
says
that
veterinarians
are
only
allowed
to
see
the
details
of
pets
that
they're
treating
right,
that
information
about
which
veterinarians
are
treating
which
pets
is
not
contained
in
the
request
right.
A
So
it's
not
readily
available
when
the
pet
details
service
would
execute
the
policy
query
right.
We
could
change
the
pet
details
service
to
call
out
to
the
database
and
get
the
data
and
then
pass
it
in
the
input
or
we
could
try
to
replicate
the
data
from
the
database
into
oppa,
but
when
you
start
doing
that
at
a
large
scale,
you're
gonna
find
that
there
are
certain
challenges
around
performance
and
scalability
that
are
hard
to
overcome.
A
A
The
problem
is
that
at
this
point,
the
logic
that
decides
whether
or
not
you're
allowed
to
see
a
row
in
the
database
is
now
hard-coded
into
the
pet
details
service
right,
and
so,
if
we
want
to
change
this
policy
in
any
way,
we
have
to
go
into
that
service
and
understand
it
at
a
very
fundamental
level.
In
order
to
do
anything,
and
so
what
you
really
want
to
be
able
to
do
is
control
that
query
that's
running
through
policy
right,
because
that
way
we
don't
have
to
replicate
all
the
data
into
OPA.
A
A
So,
for
example,
this
is
a
little
sample
app
that
we
have
it's
the
sample
app
for
the
pet
clinic
that
pet
calm
is
trialing,
and
so
you
can
see
that
right
now
we're
logged
in,
but
we
can
see
or
we're
not
logged
in
rather,
and
we
can
see
all
the
pets
right,
so
we
can
see
Bob's
pets
and
and
Liz's
pets
and
and
John's
pet
and
so
on,
and
even
if
we
log
in
right
now
it
doesn't
really
change
anything
we're
logged
in
this
Bob.
We
can
see
everything.
A
The
reason
why
that's
the
case
is
because
the
policy
here
hasn't
put
any
constraints
over
the
data
that
can
be
returned
to
the
user.
It's
just
saying
that
basically,
any
pet
can
be
returned
to
any
user,
and
so,
if
we
wanted
to
restrict
this
return
value
to
say
that
you
know
you
can
only
see
pets
that
you
own.
We
would
add
a
condition
into
this
policy,
so
we
would
say
that
the
pet
clinic,
the
clinic
for
the
pet
must
match,
or
rather
the
owner
of
the
pet
must
match
the
user
in
the
request.
A
And
now,
if
we
refresh
the
page,
you
can
see
that
we're
only
seeing
the
valid
the
pets
for
Bob
right,
and
so,
if
we
go
in
and
we
log
in
as
Liz,
we
see
her
pets.
If
we
log
in
as
John,
we
see
his
pets,
okay.
So
this
is
a
super
simple
example
of
a
policy
that
just
says
that
you
know
you
should
be
allowed
to
see
the
pets
that
you
own.
But
what
about
the
veterinarians
right?
A
If
I
log
in
as
Alice
here,
she
can't
see
anything
and
so
in
order
to
get
Alice
access
to
the
data.
What
we're
gonna
do
is
add
another
rule,
so
we're
gonna
say
that
data
pets
can
be
displayed
if
the
pet
veterinarian
hopefully
I
can
spell.
This
correctly
is
equal
to
the
subject
user
and
now,
if
I
save,
that
and
refresh
you
can
see
that
alice
is
able
to
see
the
pets
that
she's
treating
similarly
teri.
The
other
veterinarian
is
able
to
see
the
pets,
the
she's,
treating
right.
A
But
what
if
we
want
to
go
further
than
this?
What
if
we
want
to
say
that
you
know
you
should
only
be
pets
that
you're
treating
at
the
clinic
that
you're
working
at
right?
Well,
you
just
extend
the
policy
with
another
condition
that
says
that
the
pet
clinic
must
be
equal
to
the
location
that
was,
you
know,
determined
when
the
user
authenticated,
for
example,
right
and
so
now,
if
we
sign
back
in
as
Alice,
she
can
only
see
the
pets
at
shady
bluffs,
where
she's
currently
signed
in
okay.
So.
A
That's
data
filtering
with,
though,
but
the
way
this
works
is
slightly
different
from
the
other
examples
that
I
showed.
So
when
the
pet
detail
Service
receives
the
the
incoming
API
request,
it's
still
queries
OVA.
It
still
supplies
a
bunch
of
attributes,
but
now,
instead
of
replying
with
just
simply
true
or
false,
what
OPA
does?
A
So
this
is
a
quick
example
of
how
this
is
how
this
works.
We
have
a
blog
for
the
project.
There's
a
post
on.
There
called
write
policy
and
OPA
enforce
policy
in
SQL.
If
you're
interested
in
these
kind
of
data
filtering
use
cases,
I
recommend
that
you
take
a
look
at
that
and
if
you
have
ideas
about
how
this
can
be
used-
or
you
know
your
feedback
we'd
love
to
hear
it
and
we'd
love
to
talk
with
you.
A
Okay,
the
last
thing
that
I
want
to
talk
about
is
something
that
I'm
super
excited
about,
which
is
OPA
and
web
assembly.
So
I
don't
know
how
many
people
here
are
familiar
with
web
assembly,
but
I'll
just
give
it
kind
of
a
really
quick
overview.
So
web
assembly
is
basically
a
binary
instruction
format
for
building.
You
know
stack
based
virtual
machines,
so,
just
like
you
know,
x86
assembly
exists
and
you
can
compile
C
and
C++
down
to
x86
and
run
it.
A
Organizations
makes
it
kind
of
this
open
platform,
and
so
there
are
all
these
non
web
and
beddings
that
they
call
it,
as
so
called
non
web
embeddings
like
iot
and
dust
and
servers
and
even
blockchain.
But
what
I'm
mainly
interested
in
is
how
webassembly
can
be
applied
to
this
problem
of
policy
enforcement,
and
you
know
servers
and
data
centers
and
so
on.
So
what
does
webassembly
have
to
do
with
OPA?
Well,
you
know.
A
Over
the
last
three
years
we've
found
certain
things
after
talking
to
a
large
number
people
that
are
using
OPA
and
one
of
those
things
is
that
library
integrations
can
often
be
a
lot
simpler
right
as
opposed
to
having
to
stand
up
a
separate
daemon
in
the
system.
The
library
integrations
have
a
little
bit
you
a
little
bit
more
control
with
a
library
integration.
You
know,
there's
less
overhead,
there's
fewer
context,
switches,
there's
less
copies
happening,
so
it's
more
performant
there's
a
little
bit
less
operational
complexity.
A
You
don't
have
to
worry
about
securing
this
daemon,
that's
running
on
every
machine.
You
don't
have
to
necessarily
worry
about
monitoring
and
so
on
so
or
as
much
so
having
the
ability
to
you
know,
evaluate
open
policies
via
a
librarian.
Edition
is
compelling
for
a
lot
of
people
and
webassembly
will
make
this
possible
because
today
opens
written
and
go
so.
It's
only
really
embeddable
as
a
library
and
go
applications,
but
with
webassembly
runtimes
popping
up
in
go
and
rust,
and
obviously
you
know
VA
and
other
popular
engines.
A
It's
likely
that
you'll
be
able
to
embed
web
assembly
in
any
language
in
the
near
future.
The
other
aspect
is
that
some
platforms
are
unlikely
to
necessarily
embed
open
runtimes,
but
they
are
likely
to
embed
web
assembly
runtimes.
So,
for
example,
CloudFlare
recently
announced
that
they
would
support
web
assembly
executables
on
their
workers.
So
you
can
take
web
assembly,
you
can
you
can
compile
code
down
to
web
assembly
and
then
distribute
it
out
to
the
edge
to
the
points
of
presence
the
cloud
floor
has
and
have
it
run.
A
You
know
very
close
to
your
customers
right
on
voice.
The
service
proxy
is
also
considering
adding
you
know.
Web
assembly
support
to
the
service
proxy
right
and
so
I
think
that
web
assembly
is
it's
super
interesting
and
it
kind
of
might
help
answer
the
question
of
how
do
I
enforce
policies
in
a
server,
less
or
edge
computing
environment,
and
so
we
actually
have
an
initial
version
of
this
working
today
you
can
compile
down
a
fragment
of
the
language
today
and
so
the
right
terminal
yep.
A
A
You
know
an
access
control
list
effectively
on
a
HTTP
API
and
what
I
can
do
now
is
I,
can
compile
this
down
into
web
assembly,
so
I'm
going
to
pass
in
the
policy
and
I'm
gonna
pass
in
a
query
to
run
in
this
case,
I
want
to
check
whether
allow
is
true
and
what
that's
gonna
do
is
emit
a
webassembly
binary.
So
you
can
see
it's
just
created
this
policy
dot
wasum
file
on
disk
and
now
I
can
load
that
up
into
a
node.js
app.
A
So
I
have
this
note
app
here
and
if
I
run
this
with,
like
the
value
1,
it's
gonna
basically
load
the
the
policy
off
disk
initialize
the
web
assembly
address
space
and
then
evaluate
the
policy,
and
in
this
case
the
value
1
gets
denied.
But
if
I
pass
in
the
value
you
know
get
and
path
trades
that
should
be
allowed
right.
But
similarly,
if
I
try
to
post
and
I'm,
not
an
admin,
then
I'll
be
denied
all
right.
So
I
think
this
is
super
cool,
because
the
integration
is
really
simple
for
the
app
right.
A
So
there's
a
bit
of
boilerplate
here
just
ignore
that.
Basically,
the
way
this
works
is
that
you
instantiate
the
web
assembly
address
space.
You
can
give
it
a
size,
so
you
can
put
a
bound
on
the
actual
amount
of
memory
that
the
policy
evaluation
can
consume
and
then
you
and
you
blowed
the
policy
off
disk
or
off
the
off
the
wire
and
evaluate
it
right,
and
so
here,
I'm
just
parsing
the
JSON
input
and
then
interpreting
the
output.
A
There's
not
too
much
interesting
about
the
actual
evaluation,
there's
a
little
bit
of
setup
that
has
to
happen
on
the
address
space.
But
after
that,
it's
it's
pretty
straightforward.
So
this
is
obviously
proof
of
concept.
We
would
probably
wrap
this
in
an
SDK
or
something
like
that
or
a
library
that
presents
a
little
bit
of
a
higher-level
interface.
But
this
gives
you
a
sense
of
how
this
how
this
works,
cool.
A
So
that's
it.
Thank
you
very
much.
If
you're
interested
in
the
project
check
out
the
slack
organization,
we
have
about
450
people
on
there
check
it
out
on
github
start
the
project.
We
love,
we
love
more
stars.
I'm
gonna
push
all
of
the
code
from
this
talk
up
to
github
later
today
and
if
you're
interested
in
contributing
please
come,
say
hello,
I'd
love
to
chat.
A
If
you
want
to
contribute,
integrations
or
tooling
or
work
on
the
core
part
of
the
language,
I'd
love
to
chat
with
you,
we
also
have
tickets
that
are
assigned,
or
that
have
labels
like
low-hanging
fruit
that
are
super
easy
to
get
started
with
or
Help
Wanted.
Some
of
those
are
little
bit
bigger,
but
yeah.
Thank
you
very
much.