►
From YouTube: Keynote: Getting Permission or Asking Forgiveness? - Liz Rice, Technology Evangelist, Aqua Security
Description
Join us for Kubernetes Forums Seoul, Sydney, 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
Keynote: Getting Permission or Asking Forgiveness? - Liz Rice, Technology Evangelist, Aqua Security
In this talk we’ll explore how permissions work in Kubernetes. If we think of Kubernetes as a distributed operating system, what's the equivalent of the read, write and execute permissions we see when we list files on Linux?
About Liz Rice
Liz Rice is the technology evangelist at container security specialists Aqua Security, where she works on container-related open source projects including kube-bench and kube-hunter. Last year she was Co-Chair of the CNCF’s KubeCon + CloudNativeCon events in Copenhagen, Shanghai and Seattle. She has a wealth of software development, team, and product management experience from working on network protocols and distributed systems, and in digital technology sectors such as VOD, music, and VoIP. When not writing code, or talking about it, Liz loves riding bikes in places with better weather than her native London, and competing in virtual races on Zwift.
A
Hi
everyone
and
thank
you
so
much
for
joining
us
here
at
the
first-ever
kubernetes
Day
in
India,
as
Dan
said,
I
work
for
aqua
security
and
we
help
enterprises.
We
have
a
product
that
helps
enterprises
secure
their
container
deployments.
We
quite
recently
opened
an
office
here
in
India,
actually
in
Hyderabad,
that's
just
part
I,
think
of
a
growing
community
of
cloud
native
people
and
it's
very
exciting
to
see
so
many
of
you
here
today.
You
know
spending
your
time
to
come
and
learn
about
Kievan
entities
that
abound
cloud
native.
A
So
thank
you
and
welcome
to
today,
all
right
so
today,
I'm
going
to
talk
a
bit
about
permissions
and
I
want
to
start
by
introducing
this
woman.
I,
don't
know
who
recognizes
who
that
is
anybody
shout
out
if
you
may
Grace
Hopper,
it
is
indeed
Grace
Hopper,
so
she
was
really
one
of
the
founding
figures
of
modern
computing.
She
came
up
with
the
idea
of
programming
languages,
so
basically
none
of
us
would
be
here
today
if
it
wasn't
for
Grace
Hopper
and
she
said
a
lot
of
really
smart
things.
A
A
I'm
gonna
go
a
little
bit
off
piste
here
and
go
a
little
bit.
Personal
Grace
Hopper
is
obviously
a
huge
inspiration
to
all
of
us
who
do
anything
in
the
world
of
computing
and
I
quite
recently
lost
my
mum.
She
wasn't
in
technology,
she
was
the
doctor.
She
was
a
psychiatrist.
She
was
pretty
much
the
top
of
her
field
and
she
got
there
by
working
really
really
really
hard.
A
She
also
loved
travel
and
she
loved
the
fact
that
people,
she
loved,
learning
and
I
think
she
would
be
hugely
hugely
proud
of
the
fact
that
I'm
here
today,
you
know
in
India
talking
about
something
that
I
love
and
hopefully
teaching
you
something
with
a
picture
of
Grace
Hopper.
Who
I
think
is
an
inspiration
to
all
of
us.
Could
I
get
a
giant
round
of
applause
for
inspirational.
A
Ok,
so
I'm
going
to
talk
about
permissions
and
what
I
thought
I'd
do
today
is
compare
how
we
consider
permissions
in
Linux
and
in
kubernetes,
so
who's
had
the
idea
that
kubernetes
is
a
distributed
operating
system.
You
heard
that
idea
a
few
hands
going
up
like
this
is
hard
to
see
so
I
think
it's
interesting
to
draw
parallels
between
an
operating
system
that
we
may
be
quite
familiar
with
like
Linux
and
how
we
do
the
same
things
in
kubernetes.
We
think
of
that
as
a
distributed
operating
system.
A
So
let's
have
a
quick
review
of
how
permissions
work
in
Linux
I'm
sure
most
of
you
here
are
familiar
with
running
LS,
minus
L,
and
you
can
see
information
about
a
file.
It
shows
us
who
the
owner
of
that
file
is
in
the
group
and
some
permissions
information
about
the
file.
Those
permissions
are
show
us
attributes
for
the
owner
for
the
group
before
everybody
else,
and
it
tells
us
whether
those
different
groups
of
people
can
read,
write
or
execute
that
file.
A
A
A
A
A
There
are
also
processes,
but
basically
everything
is
a
fire
in
kubernetes
we
don't
really
have
files,
but
what
we
have
is
resources.
We
have
lots
and
lots
of
different
types
of
resources.
We
have
pods
nodes
and
pods
security
policies
and
daemons
s.
We
have
custom
resources,
everything
can
be
defined
as
a
resource
and
if
you're
linux,
everything
is
a
file
and
in
kubernetes
everything
is
a
resource
I'm
just
going
to
fill
in
this
line.
Instead,
the
equivalent
for
file
is
a
resource.
A
It's
quite
abstracts
have
a
concrete
example
of
that.
If
I
want
to
run
an
application
called
my
app
on
Linux,
it's
a
file
that
I
can
execute.
If
I
want
to
run
that
same
application
in
Cuba
Nexus,
we
have
to
create
a
pod
that
will
run
our
application.
So
I'm
kind
of
saying
that
executing
a
file
in
Linux
has
the
equivalent
of
creating
a
pod
in
kinetics.
A
So
how
can
you
know?
Does
that
mean
my?
My
equivalence
is
here
breaks
down.
Does
this
table
make
no
sense
in
order
to
find
what
the
equivalents
are,
what
we
need
to
look
at
role
based
access
control,
and
the
clue
here
is
in
that
first
word
wrong:
if
we
look
at
a
definition
of
a
role,
here's
some
yam
all
we
can
see
that
the
the
role
defines
some
verbs
and
some
resources.
A
A
We
have
a
lot
more
verbs
in
kubernetes.
We
have
read-only
verbs
like
get
a
list
and
watch.
We
have
verbs
that
change
states
of
things
like
creating
or
updating
a
resource,
and
we
have
a
few
slightly
more
esoteric
verbs
like
you
can
use
a
pod
security
policy.
So,
there's
a
bit
more
complexity,
but
it's
still
actions
that
were
performing
on
things.
A
We
might
have
a
role
that
talks
about
the
actions
you
can
take
on
a
whole
group
of
things,
a
whole
set
of
resources,
like
all
the
pots
in
a
namespace,
or
we
might
define
a
role
that
specifies
a
particular
resource
by
name
thing
is
I,
just
go
back
to
that
for
a
second
there's.
Nothing
in
here
that
talks
about
who
can
do
this.
It's
only
talking
about
the
actions
and
the
verbs
and
the
resources,
the
things
that
you
can
apply,
those
actions
to
know
information
about
food.
Do
that.
A
We
have
a
role
and
if
we
want
to
assign
that
role
to
a
user,
we
create
a
role
binding
and
the
role
binding
refers
to
the
role
and
it
refers
to
some
subjects.
A
user-
or
maybe
it's
a
group
just
to
make
things
kind
of
a
little
bit
more
weird
users
and
groups,
aren't
actually
a
thing
in
keeping
assets.
They
have
to
be
defined
somewhere
else.
So
you
can
refer
to
these
users,
but
you
couldn't
do
something
like
acute
control
get
users.
A
That's
that's,
not
a
thing,
but
we
do
have
some
identities
in
Illuminati's
we
have
service
accounts
so
for
users
and
groups
we're
expecting
those
to
be
defined
somewhere
outside
of
kubernetes.
Maybe
there's
a
an
LDAP
directory
service
accounts
are
the
identities
of
pieces
of
software
that
are
running
inside
the
cluster
and
we'll
see
a
bit
more
about
that
later.
I.
A
Mentioned
briefly
that
the
roles
apply
to
a
particular
namespace,
we
also
have
cluster
wide
equivalents,
so
there
are
cluster
roles
and
cluster
role
bindings.
Apart
from
the
fact
that
they're
applying
across
the
whole
cluster,
it's
kind
of
the
same
thing.
So
if
we
go
back
to
a
role
and
a
role
binding,
we
might
want
to
also
draw
into
this
picture
the
resources
that
the
role
refers
to.
A
Maybe
it's
one
pod,
for
example,
or
maybe
it's
a
whole
group
of
pods,
all
the
parts
in
the
namespace
and
with
all
these
things
that
diagram
kinda
shows
us
what
we
need
in
place
to
express
permissions
in
kubernetes.
We
need
all
of
these
things,
which
contrasts
quite
starkly
with
what
we
needed
for
linux
right.
This
is
really
simple.
This
looks
quite
a
lot
more
complicated,
so
if
you've
ever
found
all
that
kind
of
confusing.
A
So
if
you
remember
your
physics
classes
in
school,
you
might
recall
the
second
law
of
thermo
around
the
thermodynamics,
which
says
that
systems
will
tend
towards
thermodynamic
equilibrium.
Thermodynamic
equilibrium
is
kind
of
the
most
randomly
distributed.
States
that
a
system
could
achieve
systems
will
tend
towards
more
and
more
entropy,
more
and
more
kind
of
randomness,
more
more
messiness,
less
tidiness
over
time.
A
Is
that
entropy
of
permissions
increases
with
time?
Let
me
show
you
what
I
mean
we
already
start
off
when
you
install
kubernetes
you're,
going
to
start
with
a
whole
load
of
service
accounts
and
cluster
roles
and
cluster
role
bindings.
You
know,
I
mentioned
that
service
accounts
of
the
identities
that
components
or
software
running
in
your
cluster
they
run
under
these
service
account
identities
and
there's
a
whole
set
of
them.
This
is
just
an
extract
that
are
installed
right
from
the
get-go.
These
are
really
great.
A
They
give
granular
access,
so
all
of
the
kubernetes
compound
I
only
get
the
permissions.
They
need
to
do
their
job.
It's
really
great,
but
it's
quite
a
you
know:
it's
it's
a
lot
to
get
your
head
round
when
you
first
install
human
essence,
you've
got
all
these
roles
and
role
bindings
already
in
place,
and
you
probably
couldn't
hold
that
in
your
head.
A
So
there's
quite
a
lot
of
things
that
you
would
want
to
configure
to
get
your
roles
and
role
bindings
in
place
and
it's
quite
telling
to
escape
some
of
those
things.
Quite
broadly,
for
example,
you
might
say:
well,
everybody
needs
to
create
pods
or,
and
everybody
needs
to
go
to
read
pods.
So
maybe
you
create
some
role
bindings
that
have
a
really
wide
scope
like
everyone,
because
it's
human
nature.
A
If
there's
any
role
out
there
found
to
a
user,
that
gives
a
permission
that
user
has
that
permission,
there's
no
like
black
listing
or
anything.
So,
the
more
of
these
things
over
time,
you're
more
likely
to
have
more
people
more
groups,
more
service
accounts
that
have
permissions
to
do
more
things,
just
because
it's
human
nature.
A
Another
problem
with
this
is
that
the
more
people
who
can
do
more
things,
the
greater
the
chance
that
one
of
those
people
behaves
badly.
They
might
be
a
bad
actor,
they
might
just
be
incompetent
and
they
might
just
yeah.
You
don't
want
to
give
too
many
people
the
ability
to
delete
all
the
resources
in
your
cluster,
because
somebody
will
do
that
accidentally
and
that
will
be
a
bad
day
further.
You
have
your
application
code
running
in
your
cluster
and.
A
Application
code
is
software,
so
it's
associated
with
a
service
account
and
by
default
the
token
that
identifies
that
service
account
is
actually
accessible
to
the
application.
So
the
application
could
use
that
token
to
make
requests
of
the
API
server
and
we'll
see
an
example
of
this
in
in
a
moment.
A
The
problem
is,
if
you
have
some
vulnerability
in
your
application,
and
maybe
an
attacker
gets
into
your
application.
They
can
get
hold
of
this
token
and
then
they
could
use
that
to
make
requests
of
your
API,
sir,
so
by
default,
they're
not
going
to
have
very
many
permissions
and
they
probably
can't
do
anything
too
dangerous.
But
if
you've
gone
to
that
surface
account
some
extra
permissions
that
could
be
abused
so
I
have
an
example
where
I
created
a
service
account,
but
I
called
super
power
and
roll
behind
a
cluster
roll,
binding
called
super
binding.
A
A
Hopefully,
this
will
be
invisible
when
we
go
to
the
video
okay,
so
I'm
gonna
start
by
listing
some
pods
or
seeing
whether
like
realistic
pods
for
the
superpower
service
account-
and
it
said
yes,
but
with
the
default
service
account
I
couldn't
list
pops.
Oh,
we
don't
need
audio.
You
can
just
hear
my
typing,
so
I
accept
into
that
running.
Pod
and
I've
just
got
a
bash
shell
and
the
first
thing
I'm
doing
here
is
setting
an
environment
variable
to
the
token
I'm.
Storing
the
service
account
taken
in
this
environment.
A
Variable
I'm
not
going
to
use
that
for
for
a
moment,
I'm
going
to
try
hitting
the
kubernetes
api
and
I'm
just
doing
this
anonymously,
I'm,
not
using
the
token
yet
and
we'll
see.
Yeah
anonymous
was
forbidden
access,
so
that's
good
and
then
the
next
thing,
I'm
gonna
try
is
actually
the
API
for
listing
pots.
We'll
see
whether
or
not
I
can
do
that.
I'm
still
anonymous,
I
haven't
expressed
any
sort
of
identity
in
this
car
request
and
again
I
get
the
error
code.
I'm
forbidden
from
accessing
listing
pots.
A
I'm
gonna
run
the
same
query,
but
this
time
I'm
using
that
service
account
token
so
I'm
passing
in
a
header,
including
it
to
authorize
myself.
With
this
token,
this
is
telling
the
API
server
that
I
am
this
service,
and
so
I
get
all
the
permissions
associated
with
that
service
account
and
now
I
can
get
all
the
information
I
want
about
pots.
I
didn't
do
it,
but
because
I
have
that
cluster
admin
privileges
I
could
have
deleted
that
whole
cluster,
if
I
wanted
to
from
inside
the
pod,
and
that
would
be
bad.
A
Think
we
need
to
okay
say
that
demonstration
was
really
to
show
you
that,
even
if
you
trust
everybody
in
your
organization,
you
should
be
careful
about
the
service
accounts
and
the
permissions
that
you
give
to
those
service
accounts,
because
somebody
might
be
able
to
abuse
them
if
they
manage
to
compromise
one
of
your
applications
as
an
administrator.
How
can
you
check
whether
you've
reached
this
kind
of
you
know
maximum
entropy?
How
can
you
check
who
has
permission
to
do?
What?
Who
can
individuals
perform
actions
on
a
given
resources?
Who
can
delete
parts?
A
For
example,
you
can
create
pods
in
Linux?
We
can
do
this
really
easily.
We
can
just
look
at
this
file.
We
can
easily
see
you
know
just
in
this
one
snapshot
we
can
see
who
can
execute
the
file
and,
if
I'm,
the
use
of
this
or
a
member
of
staff
I
can
execute
it
and
I
can
run
a
simple
ID
commander
to
find
out
that
yeah
I
am
Liz
and
I
am
a
member
of
staff,
so
I
can
execute
that
file
in
Cuba
Nettie's.
If
I
want
to
find
out,
can
I
create
a
pod.
A
It
involves
quite
a
lot
of
steps.
We
have
to
start
with
the
user.
We
need
to
find
all
that
were
all
bindings
that
reference
that
user
and
then
we
need
to
find
all
the
roles
that
those
role
bindings
refer
to
and
if
any
of
those
roles,
let
you
create
support,
then
that
user
can
create
a
pod.
So
you
have
to
kind
of
traverse
these
different
abstractions
to
get
that
information.
A
There
is
a
tool
we
actually
saw
it
in
the
beginning
of
that
video
queue
control
or
can
I
as
a
user
perform
a
verb
on
a
resource,
so
can
I
create
pods
Lesley's
in
this
example.
No,
but
if
I
wanted
to
list
pods,
yes,
so
to
get
this
simple
app,
that's
telling
us
whether
this
identity
can
do
a
particular
action
upon
a
particular
resources.
A
What
if
we
wanted
to
find
out
all
of
the
identities
who
can
create
pods,
for
example?
Again
we
have
to
traverse
all
these
different
abstractions,
but
we
have
to
kind
of
start
from
the
other
end.
We
have
to
find
all
the
roles
that
allow
the
creation
of
pods.
We
need
to
find
all
the
role
bindings
that
refer
to
those
roles,
and
then
we
need
to
find
all
the
identities
that
uses
the
groups
and
the
service
accounts
that
are
referenced
by
those
role,
findings
and
I
couldn't
find
at
all.
A
A
So
we've
seen
how
cognizes
permissions
are
quite
a
lot
more
complex
than
Linux.
There
kind
of
is
some
equivalence.
We
can
draw
parallels
where
in
Linux
we
just
have
files
and
cuba
niceties.
We
have
more
complexity,
we
have
lots
of
resources.
We
have
a
lot
more
verbs,
a
lot
more
actions
that
we
can
perform
on
those
resources
and
we
have
these
additional
abstractions
of
roles
and
role
bindings
that
are
hugely
powerful,
but
also
can
create
some
additional
work
in
terms
of
figuring
out
who
has
which
permissions
and
managing
those
the
configuration
of
these
permissions.
A
We
also
have
the
unusual
idea
of
having
users
and
service
accounts
as
well
as
groups,
but
users
and
groups
being
managed
externally,
tsukuba
Nettie's,
that's
another
source
of
potential
confusion,
but
in
broad
strokes.
That
shows
us
how
Linux
permissions
matter
versus
permissions,
and
it's
not
really
a
surprise
that
it's
more
complex
in
cuban
at
ease,
because
it's
distributed
and
distributed
systems
are
more
complex
than
sort
of
local
systems.
A
That's
kind
of
just
scratch.
The
surface
of
our
back.
I
co-wrote
this
book
with
micro
has
inverse,
which
talks
about
lots
of
different
aspects
of
kubernetes
security.
There
is
more
on
our
back
and
some
of
the
tools
you
can
use
to
manage
our
back
and
and
some
other
security
information
as
well.
This
book
you
can
download
from
lack
or
website
for
the
mere
price
of
your
contact
details
and
do
go
and
check
out
that
proof
of
concept
for
keep
control.
Who
can
and
let
me
have
your
feedback,
I'd
love
that.
A
Coming
back
to
that
original
quote:
I
think
for
cube
analysis.
We
can
just
slightly
rephrase
that,
although
configuring
for
missions
is
kind
of
complex
and
does
require
some
some
tooling
and
hopefully
as
a
community
over
time,
we
will
make
it
easier
to
configure
these
permissions.
But
it's
a
worthwhile
thing
to
do,
because
if
you
can
get
your
permissions
configuration
right,
you
won't
be
having
to
go
to
your
boss,
asking
for
forgiveness
when
somebody
deletes
important
resources
from
your
notes.