►
Description
Keynote: Running with Scissors - Liz Rice, Technology Evangelist, Aqua Security
Liz explores some common risks that many users are - often unknowingly - taking with their cloud native deployment, by running workloads with more privileges than they need.
"About Liz
Liz Rice is the Technology Evangelist with container security specialists Aqua Security, and also works on container-related open source projects including manifesto and kube-bench. 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."
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
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
Hi
now
you'll
notice
I
am
walking
up
today
and
there
is
a
reason
for
that,
partly
because
I'm
carrying
my
laptop
and
I
don't
want
to
drop
it,
and
partly
because
I
want
to
talk
about
the
dangers
of
running
with
scissors.
So
as
kids,
we
are
taught
not
to
run
with
scissors.
You
trip
over
while
you're
running
and
you're
carrying
a
sharp
blade.
It
could
get
messy.
So
we're
told
put
the
scissors
down
before
you
run.
A
You
might
be
able
to
run
for
miles
and
miles
carrying
those
scissors
without
incident
with
no
tripping
and
no
terrible
injuries,
but
you've
increased
the
risk
because
you've
got
that
sharp
implement,
and
what
I
want
to
talk
about
today
is
how,
by
running
with
privileges
that
perhaps
we
don't
realize
we've
got.
We
are
kind
of
doing
the
equivalent
of
rowing
with
scissors,
sometimes
in
our
cloud
native
deployments.
This
is
going
to
go
like
kind
of
deep
here,
but
I
think
you
guys
can
take
it.
I
should
say
you
people,
sorry
right.
A
This
is
a
single
node
kubernetes
cluster
running
on
a
virtual
machine
on
my
laptop
and
I'm,
going
to
do
a
few
things
this
morning
that
you,
you
don't
do
in
production
and
you
know
don't
do
everything
that
I'm
about
to
do.
But
the
first
thing
I'm
going
to
do
is
pretty
straightforward:
I'm
going
to
run
a
an
engine
X
container
inside
a
pod,
it's
pretty
much
vanilla,
nginx!
You
might
see
the
image
name.
A
It's
I've
also
added
a
utility
called
catch
which
we'll
come
to
shortly,
but
in
other
respects
it's
just
a
standard
nginx
image
that
I
pulled
off
docker
hub
last
week,
so
I
can
just
apply
that
yanil
and
we'll
see
at
the
bottom.
It's
creating
that
part
and
if
I
go
back
into
my
history,
far
and
I
should
find
there.
We
go.
I
can
exec
into
that
pod
and
get
a
shell
okay.
So
here
I
am
in
my
container
in
my
pod
running
as
root
reach,
a
privileged
user.
That's
fine
right
inside
a
container!
A
It's
not
just
inside
the
container
processes
that
are
running
inside
containers
can
also
be
seen
from
the
host
they're
running
on.
So
if
I
go
here
and
look
for
I'm
just
going
to
look
to
see
if
anything
called
sleep
is
running
and
if
it
is
I
would
like
to
know
who's
running
it,
and
at
the
moment
there
are
no
sleep
processes.
A
Okay,
so
does
that
mean
I
can
do
absolutely
anything
I
want
inside
my
container?
Well,
let's
try
something
like
changing
the
host
name.
I
can
see
the
host
name,
it's
it's
the
name
of
my
container
nginx
and
if
I
try
to
change
that
it
gives
me
this
error
message
telling
me
that
I
need
to
be
rude,
but
I
am
rude.
What's
going
on
so
it
turns
out.
There
are
these
things
called
capabilities
in
Linux
and
there's
a
set
of
really
quite
granular
capability
flags
and
you
can
add
or
remove
those
as
well
see.
A
So
if
I
use
that
cat's
utility
that
I
mentioned
earlier
print
and
I'm
only
interested
in
the
capabilities
I.
Currently
have
doesn't
really
matter
what
they
are.
The
point
is
I've
got
about
two
new
lines
worth
of
capability:
Flags
writing
as
a
normal
user
lives
on
my
machine.
I
can
do
the
same
thing.
Take
a
look!
What
capabilities
I
have
and
I
yeah
I?
Don't
have
any
I
need
to
spell
that
with
a
capital
C
just
to
be
there,
we
go
I,
don't
have
any
of
those
capability
flags
as
a
normal
user.
A
A
A
A
Yeah,
so
that
way,
it
was
only
into
the
container
but
I
needed
an
extra
capability
flag
to
be
able
to
do
that.
So
I
would
say
that
privilege,
flag
is
really
more
like
super
privileged
gonna
kill
that
pod
again
right
so
I've
shown
that
we're
running
as
root.
What
could
I
do
to
stop
myself
from
just
automatically
running
as
root?
So
if
you
looked
up
the
documentation,
you
might
find
under
security
context,
a
thing
called
run
as
non-root,
which
sounds
pretty
pretty
compelling
for
what
I
want
to
do
so.
A
I
run
that
and
we'll
see
at
the
bottom.
We
got
a
config
error.
Okay,
what's
going
on
there,
let's
describes
a
pot,
and
we
can
see
there.
It
says
container
has
run
as
non-root
and
image
will
run
as
root.
What
it's
complaining
about
is
that
I've
set
this
constraint.
I
want
to
run
this
pod
as
a
non
root
user,
and
yet
the
image
I
want
to
run
wants
to
run
as
root.
A
If
you
want
to
run
as
a
non
root
user,
you
have
to
change
your
image.
Okay,
so
I
I
did
that
here's
a
docker
file
starts
with
my
nginx
image
that
I
had
before
you
can
see
at
the
end.
I
can
use
this
user
icon
to
specify
some
other
user
identity.
Just
some
any
old
number
that
I
chose
now
nginx
like
loads
of
software,
was
written
before
we
started
running
everything
in
containers
and
it
expected
to
run
on
a
host
and
it
expected
to
serve
web
traffic.
A
Web
traffic
by
default
runs
on
port
80
and
it
turns
out
you
need
another
one
of
those
capability
flags
to
bind
to
low
numbered
ports
and
because,
presumably
you
don't
want
every
user
of
being
able
to
bind
to
the
standard
ports
like
480,
because
you
want
things
like
nginx
to
be
able
to
do
it.
So,
there's
like
a
privilege,
you
need
to
be
able
to
get
to
those
low
numbered
ports,
but
I
want
to
run
this
in
a
container
and
I
can
map
ports
from
a
container.
It
doesn't
matter
what
port
number
I
use.
A
Cuz,
it's
gonna,
get
mapped
anyway,
say
rather
than
give
myself
that
capability
flag,
I
can
set
up
a
config
to
say
actually
run
on
a
high
numbered
port
run
on
port
8080.
That's
fine
and
I
also
had
to
change
the
ownership
of
a
couple
of
files
in
this
case,
and
then
I've
already
built
this
image
and
I
called
it
user
and
your
next
user.
A
So
now,
if
I
apply
that
yeah
more,
that
should
come
up.
Yeah
that's
running
now,
so
I
can
get
back
into
a
shell
in
that
in
that
pot,
and
now
we
can
see
that
user
is
well,
it's
an
unidentified
user,
but
it's
not
root
anymore,
which
is
a
good
sign.
Let's
do
the
same
thing
we
did
before
with
sleep
I'll
sleep
for
a
little
while
inside
the
container
and
there's
my
sleep
process
from
the
perspective
of
the
host
and
it's
running
as
a
non
root
user.
Id.
All
right,
that's
good!
A
A
Making
those
changes
to
your
docker
file-
that's
that's
kind
of
work.
I
have
to
go
and
think
about
binding
to
a
different
port
and
changing
some
file,
permissions
and
ownerships
and
most
chakra
files.
It
turns
out
people
haven't
done
it
most.
Dhaka
files,
people
are
running
his
route,
I
worked
on
a
project
called
micro
badger
awhile
ago
and
that
inspects
images
from
docker
hub,
and
we
had
a
look
this
week
and
86%
of
images.
Don't
have
a
user
lines
so
they're
running
as
routes
by
default.
A
A
Maybe
there's
some
kind
of
vulnerability.
Maybe
somebody
exploits
that
vulnerability
and
escapes
the
container
and
there
if
they're
able
to
take
it.
You
know
you
might
think
that's
not
going
to
happen,
but
nobody
thought
meltdown
inspector
we're
going
to
happen
right,
so
it
could
happen
once
you've
escaped
the
container
your
route
on
the
host.
You
can
do
anything
you
like
this
seems
kind
of
risky,
but
you
don't
even
have
to
wait
for
an
exploit
to
come
along
for
it
to
be
possible
to
do
things
on
your
host
machine.
A
I
am
gonna,
do
something,
but,
first
of
all,
let
me
change
back
to
the
catch
image
and
get
rid
of
this
non-root
thing
now.
I'm
gonna
do
something
really
reckless
I'm
going
to
mount
I'm
mounting
the
root
directory
from
my
host
and
then
making
it
accessible
inside
my
container
as
the
host
directory.
This
is
an
extreme,
extremely
stupid
thing
to
do
in
some
ways,
but
I
will
do
it
anyway.
Okay,
so
I
need
to
stop
this
there.
A
A
A
Don't
really
want
that
file
there.
Let's
get
rid
of
that.
Yeah
I
want
to
delete
that.
Oh
I,
don't
have
permission
now.
I
started
that
pod
by
running
a
cute
control
command
as
Liz,
and
by
doing
so
I
s
collected
my
own
privileges,
I
became
roots,
and
now
I
can
do
more
things.
I
can
write
a
file
that,
under
as
this
acquired
root
identity,
but
I
can't
actually
do
anything
with.
Under
my
own
identity,
it's
pretty
powerful
stuff.
I
can
do
basically
anything
now
because
I've
got
the
access
to
the
whole
ring.
A
Manifest
seems
to
be
alright,
and
this
directory
has
the
definition
of
some
static,
pods,
so
Kuebler
running
on
this
node
looks
in
this
directory
and
runs
the
yam
all
that
it
finds
here,
and
this
is
used
to
start
the
kubernetes
control
plane.
We
can
see
at
CD,
API
server
the
control
plane
components
are
defined
by
what
cubelet
finds
in
this
directory.
A
A
A
It
was
kind
of
a
dumb
thing
to
do,
to
give
myself
permission
to
write
into
the
entire
root
filesystem,
but
there's
nothing
to
stop
you
from
doing
that.
All
right,
there's
no
kind
of
controls
on
that
people
can
write
yam
all
that
potentially
gives
them
access
to
all
kinds
of
interesting
things.
Now,
I,
don't
want
to
kind
of
leave
you
with
the
impression
that
you
know
lots
of
insecure
things.
Are
you
know
what
things
are
insecure,
there's
loads
of
really
good
security
measures
in
place?
A
But
if
we
get
down
to
this
level,
the
default
settings
allow
you
to
do
all
sorts
of
interesting
and
powerful
things.
There
is
work
afoot
to
do
things
like
support,
rootless
containers
and
username
spaces,
and
when
we
get
support
for
that,
that
will
help
us
will
help
stop
us
falling
into
this
kind
of
trap.
We
need
to
find
ways
to
prevent
ourselves
running
with
sharp
blades
in
our
hands.
A
Maybe
you
want
to
change
your
docker
files,
make
sure
you're
only
ever
running
as
an
on
root
user
and
then
you'd
be
able
to
set
a
pod
security
policy
with
that
run
as
non-root
that
would
be
kind
of
a
good
thing
would
make
you
know.
You'd
have
to
do
some
work
to
make
sure
you
can
run
your
images
as
non-root
users.
A
You
could
work
with
commercial
suppliers.
Akwa
have
some
really
powerful
tools.
That
would
stop
you
from
running
images
that
weren't
approved.
Stop
me
from
running
images
that
didn't
meet
certain
policies
that
you
might
have
set
up,
and
that
can
also
do
some
really
neat
controls
over
what
you're
actually
allowed
to
do
at
runtime.
So
we
could
stop
you
from
executing
things
like
the
cat
command
that
allowed
me
to
write
that
inject
file.
A
So
there
are
tools
out
there
to
prevent
you
from
running
with
scissors,
or
perhaps
you
just
want
to
pay
attention
to.
You
know,
look
at
what
you're
doing.
Are
you
allowing
people
to
mount
unexpected
files
in
their
yam,
or
are
you
allowing
people
to
run
as
none
as
as
root
user?
Are
you
letting
people
run
with
a
sharp
object
in
their
hand?