►
From YouTube: CNCF SIG-Security Meeting - 2018-02-23
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
Open Policy Agent
A
A
Morning
and
sometimes
the
audio
gets
lost,
so
if
you
haven't
checked
in
the
docs,
please
add
yourself
to
the
box.
Looking
for
two
individuals
really
did
not
do
a
good
job
at
sort
of
capturing
notes
last
last
session
and
apologize
for
that.
So
looking
forward
for
two
volunteers
to
focus
on
on
minutes
capturing
some
minutes,
especially
you
know
as
we're
getting
these
use
cases
I
want
to
make
sure
we
capture
the
questions
and
answers,
since
theirs
will
be
three
key
things
that
will
help
us
build
our
case.
A
Turn
are
you
presenting
it
who's,
presenting
on
your
side.
A
C
A
C
A
A
So
for
everyone's
logging
on
you
know,
I've
got
in
the
chat.
The
meeting
notes,
please
add
yourself.
A
A
Great,
thank
you
appreciate,
then,
could
I
get
someone
else
to
help
support
toward
one
more
volunteer.
D
A
That
was
a
great
discussion
and
you
know
really
insightful
to
you
know
get
that
context,
and
you
know
we
had
a
number
of
folks
who
who've
had
the
opportunity
to
collaborate
with
OPA,
and
so
we
wanted
to
take
the
full
session
today
to
you
know,
go
through
the
the
use
cases,
and
your
hear
a
bit
about
of
the
the
journey
is
that
the
team
behind
OPA
has
been
going
through
and
you'll
go
through
some
some
questions
and
answers
today
so
forget
to
who's
got
Tim.
Does
that
that
you
have
slides
up
sorry,
yeah.
B
C
Thanks,
so
so
what
I
thought
I'd
do
is
spend
a
few
minutes
just
give
you
a
quick
overview
of
OPA
and
sort
of
setting
the
stage
there
and
then,
and
then
talking
just
a
little
bit
about
the
process.
That
journey
is
you
say
that
we've
gone
through
and
then
and
then
diving
into
the
use
cases?
Obviously
that's
neither
the
discussion,
but
I
thought
we
should
set
the
stage
of
effort
and-
and
so
the
first
thing
that
that
I
think
the
dimension
is
just
sort
of
the
goal
of
Oakland
right.
C
The
goal
logo
has
always
been
to
make
it
easy
to
add
rich
policy
support
to
other
projects
and
services.
Right,
that's
been
the
goal,
I
think
of
oppa's
sort
of
like
a
library
in
that
sense,
but
but
the
idea
is
really
that
you've
got
like,
as
this
picture
shows.
What
we
expect
to
happen
have
happened
is
that
OPA
is
running
in
a
bunch
of
different
places,
and
you
know
those
oppa's
are
integrated
with
different
kinds
of
systems,
like
maybe
in
the
micro
service
space.
C
You've
integrated
opal,
with
all
the
different
micro
services
that
are
running
or
maybe
you're,
integrating
open
to
different
components
of
kubernetes
or
into
Linux
or
into
all
kinds
of
different
laces
and
we'll
go
into
what
some
of
those
use
cases
are
and
what
people
have
found
open
useful
for.
But
then
the
idea
is
that
we
want
to
make
opal
really
easy
to
use
and
take
some
zero
runtime
dependencies.
C
It's
always
been
one
of
the
goals
to
make
it
very
easy
to
integrate
very
easy
to
deploy,
and
then
the
idea
behind
Noah
is
that
is
really
intended
to
be
something
that
can
make
policy
decisions
for
something
running
right
next
to
it
right.
So
we
like
to
think
of
this
as
like
a
host
local
kind
of
daemon.
That
knows
how
to
make
authorization
or
more
generally,
policy
decisions
for
anything
that's
running
on
that
host,
but
the
goal
of
hope
is
never
to
has
never
been
to
be
a
service.
It's
never.
C
It's
always
just
designed
to
be
basically
a
library
or
something
that
answers
answers,
questions
form,
services,
they're
sitting
on
the
hosts
and
so
sort
of
the
sort
of
management
of
how
you
integrate
and
deal
with,
multiple
opis
has
always
been,
and
out
of
scope
for
Oakland,
so
I
think
you
know
from
my
understanding
of
what
safe
is
is
designing
to
do.
This
seems
like
a
natural
fit
for
for
safe
all
right,
so
I
think
that
was
the
the
goal.
I
will
say
also
get
to
use.
Some
of
this.
C
Everybody
here
knows
roughly
what
the
policy
problem
is.
I'm
assuming,
and
so
one
of
the
things
that
OPA
does
provide
is
declared
language.
Those
designed
to
work
fundamentally
with
JSON
data,
we'll
see
some
examples.
In
these
cases
there
I
already
went
through
this.
It's
the
library
daemon,
it's
all
ready
to
go.
So
if
you
want
to
integrate
as
a
library,
you've,
gotta
use,
you've
got
to
have
your
system,
your
service
written,
go
all
all
storage
of
data
and
policy.
C
All
of
that
is
done
in
memory
right
and
so
on,
and
so
having
a
management
piece
that
is,
is
capable
of
actually
feeding
opah.
Those
policies
and
any
data
it
needs
is
valuable
there.
Now
we've
done
a
bunch
of
work
around
tooling
as
well.
So
has
you
know
a
repple,
an
environment
where
you
can
go
into
and
run
and
ask
for
the
results
of
the
evaluating
ad-hoc
queries
or
just
running
the
the
policy
even
without
having
deployed
it.
C
There's
a
test
framework
for
writing
unit
tests,
there's
tracing
to
do
the
bug,
ability
and
we're
working
on
some
profiling
stuff
to
look
at
performance.
We
are
working
on
a
standard
library
as
well,
so
that
you
don't
have
to
write
policies
from
scratch
to
go
when
you
pull
them
in
and
and
immediately
you're
up
and
running,
without
even
necessarily
having
to
write
policy
and
then
what.
C
Good
all
right,
I'll
keep
I'll,
keep
hammering
away
okay,
so
the
conceptually
the
way
that
opal
works.
Is
that
remember
the
goal
of
opus
to
add
policy
support
to
an
existing
project
or
service,
and
so
here
we
have
sort
of
a
pictorial
representation
of
that.
So
we
have
some
service.
It
doesn't
matter
what
it
is.
Maybe
it's
a
micro
service,
maybe
it's
kubernetes,
maybe
it's
Kafka
and
then
what
you
do.
Is
you
there's
an
API
that
open
exposes,
so
the
that
service
can
ask
for
policy
decisions
for
enforcement
decisions.
C
So
the
idea
is
that
the
service
anytime,
it
needs
an
authorization
decision
it
just.
It
opens
up
a
simple
HTTP
request
and
asks
OPA
for
that
decision
independently.
There's
a
management
API,
that's
used
for
OPA
and
through
that
API
you
actually
provide
OPA
with
two
different
conceptual
pieces
of
information.
One
is
logic.
This
is
sort
of
like
the
policy
that
you
would
expect
right,
allow
this
user
to
run
this
API
call
under
these
conditions.
C
So
in
the
kubernetes
case,
this
might
be,
although
all
the
pods
that
exist
or
in
the
in
the
micro
service
case
may
be,
the
data
is,
you
know
something
like
your
org
chart
so
that
you
know
who's
a
manager
of
whom
all
right,
and
so
these
are
the
two
kinds
of
api's
that
open
exposes
the
in
particular
they're,
both
sort
of
initiated
by
by
things
outside
of
Okla.
So
today
the
service
is
the
thing
that
initiates
the
the
request.
C
What
we've
done
is
there's
a
there's,
a
sidecar
that
runs
next
to
OPA,
that
that
goes
and
pulls
policies
out
of
the
kubernetes
api
server
and
pushes
them
into
OPA,
and
likewise
that
Coupe
sidecar
will
go
off
and
grab.
Let's
say
all
of
the
pods
that
are
currently
running
the
API
server
and
push
that
as
data
into
into
oppa,
and
so
that's
sort
of
the
you
know
the
division
that
we
saw
earlier,
which
is
that
oppa
is
really
intended
to
be
this
post
local
policy
engine
that
makes
decisions.
B
C
Oh
not
today,
not
today,
we
could
certainly
we-
and
in
fact
Turin
did,
did
translation
of
he
had
a
collection
of
our
Bach
policies
and
showed
how
you
could
ride
him
in
oppa.
We
didn't
automate
that
it's
all
a
torn
said,
but
but
yeah
we've
definitely
talked
about
having
that
kind
of
functionality
where
you
could
take
an
existing
policy
language
and
then
sort
of
compile
it
down
into
into
opus,
but
what
the
but
what
we
did
do
or
what
what
exists
is
called
the
coop
management.
C
It's
in
the
coop
management
repo
within
the
open
policy
agent
goetaborg.
What
that
actually
does
is,
that
is,
it
pulls
over
policies
out
of
a
conflict
map
inside
of
kubernetes
and
then
pushes
them
into
OPA.
So
the
way
that
you
sort
of
use
OPA
for
at
least
the
kubernetes
for
at
least
a
couple
of
companies
use
cases-
is
that
you
write
your
coffee.
You
push
it
in
as
conflict
maps.
Okay,.
C
Okay,
so
I
mentioned
the
EPI
is
in
the
last
slide
and
so
I
figured
especially
given
some
of
the
interests
of
this
group.
It
was
worth
spending
a
couple
minutes
just
talking
about
what
what
API
is
OPA
supports
today,
to
give
you
a
better
feel
for
this.
So
really
there
are
two
kinds
of
API.
Is
it
open
supports
here
on
the
top?
C
So
those
are
the
first
four
api's
and
then
the
fifth
api
is
really
the
one
that
asks
for
a
policy
decision
right
and
here
the
idea
is
just
basically
open
up
a
get
request,
and
so
all
the
the
service
needs
to
do
is
run
a
get
request
on
on
basically
a
URL.
That
means
the
policy
that
they
want
the
decision
from
okay,
and
so
it's
it's
really
pretty
much
that
simple
in
terms
of
the
API.
C
The
one
thing
I'll
mention
here
that
that
that's
noteworthy
in
this
sort
of
REST
API
space
is
that
all
of
the
policies
and
all
of
the
data
are
registered
at
human,
readable
path.
Names
so
like
when
you
create
a
policy
even
created
at
foo,
slash
bar
slash
baths
in
the
API,
and
then
that's
reflected
in
the
in
the
policy
language
as
well.
The
same
is
true
of
data.
C
You
can
register
data
whatever
whatever
path
you
like
and
then
decisions
are
also
named
via
path,
so
you
could
ask
for
a
decision
which
is,
like
you
know,
decisions,
flash,
flash,
microservice,
slash
app
a
and
then
you
get
the
decisions
that
are
for
the
policy.
That's
registered
at
that
point.
Any
any
questions
there.
C
C
C
John
so
mentioned
that
we
have
been
asked
a
couple
of
times
to
add
enough
functionality
inside
of
OPA
to
actually
do
that
kind
of
validation
in
the
policy
itself,
and
then
the
policy
language
itself
today
already
has
enough
control
to
be
able
to
like
inspect
the
intervals
of
the
job
token,
to
make
policy
decisions
using
the
information
contained
within
that.
How.
C
C
You
want
it
like
it
encrypt
the
traffic
like
Kim
said
you
can
configure
OPA
with
error
tokens
for
authentication
and
then
obviously
it
would
not
be
complete
if
you
couldn't
write
authorization
policy
over
the
open.
It
guides
themselves.
So
you
can
do
that
as
well.
So
you
have,
you
know:
support
of
TLS
authentication
and
authorization
ATO
itself,
and
then
some
people
have
been
asking
about
support
for,
like
usual
TLS
authentication
when
target
opens
that's
sort
of
on
the
roadmap.
Thank.
D
C
Okay,
so
yeah
it
felt
like
before
this
kind
of
topic.
It
was
worth
spending
one
minute
talking
about
the
journey
that
we've
taken
to
get
here
and
where
we
are-
and
so
you
know
we
started
hopefully
two
years
ago
and
sixteen,
and
we
spent
basically
the
first
year
building
a
basic
OPA,
the
language,
the
API
and
so
forth.
C
Looking
at
performance
and
then,
of
course,
continuing
to
solve
real
world
problems
right
and
building
community,
so
what
we
thought
we
would
do
for
the
rest
of
the
talk
is
just
go
through
some
of
the
use
cases
that
we
that
we've
used
okhla
to
solve
from-from
different
places,
all
right
all
right.
So
here's
our
here's,
our
picture
of
the
the
classes
of
different
use
cases
that
we've
used
with
that
we
solved
with
OPA
and
and
so
we're
gonna,
go
through
I.
Think
most
of
these
I'll
just
highlight
them.
C
C
We've
done
integrations
with
OPA
the
sort
of
public
cloud
layer
with
with
terraform
to
do
some
risk
management.
We've
done.
We
solved
these
cases
with
OPA
at
the
micro
service,
api
layer
as
well
that
that's
been
pretty
public
around
we've
been
probably
most
public
around
that
with
Netflix
in
this
do
and
then
we've
recently,
we
started
getting
into,
or
necessarily
but
users
who
started
using
OPA
to
do
some
data
protection
stuff
in
this
sort
of
Kafka,
open,
STS
and
Mineo
space.
C
The
interesting
thing
I
did
spend
some
time
for
this
meeting,
trying
to
think
through
some
of
the
different
dimensions
that
we
think
about
when
we're
looking
at
a
new
use
case,
and-
and
so
we
thought
that
this
would
be
valuable
for
this
for
this
group
just
because
it
this
does
sort
of
highlight
some
of
the
different
things
that
you
need
to
think
about
when
you're
thinking
about
a
use
case.
At
least,
at
least
in
our
experience,
that's
the
case,
so
I'll
just
run
through
these
one
at
a
time
and
then
very
quickly.
C
One
is
just
sort
of
basic
policy
like
what
kind
of
policy
were
even
writing,
and
obviously
this
is
really
interesting
from
an
oak
LaPoint
of
view,
because
it's
you
know,
openness,
fundamentally,
a
language
and
so
understanding
what
kinds
of
policy
what
kind
this
requirements
are
needed.
It
is
an
important
property
of
any
use
case.
The
second
thing
is
data
in
context,
and
this
is
typically,
you
know
from
open
point
of
view.
Data
represents
kind
of
what's
going
on
in
the
world
and
so
sometimes
I'm
going
to
make
policy
decisions.
C
You
need
information
that
the
requester
does
not
provide,
for
example,
in
the
micro
servers
API
case.
If
you
want
to
authorize
an
API
server,
I
start
an
API
request.
You
may
need
to
know
whether
the
user-
that's
making
that
request,
is
a
manager
in
the
organization
right
and
that
management
information
is
not
always
something
that
comes
in
as
part
of
the
request.
So
what
data
in
context
you
need
to
actually
make
decisions
is
valuable.
The
third
thing
here
is
what
what
does
this?
What
do
the
decisions?
Look
like
you
know,
classically
with
authorization
policies.
C
The
decision
is
always
true/false.
It's
loud
an
eye:
maybe
there
are
a
couple
of
others
like
not
applicable,
but
but
fundamentally
they're.
You
know
often
allow
deny,
and
one
of
the
things
that
we
built
into
OPA
from
their
very
early
days
was,
was
the
ability
to
make
decisions
that
were
not
just
allow
and
deny
States.
You
can
return
decisions
that
are
numbers,
for
example,
you
want
to
do
rate
limiting
or
strings
or
sets
or
even
dictionaries,
and
their
use
cases
throughout.
That
will
show
each
of
those.
The
next
thing
is
integration.
C
You
know
in
some
sense
you're
always
at
the
mercy
of
the
system
you're
trying
to
integrate
with
when
when
it
comes
to
actually
doing
the
integration.
So
so,
how
does
that
even
work?
And
that's
something
that
we
look
at
for
each
and
every
use
case?
And
it's
always
a
little
bit
different
policy
management's.
The
obvious
thing
that
we've
mentioned
earlier,
which
is
that
every
use
case,
at
least
for
OPA,
requires
a
potentially
a
different
kind
of
management
system
and
then
there's
performance.
It
turns
out
that
use
cases
can
vary
widely
in
terms
of
performance.
C
We've
got
some
use
cases
where
you
know.
Spending
10
seconds
to
make
a
policy
decision
is
fine.
Others
where
you
you
have
to
come
in
under
you,
know
a
millisecond
if
you're
going
to,
if
you're,
going
to
make
a
decision
and
then
finally
is
terribly
named
here,
unfortunately
mode,
but
here
the
idea
is
that
there
different
ways
of
actually
enforcing
policy
one
is
the
sort
of
obvious
one,
which
is
that
you
we
call
it
for
up
proactive
here,
which
is
that
you
stop
policy
violations
before
they
happen
right,
for
example,
you
don't
deploy.
C
You
don't
allow
a
pod
to
be
deployed
on
kubernetes
unless
the
policy
says
it's
okay
to
deploy,
but
there's
this
other
version,
which
is
what
we're
calling
reactive,
which
is
that
you
look
at
the
state
of
the
world,
and
you
say
here:
violations
of
policy
now
I'm
gonna
go
off
and
fix
them
right,
and
now
this
is
actually
more
common
than
you
would
think.
Like
imagine,
in
kubernetes
you
actually
change
your
policy
and
now
you've
got
a
bunch
of
pods
that
violated
that
policy.
C
Do
you
want
to
go
off
and
fix
them,
or
do
you
not
right?
The
third
kind
of
thing
here
is
audit,
so
here
the
idea
is
well,
let's
go
off
and
actually
just
identify
violations
and
then
use
them
and
then
plug
into
some
external
system
to
actually
let
people
know
that
they're
actually
violations
in
place
other
questions
or
comments
here,
oh
right
and
let
me
know
which
things
are
most
important
to
you.
A
How
like,
when
you're
in
that
your
decommissioning
state
of
pods,
you
know
how
easy
it
is.
Is
it
to
leave
those
things
behind?
Yeah,
that's
been
a
pain
point.
You
know,
I
haven't
experienced
that
in
kubernetes,
but
you
know
in
sort
of
other
orchestration
systems.
You
know
having
decommissions,
you
know
nodes
in
there
that
you
know
have
the
wrong
policy.
You
know
we've
put
in
one
of
those
things
where
you're
pulling
your
hair
out
you're
pulling
your
hair
out.
Oh
my
god,
and
like
we
thought
it
was.
C
So
you
can
just
ask
the
question
well
like
tell
me,
which
pods
and
knows
exists
that
that
shouldn't
right
and
then
you
can
even
stopwatches
that
you
know
stream
the
results
of
that
query
back
out
to
you
so
I
mean
so
I,
I,
guess,
I,
don't
know
how
to
answer
your
question
except
to
answer
it
with
the
way
opal
would
the
way
we
would
use
OPA
to
help
with
that
kind
of
problems.
Cool,
okay,
well,
I!
Guess,
as
we
go
sorry
go
ahead,
I'm.
C
E
C
Yeah
I
mean
obviously
the
you
know
their
standards.
Things
would
help
here
right,
like
so
like
having
a
fairly
simple
and
standard
way
to
ask
for
decisions.
I
guess
would
help
I
mean
it.
It
would
definitely
help
the
the
so
maybe
I
know
I
like
this
from
the
users
point
you
like,
which
is
it
as
a
user
I'd
like
to
have
a
consistent
way
of
managing
and
dealing
with
all
these
different
kinds
of
policy
systems.
C
What
I'd
really
like
those
to
be
able
to
reason
about
how
the
different
policies,
presumably
different
languages,
would
interact
with
each
other,
and
it's
not
clear
to
me
what
you
can
do
there
from
from
an
outside
like
if
we
treat
all
policy
languages
as
block
boxes.
It's
not
clear
to
me
what
you
can
do
there
other
than
to
have
other
than
that.
Maybe
surface
actual
policy
decisions
in
some
sort
of
format
that
you
know
some
tooling
to
come
along
later
and
and
sort
of
combine
them.
E
Well,
I
think
one
of
the
things
that,
like
survival,
hypothesis
that
you
know
like
so
that
generally
we're
all
kind
of
dealing
with
the
same
nouns
and
verbs
for
the
most
part,
sort
the
same
nouns
right.
So
there
might
be
some
certain
amount
of
where
we
say:
okay,
if
you're
develop
your
deploying
an
app
right
or
sir
or
microservice
and
you're
in
this
world
of
deploying
software
that
operates
with
other
software
via
you
know,
tcp/ip.
E
This
is
some
set
of
concerns
that
you
have
and
if
we
were
to
standardize
like
words
for
those
concerns
or
api's
to
query
you
know
or
something,
then
you
could
imagine
people
being
able
to
compare
equivalent
policies
right.
Obviously,
if
some
policy
system
has
capabilities
that
another
policy
system
doesn't
that's
one
thing
that
what
I
hear
from
people
who
have
these
heterogeneous
infrastructure
environments
is
they're.
You
know
they
want
to
do
something
as
simple
as
like
I
want
to
know
that
you
know
these.
These.
These
anta
points
aren't
open
to
the
world
and
I.
E
Can't
even
I
have
to
write
different
code
for
each
system
to
even
ask
very
simple
questions,
and
you
know
and
I
don't
know
whether
that's
you
know
what
what
form
that
takes.
But
I
think
that
we
have
this
dream
of,
like
you
say
like
having
tools
that
would
be
able
to
say.
Okay,
I
can
go
across
all
of
these
systems
and
without
writing,
something
that
is
custom
for
every
system.
C
We've
talked
about
this
in
the
past,
which
is
that
it
would
be
nice.
It
would
be
wonderful
if
there
were
some
ontology.
Some
schema
that
everyone
in
the
world
agreed
on
and
that,
like
represented
policy,
where
you
go
back
represented
all
the
mounds
in
the
you
know
in
this
landscape
that
we
see
here
and
I
think
what
I've
been
hesitant
to
try
to
go
down
that
road,
just
because
it
seems
it
feels
to
me
like
a
like
a
such
a
gigantic
undertaking
and
that
will
never
be
finished
and
so
what
I?
C
E
Yeah,
maybe
there's
models
for
that
out
there
in
the
world.
You
know
like
how
do
we
get
to
really
standard
mime
types
for
email
right,
like
there's
processes
that,
where
we've
done
this
on
the
internet
before
where
we
start
with
a
few
and
there's
ways
to
promote
something
to
be
what
everybody
uses
and
that
that's
that
could
be
an
exercise
for
the
working
group.
It's.
A
C
All
right,
maybe
I,
should
hang
on
actually
talk
about
some
use
case.
What
do
you
think?
Okay?
So
all
right,
so--okay,
the
first
one
we're
gonna
talk
about
here-
is
Kubb
and
I'll
just
kind
of
rattle
on
through
some
of
this
stuff
and
then
stop
me
with
questions.
I'll,
try
to
remember
ass,
but
if
I
don't
do
something,
okay,
so
kubernetes
we've
done.
C
Actually
a
number
we've
seen
actually
a
number
of
different
use
cases
actually
within
kubernetes
itself,
because
there
are
a
number
of
different
places
that
are
extensible
enough
to
support
a
policy
system,
and
so
you
know
at
one
point
we
have.
We
have
an
integration
with
the
Federation
control
plane.
So
here
the
problem,
the
policy
problem
is
really
given
a
new
workload,
tell
open
decide
which,
which
kubernetes
clusters
to
place
that
workload
on
right.
So
that's
the
use
case.
There
are
others
at
the
API
server
level,
around
authorization
and
admission
control.
C
Here
the
idea
is
somebody's
trying
to
create
a
new
pod
and
now
openings
decide
either
whether
to
allow
it
in
or
not,
or
that
we've
used
OPA
to
actually
define
the
mutations
that
need
to
happen
to
that
table
before
it's
before
it
slept
through
and
then
in
the
in
the
scheduler
we
did
a.
We
did
an
integration
there
as
well
to
actually
use
policy
to
control
effectively
which
to
filter
out
which
nodes
are
not
are
not
used
during
scheduling.
C
C
Let's
make
sure
that
all
the
images
in
this
pod
come
from
a
trusted
repository
like
if
we're
if
this
is
a
production
cluster,
so
those
are
just
some
of
the
the
use
cases
that
we've
seen
there.
Oh
here,
I
think
maybe
I'll
skip
through
this
I.
Don't
think
full
here
are
gonna
care
too
much
about
the
language.
I
will
mention,
though,
that
that
the
yeah
here,
the
the
input
that
comes
in
to
oppa
when
it
makes
a
decision,
is
this
gigantic
yeah
mo
things
shown
here
on
the
left
right.
C
C
C
C
All
right,
ok,
I,
just
check
the
time
we've
got
about
20
minutes
left
I
will
skip
reading
through
these
things.
I'll
just
pick
out
a
couple
highlights
in
terms
of
management,
we've
already
discussed
how
OPA
handles
management
was
in
kubernetes
right.
We
had
the
sidecar
that
pulls
policies
out
of
conflict
maps
and
pushes
kubernetes
data
into
OPA.
We
actually
have
looked
at
this
for
both
the
proactive
reactive
as
well
as
audit
perspectives.
C
So
the
idea
here
the
problem
that
we're
solving
is
that
you've
got
a
whole
collection
of
micro
services
that
are
doing
what
they
do
and
now
we
need
to
add
authorization
on
top
of
it
and
the
idea
being
here
that
each
and
every
API
call
that
a
micro
service
sees
is
something
that
it
sends
to
OPA
to
ask
for
an
authorization
decision
on
right
and
so
conceptually.
The
way
that
you
should
think
about
this
is
it.
C
There
are
different
ways
of
integrating
OPA
with
those
micro
services.
Some
some
is
right
from
top
to
bottom.
Some
folks
will
actually
just
do
a
direct
integration
with
OPA
or
what
we
just
released.
I
think
this
week
was
a
spring
integration,
where
even
the
developer
doesn't
even
know
that
OPA
is
being
used,
but
but
the
Java
framework
is
actually
made
taking
every
API
call
in
authorizing
OPA.
C
Some
folks
will
actually
embed
OPA
as
a
library
into
the
micro
service.
That's
the
second
one.
The
third
one
from
the
top
is
effectively
the
service
mesh
version,
where
you
run
next
to
your
micro
service,
a
sidecar
which
is
a
network
proxy
that
that
handles
all
the
network
traffic
and
then
what
we
do
is
an
integration
with
that
with
that
proxy,
so
that
that
proxy
actually
asks
Oprah
for
authorization.
C
Decisions
on
every
API
call
there's
another
version
in
the
sto
world,
where
okhla
was
integrated
into
mixer,
and
so
it
can
do
centralized
decisions
there
as
well,
and
then
the
last
one
here
I
think
we're
just
illustrating
the
fact
that
if
you've
got
multiple
micro
services
running
on
a
single
host,
they
can
all
use
the
same
OPA.
And
so
then,
here
the
interesting
bit
for
this
use
case
is
here
are
the
inputs
that
come
in
as
I
mentioned
earlier.
C
Looking
at
this
sort
of
the
dimensions
of
comparison
that
we
talked
about
earlier,
the
performance
on
this
one
is
crude,
is
critical
right.
So,
if
you're,
the
Netflix,
the
number
the
Netflix
came
out
with,
was
actually
twice
this,
so
two
thousand
requests
per
second
is
what
you
need,
and
then
at
least
for
them,
and
so
like.
C
Obviously,
the
and
I
guess
I
didn't
mentioned
this
previously,
but
in
kubernetes
the
the
number
was
more
like
a
second
right
or
a
tenth
of
a
second
something
like
that,
and
so
obviously
the
performance
demands
in
this
use
case
are
significantly
different,
but
in
so
consequently
they're
they're.
We
ended
up
adding
some
functionality
to
okhla
to
handle
these
really
mission-critical
performance,
critical
applications,
and-
and
so
that
was
just
something
that
we
needed
to
do.
C
C
B
C
Right
so
this
was
interesting,
so
this
has
come
up
several
times
in
the
last
couple
months
where
people
want
to
use
OPA
for
this,
for
this
particular
use
case.
But
what
they
want
to
do
is
sort
of
split
off.
Think
of
this,
as
maybe
a
service
graph
like
so
they've
got
some.
The
Amla
file
that
represents
a
service
graph
and
what
they
want
to
do
is
basically
treat
that
as
the
actual
policy.
And
then
what
happens
is
that
the
you
end
up
writing
a
little
bit
of
a
raid
array
goes
the
internal
open
language.
C
C
C
When
it
comes
to
management,
in
this
case,
Netflix
ended
up
rolling
their
own,
their
own
management
layer.
They,
you
know,
Netflix,
is
good
at
replicating.
State
and
policy
is
an
example
of
that,
so
they
rolled
their
own
and
I
know
is
I.
Don't
know
if
finishes
on
the
call
or
not.
I
saw
his
name
on
the
on
the
folks
in
the
working
group,
but
they
rolled
their
own.
C
C
All
right
we'll
keep
on
moving.
Then
then.
Another
use
case
that
was
interesting
here
is
in
sort
of
public
cloud
space,
and
this
one
is
really
focused
on
terraforming
in
using
terraform
to
manage
the
public
cloud
resources.
So
there
were
actually
kind
of
two
use
cases
that
came
out
here.
So
what
happened
was
that
there
really
two
cases
right,
so
one
of
which
is
you've,
got
an
application
developer
who
or
a
platform
engineer
who
wants
to
make
a
change
to
public
cloud
infrastructure,
so
they
go
in
to
terraform.
C
They
make
some
changes
to
the
file
and
then
and
then
they
want
to
go
ahead
and
apply
those
changes
and
so
what
it
was
Medallia.
So
what
Medallia
wanted
to
do
was
take
the
plan.
The
careful
produces
and
compute
a
risk
score
for
that
plan
and
then
decide
whether
or
not
that
users
authorised
to
make
that
change
all
by
himself
without
peer
review,
based
on
the
risk
score
of
the
plan,
as
well
as
based
on
how
senior
an
employee
base
alright.
C
So
if
you're
a
senior
platform
engineer,
then
your
risk
score
might
might
be
like
a
thousand
and
you
can
make
any
change
up
to
that
risk
score.
But
if
you're
a
junior
developer,
maybe
you're
only
authorized
to
automatically
execute
risk
scores
under
100
or
something
and
here
the
risk
score
that
they
came
up
with
was
based
on
the
the
networking
ports.
It's
you
open.
The
number
of
servers
are
you
deleted
and
so
on
and
so
forth.
C
So
this
is
it
we
didn't
convince
them
to
add
this
risks
or
policy
to
to
our
standard
library,
including
the
second
kind
of
use
case,
is
sort
of
the
back
end
of
that
which
is
once
you've
already
used
terraform
to
push
and
manage
your
public
cloud
resources.
How
do
you
know
that
people
are
only
using
terraform
to
actually
manage
that
infrastructure?
And
here
the
idea
was
that
what
I
did
was
they
took
I?
C
Think
AWS
I
took
the
AWS
the
state
of
a
double:
yes,
all
the
resources
in
it,
and
then
they
cut
the
turf
own
state
file,
which
represents
what
resources
terraform
knows
is
under
its
management.
It
you
toss
both
of
those
into
open.
Then
you
write
poverty
that
looks
for
differences
rights.
It's
a
show
me
a
resource
in
the
public
cloud
that
is
not
also
in
the
terraform
state
and
so
they're
using
that
for
for
audit
okay,
what
about
those
use
cases.
C
All
right,
maybe
the
ground
that
I
do
have
an
example
here
of
the
kind
of
input
that
would
come
in.
That
would
actually
ask
for,
in
this
case,
a
risk
score
for
this
particular
terraform
plan,
and
so
there
was
no
way
I'd
know
if
anything
to
have
seen
terraform
plans,
but
there's
no
way
I
could
actually
put
on
a
slide.
So
there's
a
whole
bunch
of
ellipses
here,
but
but
you
get
the
basic
idea
that
there
are.
C
C
Oh
here
I
broke
down
the
sort
of
to
terraform
use
cases
in
terms
of
these
dimensions
of
comparison
that
we
talked
about
performance
here
was
not
a
real
issue.
You
know
it's
it's
some
person
using
it
for
the
most
part,
so
it's
not
a
big
deal
and
then
obviously
here,
though,
the
policies
were
quite
sophisticated
in
terms
of
the
kinds
of
inputs
they
required
and
it
comes
and
in
terms
of
the
expressiveness
you
needed
to
actually
compute
a
risk.
Score
decision
was
a
number.
C
B
C
Moving
on,
then,
this
is
actually
a
recent
category
and
we
don't
have
as
much
data
here
but
but
recently,
folks
have
been
starting
to
use
OPA
to
do
data
protection.
Here,
we've
got
a
couple
of
examples:
open
SDS
Mineo
is
new
and
Kafka's
new.
So
all
those
so
in
fact
there's
so
I,
don't
have
a
ton
to
say
here
other
than
what
I
try
to
do
is
again
talk
through
the.
How
each
of
these
use
cases
of
course
correspond
to
those
those
early
dimensions
that
we
talked
about.
C
Oh
and
there's
another
one
here,
rate-limiting
that
I
didn't
have
on
the
that
I
didn't
have
on
the
graphic.
This
is
also
new,
so
for
the
rate
limiting
use
case,
the
idea
is
that
somebody
wants
to
set
up
policies
to
control
network
rate
limits,
and
so
we're
still
not
quite
sure
exactly
what
they're
what
they're
doing
there.
But
what
we
do
expect
is
that
the
performance
is
pretty
high
again.
C
This
is
sort
of
close
to
the
microservice
api
case
and
again
they're
doing
this
thing
that
the
tauren
talked
about,
and
I
guess
I
will
tune
to
to
where
they
they
have
a
GUI
or
a
Hamel
file
for
writing.
This
sort
of
the
core.
The
crux
of
the
policy
that
people
care
about
and
then
they're
effectively
treating
that
as
data
when
they
author
policy
in
Rago
here
are
obviously
the
decisions.
A
number
the
policy
management
we
know
is
gonna
be
custom.
C
D
I
have
a
basic
question:
I
mean
they're,
going
to
make
a
difference.
A
lot
of
use
cases
there
are
different
resources
outlined.
There
does
OPA
have
like
a
specific
schema
for
how
resources
are
identified,
and
you
know
like
basically
defined,
and
you
know
like
how
attributes
are
set
for
those
resources.
What
is
it
like?
Very
open-ended?
It's
like
a
JSON
data
file
that
gets
uploaded
and
then
me
give
emigrate
a
policy
on
back
yeah.
C
D
How
does
they
use
it?
Identity
itself
come
into
the
policy
decision
making
like
so
you
can
write
policies
where,
in
you
know,
like
you
have
example,
policies
where
you
have
a
user
right
for
which
that
policy
is
applicable,
but
in
in
a
real
life
use
case
like
how
would
how
does
the
user
context
flow
into
the
policy
like
a
typical
example
like
how
did
Netflix
to
it
or
in
the
communities
example.
D
C
So
the
the
standard
way
for
for
is
to
use
something
like
a
job
right,
so
I
mean
it's
sort
of
an
obvious
way
of
doing
this,
though
you
have
the
user
authenticate
through
a
jot,
and
then
you
pass
that
jaw
into
Opa.
Opa
does
have
support
special
support
for
jot,
so
you
can
go
and
inspect
the
internals
and
and
yeah,
and
then,
where
we've
had
a
couple
of
requests
to
actually
be
able
to
validate
tokens
within
the
policy.
So,
but
in
those
cases
we
haven't
sort
of
made
again
is
same
sort
of
questions.
C
The
first,
which
is
we,
don't
require
any
sort
of
authentication
scheme.
It's
pretty
open-ended
right
now,
so
you
can
pass
in
tokens
as
part
of
the
input
here.
Right.
Just
imagine
there's
another
field
in
this
input
document.
That's
like
called
token,
and
so,
and
so
in
that
sense,
we
sort
of
assume
that
the
the
the
user
has
solved
authentication
in
some
way
shape
or
form
and
that
they
have
a
trusted
decisions
from
open.
So
they
can
provide
that
user
and,
however,
they,
however
they
like
and
then
again
when
you're
writing
policy.
C
You
know
how
that
user
is
is
being
represent
so
so
like
in
case
of
spring,
for
example,
like
they
have
a
whole
way
of
representing
user
details
right,
and
so
we
just
take
that
that
object.
We
just
place,
send
it
into
open
as
JSON
right.
So
then
you
get
you
know.
You
know
whether
or
not
like
that
account
is
locked
or
like
whatever
the
attributes
are.
The
data
fine
I
like
the
stuff
there
on
the
principle
right,
but
they
already
have
a
schema
for
that.
So
we
don't.
C
C
No
coupling
between
OVA
and
these
these,
like
the
way
projects
choose
to
represent
their
right,
and
the
thing
I'll
add
to
that
is
that
you
know
one
of
the
you
sort
of
want
both
of
these
things
right.
What
you
really
like
is
to
have
a
canonical
way
of
writing
policy
over
these,
but
what
you'd
also
like
is
to
make
integration
super
simple,
so
that
you
can
turn
out
a
whole
bunch
of
these
things,
and
so
the
question
is:
how
do
you
achieve
both
right?
C
Because
if
you
couple
Oh
buzz
as
Torrance
said
and
then
to
the
actual
enforcement
point?
Well,
then,
you
got
to
change
a
note
buffer,
every
enforcement
point
that
doesn't
work
very
well,
so
we've
done
the
opposite,
which
is
say
well
we're
not
going
to
require
any
sort
of
schema
for
users
or
resources
and
opal
will
accept
any
sort
of
any
sort
of
JSON
data
as
input.
C
But
then
in
the
in
the
policy
language,
the
idea
is
its
expressive
enough
to
be
able
to
to
codify
schemas
or
oncology's
or
whatever
you
want
to
call
them
so
that
you
can
still
author
policy
at
this
sort
of
with
this
sort
of
canonical
Mounds
canonical
user
formats
or
whatever.
And
then
you
just
write
a
little
bit
of
policy
that
connects
whatever
format
that
data
comes
in
as
whether
it's
users
or
resources
or
whatever
into
that
canonical
schema.
C
So
what
we
do
is
we
sort
of
try
to
to
give
people
the
best
of
both
worlds,
make
the
integrations
especially
simple,
but
also
give
people
the
option
of
writing
sort
of
canonical
policies,
and
so
what
was
sort
of
missing?
There
is
sort
of
a
standard
library
that
says
well
for
a
spring
for
a
spring
integration.
Then
here's
how
you
map
the
spring
user
data
into
this
canonical
data
format
and
for
a
kubernetes
integration.
Here's
how
you
map
the
kubernetes
user
information
into
that
same
canonical
format,
and
we
we
support
that.
D
B
C
So
the
the
right
picture
in
your
head
is
that
there's
the
the
input
that
comes
in,
which
is
shown
here,
there's
the
data
that
you
can
load
from
any
data
source
from
any
kind
of
system
on
the
planet
and
then
there's
a
policy
of
course,
and
then
all
of
that
is
local
to
the
decision
and
then
fairly
recently,
we
added
the
capability
to
within
policy
go
and
make
an
HTTP
call
to
an
external
system.
Here
the
idea
is
the
use
case.
C
So,
for
example,
if
you
had
a
gigantic
database,
it
was
a
terabyte
large,
well
you're,
not
gonna
load,
that
into
OPA
and
and
if
what
you
know
is
that
on
every
policy,
I
only
need
to
make
a
single.
You
know:
I
only
need
to
check
up
a
single
row
exist
in
that
in
that
in
that
database.
Well,
then,
you
can
use
that
external
connector
to
go
out
during
policy
evaluation
and
check
if
that
role
exists.
C
Policy,
yeah
yeah
for
sure
yeah,
so
yeah
we've
been
as
as
I
mentioned
earlier,
we're
working
closely
with
Tristan
and
Sarah
and
and
they're
all.
They
know
all
about
obligations
and
advice.
Yes,
exactly
exactly,
and
so
the
plan
is
for
for
it
in
open.
Today
you
can
express
those
kinds
of
concepts
because,
because
the
policy
decisions
can
be
these
arbitrary
JSON
documents
they
can
they
can
you
and
include
well
here's
the
advice
and
here
the
obligations
there's
no,
and
so
so
from
the
caller's
point
of
view
it
can
you
can
return
those
kind
of
information.
C
There's
no
super
store
support,
though,
and
inside
of
OPA,
to
do
that.
That's
not
a
thing
that
open
knows
about,
but
in
some
sense
that's
okay.
As
long
as
you
can
express
the
obligations
and
advice
you
care
about,
because
the
burden
is
really
on
the
client
to
actually
do
something
with
that
advice
in
those
obligations,
but
the
like
I
said:
Sarah
and
Tristan
are
the
experts
there
and
we'll
learn
more
as
we
afford
them
and
b2.
E
Yeah
I
think
that
we're
we're
really
excited
about
like
that
that
capability,
right
and
I
think
taking
that
layered
approach
makes
a
lot
of
sense
like
not
putting
like.
We
don't
need
to
put
all
of
the
concerns
and
how
it's
going
to
be
used
into
the
policy
evaluation
itself.
In
fact,
it's
stronger
if
we
don't
all
right,
let's
only
put
the
concepts
into
it
that
we
really
really
need
to,
because
then
it's
powerful
and
can
be
used
across
many
domains
right
right,
at
least
that's
my
current
thinking.
What's.