►
From YouTube: Cloud native policy enforcement with Open Policy Agent
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
this
cncf
webinar,
where
I'll
be
talking
about
policy-based
access
control,
using
open
policy
agents,
which
is
a
cncf
graduated
project.
A
I
have
a
long
background
in
software
development
and
primarily
in
identity
systems,
for
I've
worked
with
opa
for
about
two
years
now,
and
when
I
don't
I'm
mainly
interested
in
cooking
food
and
football,
and
I'm
on
twitter,
I'm
on
github
and
if
you
want
to
connect,
feel
free
to
do
so
so
policy
is
code
and
oppa.
What's
what's
this
challenge
we're
trying
to
tackle?
What's
what
is
the
problem
we're
trying
to
solve
here?
A
I
think
one
common
theme
here
is
pretty
much
to
manage
policy
in
increasingly
distributed
complex
and
heterogeneous
systems.
So
we
have
all
these
application
stacks
programming
languages
frameworks.
A
We
have
deployment
platforms
like
kubernetes,
we
have
the
underlying
cloud
and
infrastructure
and
we
have
data
in
all
in
all
its
forms
and
all
these
systems
they
they
kind
of,
tend
to
deal
with
policy
in
their
own
way,
using
their
own
domain,
specific
languages,
their
own
way
of
logging
and
so
on.
So
what
we're
really
trying
to
do
here
is
to
unify
policy
enforcement
and
the
way
we
deal
like
manage
policy
distribute
policy
and
log
policy
decisions
across
this
whole
stack
and
that's
really
what
oppa
is
about
there
are.
A
There
are
many
other
systems
to
you
know
work
with
policy
if
you
check,
if
you
zoom
into
one
of
these
one
whenever
one
of
these
icons
or
one
of
these
systems,
you'll
probably
find
ways
of
working
with
policy
for
just
that
system,
but
oppa
is
trying
to
to
tackle
the
problem
at
large.
A
A
Across
this
diverse
set
of
technologies
and
products,
you
oppa
offers
a
unified
toolset
and
a
framework
for
working
with
policy
across
this
whole
stack
opa,
decouples
policy
from
application
logic,
meaning
that
you
can
extract
policies
from
from
your
regular
business
logic
or
application
logic.
Sort
of
like
you'd
extract.
A
A
A
Policies
they're
written
in
a
declarative
language
called
rego,
which
we
will
look
into
closer
later
today,
since
we're
talking
about
a
general
purpose
policy
engine
we're
seeing
use
cases
here,
ranging
from
anything
from
kubernetes
admission,
control,
micro
service
authorization,
infrastructure
policies,
data
source,
filtering
of
attributes
or
ci
cd
like
build
and
deployment
pipelines.
So
there's
policies
all
across
the
stack
and
oppa
is
really
oppa
really
fulfills.
This
promise
of
of
unifying
policy
enforcement
across
the
stack
so
oppa
is
a
vibrant,
open
source
community.
A
I
think
these
numbers
might
even
be
a
little
dated
by
now,
because
last
I
checked,
we
had
over
5
000
get
up
stars
and
even
4
000
slack
user.
It
doesn't
really
matter
it's
a
big
and
vibrant
community,
and
and
not
only
do
we
have
the
open
policy
agent
project
like
proper,
but
also
there
are
many
interesting
projects
beneath
that
were
included
in
in,
in
the
whole
big
oba
product,
such
as
conf
test
for
testing
like
config,
doing
conflict
validation
and
having
policies
on
on
configuration
files.
A
There
is
gatekeeper,
oppa,
gatekeeper
for
doing
admission
control,
and
there
is
plugins
for
editors
such
as
vs
code
and
intellij.
A
I
finally
have
a
framework
that
helps
me
translate
written
security
policies
into
executable
code
for
every
layer
of
the
stack,
so
that
kind
of
summarizes
what
oppa
is
about
and
also
why
it's
so
useful,
so
oppadan.
How
does
it
work?
How
can
how
can
opa
service
requests
for
all
these
diverse
services
and
all
these
diverse
technologies
and
the
answer
behind
that
is
the
policy
decision
model?
A
The
way
it
works
is
that
any
service,
this
is
normally
an
application
or
it
could
be
an
envoy
proxy
or
it
could
be
the
kubernetes
api
server
or
it
could
be
a
kafka
and
again
so.
This
is
this
is
where
the
general
purpose
model
comes
in
any
service,
anything
that
can
serve
as
requests
reaches
out
when
it's
when
it
receives
a
request,
it
reaches
out
to
oppa,
and
it
asks
for
a
decision
and
most
normally
it's.
A
It
will
also
provide
some
data
as
part
of
that
request,
and
that
data
is
just
json,
so
it
says
something
I
I
have
this
information
here.
I
have
maybe
the
name
of
the
user
and
some
roles
and
here's
the
end
points
that
this
user
is
trying
to
access.
Should
this
request
be
allowed
or
not,
and
oppa
will
make
a
decision
based
on
the
policy
which
we
have
provided
oppa
from
before
and
based
on
that
policy?
Oppa
will
make
a
decision,
and
that
decision
is
also
just
json.
A
So
so
that
kind
of
that
is
the
secret
sauce
be
behind.
How
can
how
can
oppa
work
with
all
these
technologies,
because
any
product
or
product
or
service
capable
of
of
sending
http
requests
and
parsing
and
crafting
json,
can
can
can
be
integrated
with
open.
A
A
This
would
normally
mean
that
you
run
it
on
on
the
same
host
as
your
application,
so
on
the
same
machine
or
maybe,
if
you're
in
if
you're
in
the
kubernetes
world
you'd
run
oppa
as
a
sidecar,
which
essentially
means
the
same
thing
you're
you
you'll
run
oppa
in
the
same
on
the
same
machine
as
your
main
application.
So
when
you
query
opa
it's
it's
always
a
local
host
and
the
benefit
of
of
doing
it.
A
But
but
if
you
have
applications
written
in
go,
you
can
actually
use
oppa
as
a
library
as
well.
There's
also
integrations
for
envoy
still,
and
you
can
also
compile
policies
to
webassembly.
So
there's
there's
really
a
wide
array
of
of
deployment
options
as
well,
but
the
the
one
you'll
see
mostly
deployed
is:
is
the
the
rest
api,
so
policy
offering
that
and
how
does
that
work
and
how?
How
do
we?
How
do
we
provide
policies
to
oppa
the
way
regal
works?
A
Is
it's
really
a
high-level
policy
language
and
it
declared
a
one
at
that
and
what
does
what
does
that
mean?
It's
essentially
like
sequel,
where
you
rather
than
saying
exactly
how
you
want
something
done
you
you
say
what
you
want
done
and
then
it's
up
to
the
policy
engine
to
figure
out
the
best
way
to
to
go
about
that.
A
A
policy
is
pretty
much
any
number
of
rules.
So
this
this
maps
pretty
much
to
what
a
policy
is
also
in
in
real
life
and
the
rule
is
a
rule
commonly
return
something
and
that
could
be
any
any
value
which
is
valid
json.
So
it
could
be
a
boolean
like
true
or
false.
Whether
are
you
allowed
or
not
true
or
false,
but
it
could
also
be
more
more
complex
objects
like
strings
or
lists
and
objects.
A
I
think
there
is
almost
150
built-in
functions
today
and
rigo
is
not
like
a
general
purpose,
programming
language.
So
these
built-in
functions
they
kind
of
tend
to
focus
on
things
that
are
useful
in
in
the
context
of
policy
offerings.
So
you'll
see
things
like
validating
certificates,
checking
or
verifying
json
web
tokens
date
and
time
functions.
Ip
address
ranges
things
like
that
and
and
things
around
identity
and
permissions.
A
A
We
need
to
know
the
roles
of
the
user
and
that's
what
we
call
policy
data
and
that
data
can
be
provided
to
oppa
either
as
part
of
the
input
like
as
part
of
the
query,
when
we
ask
oppa,
we
can
say
I
have
a
user
here,
and
this
user
has
these
roles
or
this
she
or
he
allowed
to
to
access
or
to
retrieve
this
data.
A
But
we
can
also
push
data
into
oppa
beforehand.
So
with
the
data
is
already
available
when
we,
when
we
query
opa
for
decisions
or
we
can
use
the
bundle
api
to
pull
data
from
a
remote
endpoint
and
finally,
there's
also
an
http
send
function
which
is
really
just
an
http
client
which
we
can
use
from
inside
our
policies
to
to
fetch
data
at
policy
evaluation
time.
A
Okay,
so
at
this
stage
I'm
actually
gonna
show
how
simple
policy
offering
might
work
and,
of
course,
I'm
gonna
use
now
the
rego
playground-
and
I
encourage
anyone
watching
to
to
do
the
same-
just
see
what
it's
see,
what
it's,
how
it
works
and
how
we
can
work
with
policies.
A
So
what
we
have
here
to
our
right,
that
is
the
input
data
which
the
in
this
case
we're
going
to
simulate
a
rest,
api
or
or
an
api
or
a
micro
service,
something
servicing
regular
http
requests.
So
we
have
a
path:
the
user
is
trying
to
access
a
path
in
this
case
it's
the
user's
path,
and
we
can
see
that
the
the
the
request
method
here
is
a
get
request
and
we
also
have
some
basic
user
information
in
this
case.
A
Only
the
name
of
the
user,
so
our
our
policy
then,
is
going
to
it's
going
to
have
to
decide
whether
this
should
be
allowed
or
not
and
yeah.
I
get
requests
on
the
user's
end
point.
That
seems
that
seems
pretty
fair,
like
anyone
can
probably
read
all
the
users,
given
that
it's
not
like
any
private
information
or
so
so
so
it
seems
fair
that
we
have
a
policy
that
that
would
allow
us.
A
So
again,
a
policy
is
just
a
series
of
rules.
So
the
first
thing
we're
going
to
want
to
add
here
is
a
rule
in
this
row.
In
this
case,
I'm
going
to
name
this
rule.
Allow
and
again
oppa
doesn't
really
care
about
your
names,
so
alau
has
no
special
meaning
for
oppa.
It
has
a
special
meaning
for
us
as
people,
but
to
oppa
it's
just
the
name
of
the
rule
and
the
anatomy
of
the
rule
is
kind
of
like
this.
A
So
you
have
an
you,
have
a
name
of
the
rule
and
you
have
a
body
and
if
all
the
conditions
inside
of
the
rule
are
true,
so
we
do
something
like
this.
One
is
equal
to
one
and
we
evaluate
this.
We're
gonna
see
that
yes,
the
the
the
alar
rule
is
now
true,
and
if
we
do
something
like
this,
we're
gonna
see.
A
No,
it's
no
longer
true.
It's
no,
no
longer
nothing.
So
by
default,
if
a
rule
does
not
evaluate
it's
just
undefined.
So
if
we
want
to
change
that,
we
could
do
something
like
this.
We
could
say
by
that
by
default.
A
Allow
should
be
equal
to
false,
and
now,
if
we
query
we'll
see
that
this
kind
of
fallback
condition
is
triggered
and
and
we'll
always
get
a
response,
so
if
we
change
back
here,
we're
going
to
see
that
it's
true
and
remember,
I
said
that
all
conditions
inside
here
need
to
be
true.
So
if
we
do
something
like
this
we're
back
to
false,
because
this
is
obviously
not
true,
so
the
way
you
can
think
of
of
this
is
pretty
much
like
if
you're.
A
A
So
if,
if
one
line
evaluates
it
will
hop
on
to
the
next
line,
evaluate
that
and
once
once
it
doesn't,
the
the
condition
is
or
the
rule
is
just
going
to
be
undefined.
A
Unless,
of
course,
as
we
did
here,
we
declared
a
default
value
for
a
rule-
oh
okay,
so
this
is
just
like
silly
constants
in
use
here.
So
let's
make
something
useful
if
we
say
if
the
path
and
we're
going
to
use
the
global
input
here,
which
is,
of
course,
the
values
we
see
here
to
our
right.
A
So
with
the
input
path,
sequel
to
users
yeah,
then
then
this
should
be.
This
should
be
true
right
because
the
input
path
is
equal
to
user.
So
we're
going
to
say
that
if
that
happens,
yeah
we
should
allow
that.
But
of
course,
in
this
case
the
input
method
could
be
delete
or
put
or
something
trying
to
modify
this
users,
and
we
don't
want
that.
We
don't
want
to
allow
that.
So
we're
also
going
to
say
that
if
the
input
method
is
equal
to
get.
A
And
one
thing
we
might
want
to
change
here
is
how
how
this
can
add,
there's
using
a
string
like
this.
A
We
can't
really
know
is
this:
the
application
always
gonna
provide
us
with
like
a
leading
slash
like
this
or
a
trailing
slash
or
so
so
what
we
could
do
here
is
we
could
use
oppa's
built-ins
the
built-in
functions
again,
there's
a
built-in
functions,
so
what
we
could
do
here
is
we
could
say
that
the
path,
if
we
try
and
maybe
trim
these
these
we're
gonna
say
and
we're
gonna
trim
the
input
path
from
slashes,
and
if
we
evaluate
this
now,
we
should
see
that
both
the
path
and
the
allow
rule
is
evaluated,
and
we
can
see
that
yes,
indeed,
the
slashes
were
trimmed
and
sorry
about
that,
and
what
we
might
want
to
do
now
is
rather
than
working
with
strings,
because
if
we
have
more
names
here
later,
like
somebody's
trying
to
access
this,
we're
going
to
need
to
do
something
like
regex
or
so
so
what
we'd
rather
want
to
do
here
for
the
path
is
that
we'd
rather
want
it?
A
We?
What
we
really
want
to
do
here
is
we
want
to
split
that
we're
going
to
split
that
on
slash,
so
so,
instead
of
a
string
we'll
have
an
array
to
work
with.
I
I
think
this
is
often
preferable
and
this
kind
of
shows
how
we
can
work
with
the
built-in
functions
of
opa
and
again,
if
you
check
that
the
docs
you'll
see
there's
a
reference
for
each
of
these
or
each
of
these
built-ins
are
listed
there.
A
So,
okay,
so
now
we
have
a
path
to
work
with
and,
of
course,
we'd
rather
want
to
work
with
this
new
path
that
we
have
so
we're
gonna
do
so,
if
the
first
or,
if
the,
if
the
first
path
component,
because
in
this
case
we
don't
really
care
as
long
as
the
the
method
is
get,
this
could
be
any
user.
This
could
be
anders
or
this
could
be
jane.
If,
if
someone
is
trying
to
read
a
user,
we
should
still
allow
it.
A
We
should
see
that
now.
Allow
is
no
longer
true,
so
this
is
connect.
How
we
work
with
decisions
in
oppa
and
maybe
we'd,
want
to
add
another
condition.
Maybe
we
would
want
to
allow
some
form
of
modification,
maybe
a
user
should
be
able
to
modify
their
own
details,
but
obviously
not
of
any
other
users.
A
So
how
would
we
add
another
condition?
The
easy
way
to
do.
This
is
simply
just
to
add
another
rule,
and
we
can
have
as
many
rules
as
we
want
with
the
same
name,
and
the
way
it
works
is
that
if
any
of
these
rules
are
true,
then
we
say
that
the
rule
named.
Allow
is
true.
So,
while
the
conditions
inside
of
the
rule
are
ended
together,
the
rules
themselves
are
ored.
A
So
if
one
of
them
is
true,
the
the
result
or
the
decision
is
true
and
of
course
again,
rules
don't
have
they
don't
necessarily
have
to
be
true
or
false,
but
they
can
return
any
value.
But
for
for
this
example,
we're
just
gonna
go
with
a
boolean
response.
A
A
A
If
we
change
that
to
put
it
should
work,
and
it
does
so
so
we
we've
kind
of
have
a
a
way
of
in
just
16
lines
of
rego.
A
We
have
a
policy
that
allows
any
user
to
read
from
any
endpoint
or
from
any
user
endpoint
on
the
users
kind
of
base
path,
but
users
may
only
modify
their
own
user.
So
if
we
change
here
to
jane,
we
can
see
that
anders
can
no
longer
modify
this
user
because
that's
not-
who
I
am
so
so
yeah
16
lines
are
rego
and
it's
a
fairly
useful
policy.
A
We
we've
managed
to
formulate
a
policy
which,
where
we
kind
of
decouple
these
decisions
from
from
our
application
logic,
so
our
applications.
They
would
not
need
to
know
about
these.
These
this
logic
who
gets
to
access.
What,
in
your
in
your
business
logic,
you
can
focus
on
actually
servicing
the
request
and
oppa
will
focus
on
on
actually
on
enforce
or
making
these
policy
decisions.
A
A
Another
common
use
case
is,
of
course,
kubernetes,
and
how
does
that
work
then?
The
way
the
kubernetes
api
works
is
that
whenever
a
resource
is
sent
to
be
persistent,
meaning
if
you
try
and
modify
one
if
you
create
something
new.
So
in
this
example
here,
if
we
do
cube,
cdl
apply
and
we'll
try
and
deploy
a
new
application.
A
That
request
is
going
to
be
it's
going
to
have
to
pass
a
series
of
modules,
and
these
modules
are
authentication,
they're
authorization,
it's
a
mutating
admission
controller.
It's
a
validating
admission
controller,
there's
even
more
modules
involved
but
kind
of
try
and
keep
it
understandable
here
and
additionally,
all
these
modules
are
shaneable.
So
it's
not
just
one,
but
there
could
be
many
authorizers
involved
and
there
could
be
many
admission
controllers
involved
and
once
the
request
is
passed
all
these
modules
we
say
it's
finally
persisted
to
xcd,
which
is
the
database
of
kubernetes.
A
There's
a
whole
bunch
of
built-in
modules
in
all
these
steps,
some
of
them
are
allowed
by
default
or
enabled
by
default
and-
and
some
are
not.
But
what's
interesting
for
us
here
is,
of
course,
the
web
hook,
because
for
what
a
web
hook
is
it's
really
an
http
request?
And
in
the
case
of
kubernetes
it's
json
and
remember:
that's
that's
exactly
what
oppa
is
meant
to
do
it.
Services
requests
all
over
or
json
requests
sent
over
http.
A
A
So,
let's
zoom
in
here
on
the
on
the
validating
one,
and
why
why
the
validating
one,
because
it's
by
far
the
most
popular
module
to
extend
the
and
the
reason
for
for
that,
is
that
it
allows
us
to
build
policy-based
guardrails
around
our
clusters.
So
we
can
we
can.
We
can
build
rules
to
enforce
things
like
forbid
any
container,
to
download
an
image
from
an
external
docker
industry.
We
only
want
to
allow
the
internal
approved
company
registry,
for
example,
all
resources
deployed
in
our
cluster
must
have
appropriate
labels.
A
A
Maybe
you
want
to
enforce
tls
deny
certain
attributes,
have
certain
resource
allocation
limits,
and
so
on.
So
there's
there's
basically
no
end
to
the
type
of
policies
you
can
write
for
for
an
invalidating
admission,
controller,
and-
and
this
of
course
allows
us
to
build
these
guardrails
that
we
mentioned
before
the
way
it
works
is
essentially
the
same
as
the
rest
api
policy
we
saw
before
the
order
here
is
a
a
bit
randomized,
but
the
input
to
the
left.
A
That
was
obviously
what
was
up
to
the
right
before
we
can
see
it's
still
just
json.
In
this
case
it's
a
port
being
submitted
for
admission
control
and
in
the
middle
we
see
the
actual
policy
and
it's
a
very
simple
policy.
It
just
checks.
If
there's
not
an
input,
request
object,
metadata
labels
cost
center
attributes.
A
So
before
we
finish
just
a
quick
word
on
opus
management
apis,
because
once
you
kind
of
pass
the
initial
stage
of
having
deployed
a
couple
of
policies,
a
couple
of
opas
servicing
your
apis
or
your
microservices
or
kubernetes
you're,
going
to
want
to
manage
oppa
at
scale
and
for
doing
that.
There's
a
couple
of
api
endpoints
which
oppa
implements
or
which
oppa
reaches
out
to
for
for
management
features
like
bundles
fetching
bundles.
So
this
is
really
for
fetching
policy
and
data
from
a
centralized
location.
A
The
decision
log
api
allows
oppa
to
report
back
on
any
decisions
made
in
in
its
yeah
during
its
operation.
So
any
decision
ever
made
is
reported
back,
so
we
can
use
that
for
auditing
or
for
improving
the
quality
of
our
policies
and
there's
also
a
status
api
for
like
health
and
health
check
and
status
updates
and
a
discovery.
Api
for
configuration.
A
So
where
do
you
start?
My
suggestion
is
usually
just
start
small,
maybe
try
the
the
rego
play
around
browse
the
open,
docs
get
a
feel
for
the
basics
and
and
how
everything
works,
and
once
you
kind
of
once,
you
grasp
the
basics.
You
can
start
looking
into
the
applications
that
you've
worked
with
previously
and
again.
You
can't
really
choose
whether
to
work
with
policy
or
not
like
policy
is
pretty
much
everywhere,
but
but
what
you
can
try
and
do
is
identify.
A
Where
do
we
have
policy
today
and
once
you've
done,
that
you
can
start
to
slowly
delegate
some
of
that
responsibility
to
oppa
and
again
you
you
can
start
small,
you
don't
need
to
rewrite
your
whole
authorization
logic
or
your
whole
policy
system,
but
maybe
start
with
a
single
endpoint
or
a
single
role,
like
maybe
delegate
the
admin
check
to
oppa,
deploy
and
build
experience
from
that,
and
once
you're
done
with
that,
you
can
start
scaling
up.
You
can
look
into
things
like
policy
management
decision.
Logging
bundle
server.
A
A
It's
a
free
resource
as
well,
where
you
have
like
video
tutorials,
followed
by
quiz
style
tests,
so
I
can
hardly
recommend
that
for
more
management
features,
there's
the
styrodas,
which
also
has
a
free
edition,
which
you
can
try
out
and
finally
join
the
opa
slack
community,
we're
over
4
000
members
already
and
it's
a
great
way
to
ask
questions,
see
what
others
are
asking.
A
What
what
are
the
interesting
projects
brewing
in
the
oppa
community
and
just
like
general
good
place
to
hang
out
so
do
join
us
there,
and
with
that
I
say,
thank
you
and
I
hope
you
enjoyed
this
webinar
and
that
you
learned
something
about
policy
and
open
policy
agent.
So
thanks.