►
Description
Join us for Kubernetes Forums 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
OPA Policy Templating and Testing - Tejas Cherukara, ANZ Bank & Ben Ebsworth, Digio
Speakers: Tejas Cherukara, Ben Ebsworth
Ever since its inception and acceptance into CNCF, OPA has been widely regarded as the default policy evaluation tool in the Cloud Native landscape. Due to the functionality that OPA provides, it was quickly adopted as a control point but did not scale as expected. This talk discusses the significant role OPA plays in a large banking context, and how we went about productionising the deployment across a number of use-cases.
A
Hello
how's
everyone
going
so
today
we're
going
to
be
talking
about
OPA
policy
and
how
you
can
go
about
testing
and
production
izing
and
go
about
improving
the
overall
process
of
delivering
OPA
policy
and
in
a
production
environment.
My
name
is
Ben
and
I'm
dizzy
Oh,
my
name
is
stager
somewhere
they
own
Zed,
okay.
So
let's
that's
kind
of
just
do
a
quick
overview
here
of
how
many
people
have
heard
of
OPA.
A
So
hopefully,
out
of
this,
we
kind
of
get
to
get
a
bit
of
a
feel
for
some
of
the
things
that
we've
kind
of
thought
about
and
some
of
the
measures
we've
taken
to
improve
the
kind
of
production
ization
aspects.
So
if
I
give
it
just
a
really
quick
overview
because
there
was
a
precursor
session
I
guess
it's
not
worth
necessarily
going
deep
onto
this,
but
just
the
main,
the
main
aspects
of
OPA.
B
Yeah,
so
one
of
the
major
use
cases
of
OPA
is
to
provide
some
dev
guardrails,
often
in
companies.
We
have
high
feature
cadence,
you
know,
you
know
let
developers
prototype
and
have
their
own
segments
cluster
which
they
can
administer
so
in
in
such
scenarios,
we
can
then
had
deployed
OPA
in
order
to
provide
some
guardrails
or
some
like
restraints
in
to
in
there
in
the
clusters.
B
So
one
of
the
major
examples
that
come
into
mind
when
we
talk
about
dev
guardrails
is
the
use
of
like
external
versus
internal
load
balancers,
so
different
cloud
providers
have
different
annotations
that
you
add
to
services
in
order
to
specify
whether
it's
an
internal
or
an
external
load
balancer.
Now
it's
often
times
we
forget
to
add
this
annotation,
so
we
can
instead
use
opa
to
police
police
this
and
ensure
that
all
services,
all
these
services
with
these
annotations,
are
actually
deployed
into
the
cluster.
B
Now
security
is
another
major
aspect
which
OPA
can
be
very
applicable,
and
one
of
the
major
of
use
cases
of
this
would
be
to
actually
isolate
a
sensitive
workloads
into
different
node
pools.
Essentially,
we
can
have
the
functionality
of
having
any
any
workloads
that
are
deployed
in
namespace
a
be
deployed
to
a
specific
node
pool.
Now
this
might
be
because
of
compliance
requirements,
or
if
you
have
specific,
yes,
specific
compliance
or
sensitive
workloads,
you
want
to
make
sure
that
that
is
separated
from
your
other
workloads.
B
B
Often,
enterprises
need
to
inject
metadata
information
such
as
which
team
owns
this
or
which
billing
account
assist
with
this
deployment
associated
with,
and
so
all
this
administrative
metadata
is
required
to
deploy
into
a
cluster
at
times
now
for
a
development
it
can
often
be
cumbersome
in
order
to
have
to
do
that,
every
single
time
they
prototype
or
deploy
something
something
into
the
cluster.
So
we
can
instead
offload
this
capability
into
the
platform
team.
B
A
So
now,
if
we
actually
touch
on
some
of
the
production
requirements,
we
had
going
into
the
overall
aspects
of
deploying
OPA,
so
in
a
large
kind
of
enterprise
context.
These
are
some
of
the
requirements
that
we
were
looking
at,
primarily
so
as
part
of
the
overall
development
process
of
the
underlying
OPA
policy.
Some
of
the
focuses
we
had
was
effectively
simplifying
and
making
it
easier
to
extend
and
continuously
develop.
A
So,
for
example,
you
might
be
wanting
to
mutate,
you
might
be
wanted
to
do
with
admission
validation,
and
so
you
could
have
a
reference
to
a
common
library
function.
That
would
then
give
you
most
of
that
capability
out
of
the
box,
and
so,
if
we
take
a
look
at
what
this
would
look
like,
is
you
effectively
have
just
a
common
package
where
you
would
define
all
of
your
common
functions
and
then
those
would
be
referenceable
in
your
higher-order
functions
which
are
actually
implementing
your
specific
capability,
and
so
you
can
see
in
this
scenario.
A
Here
we
have
some
mutations,
so
a
mutation
of
a
label,
and
so
we're
using
is
just
a
basic
function
here
to
just
check
to
see
if
it
has
a
label,
and
so
this
is
an
example
of
how
we
can
go
about
simplifying
the
the
readability
as
well.
So
now
that
we
can
reference
a
kind
of
a
core
library
function,
we
now
have
the
ability
of
referencing
that
and
using
it
and
reducing
the
overall
code
that
would
go
into
a
specific
function.
Higher-Order
function.
A
Another
scenario
we
looked
at
was
effectively
trying
to
be
admission,
controller,
agnostic,
and
so
what
we
mean
by
that
is
effectively
that
there's
different
solutions.
You
can
use
to
overall
implement
OPA
inside
of
a
kubernetes
environment
where
you
can
use,
for
example,
just
the
raw
OPA
server
itself,
in
combination
with
cube
manager
to
then
go
about
just
effectively
applying
config
Maps
and
then
having
that
OPA
policy.
The
read
read:
policy
Rhaego
policy
rather
directly
go
into
the
the
kubernetes
environment.
A
Now,
an
alternative
to
that
is
to
use
gatekeeper
where
you
have
a
different
controller
that
will
consume,
see,
IDs
and
go
about
achieving
a
similar
function
where,
for
example,
that
might
try
and
reduce
the
cognitive
complexity
in
delivering
OPA
into
a
given
environment,
where
you
have
a
nicer
way
of
representing
it
using
gatekeeper,
and
so
what
we
wanted
to
do
is
effectively
generalize
that
or
decouple
it
where
we
use
templating.
So
in
our
case,
we're
using
ginger
to
to
go
about
building
out
all
of
our
raw
Reggio
policy.
A
And
so
this
gave
us
the
ability,
once
we
were
decoupled
like
this,
to
be
able
to
support
things
like
gatekeeper
and
pretend
she
even
inter
changeably
support,
both
at
the
same
time
as
the
community
would
evolve
in
how
they
go
about
applying
OPA
policy.
So,
just
to
kind
of
show
what
we
mean
by
templating:
we've
got
this
ability
here
to
iterate
over
like
high-level
config
values
and
generate
all
of
the
Associated
OPA
policy
that
that
would
then
translate
to.
A
So
if
a
developer
needed
to
add
some
extra
capability
or
reduce
the
number
of
controls
or
extend
them
on
their
specific
namespace,
we
want
them
to
do
that,
not
necessarily
through
raw
Reggio
policy,
but
through
a
higher-level
representation
where
we
would
be
as
the
platform
team
responsible
for
that
abstraction
and
managing
then
the
extension
when
they
did
have
new
requirements
and
so
just
to
see
what
we
mean
by
that
as
well.
We
have
effectively
a
higher
level
yeah
more
representation
of
that,
and
so,
in
this
case
here.
A
More
develops
would
be
expected
to
potentially
manage
that
OPA
policy
for
their
given
environments.
We
wanted
to
also
have
a
higher
level
of
reliability
on
the
overall
functionality
of
the
OPA
policy
being
templated
and
applied
to
our
environments,
so
as
part
of
that
templating
that
we're
doing
we're
also
automatically
generating
all
of
the
Associated
unit.
Tests
are
needed
for
each
of
those
functions,
and
so
this
gave
the
final
result.
A
And
so,
if
we
have
a
look
at
what
a
unit
test
effectively
translates
to
an
OPA,
it's
just
another
function
that
goes
about
doing
a
specific
validation,
and
so
we
can
see
here
that
it's
doing
that
same
templating
that
we
were
doing
for
the
high-level
functions
as
well.
So
we
kind
of
get
them
in
unison.
So,
when
we're
generating
specific
bespoke
function,
we
generate
the
corresponding
unit
test,
so
I'm
gonna
now
hand
it
to
teachers.
Who's
gonna
walk
us
through
the
final
requirement
we
had
here,
which
was
integration,
testing,
yeah,.
B
So
integration
testing
so
taking
inspiration
from
like/comment
software
development
practices.
We
wanted
to
ensure
that
we
integration
test
each
of
our
OPA
policies
before
deploying
it
to
dev
clusters
or
non
prod
or
even
prod.
Now,
in
context
to
OPA,
we
wanted
to
ensure
that
once
the
bottom,
once
the
policies
are
in
the
cluster,
we
wanted
to
make
sure
that
it
was
compiled
and
recognized
by
OPA
as
needed.
We
wanted
to
make
sure
that
the
validation
policy
returns.
B
The
expected
error
that
we
would
expect
it
with
I
would
expect
it
to
return
and
that
the
mutating
policy
appropriately
mutates
the
resources,
as
we
would
expect
there
till
now.
Looking
at
the
toolset
testing
tool
set
that's
available
in
the
current
environment,
we
didn't
really
find
anything
that
could
particularly
fit
all
three
of
our
requirements.
So
the
closest
thing
that
we
found
out
was
about
the
contest
which
does
structure,
conflict
testing
against
OPA
policies.
B
Fantastic
tool
enables
us
to
do
validation,
policy
checks,
but
it
doesn't
enable
us
to
test
against
a
real
cluster
or
it
doesn't
enable
us
to
test
for
the
mutating
policies.
So
we
came
up
with
a
small
goal
line.
Cli
tool
that
that
enables
us
to
interact
and
test
with
a
real
cluster.
So
it's
essentially
a
library
of
assertion,
functions
which
enable
you
to
prototype
and
develop
Kuban
Eddie's
components
with
a
very
test-driven
approach,
so
it
essentially
enables
developers
to
easily
reason
about
and
develop
integration
testing
for
different
kubernetes
components.
B
As
you
can
see,
the
interface
of
this
kind
of
looks
like
a
CR
D,
which
provides
a
similar
which,
which
means
that
developers
are
able
to
define
the
integration
test,
the
same
way
that
they
would
be
able
to
define
their
deployments
now.
Taking
a
closer
look
at
the
actual
spec
of
ankus
ETL
so
similar
to
other
testing
frameworks
and
caseta
actually
allows
you
to
bootstrap
your
testing
environment.
B
It
allows
you
to
deploy
the
testing
namespaces
and
the
and
any
any
resources
that
you
can
then
reference
at
a
later
test
in
order
to
ensure
that
it
is
working
as
expected,
it
has
the
functionality
of
looking
up
a
resource
from
an
existing
cluster
or
being
able
to
create
a
new
resource.
Now
these
functionalities
can
then
be
used
at
later
test
stages
in
order
to
assert
that
it
is
functioning
as
you
expect
it
to
now
asserting
the
API
interactions
to
actually
assert
that
the
validation
policy
works.
B
You
need
the
capability
of
applying
a
resource
into
the
cluster,
taking
the
error
that
the
cube,
API
server,
outputs
and
then
making
sure
that
that
error
approximately
matches
the
error
that
you're
expecting
it
to
so
anka
CTO
provides
a
way
of
asserting
asserting
API
interactions.
The
other
thing
it
also
helps
do
is
to
assert
Jason
pats.
So
if
there's
an
object
in
the
light,
cluster
you're
then
able
to
look
up
the
resource,
that's
in
the
cluster
and
then
assert
that
adjacent
path
of
that
resource
is
what
you
expect
it
to
be
now.
A
Okay,
so
we've
kind
of
gone
through
quite
a
lot
of
material
here,
we've
kind
of
walked
through
a
number
of
steps
that
we've
gone
about,
implementing
to
improve
the
kind
of
production,
ization
and
reliability
that
we
have
in
our
OPA
deployments,
and
so
we're
gonna
actually
kind
of
bring
this
all
together
with
an
actual
demonstration
where
we're
going
to
connect
all
the
dots
but
Before.
We
jump
into
that.
A
Is
it's
going
to
trigger
a
Tecton
pipeline
now,
if
you're
not
familiar
with
Tecton
tech
tongs
is
effectively
an
arbitrary
pipeline
engine
solution
that
allows
you
to
build
pipelines
like
you
would
in
github
actions
or
other
solutions
where
you
can
actually
run
everything
inside
of
kubernetes
and
because
we're
at
the
kubernetes
forum,
it's
cool
to
actually
be
able
to
run
everything
inside
of
the
same
kind
of
environment,
and
so
I've
raised
that
pull
request.
What
that's
going
to
do
is
it's
going
to
then
create
the
that's
going
to
trigger
a
web
hook.
A
The
first
thing
we're
going
to
do
is
that
templating
aspect
so
we're
going
to
generate
all
of
our
policy
we're
going
to
do
the
generation
of
our
test
cases
as
well,
and
then,
in
addition
to
all
of
that,
we're
actually
going
to
convert
the
policy
we've
generated
into
config
maps.
So
we
can
actually
apply
it
to
the
environment,
we're
going
to
try
and
do
our
integration
testing
on
so
once
that's
passed.
We
actually
then,
are
going
to
run
our
unit
tests,
so
our
unit
tests
are
simply
going
to
execute
the
OPA
test.
A
Entry
point
where
it's
only
going
to
run
against
all
of
the
generated,
read,
read
policy
and
then
give
you
a
test
coverage
report
and
we'll
see
that
in
action
shortly
once
those
two
have
passed,
we
then
go
into
the
integration
testing
phase.
Now
this
is
by
far
one
of
the
most
interesting
scenarios
here
where,
when
we
say
integration
test
were
actually
going
to
be
running
the
validation
process
that
tasers
walk
through
that
anchor
CTL
gives
us
insider
or
against
a
real
kubernetes
environment.
A
That's
been
you
ephemeral,
II
spun
up
specifically
for
this
CI
pipeline,
and
so
the
way
we're
doing
that
is
we're
using
kind
which
is
kubernetes
and
docker,
which
is
running
inside
of
a
kubernetes
pod.
So
in
this
scenario
here
we're
actually
running
kubernetes
inside
of
cuba,
Nettie's,
which
is
pretty
cool.
So
let's
jump
into
that.
So
I'm
just
gonna
raise
a
PR
here
and
then
we're
gonna
walk
through
what
happens.
A
So,
if
I
create
a
pull
request,
so
I've
already
prepared
this
earlier,
just
so
that
we
weren't
doing
some
live
coding,
which
would
be
quite
scary.
We're
gonna
create
a
pull
request,
and
this
has
all
of
the
associated
changes
for
a
specific
feature
that
someone's
adding
hypothetically,
where
it's
going
to
be
updating
the
OPA
policy
interface.
It's
going
to
be
defining
some
anchor
CTL
changes,
as
we
just
walk
through
that
here,
it's
going
to
have
the
ability
of
setting
up
some
specific
resources.
A
So
in
this
case
here
let's
say
we
need
to
create
a
certain
namespace
before
we
run
our
tests,
and
so
in
this
case
here
we're
just
defining
effectively
the
actions
we
need
to
take
initially,
we're
then
going
into
defining
our
assertion.
So
our
test
cases,
and
in
this
case
we're
just
saying
that
we
expect
a
certain
path
within
the
resource
that
gets
created
to
have
a
certain
value.
A
A
Okay,
so
now
in
Tecton-
let's
just
because
we
did
that
so
many
times,
it's
just
triggered
a
few.
Let
me
just
stop
those,
so
we
can
see
here
that
that
web
book
is
triggered
effectively
the
start
of
the
Tecton
pipeline
run,
and
so,
if
we
jump
into
here
and
actually
what's
happening,
if
we
just
wait
a
moment
is
we
can
see
that
the
first
step
here
is
generating
the
OPA
policy,
and
so
we've
defined
effectively
the
necessary
steps
to
go
about
generating
those
necessary
policies.
So
we
actually
look
at
the
details.
Here.
A
Is
we've
just
got
to
make
entry
point
here?
That's
kicking
off
all
the
necessary
steps,
and
just
as
it,
by
the
way,
we're
going
to
have
references
to
all
of
the
necessary
code
we're
running
here.
So
you
can
potentially
follow
this
in
your
own
pace
and
kind
of
get
a
feel
for
how
all
this
looks
so
what's
happening
in
Tecton.
Is
it's
now
running
those
steps?
A
So
we
can
see
in
the
logs
here
it's
generated
all
of
our
OPA
policy,
and
so
once
this
steps
complete
we're
actually
going
to
see
the
next
step
kickoff,
which
is
actually
going
to
be
the
stage
to
actually
generate
or
run
on
our
OPA
policy
test
cases
before
then
getting
to
the
next
step.
And
so,
if
we
have
a
look
inside
of
github
here
as
well.
A
You
know
github
actions
we
can
see
here.
The
github
status
API
is
being
used
to
actually
show
us
the
stage
in
which
the
those
those
testing
phases
are
running.
So
we
can
see
the
generation
has
been
successful.
So
hypothetically,
you
could
introduce
a
change
which
breaks
that,
and
so
you
could
fail
quickly
and
give
the
feedback
that
that
step
failed.
The
next
two
steps
that
are
still
pending
here
at
the
unit
tests
and
integration
tests.
So
if
we
just
see
what
OK's
tacked
on
is
doing
so.
A
I
believe
this
is
actually
the
Wi-Fi
okay,
so
the
unit
tests
of
now
run
successfully-
and
we
can
see
here
that
all
those
unit
tests
that
were
generated
have
now
successfully
run
and
we
can
see
that
53
out
of
53
have
successfully
passed.
So
that's
effectively
demonstrated.
We've
got
that
hundred-percent
test
coverage.
We've
got
all
of
our
unit
tests
passing
the
next
step
is
the
actual
spinning
up
of
the
cube
cluster
inside
of
a
kubernetes
pod.
To
then
run
our
integration
test
against
a
real
life
like
kubernetes
environment.
A
So
those
OPA
images
need
to
be
loaded
into
kind,
so
that
then,
when
you
create
the
OPA
deployment
inside
of
the
client
cluster,
the
images
are
there
so
that
it
can
stand
up
your
environment,
and
so
we
can
see
here
it's
just
going
about
its
its
way,
spinning
everything
up
and
so
then,
once
that's
successful.
The
next
step
is
going
to
kick
off,
which
is
going
to
be
to
deploy
OPA.
A
So,
what's
happening
in
this
step
here
is
we're
effectively
doing
what
you're
doing
a
real
nonprofit
or
production
environment
where
you
would
deploy
OPA,
but
this
time
we're
actually
targeting
effectively
that
kind
cluster
which
is
running
inside
of
a
kubernetes.
It's
like
nested
kubernetes,
and
so
once
that's
successfully
up
and
running,
we're
actually
able
to
then
deploy
our
OPA
policy
and
then
we're
gonna
go
about
doing
the
whole
validation
process
that
that
OPA
policy
is
doing
what
we
expect.
A
So
this
isn't
particularly
active.
But
what
you
can
see
here
is
this
is
the
test
report
that's
produced
as
part
of
ankor
CTO,
where
we
can
see
that
these
specific
use
cases
these
specific
test
cases
have
passed.
So
we
can
see
here
that
we've
done
a
JSON
parser
past
assertion,
validating
that
the
config
maps
that
we
applied
to
the
cluster
of
those
reg
wrote
policies
meet
the
certain
expectation
that
the
status
is
okay
and,
as
tages
mentioned
before,
what
that's
doing
is
it
saying?
A
Finally,
we
get
the
overall
kind
of
report
coverage
here
which
tests
pass
and
which
tests
failed,
and
so
that
overall
gives
us
the
end-to-end
pipeline
of
how
we
can
actually
go
about
implementing
all
of
those
steps.
And
if
we
have
a
look
at
the
github
status,
we
can
see
all
checks
have
passed,
and
so
now
that
true,
that
policy
should
be
valid
to
effectively
merge
into
master.