►
Description
Learn more about Kong: https://bit.ly/2I2DypS
Applications architected as microservices are becoming more prevalent every day, but just like their monolithic ancestors, microservice applications must adhere to organization-wide constraints around compliance, security, performance, etc. Authorization — controlling which people and machines can perform which actions — is a foundational security problem that requires new solutions in a microservice world because of changes in requirements around performance, availability and even where authorization gets enforced architecturally.
This talk discusses these new requirements, architectural choices for how to satisfy them and modern technologies for rolling them out. We describe taking a policy-as-code approach, where authorization policies are decoupled from the underlying microservices yet employ a shared-fate evaluation model so that policies are consistent, enforced consistently, meet high-availability and performance demands, and enable relatively rapid security reviews and hot-patching. Specifically, we describe how to employ the Open Policy Agent for a unified approach to policy-as-code, where policies are enforced through the Kuma service mesh.
A
Welcome
everybody
to
this
far
side
chat
with
the
team
and
math.
Today
we're
going
to
be
talking
a
little
bit
about
technology
and
also
about
the
important
role
that
maintainers
have
when,
when
managing
an
open
source
project,
a
successful
open
source
project.
So,
let's
start,
let's
start
by
you
know
doing
a
quick
round
of
introductions.
My
name
is
marco.
I'm
the
cto
co-founder
of
kong
matt.
You
want
to
start.
B
Sure
happy
to
be
here.
Thank
you.
My
name
is
matt
klein,
I'm
a
software
engineer
at
lyft,
where
I
spend
my
time
leading
the
infrastructure
team
and
then
that's
about
50
of
my
time
and
then
the
other
50
of
my
time.
I
work
within
the
cncf
I'm
on
the
toc,
I'm
on
the
governing
board
and
I
help
lead
the
open
source
proxy
project
called
envoy.
C
B
B
So
having
previously
worked
with
existing
proxies
like
nginx
and
aj
proxy
and
had
built
an
edge
proxy
proprietary
to
twitter,
I
I
had
a
inclination,
you
know
that
we
could
do
something
different
and
that's
where
envoy
came
from,
and
actually
just
really
briefly
at
lyft
envoy
originally
was
was
not
a
service
mesh
proxy.
We
actually
deployed
it
first
as
an
edge
proxy
just
to
get
better
observability
into
all
the
api
calls
coming
into
our
system
and
then
very
quickly.
After
that
we
ran
it
on
our
monolith.
B
You
know
so
that
was
our
first
service
to
service
case
started,
to
use
it
to
proxy
to
mongodb
to
you
know,
deal
with
observability
and
reliability
problems
there
and
then
the
rest
is
history.
We
deployed
it
everywhere
across
all
services,
and
you
know
to
to
give
us
the
service
mesh
that
we
have
today.
B
B
Well
right,
so
we
we
made
envoy,
so
you
know
the
control
plane
built
up
around
envoy.
You
know.
In
the
beginning,
it
was
basically
bundling
static,
config
files
with
with
onboard
binaries,
and
then
we
built
you
know
the
initial
rest
apis
that
eventually
became
xds,
and
then
we
built
more
rusty,
more
rest
apis,
and
then
we
built
the
grpc
apis
and
built
our
internal
control
plane.
C
They
built
it
simply
to
to
solve
the
problem
of
policy
and
authorization
across
many
different
pieces
of
software,
and
so
when
we
started
the
the
company
at
some
point,
we
knew
that
that
was
a
very
real
problem,
certainly
in
a
number
of
verticals,
those
that
were
heavily
regulated,
and
so
you
know
what
we
built
in
terms
of
opa.
Was
this
general
purpose
solution
to
the
the
authorization,
the
policy
problem?
C
The
idea,
of
course,
was
to
make
sure
that
you
could
have
one
unified
solution
to
authorization
that
would
work
for
really
any
kind
of
any
kind
of
software.
You
know
in
in
theory,
at
least
and
and
where
we
started
was
really
the
cloud
native
ecosystem
and
that
cloud
native
ecosystem
just
sort
of
had
a
whole
bunch
of
things
going
on
in
it.
That
made
the
authorization
and
policy
problems
just
more
interesting,
more
more,
more
pressing,
more
important
than
than
maybe
they
would
have
been
in.
C
You
know
in
other
kinds
of
environments,
and
so
you
know
just
the
the
dynamicity
that
you
see
in
in
cloud
technology.
Right
servers
are
spinning
up
and
down
at
the
whim
of
like
software.
If
you
think
about
all
the
devops
folks,
suddenly,
you've
got
a
whole
bunch,
more
people
that
are
putting
that
are
in
control
of
production
environments
and
so
somehow
you've
got
to
authorize
which
people
can
perform,
which
actions
and
so
on
and
so
forth.
C
So
you
know
we
saw
in
the
cloud
native
ecosystem
is
that
everybody's
embracing
a
whole
new
swath
of
technology,
a
whole
new
collection
of
software
components,
and
so
when
they
do
that
they
they
still
have
to
put
authorization
in
place.
It
doesn't
go
away,
it's
one
of
the
foundational
problems
in
security,
and
so
you
know
when
we,
when
we
built
opa,
that
was
that
was
the
goal
to
give
people
a
single
way
of
solving
that
authorization
problem
across
all
the
all.
The
different
software
systems
within
cloud
native
cloud
name.
A
So
assuming
there
is
an
organization
that
wants
to
explore
with
opa,
obviously
they
already
have
lots
of
different
bits
and
pieces
of
authorization
authentication
spread
across
the
entire
org.
How?
How
would
you
suggest
any
organization
or
team
starts,
you
know,
starts
adopting
oppa,
and-
and
would
you
suggest
to
avoid
in
order
to
not
fall
into
common
pitfalls.
C
Sure
yeah,
it's
a
good
question.
I
think
what
a
lot
of
people
see
and
and
what
a
lot
of
people
love
about
opa
is
the
fact
that
it
can
be
used
across
all
these
different
software
systems
so,
like
you,
can
use
it
for
kubernetes
admission,
control
and
microservice
authorization
and
and
a
lot
of
folks
use
it
for
kafka
authorization
and
ci
cd
pipelines,
and
so
people
love
that
that
that
that
vision,
that
you
know
that
the
picture
that
we
always
show
people
they
get
excited
by
it.
C
The
recommendation
we
always
make,
though,
is
that
you
need
to
find
one
place
where
you're
in
pain
today,
where
you
absolutely
have
to
solve
the
authorization
problem,
and
it
doesn't
really
matter
where
you
start.
Maybe
it's
kubernetes
and
mission
control.
Maybe
it's
service
mesh
authorization,
but
pick
one.
C
Try
it
out
with
opa,
make
sure
that's
working,
make
sure
that
you
succeed.
You
know
communicate
to
security
and
compliance
and
and
engineering
and
dev
and
ops,
and
make
sure
that
everybody
is
on
the
same
page,
that
this
is
a
good,
viable
solution
and
then
go
ahead
and
think
about
the
broader
vision
and
and
using
it
in
in
other
areas.
So
that's
certainly
you
know
the
the
one
piece
of
advice
I'd
give
to
anybody
who
is
looking
into
oppa.
A
C
C
You
run
many
many
copies
of
opa
as
side
cars,
just
like
you
would
with
a
network
proxy
in
a
service
mesh,
and
so
what
we
do
commercially
is
we
have
a
product
that
allows
you
to
to
manage
or
control
all
of
those
opens
right,
think
of
it
as
the
control
plane
or
the
management
plane,
or
that
you
know
single
pane
of
glass.
However,
you
want
to
think
about
it
for,
for
opa.
A
Yeah
speaking
of
which,
if
I'm
not
wrong,
people,
can
use
the
external
authentication
filter
that
envoy
provides
to
integrate
to
to
connect
with
with
an
opa
agent,
if
in
case,
they
wanted
to
integrate
oppa
with
way
down
boy,
which
is
pretty
cool.
It
comes
out
of
the
box
actually
and
so
matt
when
somebody
wants
to
start
using
envoy
to
process
their
data
in
motion
right
either
at
the
edge
or
in
a
service
mesh.
A
B
Yeah,
so
I
I
you
know,
I
think
that
envoy
at
this
point
is
one
of
these
foundational
technologies
that
is
under
a
lot
of
other
systems
that
are
being
built.
So
I
think
in
in
that,
from
that
standpoint,
kubernetes
and
enboy
are
somewhat
similar,
they're
being
used
as
these
building
blocks,
to
build
higher
layer
systems
and
because
of
that
envoy,
by
its
very
nature,
is
a
very
powerful
but
also
very
complicated
piece
of
software,
and
I
think,
from
a
project
perspective,
we're
always
trying
to
strike
this
balance
of.
B
How
do
we
onboard
people
right
like
how
do
we
get
them
to
potentially
use
envoy
in
an
incremental
way
and
to
try
to
better
understand?
Who
is
our?
Who
is
our
user
base?
Is
our
user-based
system
integrators
that
tend
to
have
a
better
understanding
of
some
of
these
networking
concepts
or
is
our
user
base?
B
You
know
what
are
the
business
problems
or
like
what
are
the
problems
that
are
actually
trying
to
be
solved
because
envoy
does
so
many
things
I
mean
from
observability
to
reliability,
to
integration
with
oppa.
To
oft
I
mean
it's
just
like
almost
endless
at
this
point
and
I
think
it
can
be
overwhelming
to
users.
You
know
to
decide
what
parts
of
the
system
that
that
they
want
to
use.
So
my
my
first
piece
of
advice
is
always
forget.
B
The
the
giant
feature
set
that
the
envoy
has
you
know
start
with
a
very
specific
use
case,
and
you
know
figure
out
why
envoy
is
going
to
be
the
best
use
case
for
for
that
and
then
deploy
just
that
right
and
get
some
facility
with
understanding
envoy
and
operating
it.
And
then
you
know
once
users
take
that
first
step.
B
I
think
it
becomes
easier
to
incrementally
add
other
configurations
or
pieces
of
technology,
but
it's
certainly
not
a
as
easy
a
a
journey,
as
I
think
some
people
would
would
like,
and
that's
where
I
think,
a
lot
of
the
a
lot
of
the
system
integrators
come
in
and
these
days
you
know
we
see
envoy
being
used
in
cloud
products
and
service
meshes,
and
you
know
all
types
of
different
verticals.
So
again,
I
think
it's
important
for
a
user
to
understand
what
problems
are
they
trying
to
solve?
Should
they
be
using
raw
envoy?
A
A
C
A
One
one
of
the
reasons
why
this
has
been
working
well
for
for
many
folks
is:
it
builds
up
that
confidence
not
just
within
themselves,
but
also
with
the
people
and
the
teams
that
are
affected
by
this
change.
If
they
can
go
step
by
step
that
confident
confidence
requires
time
to
build
in
into
and
to
get
and
so
going
little
by
little.
Getting
those
immediate
business
wins
right
away,
helps
building
that
confidence,
be
it
tomboy
bit
oppa
or
kubernetes
or
really
any
other
piece
of
technology.
A
The
pitfall
is:
if
it's
not
tied
to
a
business
use
case,
then
it
becomes
an
academic
project.
Why
are
we
even
doing
this
and
spending
time
doing
this,
so
very,
very
wise
piece
of
advice,
so
tim
and
matt?
Actually,
so
you
both
oppa
and
amboy,
are
part
of
cnc
so
team.
Let's
talk
about
you!
Why
do
you
did
you
think
that
cncf
was
the
right
home
for
oppa?
Why
not
another
foundation.
C
Well,
I
think
you
know,
as
I
sort
of
described
earlier,
one
of
the
things
that
we
knew
early
on
was
that
the
cloud
native
ecosystem
was
going
to
be
a
place
where
there's
a
bunch
of
technology
that
could
use.
You
know
authorization
and
unified
authorization.
More
than
that,
and
so
for
us
you
know
the
cncf
was
a
was
a
great
place,
not
only
technology,
wise
though,
but
also
in
terms
of
just
you
know
it.
C
A
We're
seeing
lots
of
software
being
adopted
in
the
past
10
years
when
it
comes
to
open
source
software,
I
mean
the
world
today
when
it
comes
to
architecture.
When
it
comes
to
these
kind
of
things,
it's
certainly
very
different
than
the
world.
You
know
in
the
early
2000s
or
you
know,
and
so
why
do
you
think
math
open
source
is
taking
such
an
important
role
into
into
defining
these
new
these
new
ways
of
building
our
architectures.
B
It's
a
it's
a
very
interesting
topic,
because
I
you
know
if
you,
if,
if
you
really
want
my
honest
assessment,
is
that
I
think
source
available
is
mostly
around
comfort.
I
think
people
you
know
like
to
be
able
to
look
under
the
hood,
even
though
they
probably
never
will
right
it's
like
most
users.
Never
most
users
never
modify
software,
they
never
patch
software.
They
might.
They
might
file
bugs,
but
I
think
for
many
users,
it's
really
just
it's
it's
about
comfort
on
two
levels.
B
It's
about
you
know,
theoretically,
if
there's
a
problem
that
a
vendor
won't
fix,
they
can
get
in
there
and
fix
it,
and
if
they,
you
know,
want
to
look
at
security
aspects
or
implementation
details.
You
know
it's
not
a
black
box,
so
I
you
know.
If
you
really
push
me,
I
I
think
those
are
the
two
things
that
are
really
driving
it.
It's
not
like
this
virtuous.
All
software
should
be
free.
I
mean
that
that
that's
just
that's
just
not
the
way
that
it
is.
B
You
know
competitors
that
you
know
really
are
trying
to
sell
different
products
and
they're
all
built
on
envoy
and
they
compete
because
we
have
these
open
apis
and
they
build
their
own
control
plane
and
their
own
way
of
managing
and
their
own.
You
know
enterprise
services,
but
we
all
collaborate
on
this
open
source
data
plane.
So
I
think
a
lot
of
it
is.
You
know
what
I
call
this
loose
open,
core
concept
of
trying
to
make
it
where
we
have.
B
A
So
both
of
you
are
very
active,
obviously
in
the
open
source,
given
your
involvement
with
with
your
projects,
what
are
the
untold
challenges
of
being
a
public
open
source
maintainer-
and
I
know
I
know-
actually
I
know
matthew
that
you
have
some
thoughts
around
the
topic,
because
I
saw
your
tweets
every
once
in
a
while,
where
you
bring
this
with
this.
This
topic
up,
but
let's,
let's
start
with
him
and
then
yeah.
B
C
Yet
you
need
to
go
out
and
spend
quite
a
bit
of
time
explaining
to
people
what
it
does
why
it
matters
and
how
they
can
use
it.
And
so
certainly
you
know
my
my
recommendation
would
be
that
to
to
if
you
open
source,
a
project
that
you're
gonna
you're
gonna
own,
that
open
source
project
for
a
very
long
time.
C
You're
gonna
continue
writing
code
for
it,
of
course,
but
what
you're
also
going
to
do
for
a
good
amount
of
time
is:
go
out,
reach
out
to
customers
or
users
and
and
explain
to
them
what
the
thing
does
and
and
why
it's
useful
for
them.
So
you
know
I
I
would
even
go
so
far
as
to
say
you
know,
expect
to
spend.
You
know
as
much
time
as
you
spend
writing
code
as
you
do
talking
to
and
engaging
with
your
with
your
users
and
community.
More
broadly.
A
B
I
mean
this
is
a
topic
that
I
could
literally
talk
about
for
hours
and
hours
and
hours,
so
I'm
I'm
trying
to
figure
out
how
to
summarize
it
in
a
in
a
sound
bite.
But
you
know,
I
think
this
comes
back
to
what
I
was
saying
before,
which
is
that
there's
an
expectation
today
that
for
some
of
these
critical
projects
that
these
are
these
are
mission
critical
systems.
B
They
have
super
high
standards
in
terms
of
security
and
performance
and
reliability
and
who
makes
these
things
happen
highly
paid
professional
programmers
and
product
managers
and
documentation,
writers
and
all
these
things
so
from
an
open
source
perspective
where
it
gets
complicated.
Is
that
you
know
I
at
this
point
I
like
to
think
of
myself
as
a
ceo
of
a
company
in
which
no
one
actually
reports
to
me.
So
it's
just
like
controlled
anarchy
all
the
time
right
of
like
people
complaining
about
this
or
wanting
to
do
that.
B
You
know,
and
I
mean
I-
I
barely
write
any
code
anymore.
It's
exactly
what
tim
was
saying.
I
spent
all
of
my
time
just
trying
to
stitch
together
the
pieces
of
like
pr,
marketing
and
documentation
and
like
security
release
processes,
but
but
the
problem
is,
is
that
we
haven't
figured
out
as
an
industry
how
to
how
to
pay
for
this,
how
to
make
it
sustainable
so
that
there's
people
that
are
doing
it,
that
are
that
are
well
compensated,
but
aren't
you
know
doing
two
jobs
aren't
working
nights
and
weekends,
and
you
know
my
my
work.
B
Life
balance
is
a
lot
better
than
it
was.
But
it's
still
you
know
I'm
I'm
an
employee
of
lyft.
It's
like
I
work
on
lift
things
you
know
yet.
I
think
sometimes
people
think
that
I,
you
know
I
am
mr
enboy,
and
I
do
this
like,
like
100
of
my
time.
So
it's
it's
just
it's
a
really
complicated
topic
of
trying
to
understand
all
of
the
things
that
goes
into
making
these
projects
successful
and
I
think,
from
a
community
standpoint,
it's
about
building
a
larger,
a
larger
community.
B
A
B
I
I
that's,
I
think,
there's
probably
nothing
that
does
it
right,
just
because
it's
so
hard
to
get
everything
everything
100
right,
you
know,
I
I
look
to
linux
as
a
project
that
has
existed
for
a
very
long
period
of
time
and
again,
you
know
we
have
short
time
here.
There's
certain
things
about
linux
that
I
that
I
don't
like
at
all,
but
I
I
think
that
just
from
a
sustainability
perspective,
you
know
they
have
scaled
that
project
to
a
massive
level
right
and
like
and
they've,
and
they
made
it
work.
B
So
I
think
there's
a
lot
that
we
can
learn
from
linux,
in
particular
just
because
of
how
how
long
it's
been
around,
how
much
how
much
commercial
entity
and
usage
there
is.
So
I
think,
there's
a
lot
to
learn
there
in
the
cloud
native
space.
You
know
I'm
not
sure
that
there's
any
project
that
I've
seen
that
you
know
does
it
right,
it's
just
so
complicated
from
the
funding
perspective
for
how
fast
things
move
from
frankly
the
the
vendor
fighting.
You
know
that
goes
on.
A
C
Sure
I
mean
I
think,
for
me:
it's
pretty
pretty
easy.
You
know
we've
sort
of
talked
about
how
there
are
all
these
different
use
cases
for
opa-
and
you
know
I
think
the
thing
that
always
gets
me
excited
is
when
somebody
goes
ahead
and
takes
opa
and
you
know
solves
a
new
problem
with
it
that
I
hadn't
I
hadn't
envisioned.
B
I
I
think,
there's
two
things
I
think
from
a
tech
perspective.
I
think
web
assembly
is
one
thing
that
I
think
is
really
going
to
unlock
all
types
of
different
use:
cases
from
the
service
mesh
case
to
the
edge
computing
case,
just
making
it
easier
for
people
to
plug
in
software
into
this
platform.
But
I,
I
think
what
I'm
most
excited
about.
B
It's
too
complicated.
It's
not
opinionated
enough
for
what
most
users
want
to
see,
which
is,
you
know,
passes
fastest
those
those
types
of
things,
and
I
think
that
this
is
where
cloud
vendors-
and
you
know
software
vendors-
you
know
you
know-
can
come
in
and
build
these
more
opinionated
products
that
use
envoy
and
and
and
kube-
and
you
know,
hopefully,
provide
better
better
value
for
for
users.