►
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
Slowing Our Role: Moving Towards Policy at Plex - John Reese, Plex Systems
In this talk, we'll walk through Plex's journey from role-based access to embracing policy.
To be fair, roles got us far at Plex. Roles can be a completely valid solution, especially for smaller systems. However, as we grew, we knew roles would not be able to solve all of our problems forever. Our solution? Policy.
Through policy, automation and autonomy became a reality. By defining policies upfront, we could include them in our environments and release processes, allowing for changes to be made without any human intervention. Policy also allowed us to focus on what we actually want to secure: data. Developers no longer have to concern themselves with permissions or roles and can just use the APIs they need to get their job done.
Our journey is not over yet, but you can still come hear all about where we started with role-based access control, where we are today, and where we want to be.
A
All
right,
thank
you
so
much
yeah,
my
name
is
John
Reese
I'm
gonna
be
talking
to
you
about
our
company's
approach
to
policy
coming
from
a
very
roll
heavy
focus
security
model.
Again
name
is
John
Reese
work
at
plex.
The
manufacturing
cloud.
Get
that
a
lot
we're,
not
the
media
server.
We
are
actually
a
ERP
system
for
manufacturers,
enterprise
resource
planning,
so
we
handle
anything
from
the
shop
floor
all
the
way
to
the
CEO,
so
thing
shipping
accounting
their
their
HR
system.
Anything
they
need
to
do
to
run
their
business.
A
So
for
some
background
in
the
beginning
roles,
just
controlled
everything
within
the
system.
So
again
we
are
a
full
solution
for
manufacturers
and
we
built
everything
for
them.
This
includes
again
their
their
HR
system,
their
therein
out
system,
everything
that
they
need
to
do.
They
would
log
into
our
system
and
they
would
use
us
..
A
This
also
means
that
early
on,
we
as
a
company,
also
used
everything
within
the
system.
So
maybe
not
the
greatest
idea
because
we're
a
software
company,
not
a
manufacturing
company,
but
that
also
means
that
everything
that
you
needed
to
do
in
that
system
was
role
based
if
you
needed
to
log
in
to
to
check
in
if
you
needed
to
do
any
action
with
the
system
through
is
gonna,
be
a
role
for
that
and
honestly,
it
looked
a
lot
more
like
permissions
more
so
than
roles.
A
We
had
a
lot
of
them
and
even
again
we
put
our
deployment
system
in
here.
We
put
everything
you
needed
to
do
in
the
system
and
so
in
a
way
for
us
roles
were
way
of
assigning
responsibilities.
If,
if
you
were
given
a
role
that
was
kind
of
your
wheelhouse
of
what
of
what
you
had
to
do
so
so,
for
example,
we
had
this
idea
of
a
module
champion,
you
can
think
of
a
module
as
just
an
area
of
the
system.
Right,
you
have
an
accounting
module
champion.
A
You
can
think
of
this
as
where
the
braces
go
in
JavaScript
or
tabs
or
spaces,
but
they
were
also
responsible
for
deploying
restricted
source
code
and
we
defined
restricted
source
code
as
really
any
code
that
we
felt
could
negatively
impact
the
system
in
a
large
way.
So,
for
example,
the
the
menu
system
that
was
a
module
and
a
menu
is
pretty
much
going
to
be
everywhere
throughout
your
system.
A
It's
how
your
users
navigate,
so
that
would
be
a
restricted
restriction,
module
that
a
standard
member
would
have
to
deploy
because
they
know
how
to
deploy
restricted
code.
But
the
problem
with
this
again
we
have
this
very
clear
definition
of
roles
is
that
we
had
this
situation.
Where
someone
who
owns
this
system,
who
knows
everything
about
it,
can
actually
deploy
the
change.
A
Rolls
were
often
a
solution
for
us
to
prevent
problems
from
happening
again.
So
to
put
simply,
if
you
have
an
employee
who
does
a
thing
and
that
thing
didn't
go
right,
we
would
generally
create
a
thing,
do
a
role
and
it
seems
a
little
extreme,
but
that's
kind
of
how
things
evolved.
If
we
would
give
employees
a
lot
of
privileges,
because
we
trust
them
and
in
the
event
that
they
didn't
do
something
right,
maybe
it's
their
own
fault
or
not.
We
would
all
get
into
a
room
and
would
be
like
hey.
A
How
can
we
solve
this
problem?
How
can
we
make
sure
that
this
thing
doesn't
happen
again
and
you
would
we'd
all
be
like
boom
that
guy,
like
he's
in
that
he
is
now
the
thing
doer?
It
is
your
responsibility
to
make
sure
that
thing
doesn't
ever
happen
again,
and
so
this
created
a
lot
of
problems
again
as
the
company
grew
and
grew
and
grew
where
simple
tasks
would
just
involve
multiple,
multiple
people.
So
true
story,
we
have
a
developer
who,
who
simply
just
they
asked
the
the
network
engineer
for
a
new
domain.
A
This
is
the
internal
domain.
It's
gonna
be
with
inside
our
four
walls.
He's
just
asking:
hey
I
need
to
get
this
made.
We
are
using
Azure,
so
in
this
case
he
needs
to
create
a
resource
group.
Resource
groups
in
Azure
are
kind
of
where
you
put
all
the
resources
it's
responsible
for
for
billing,
and
you
can
put
some
more
restrictions
on
it,
but
because
a
resource
group
isn't
a
networking
concern,
the
network
engineer
cannot
create
resource
groups,
so
he
has
to
go
over
to
the
system.
A
Engineer
and
be
like
okay,
yeah
sure
yep
I'm
gonna
create
one
for
you
comes
back.
All
set
realized
hey.
This
is
a
dev
domain.
Http
like
can
I
make
a
cert,
so
he
asked
the
engineering
managers
who's
responsible
for
approving
these
types
of
requests,
he's
like
yeah,
sure
I
guess,
cool
domain
gets
added,
and
then
this
comes
back
to
me,
the
developer,
and
so
what
to
realize
here
is
that
you
know
all
these
steps
take
time.
A
A
Right
is
like
these
were
probably
the
right
choices
at
the
time,
I
mean
again
the
company's
been
around
for
a
really
long
time.
I
have
a
paycheck
because
of
these
decisions
when
we
are
thriving
because
of
these
decisions,
but
you
know
there
comes
a
time
where
you
actually
do
need
to
change
and
need
to
evolve.
So
when
you,
when
you're
working
on
like
a
legacy
system,
you're
like
how
did
they
ever
make
these
decisions,
why
would
they
ever
ever?
A
So
that's
kind
of
a
a
look
into
what
we
what
we
did
back
then
you
know
still
a
little
bit
today,
but
for
the
most
part
we
have
a
very
different
mindset.
So
at
the
heart
of
it
it's
automatic
approvals
through
policy,
so
think
of
it,
as
we
had
that
previous
slide,
where
we
have
to
go
through
every
single
individual
step
and
those
are
pretty
much
all
approvals.
A
A
These
concerns
up
if
you
like,
a
virtual
machine
or
a
repository
or
any
any
sort
of
thing
that
you
might
want
to
request
when
you
ask
for
those
the
person
in
charge
of
that
is
just
going
to
make
sure
that
the
the
constraints
are
within
reason,
you're,
not
asking
for
a
ton
of
resources.
Maybe
it's
name
correctly.
You
know
whatever
they
care
about
in
terms
of
like
their
domain.
That's
what
they're
looking
for
and
if
you
meet
all
the
criteria,
they're,
just
probably
gonna.
Do
it
for
you
so
to
kind
of
tackle
this
problem.
A
It
all
starts
with
OPA
for
us
open
policy
agent.
If
you're
not
familiar,
you
can
really
think
of
it
as
a
yes/no
engine.
For
the
most
part
you
give
it
a
you,
give
you
some
data
and
then
you
have
red,
go
files
which
are
your
policies
and
then,
given
those
those
to
it
will
say,
can
you
do
this?
Or
can
you
not
do
this,
and
so
as
an
example,
this
is
a
really
simple
regulatory
to
kind
of
show
you
how
a
policy
might
look.
A
This
is
a
kubernetes
manifest
for
for
a
namespace,
and
this
is
saying:
if
input
kind
is
namespace
and
there
does
not
exist
a
labels
field
vanish
it
should,
it
should
deny
and
say:
namespaces
must
have
labels.
So
one
of
the
really
powerful
things
about
about
reg
o
is
that
it
doesn't
necessarily
care
about
the
the
structure
of
the
data
coming
in.
That's
something
that
you
define
so
input
here
is
in
blue,
because
that
is
a
key
word.
A
It's
the
input
to
reg,
oh,
but
you
know
kind,
is
just
something
that
that
we
set,
because
that
is
what
is
in
a
community's
manifest.
You
have
kind
operations,
but
you
also
have
metadata
labels,
but
anything
to
the
right
can
really
be
anything,
and
so,
in
our
case
of
creating
a
namespace,
you
can
say
here's
this
manifest
it's
a
namespace.
Does
it
have
a
label,
yes
or
no,
and
so
two
to
use
all
these
tools
together?
A
We
use
something
called
called
comp
test
and
the
the
power
of
this
tool
for
us
when
we
were
introduced
to
it
was
the
fact
that
it
supports
just
a
wide
arrange
of
file
format
so
to
really
kind
of
showcase.
What
can
happen
with
files?
You
have
yam
all
JSON,
I
and
I
and
docker
files,
for
example,
and
so
we
can
take
any
sort
of
structured
data
where
we
know
what
the
data
is
going
to
look
like,
throw
it
at
com
contest.
A
Has
our
policies
in
it
and
it
can
tell
us,
does
this
file
violate
our
policies?
So
a
really
simple
pipeline
could
be
that
a
developer
is
going
to
submit
a
pull
request
and
that
pull
request
is
going
to
contain
their
terraform.
It's
gonna
contain
their
kubernetes
resources
and
then,
when
they
submit
it
contest
itself
will
validate
the
PR.
A
The
key
thing
to
note
here
and
to
really
highlight
again,
maintain
errs,
define
their
policies
because
again,
policies
are
really
just
a
brain
dump
for
what
the
maintainer
wants.
The
maintainer,
the
person
who
might
have
had
that
role
is
the
person
creating
these
policies
so
as
a
developer,
I
contribute
to
your
to
your
repository.
I
must
abide
by
your
policies
and
then,
if
it
validates
then
you're
just
you're
off
to
the
races,
because
if
you
are
within
spec,
everything
is
named
correctly,
you
have
all
the
right
labels,
etc.
A
It's
just
going
to
go
off
and
do
it
in
this
case.
Now,
a
lot
of
our
a
lot
of
our
implementations
are
using
terraform.
So
we
can
just
say:
hey.
This
is
valid
terraform.
Do
a
terraform
apply
good
to
go
so
again
to
really
showcase
some
of
the
other
use
cases
that
you
have
for
this
that
we
do
talked
a
lot
about
terraform.
A
We
have
a
means
for
if
a
developer
wants
a
repository
and
azure
devops,
we
don't
have
an
azure
devops
guy,
creating
repositories
anymore
we
used
to,
but
now
that's
all
automated,
where
the
the
DevOps
guys
wrote
a
terraform
source
module,
so
they
define
how
they
want
their
repositories
to
look.
And
so,
when
you
request
a
new
one,
we
just
have
to
make
sure
to
say:
hey.
A
Are
you
using
the
Plex
source
module
for
this
for
this
repository
the
the
other
use
cases
again,
because
it
doesn't
really
matter
what
the
input
is
we
have
kubernetes
manifests
that
say
you
have
to
have
these
labels
and
also
again
docker
files.
You
can
make
sure
that
it
has
a
label
for
origin.
Some
other
examples
could
be.
The
docker
file
has
to
come
from
blessed
images.
A
So
if
you
at
your
company,
have
only
images
that
you
allow
your
employees
to
use,
you
can
make
sure
that,
like
the
from
tag
is
actually
from
list
of
approved
images,
super
super
powerful
if
you're
interested
in
learning
more
about
the
tool
itself.
This
talk
just
like
blew
my
mind
when
it
came
to
came
to
policy
aging
and
comp
test,
because
we
were
working
through
this
just
at
this
moment
when
I
believe
that
this
talk
came
out.
A
Where
we
were,
we
were
thinking,
we
knew
we
wanted
to
apply
policy,
especially
at
the
at
the
kubernetes
level.
We
knew
that
we
wanted
to
make
sure
that
our
policies
are
our
llamó
files
had
specified
labels
on
them,
but
we
were
really
afraid
of
the
fact
that
how
would
we
put
this
to
the
left
shifted
to
the
left
for
developers,
because
we
didn't
really
like
the
idea
of
developers.
A
Writing
writing
code
writing
manifest
and
then
they
didn't
know
it
was
actually
going
to
violate
spec
until
it
actually
went
to
the
cluster
and
we
were
really
afraid
of
that.
But
calm
test
again,
it
can
be
run
on
your
local,
because
it's
just
a
binary,
it
can
be
running
your
CI
CD
pipelines
and
then
once
it's
deployed,
that's
kind
of
where
the
wheelhouse
for
for
comp
test
ends.
A
The
other
approach
we
are
taking
is
not
only
the
creation
of
resources,
but
also
the
configuration
of
those
resources
once
they're
already
created.
So
this
is
actually
pretty
pretty
new
for
us.
We
are
doing
repository
policies
through
a
policies
that
yamo
file
where
we
can
say
in
the
root
of
your
repository.
These
are
the
things
that
I
want
set,
so
you
don't
really
need
any
sort
of
entry.
'extra
permission
aside
from
being
able
to
contribute
to
your
repository
and
once
you
make
these
changes,
we
have
an
azure
function.
A
That
was
basically
monitoring
for
pushes
to
policies.
Yeah
Mille,
it
will
notice
say:
hey
did,
did
anything
change
and
if
it
did
validate
against
our
ops
team's
set
policies,
even
if
it
doesn't,
then
you
can
go
ahead
and
you
can
modify
that
repository.
So
it's
end-to-end,
essentially
of
you
can
create
this
repository
and
then
once
it's
up
and
running,
you
can
still
make
changes
to
it.
You
don't
need
to
say
hey,
yes,
we
we
this
repository,
but
now
we
need
to
make
a
change
to
it.
Can
you
update
this
value
for
me?
A
A
The
the
last
thing
for
for
policy
that
we're
really
starting
to
get
into
is
is
a
tool
called
gatekeeper,
and
this
is
this
essentially
picks
up
where
comp
tests
stopped.
So
again,
we
use
com
test
for
everything
for
like
local
and
CIC
d,
and
then
gatekeeper
is
responsible
for
enforcing
those
like
in
the
cluster
themselves.
A
This
is
what
we
were
going
to
use
for
the
actual
application
of
the
policies,
and
we
didn't
know
what
to
do
with
the
the
CI
CD
part
until
contest,
but
this
is
allowing
you
to
use
the
same
policies,
because
both
tools
are
built
off
OPA
and
built
off
reco
again,
reco
doesn't
really
care
what
the
data
is.
Opa
just
reads
it,
so
you
can
shut
any
kind
of
data
and
you
can
use
the
same
policies
wherever
because
again,
policies
might
change
from
an
environment
environment
and
you
can
configure
that.
A
But
for
the
most
part,
if
you
say
that
you
don't
want
a
late
or
you
need
a
label
somewhere,
you
shouldn't
have
to
rewrite
that
policy.
For
for
everything
you
shouldnt
have
to
deploy
this
to
gatekeeper
and
deploy
this
to
comp
test.
You
can
have
a
central
policy
location
that
has
that
defines
all
of
your
policies
in
kind
of
to
the
point
of
like
it
doesn't
make
sense
for
someone
to
do
this.
The
the
thing
that
really
resonates
for
me
is
that
a
bit
another
big
push
of
this
again.
A
We
want
employees
to
innovate
and
not
just
approve
request
right.
We,
these
individuals
are
incredibly
smart.
We
we
pay
them
well,
and
we
shouldn't
have
to
take
away
their
time
just
to
approve
request
right
there,
they're
working
on
highly
complex
things.
They
they
see
a
list
come
in
and
in
email,
saying,
hey,
you
need
to
approve
this.
They
probably
don't
really
want
to.
They
want
to
be
off
doing
this
thing,
but
if
they
don't
approve
it,
it's
everybody
down.
A
So
with
this
type
of
approach,
we
can
just
make
it
so
we
remove
that
load
from
them
and
they're
able
to
do
what
they
actually
want
to
do.
I
like
to
call
I'll
call
this
out
too,
because
again,
it's
not
like
rolls,
are
dead
and
Paul
and
policies
everything
for
for
us.
It
was
really
just
a
different
way
of
thinking
about
security.
A
Again
early
early
days
was,
we
would
implement
a
feature
and
we
would
say:
okay
well,
this
is
new.
Now
we
have
to
add
some
role
for
that.
You
know
the
the
thing
doer.
This
thing
has
to
be
protected
and
who's
gonna
do
this
and
just
everything
was
very
locked
down
from
the
get-go,
whereas
now
we
take
very
much
the
approach
of.
Why
can't
we
open
this
up?
Why
can't
we
open
this
up
to
everybody?
What
are
the
things
that
we
actually
care
about
and
then
take
it
from
there
and
again,
policy
can
use
roles.
A
I
mean
it's.
It
could
be
very
possible
that
you
have
someone
who
is
a
kubernetes
operator
and
that's
a
role,
and
you
have
a
policy
saying
that
you
must
be
in
the
kubernetes
operator
role
and
you
must
have
have
Eastfield
on
your
gamal.
They
can
work
together
so
so
for
going
forward,
then
the
easy
bit
of
it
is
that
we
just
really
want
to
continue
adopting
policy.
A
We
want
to
make
sure
that
that
we
are
trying
to
remove
manual
sign-off
and
just
implement
policy
where
we
can,
for
me
the
the
more
interesting
part
and
where
we're
going
to
be
spending
most
of
our
time,
I
believe
going
forward
is
actually
moving
those
policies
into
the
application
level,
and
so
what
I?
What
I
mean
by
that
is
not
only
do
we
have
this
role
problem
internally
here
at
our
company,
but
since
both
systems
are
pretty
much
the
same,
that
our
customers
also
feel
this
like.
A
They
have
a
lot
of
roles
that
they
have
to
manage,
because
our
system
is
meant
to
run
their
business
and
every
business
has
different
policies,
different
security
rules,
and
so
we
give
them
the
ability
to
to
define
how
their
business
works.
But
really
only
we
have
to
do
that
is
to
say,
hey
like
you
can
create
roles,
and
then
we
have
to
check
all
those
in
our
systems,
so
it
be
really
really
cool.
A
If
we
can
say
these
are
your
policies,
you
can
kind
of
define
those
how
you
want
them
to
be,
and
maybe
we
could
even
set
our
own
global
policies.
If
you
will
of
like
this
is
how
typically
manufacturers
solve
this
problem,
but
if
you
want
to
make
modifications
to
it,
then
you're
more
than
welcome
to
to
write
your
own
policies
and
get
them
out
of
this.
This
very
very
roll
heavy
world.
A
B
A
A
Well,
yeah
I
mean
there's,
obviously
always
going
to
be
like
we
overrides
I
mean
the
we
get.
This
is
our.
This
is
our
typical
CI
CD
pipeline.
The
individuals
in
these
roles
still
have
full
full
access
again.
The
so
much
of
it
again
is
the
maintainer
z'
defining
their
policies.
So
if
you
essentially,
if
you
were
a
contributor
someone
who
is
trying
to
contribute
to
the
repository
well,
then
just
its
policy
full
stop,
but
you
as
a
maintainer
you
as
someone
who,
as
you
know,
you
can
push
the
master.
A
You
will
still
have
those
permissions,
but
anything
came
up
like
you
still
had
the
ability
to
violate
policy
there's,
actually
not
a
really
cool
thing
about
about
gatekeeper.
Lis,
specifically,
is
that
in
even
the
previous
talks
and
continues
compliance
that,
if
that
ever
happens,
we
are
actually
looking
into
ways
of
running
continuous
compliance
and
making
sure
that
no
one
did
just
go
run.
Cube
cuddle,
add
some
things
and
change
configurations
manually,
because
you
want
to
be
aware
of
those
of
those
changes
but
but
yeah
for
the
most
part.
D
A
So
I
mean
for
for
us,
it
was
I
mean
it
was
very
slow,
a
few
people.
It
was
definitely
not
an
overnight
thing.
I
mean
these
are
these
are
approaches
that
you
can
take
at
a
team
by
team
level
or
even
like
a
repository
by
repository
level,
so
so,
for
example,
the
the
first
thing
that
we
ever
did
was
just
a
policy
around
our
docker
file,
because
we
have
a.
A
We
have
a
policy
that
docker
files
must
have
an
Origin
repository,
gen
label,
and
so
the
owners
of
that
repository
said:
okay,
I'm
gonna,
add
comp
tests
into
my
CI
CD
pipeline
I'm
gonna
write
a
policy
folder
that
says
that
and
we're
good
right
and
then
that
just
kind
of
naturally
evolved
and
grows
throughout
the
system,
and
then
even
now
I
mean
it's
like.
We
are
as
more
and
more
pot
repositories
are
created.
We
are
just
leveraging
this
tool
more
and
more
as
we
as
we
naturally
grow.
A
C
Yes,
this
is
member
friends
to
your
repository
policy.
Can
you
elaborate
on
how
the
you
guys
make
decisions,
went
to
update
your
repository
based
on
spirit
policy,
so
say
you're
expecting
a
three,
but
they
put
it
too
I've
been
in
situations
where
it's
not
simply
be
a
range
of
values.
How
do
you
guys
come
to
that
decision?
You
decide
how
to
update
that
value.
A
C
A
I
mean
so
yeah
I
think.
The
best
way
to
put
it
is
that
it's
it's
up
to
the
team
I
mean
we
can
have
you.
If
you
have
a
really
simple
project
that
a
team
of
response
before
they
can
say,
hey
this
project,
we
don't
really
care
about
its
internal.
It's
used
in
very
small
areas.
That's
just
going
to
be
one
where,
as
this
is
we
as
a
team,
we
own
this
really
critical
piece
of
software.
We
think
it
should
be
five
or
some
number
right.
A
The
for
us
and
kind
of
the
whole
takeaway
for
this
is
it
allows
teams
to
make
it
make
those
choices
and
can
figure
out
how
they
want
without
bringing
in
the
the
actual
owner
of
the
overall
platform
to
look
at
me
in
this
case
a
sure
so
I
mean
I,
don't
know
how
like
they
would
have
made
it
that
decision
from
I
know
from
my
perspective,
for
on
these
types
of
projects
that
yeah.
If
we
feel
that
something
needs
to,
we
say
it's
too.
Otherwise,
it's
just
gonna
be
one
or
three
or
whatever.