►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Open Policy Agent Intro - Patrick East, Styra & Max Smythe, Google
Come to this session to learn about the Open Policy Agent (OPA) project. OPA is a general-purpose policy engine that solves a number of policy-related use cases for Kubernetes, microservices, CI/CD, cloud, and more. During this session the OPA maintainers will introduce the project for newcomers and then provide updates on the latest and greatest features landing in OPA and OPA Gatekeeper. If you are interested in policy and security as it relates to cloud native technology, this session is for you.
https://sched.co/ekI2
B
A
All
right
and
then
myself,
patrick
opal,
maintainer,
engineer
at
styra
on
slack
all
the
time
hit
me
up
and
sam.
You
can
tweet
at
me,
but
I
may
not
tweet
back
all
right.
So
let's
talk
for
a
second
about
what
opa
is
it's
an
open
source
project
cncf
founded
by
stara
in
2016.,
in
2018,
we've
donated
to
the
cncf
sandbox
project?
Since
then,
it's
gone
on
to
incubating.
A
A
The
project
has
got
tons
of
contributors
from
a
pretty
broad
spectrum.
We
have
kind
of
the
usual
suspects.
We've
got
google
microsoft.
We
also
have
a
bunch
of
startups
as
well
as
end
users.
We
have
people
like
chef
and
some
others
that
you
know
they
use
opa.
They
came
back,
they
contributed,
they
help
out
the
community.
A
So
what
is
opa?
It's
a
general
purpose
policy
engine
sounds
super
vague
and
the
reason
being
it
sort
of
is
in
the
sense
that
it's
not
domain
specific.
It's
not
just
for
solving.
You
know,
authentication
authorization,
it's
not,
for
you
know,
image
scanning,
it's
a
policy
language
that
and
the
runtime
and
the
tools
to
actually
like
you
know,
evaluate
that
and
make
decisions.
A
So
at
a
high
level
open
you,
you
query
it
the
query.
You
know
any
input
can
be
json
whatever
you
know,
if
you
can
json
serialize
it
and
go
into
opa
as
an
input.
The
decision
same
deal,
oftentimes,
you're,
gonna,
see
boolean.
You
know
like
allow
yes,
no
kind
of
thing,
but
that
doesn't
have
to
be
the
case.
It
can
be
a
set
of
reasons
why
it
wasn't
allowed.
It
could
be,
you
know,
a
set
of
mutations,
what
labels
to
add
to
a
pod
or
something
right,
the
service
here
in
this
picture.
A
I
think
all
these
logos
have
an
existing
integration,
but
it
really
could
be
anything.
It
could
be
your
custom
service.
It
can
be
a
plugin,
some
external
authorized
authorization
tool,
or
you
know
some
of
them.
Some
actually
have
plug-ins.
Some
of
them
actually
have
like
a
separate
rest
api
or
something
that
needs
to
get
implemented,
but
it
doesn't
really
matter
for
opa
as
long
as
you
can
translate
it
into
some
json
payload
it'll
work
so
again,
like
digging
a
little
deeper
you're,
getting
the
declarative
policy
language
rego.
A
It
essentially
is
it's
a
query
language.
That's
built
to.
Let
you
reason
about
structured
data,
asking
questions
typically,
like
can
a
user
do
something
you
know
some
action
on
some
resource
or
you
know
is
this:
is
this
object
missing
a
field
or
some
value
of
a
property
of
that
object?
You
know
invalid
or
valid.
A
There's
a
ton
of
built-in
functions
in
the
language.
It
provides
the
ability
to
do
kind
of
context-aware
things,
the
the
main
kind
of
like
selling
point
there.
Being
that
you
don't
just
have
your
your
policy
and
the
input
you
can
have
external
data
too.
So
if
you're
trying
to
answer
a
question
about
some
api
request,
you
can
also
provide
external
json
data,
such
as
maybe
the
entitlements
for
users
group
permissions.
A
A
A
The
the
kind
of
nice
part
in
addition
to
optimizations,
is
that
the
way
that
it's
written
and
structured
allows
us
to
do
a
lot
of
cool
tricks,
for
you
know,
reasoning
about
the
policy.
In
addition
to
like
you
know
how
fast
it
is,
but
also
like
how
correct
it
is
the
last
piece
here
you
might
be
wondering
what
you
know:
we've
been
talking
about
features
but
like
what.
What
actually
is
it?
It's
typically
going
to
either
be
used
as
a
going
library
or
as
a
sidecar,
post-level
daemon.
A
So
opa
oppa
comes
as
a
binary
that
you
can
run
most
people
just
use
docker
image
and
that
you
know
gives
you
like
the
kind
of
like
lowest
latency
approach
with
those
the
kind
of
like
higher
level
stack
of
features
the
I
guess
the
kind
of
yeah
we'll
call
them
enterprise
features
here.
You
have
a
set
of
things
for
essentially
managing
the
opa
agents,
and
this
includes
their
status
audit
logs
things
like
packaging
and
delivery
for
the
policies
themselves,
as
well
as
like
dynamic
configuration
and
things
like
that.
A
The
last
step
here
to
sort
of
round
it
out
is
the
the
tooling
to
write
policies.
So
the
cli
that
the
opel
binary
provides
a
bunch
of
tools
built
in
but
there's
also
a
whole.
You
know
I'd
say
pretty
pretty
like
fully
fledged
ecosystem
now
of
ide
and
editor
integrations
that
give
you
like
really
nice
ways
to
write
your
policies,
but
also
test
them
and
profile
them,
and
you
know,
do
do
kind
of
regular
like
code
development
with
them.
A
A
A
This
gives
you
a
really
good
way
to
just
play
around
with
the
language.
Try
things
out
help
kind
of
explore,
not
only
how
to
write
the
policies
but
how
to
troubleshoot
them
reason
about
them,
walking
through
just
kind
of
your
well.
For
some
of
you,
your
first
policy
here,
essentially
each
policy
file
defines
a
few
things.
A
A
What
we're
saying
is
build
a
virtual
like
we're
declaring
a
document
under
that
document
tree
under
the
app.ourbackpath.
We
have
a
rule,
and
by
default
this
rule
allow
is
false.
There
are
no
conditions,
it's
just
that's
it
by
default.
It's
false.
Our
next
statement
says,
allow
is
true
by
you
know,
omitting
the
equals
true.
These
are
equivalent
statements.
A
A
What
this
is
doing
is
querying
the
document
structure
and
saying
find
a
variable.
I,
if
a
value
exists
for
I
inside
of
this,
this
path
that
I'm
defining
this
rule
is
true.
The
the
rule
is
true.
If
everything
in
the
rule
body
is
true,
so
data
we're
referencing
into
our
external
data,
so
we
have
here,
in
this
middle
section,
aptly
named
data
user
roles
inside
of
user
roles,
we're
going
to
be
looking
for
the
input.user.
A
A
A
A
A
A
Now
that
we've
seen
a
little
bit
of
the
policies
themselves,
you
might
be
wondering
you
know
like:
where
do
you
use
these
things?
I
there's
a
slide
earlier
that
showed
you
know
a
service
box
and
had
some
logos.
I
think
the
the
important
thing
is
to
sort
of
step
back.
Take
a
look
at
like
you
know,
we're
at
kubecon
attending
kubecon
and
the
you
know.
In
these
ecosystems,
everybody's
got
ci
cd
pipelines,
they've
got
deployment
management,
they've
got
container
orchestration,
they've
got
cloud
management.
All
their
infrastructure
is
code.
A
A
Every
single
one
of
these
spots
has
policy,
and
every
single
one
of
these
spots
has
an
integration
point
for
ova
whether
that's
an
existing
plugin
or
a
place
where
you
can
add
your
own
kind
of
custom
callout
to
do
the
the
or
the
sort
of
policy
enforcement
oppa.
Is
there
as
the
common
unified
way
of
defining
these
policies?
That's
really
the
primary
objective,
that's
what
it
was
built
for.
That's
what
we
set
out
to
do
and
I
think
the
ecosystem
page
sort
of
shows
that
we're
succeeding.
A
There's
a
pretty
broad
spectrum
of
integrations
here.
Everything
from
doing
you
know,
like
object,
storage
authorization
to,
I
think,
there's
like
10
api
gateways
that
you
know
people
have
plug-ins
for,
as
well
as
doing
like
emission
control,
terraform
plan,
validation,
config,
validation,
all
kinds
of
other
stuff.
I'd
recommend
you
guys
check
this
out.
A
The
the
shortened
link
should
work
if
it
doesn't
just
just
go
to
the
opal
website
and
click
on
ecosystem
link.
It's
pretty
easy
to
find,
and
we
we
do
keep
this
up
to
date.
So
it
should
reflect
the
latest
and
greatest
stuff,
speaking
of
integrations
latest
and
greatest
stuff.
One
that
we
want
to
call
out
is
confessed,
so
I
think
probably
a
lot
of
people
have
heard
of
it.
If
you
haven't
go
check
it
out.
A
You
know,
there's
a
quote
here
straight
from
the
readme,
but
it
essentially
gives
a
little
bit
of
an
opinionated
way
to
write
open
policies
and
validate
over
structured
data.
In
this
case
that
structured
data
is
config
files,
whether
those
config
files
are
a
kubernetes
manifest
or
a
you
know,
docker
file
or
whatever
doesn't.
A
A
Do
that
it's
super
popular
check.
It
out,
there's
a
reason
that
it's
popular
one
thing
that
I
do
want
to
call
out
here.
It's
really
cool
contest
is
now
an
official
oppa
project,
so
they've
they've
moved
in
they're
underneath
the
open
policy
agent
org,
ongoing
efforts
to
you
know
further
integrate
sort
of
functionality
between
core
opa
and
conf
test,
but
yeah
definitely
something
to
look
at,
but
we're
kubecon.
So,
let's,
let's
stop
talking
about
config
files,
because
we
we
love
yaml.
A
Only
the
the
probably
most
popular
use
case
for
opa
right
now
is
as
a
admission
controller
for
kubernetes.
This
has
been
around
in
a
few
different
forms,
but,
needless
to
say,
oppa
kubernetes.
They
they
kind
of
you,
know
peanut
butter
and
jelly.
Everybody
should
be
using
it.
You
don't
have
the
snare
cluster,
do
it.
B
Okay,
let's
take
a
look
at
gatekeeper.
First
of
all,
what
is
gatekeeper
well,
our
tagline
is
that
gatekeeper
is
a
customizable
kubernetes
admission
web
hook
that
helps
enforce
policies
and
strengthen
governance.
And
if
we
look
at
the
sort
of
history
of
the
project,
we
can
see
how
it
is
kind
of
an
outgrowth
of
earlier
styra
efforts.
B
So
styra
originally
released
the
cube
management
sidecar
back
in
2017.
that
basically
watched
config
maps
as
a
way
to
import
opa
policy
and
microsoft
in
december
of
2018
wrote
a
project
called
kubernetes
policy
controller
that
built
on
top
of
that
and
added
mutation
and
a
little
bit
after
that
time.
Microsoft,
google
and
styra
and
other
collaborators
started
to
work
together
on
creating
a
new
sort
of
reimagining
of
what
this
could
look
like.
B
It's
going
to
hit
the
api
server,
which
is
going
to
as
part
of
its
admission
control
process,
send
out
an
admission
review
web
hook
to
or
sorry
admission
review
request
to
gatekeeper,
which
is
then
going
to
forward
a
query
to
oppa
to
return
a
response
in
terms
of
how
we
figure
out.
What
response
to
give
what's
happening
is
that
gatekeeper
establishes
a
watch
on
the
policy
configuration
objects
so
for
gatekeeper,
that
is,
constraints
and
constraint
templates
as
well
as
any
other
objects
in
the
cluster
that
you
may
be
watching
in
order
to
have
referential
policies.
B
So,
if
we
think
about
the
core
features
that
gatekeepers
offering
users,
these
sort
of
highlight
features
are
that
it's
a
validating
admission
controller
right
that
we
just
covered.
Also,
it
provides
audit
functionality.
This
periodic
checking
of
your
cluster
config
to
prevent
drift
as
well
as
maintains
opa's
ability
to
provide
context
where
referential
policies,
but
with
a
specific
focus
on
being
compatible
with
the
krm
conventions
of
kubernetes
as
well.
B
If
we
look
at
the
policy
side
of
things,
the
constraint
and
constraint,
template
conventions
allow
users
to
have
easily
shareable
policy,
bundles
that
are
designed
to
be
non-interactive
and
that,
once
they
load
those
constraint
templates
in
they're
able
to
create
policy
simply
using
constraint,
objects
which
should
be
just
straight
yaml.
Configurations
like
these
are.
The
specific
labels
I
want
to
make
sure
exist
is
a
common
example.
B
Another
highlight
high
level
feature
of
gatekeeper
is
dry
run.
We
would
like
users
to
be
able
to
test
their
policies
on
a
provisional
basis
and
get
information
as
to
whether
adding
a
new
policy
would
actually
break
the
cluster.
So
this
is
kind
of
like
a
pretend
enforcement.
That's
giving
you
feedback
either
through
prometheus
metrics
through
logs
or
through
audit
results
that
if
you
were
to
actually
enforce
this
policy,
these
requests
would
have
been
rejected,
or
this
particular
resource
that
is
already
in
your
cluster
would
no
longer
be
in
compliance.
B
B
We
have
provided
pprof
profiling,
which
gives
users
the
ability
to
see
where
gatekeeper
is
spending
time
for
its
cpu
cycles,
as
well
as
where
ram
usage
is
going
as
well
as
overhauling
the
memory
usage
profile
for
audit,
hopefully
lowering
the
maximum
possible
memory
usage.
When
you
start
scaling
to
large
clusters,
we
are
exploring
an
events
framework
where
certain
audit
incidents
or
rejections
are
reported
to
the
user
as
kubernetes
events,
we
would
definitely
like
feedback
on
sort
of
the
granularity
that
users
would
like
to
see
for
events
and
other
than
that.
B
B
The
release
management
dock
will
give
you
some
idea
of
our
release
cadence,
and
we
have
split
the
constraint
template
library,
which
is
a
repository
of
constraint,
templates
that
have
been
developed
by
the
community
for
users
to
use
to
form
their
own
policy.
We
have
split
that
into
its
own
repository.
B
B
You
can
see
this
if
we
list
the
namespaces
gatekeeper
system
exists,
which
is
a
good
indicator.
That
gatekeeper
is
at
least
installed,
and
let's
look
at
some
of
the
constraint
templates
we
have
so
we
just
have
the
one
constraint
template
in
this
case.
It
is
called
kate's
psp
privileged
container,
and
this
is
an
analog
constraint
to
pod
security
policy.
B
B
Q
proxy
is
running
with
higher
privileges
than
we
would
like,
and
a
couple
of
other
cube
system
pods,
I'm
actually
going
to
ignore
the
cube
system
pods
for
now,
because
it's
cube
system,
let's
look
at
this
opa-pod,
so
keep
cuddle,
get
pods
oppa.
It
was
called
you
can
see
that
name
here
and
that
it
is
in
the
default
namespace.
B
B
B
And
let's
just
get
rid
of
the
lines
where
we
request
extra
privileges
and
just
reapply
here
and
the
opponent
is
recreated
and
to
see
this
experimental
new
events
feature
if
I
run
keep
cuddle
get
events
on
the
gatekeeper
system
namespace,
we
find
a
few
interesting
events
here.
We
have
audit
violations
showing
up
and
we
also
should
have
yes
right
down
here,
a
failed
admission
that
is
about
46,
second
old
from
when
I
tried
to
apply
the
invalid
opapod.
B
So
this
is
just
a
sample
of
some
of
the
ways
that
you
can
use
gatekeeper
to
define
and
enforce
policy
on
your
cluster
as
far
as
gatekeepers
current
status
as
a
project.
As
I
said
before,
we
are
now
stable,
but
we
are
always
looking
for
contributors.
So
if
you
want
to
try
us
out
and
report
any
issues
or
general
feedback,
we
would
love
to
hear
from
you.
If
you
have
interesting
user
stories
that
you
would
like
to
be
supported.
Those
are
definitely
welcome.
B
B
These
top
three
items
are
things
we're
actively
focusing
on
the
biggest,
I
think,
is
mutation,
which
is
pretty
heavily
requested,
so
we
have
an
active
design
out
for
that
which
is
pending
approval.
As
of
this
recording,
and
hopefully
by
the
time
you
see
this
we'll
be
in
development
for
mutation
for
an
alpha.
B
Another
area
of
emphasis
is
developer,
tooling,
for
writing,
constraint,
templates
and
making
that
process
a
little
easier
and,
as
I
said,
the
violations
as
kubernetes
events
feature
is
in
alpha.
So
we're
going
to
continue
to
think
about
what
that
story
looks
like
in
the
future,
and
these
other
items
are
things
we're
interested
in
and
we
have
our
eye
on,
but
the
top
three
are
where
we're
currently
directing
our
effort.
B
So
please
join
us.
You
can
contribute
to
open
policy
agent
by
visiting
their
github
repo
at
opengithub.com,
open
policy
agent,
slash
opa
or
you
can
look
at
gatekeeper,
github.com,
open
policy
agent,
slash
gatekeeper,
join
us
on
slack
or,
however,
you're
comfortable
communicating,
we'd
love
to
hear
from
you.