►
From YouTube: Istio’s Mixer: Policy Enforcement with Custom Adapters - Limin Wang, Google & Torin Sandall, Styra
Description
Istio’s Mixer: Policy Enforcement with Custom Adapters [I] - Limin Wang, Google & Torin Sandall, Styra
The Istio service mesh provides a highly extensible platform to connect, manage, and secure microservices. Istio’s highly extensible nature is one of the main selling points as it allows you to enforce your own organization-specific policies across large fleets of microservices. At the same time, new technology always has a learning curve, and with all this extensibility and generality the task can be quite daunting.
In this talk, Limin Wang (Software Engineer at Google) and Torin Sandall (Technical Lead of the Open Policy Agent project) explain how Istio’s Mixer works and lead a deep dive into Mixer Adapter development. The talk shows (with demos) how the Mixer Adapter model enables custom policy enforcement and how the model is used to integrate third party policy engines like the Open Policy Agent.
This talk is targeted at platform engineers interested in using the Istio service mesh to enforce custom policies in their microservices. The talk also provides new ideas about the kinds of policies that can be enforced in Istio today.
About Torin Sandall
Torin Sandall is the technical lead of the recent open source Open Policy Agent (OPA) project. He has spent 10 years as a software engineer working on large-scale distributed systems projects. Prior to working on the Open Policy Agent project, Torin was a senior software engineer at Cyan Inc. (acquired by Ciena Corp.) where he designed and developed core components of their SDN/NFV platform such as modelling languages as well services for resource orchestration and topology discovery. Torin has recently given talks on policy-related topics in Kubernetes at ContainerDaysPDX and LinuxCon Beijing as well as the Kubernetes Community Meeting and the Kubernetes SF meetup.
About Limin Wang
Limin Wang is a security technical lead for Istio and Cloud Endpoints projects at Google. Before joining Google, she was a senior software engineer at VMware. Limin holds a PhD degree in Computer Science from Michigan State University.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
B
A
Holly
and
I
are
going
to
talk
about
a
mixer
policy
enforcement
with
custom
adapters.
This
talk
has
two
parts
in
the
first
part,
I
am
going
to
give
an
introduction
of
our
East
EO
and
the
policies
in
steel
and
I'm
going
to
talk
about
how
to
enforce
your
custom
policy
in
East,
EO,
0
mixers
adapter
model
in
the
second
part,
Tory
is
going
to
talk
about
how
these
models
are
used.
It
will
integrate
open
policy
agent
to
e
steel
and
he
is
going
to
give
a
lifetime
of
it.
A
Ok,
so
what
it
is,
is
the
sto
I'm
trying
to
keep
it
brief,
because
we
already
had
a
lot
of
excellent
talking
still
so
easier
is
an
open
platform
to
connect,
manage
and
secure
Mac
resist
micro
services.
You
can
find
more
information
on
East
EO,
dot,
IO
and
github.com.
Slash
Easter,
Easter
service
mesh
can
be
split
in
four
data
plane
and
the
control
a
data
plane
is
composed
of
a
number
of
annual
proxies
that
are
deployed
as
a
sidecars
and
they
are
mediating
and
control.
A
Other
traffic's
between
services
controlling
has
the
three
components:
pilot
mixer
and
east
eros
pallet
is
responsible
for
managing
and
configuring.
The
my
proxies
to
route
traffic
mixer
is
responsible
for
enforcing
access,
control
policies
and
usage
policies
and
collecting
telemetry
data.
From
my
proxies
easter
AWS
provides
a
service
to
service
me
to
TRS
authentication,
and
it
also
provides
a
built-in
identity
and
a
credential
management.
A
A
Monitoring
policy
allows
you
to
specify
how
the
metrics
are
collected
and
how
the
logging
and
tracing
atong
the
existing
security
policy
allows
you
to
enable
service
to
service
military
authentication
for
the
service
mesh,
and
it
also
enforces
the
simple
authorization
rules
like
denial
request.
If
a
certain
condition
is
met
or
whitelist
a
blacklist,
the
service
consumers
and
we
provide
an
expression
language
for
you
to
define
conditions.
A
We
are
continuously
adding
more
policies
in
in
still
take
security
policy.
As
an
example,
we
are
adding
authentication
policy,
authorization
policy
and
the
auditing
policy,
which
we
call
Tripoli
policies.
The
upcoming
authentication
policy
will
allow
you
to
enable
or
disable
militarize
for
each
service
and
the
configure
end
user
authentication.
A
Also,
this
inside
we
are
adding
row
based
access
control,
which
provides
the
namespace
level
service
level
and
the
master
level
access
control
for
services
in
eastern
mesh
I'm,
going
to
show
an
example
of
how
up
a
policy
looks
like
in
the
next
slide,
and
we
are
also
integrating
with
the
open
policy
agent
to
address
more
complicated
solution,
use
cases
which
Tory
is
going
to
a
demo
next
and
in
the
meanwhile.
We
are
also
working
on
improving
the
expression
language
to
provide
a
richer
semantics.
A
Okay.
Here
is
an
example
of
how
a
Peck
policy
looks
like
on
the
left
side.
I
define
a
service
role
object,
it's
called
a
reveal
product
of
your.
It
allows
you
to
all
read
a
review
service
and
the
reader
product
service
on
the
path
slash
box,
slash
epoxy,
latest
on
on
the
right
side.
I
define
a
role,
binding
object,
service,
Roubini
object.
It
assigns
the
reveal
product
bureau
to
a
given
service
account.
You
can
specify
other
identities
like
a
user
or
some
chart
claims
or
other
attributes
to
specify
the
subjects
you
can
find.
A
A
A
Mixer
exposes
the
toy
ice
check
and
the
report
check
allows
you
to
do
precondition,
check
crota
check,
and
the
report
allows
you
to
telemetry
reporting
such
as
locks
and
matrix
mixer
achieves
the
high
extensibility
by
having
a
general-purpose
plug-in
model,
and
the
plugins
are
called
adapters
in
this
picture.
I
show
some
example
adapters
that
mixer
supported
a.
A
Mixer
is
a
tribute,
processing
and
routing
machine.
The
attributes
are
the
pieces
of
metadata,
does
describe
the
environment
and
the
traffic,
for
example,
request
dot,
pass
sort
of
IPS
or
user
tests
national
service.
These
are
all
attributes
request
arrived
at
mixer
with
a
set
of
attributes,
mix
the
processes,
these
attributes
and
maps
them
to
adapter
input.
A
We
call
we
call
them
instances.
Mixer
invokes
the
adapters
based
on
the
configuration
and
passes
this
input
to
the
adapters,
mixer
suppose
two
types
of
adapters,
the
standalone
adapter
running
mixer
process.
They
do
not
have
a
back-end,
for
example,
the
main
crota
adapter
and
the
organ
policy
agent
adapter.
That
Tory
is
going
to
add
my
next
a
standalone
adapters,
the
other
type
of
adapters
adapters
that
interface
to
a
back-end
system.
For
example,
a
struct
stock
driver
adapter,
belong
to
a
such
category.
A
A
A
Next,
you
need
to
determine
how
to
configure
your
adapter.
What
are
the
parameters
you
adapter
takes?
A
configured
instance
of
an
adapter
is
called
a
handler
and,
lastly,
you
need
to
determine
the
business
logic
for
your
adapter
to
handle
the
runtime
input.
You
can
find
more
information
on
adapter
developers,
Qaida,
which
at
is
github
link
points
to
okay,
not
as
quickly
walk
through
the
steps
of
a
building,
a
custom
adapter
using
a
very
simple
example.
Suppose
we
need
to
a
build
an
adapter
to
a
verify.
A
A
Okay,
so
the
first
step
is
to
alright
to
the
basic
adapter
scallion
encoder.
You
can
copy
it
from
our
online
tutorial
or
any
Beauty
adapters.
I
highlighted
at
the
part
that
unit
will
provide
a
adapter
information,
including
the
name
of
the
adapter,
the
description
of
the
adapter
and
the
templates,
the
adapter
supports,
and
you
can
also
provide
a
default
configuration
for
the
adapter.
A
A
Ok,
now
you
have
built
your
custom
adapter.
Let's
configure
our
policy
using
this
adapter,
so
we
want
to
check
that
the
source
version
is
in
and
specified
aversions
list
so
first
unit,
who
will
create
an
instance
of
list
entry,
template
called
a
source
version,
and
so
and
the
value
is
mapped
from
the
attribute
sourced
our
latest
version.
Then
you
create
a
handler
of
the
list.
A
Ajikko
adapter
is
called
a
virgin
checker
and
you
provide
a
parameter
which
is
the
list
of
versions
v1
v2,
and
then
you
create
our
track
version
policy
which
simply
passes
the
source
version
instance
to
a
virgin
checker
and-
and
you
can
also
specify
the
condition
when
this
policy
applies.
So
in
this
case
the
Czech
version
policy
applies
when
the
ratings
applica
applies
to
the
ratings
application,
and
now
you
can
apply
the
policy
and
the
easte
eoeo
infosys
is
the
way
enforce
the
policy
at
run
time.
B
Ok,
so
thanks
Leoben
sleeving
give
a
great
overview
of
how
you
can
take
it
mixer
and
extend
it
to
enforce
your
own
custom
policies,
and
the
other
thing
that
we
wanted
to
do
in
this
talk,
though,
is
sort
of
highlight
this
ecosystem
of
integrations
that
are
being
built
up
around
us
do
and
so
to
do
that.
What
we
thought
we
would
do
is
show
how
the
open
policy
agent
project
has
been
integrated
into
sto
and
and
give
you
guys
a
sense
of
what
you
what
you
can
do
with
that.
B
So
the
open
policy
agent
is
as
an
open
source,
general-purpose
policy
engine,
and
what
that
means
is
that
you
can
use
it
basically
in
any
system
and
any
letter,
the
stack
to
offload
policy
decisions,
and
so
one
of
the
obvious
applications
for
oppa
is
API
authorization,
because
you
know
pretty
much.
Every
single
organization
has
to
be
able
control
who
can
do
what
across
their
micro-service
api's.
B
So
OPA
you
can
use
it
for
things
like
kubernetes
and
Cloud,
Foundry
and
and
docker
and
and
so
on,
but
here
we're
gonna
be
focusing
on
Castillo
and
this
this
new
integration
that's
been
built.
So
the
core
of
OPA,
though,
is
this
declarative
language
that
lets
you
codify
your
policies
when
it
gives
you
these
these,
these
this
policy
language,
the
latest,
write,
write
rules
that
answer
questions
like
is
X
allowed
to
call
Y
on
on
Z.
B
Now
it's
designed
to
be
as
lightweight
as
possible,
and
so
we
don't
have
any
external
dependencies
at
runtime,
and
so
all
the
policies
and
the
data,
and
so
on
that
it
uses
to
evaluate,
are
all
stored
in
memory,
so
doesn't
introduce
any
dependencies
onto
an
external
database
or
an
external
service,
or
anything
like
that.
You
take
it
and
you
deploy
it.
B
So
it's
very
easy
to
get
up
and
running
and
use
it,
and
so
the
whole
goal
with
the
project
is
to
give
the
community
this
reusable
building
block
that
that
people
can
leverage
to
enforce
policies
up
and
down
the
stack
using
a
unified
holistic
approach
with
with
a
language
that
is
suitable
for
all
these
different
kinds
of
things.
So
what
we
did
and
what
the
team
at
SDO
did
was
take
OPA
and
they
integrated
Indian
mixer
as
an
adapter
as
a
check,
adapter
and
the
so.
B
The
way
this
works
is
that
when
envoy
receives
incoming
traffic,
it
executes
this
check,
RPC
call
against
mixer
and
when
it
does
that
it
provides
a
bunch
of
attributes
that
describe
the
request.
So
things
like
the
method
and
the
path
and
the
headers
and
so
on,
and
then,
when
that
RPC
request
arrives
at
mixer,
mixer
looks
at
the
adapter
to
run
and
it
dispatches
it
to
the
adapter
in
this
case
OPA,
which
makes
a
policy
decision.
B
Now,
when
you,
when
you
configure
OPA
you
as
an
operator,
you
tell
it
what
inputs
you
want
to
provide
to
the
adapter,
and
so
you
can
basically
map
any
of
the
sto
attributes.
Anything
in
the
SPO
vocabulary
into
these.
These
collections,
these
subjects
and
action
collections,
and
so
it's
very
flexible
and
you
as
an
operator
get
to
decide
what
data
you
you
pass
off
to
the
policy
engine
now.
B
Ok,
so
when
you
actually
have
to
configure
OPA,
the
first
thing
you
have
to
do
is
create
a
rule,
and
so
this
is
an
sto
concept
and
mixer
concept,
and
so
what
these
rules
do
is
they
tell
you
or
they
tell
mixer
what
just
like
when
to
send
requests
off
to
adapters?
And
so,
in
this
case
we've
just
created
a
single
rule
that
says,
send
all
the
requests
to
the
OPA
handler
or
open
adapter,
and
when
you
do
that
supply
the
auth
authorization
instance
data.
B
Okay,
so
the
last
thing
you
have
to
do
after
you've
configured,
you
know
when
to
send
requests
to
adapters
and
then
what
to
send
to
adapters.
You
need
to
describe
what
to
do
when
the
adapter
receives
traffic,
and
so
that's
what
the
handler
configuration
is
for.
So
the
handler
configuration
is
always
going
to
be
specific
to
that
to
the
handler,
because
it's
in
this
case
it's
saying,
okay.
B
First
of
all,
the
check
method
to
run
inside
the
policy
is
authorization
dot
allow,
and
then
we
actually
take
the
OPA
policy
and
we
embed
it
directly
into
the
configuration
here
just
as
a
string,
and
so
this
is
just
a
really
simple
policy
that
says
by
default.
Requests
should
be
denied,
but
if
they're
performing
a
read
operation
then
you
can
allow
them.
Okay,
all
right.
So
let's
see
how
this
actually
works.
C
B
So
then
we
can
take
a
look
at
that
instance
data,
and
so
here
we've
configured
it
so
that
it
sends
in
the
the
source
and
destination
namespace
and
services,
the
headers,
from
the
request,
the
method
from
the
request
and
the
path
and
then
finally,
we've
got
the
OPA
handler
configured
and
right
now.
This
is
the
same
kind
of
configuration
you
saw
before,
but
in
this
case
it's
just
allowing
all
the
traffic
by
default.
B
Okay,
so
what
I
have
right
now
is
the
policy
on
the
left
and
the
application
are
started
application
on
the
left
and
then
the
policy
on
the
right
and
I
have
a
script.
That's
watching
the
policies
on
my
machine
and
then
reloading
them
in
sto
whenever
they
change
and
so
right
now
we
just
have
a
simple
policy
here
that
says
that
by
default
requests
should
be
denied.
However,
if
this
other
service
graph
policy
allows
the
request,
then
they
should
be
good,
then
you
should
go
ahead
and
allow
it.
B
So,
let's
take
a
look
at
the
service
graph
policy,
so
the
service
graph
policy
defines
the
allowed
connectivity
for
applications
running
on
top
of
sto
right
now,
and
basically,
these
allow
rules
below
here
interpret
that
that
data
structure
to
decide
whether
the
incoming
service
is
allowed
to
talk
to
the
destination
service.
Now
the
thing
is
that,
right
now
the
allow
rule
is
defaulting
to
true,
which
is
probably
not
good
from
a
best
practices
point
of
view.
B
So,
let's
change
that
to
false
and
we
can
see
that
the
policy
reloaded
hopefully-
and
now,
if
I
refresh
the
page,
it
still
works,
but
we
don't
see
the
product
reviews
anymore,
and
so
the
reason
for
that
is
that
the
product
page
is
not
allowed
to
talk
to
the
review
service.
So
let's
change
that
and
then
once
the
policy
reloads,
the
reviews
show
up,
which
is
great,
and
so
this
just
shows
how
you
can
write
these,
these
high-level
policies
that
are
very
dynamic
and
can
be
reloaded
on
the
fly
without
requiring.
B
B
B
However,
if
you're
a
manager
and
you're
accessing,
if
you're
manager
you'll
be
allowed
to
see
everything,
but
if
you're,
if
you're
just
on
shelving,
if
you're,
not
a
manager,
then
you'll
be
denied
if
you're
trying
to
access
these
sensitive
book
reviews,
okay,
so
in
order
to
make
that
actually
take
effect,
I
need
to
hook
it
up
to
the
top
level
here.
So
I'm
gonna
say
now
basically
a
deny
by
default.
B
This
organization
chart
data
is,
is
hard-coded
into
the
policy
right
now,
but
there
are
other
ways
to
get
data
and
so
on
into
OPA
that
are
more
efficient,
and
so
this
is
just
here
because
it
allows
us
to
easily
change
during
the
during
the
demo.
Okay,
and
so
then
a
lot
last
thing
I
want
to
show
is
how
you
can
enforce
policies
that
take
into
account
some
kind
of
context,
and
so
the
bookstore
has
developed
a
strange
idea.
They
want
to
allow
reviewers
to
look
at
book
reviews
after
4
p.m.
B
for
some
reason,
and
so
we
can
add
another
policy
here
and
what
its
gonna
do
is
check.
Whether
or
not
the
incoming
user
is
on
the
reviewer
team
and
then
it's
going
to
check
whether
the
current
date
and
time
is
between
4:00
p.m.
and
midnight,
and
so
because
this
policy
is
part
of
the
organization
chart
package.
That
answer
gets
composed
with
the
previous
one
about
sensitive
api's,
and
so
now,
if
I
try
to
sign
in
as
Bob
again,
we
should
be
able
to
see
the
reviews.
Okay,
so
that
worked.
B
But
if
I
try
to
sign,
as
can
the
poor
guy
doing
book,
shelving
he's
he's
still
unable
to
see
those
reviews.
So
that's
the
demo
switch
back
to
the
slides
so
oppa.
You
know
it
gives
everybody
this.
This
reusable
building
block
that
you
can
use
to
enforce
all
kinds
of
drug
policies
across
the
stack,
but
it's
particularly
useful
for
enforcing
authorization
decisions
in
your
micro
services,
and
this
is
super
important,
because
it's
not
enough
to
just
authenticate
users.
You
need
to
be
able
to
control
what
those
users
can
do.
B
Sto
is
great
because
it
has
this
fantastic
plug-in
framework
that
allows
you
to
plug
in
things
like
OPA,
as
well
as
other
adapters
for
authorization
and
quota
and
telemetry
and
so
on,
and
the
plug-in
framework
makes
it
pretty
easy
to
get
get
up
and
running
with
this,
and
the
documentation
is
great,
so
I
encourage
everybody
to
check
that
out,
and
so
finally,
if
you're,
if
you're
interested
in
security
you're
into
sto,
please
come
and
join
the
the
security
sig
and
check
out
the
projects
on
github,
star
them
and
yeah.
So
thank
you
very
much.
B
D
B
D
B
Okay,
okay,
so
for
the
first
question
about
how
you
get
external
data
into
OPA,
so
it
provides
api's
that
allow
you
to
push
data
in
okay,
so
you
can
load
arbitrary,
JSON
data
into
OPA
and
then
write
policy
over
it.
So
if
you
can
get
your
data
out
of
LDAP
or
workday
or
whatever
that
describes
your
organization,
you
can
load
that
into
OPA.
The
other
thing
you
can
do
is
stick
like
an
authenticating
proxy
in
front
of
OPA.
B
A
B
Then
so,
then,
for
the
second
part
of
your
question,
so
OPA
gives
you
a
test
framework
to
write
unit
tests
for
your
policies
in
and
then
you
can.
It
gives
you
a
test
runner,
so
you
can
like
execute
all
the
unit
tests
in
your
in
your
in
your
policy
code
base.
If
you
will
and
then
yeah
we're
looking
to
improve
that,
to
give
you
things
like
coverage
and
profiling
and
so
on,
yeah,
okay,
next.
B
So
the
question
is:
how
do
you
log
decisions
that
have
been
made
inside
of
Ischia
or
OPA
so
oppa
has
up,
has
a
framework
that
allows
you
to
plug
in
and
figure
out
when
a
decisions
been
made
like
the
top
level
decision,
so
you
could,
if
you're,
integrating
oppa
you
can
you
can
get
that
and
you
can
you
can
send
it
out.
However,
you
want,
but
I
think
that
women
can
probably
answer
how
sto
helps
you
there
yeah.
A
B
Okay,
so
in
the
demo
the
username
is
passed
in
a
very
secure
way
through
the
cookies
in
the
header,
and
then
the
policy
like
parses
that
cook
I
didn't
show
the
policy
that
parses
the
cookies
but
there's
little
helper.
That's
parsing
the
ahead,
the
username
out
of
the
out
of
the
headers,
but
then
I
think
that
sto
is
God
right.
B
A
The
policies
are
actually
started
in
the
East,
your
config
storm,
actually,
currents
are
into
the
API
server
and
the
policy
can
be
either
in
foster
our
mixer
or
my.
So
if
it's
a
in
first
our
mixer,
then
the
policy
supported
by
the
mixer,
if
it's
in
foster
on
my
the
imperative,
is
going
to
a
portion
of
the
policy
to
my
proxies
pilot,
who
is
going
to
get
the
configuration
from
the
east
EO
config
store
they're.
Actually,
it's
not
going
through
mixer
and.
B
A
Yeah
so
my
proxy,
we
have
a
lot
of
caching
and
the
same
as
our
mixers,
either
so
yeah,
so
okay
I
can
be
impacted
either
to
a
mixer
or
on
the
invoice
idle.
In
this
case,
we
integrated
or
with
a
mixer,
because
the
mixer
is
more
extensible-
is
actually
designed
for
extensibility.
So
it's
easy
to
integrate
any
other
policy
engine
mixer.
B
B
Yeah,
so
the
question
is
whether
the
decision
that
oppa
makes
can
be
cashed,
so
I
think
it's
cached
in
two
places,
so
it's
cached
at
envoy
at
the
in
the
data
plane
and
then
inside
of
mixer
there's
a
more
sophisticated
cache
strategy
where
it
like
it
caches
decisions
for
each
of
the
adapters,
basically
that
it
run,
and
so
it's
got
very
fine-grained
caching
and
mixer.
So
there's
two
two
levels:
yeah.
C
A
Think
my
cider,
we
are
cashing
the
request
going
out
and
basically,
the
requests
going
out
and
check
result.
So
my
cost
mixer
check
and
the
report
ap
is
so
whatever
the
check
requests
sending
out
ended
the
check
result
and
also
the
reports
any
out
is
all
being
cashed
and
on
the
on
the
mix.
Insider
I
think
the
like
the.
In
the
OPI
case,
though
we
can
catch,
the
oscillation
results
like
what
other
oscillation
requests
and
what
are
the
result
and
because
mixer
is
a
centralized
component.