►
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
Tutorial: Bullet-Proof Kubernetes: Learn by Hacking - Luke Bond, ControlPlane & Ana-Maria Calin, Paybase
Learn how to attack, exploit, and hack Kubernetes clusters and application workloads. In this workshop attendees are divided into teams, given a crash-course in Kubernetes cluster security, and then set loose on a series of vulnerable clusters in a competitive capture the flag. Full methods, solutions, and vulnerabilities are revealed, along with actionable mitigation steps to enhance a cluster’s security and lock down common misconfigurations. It is designed to develop the kind of expertise only realised in production environments. Emphasis is placed on collaboration and communication, which are key to unlocking some of the advanced flags.
https://sched.co/MPgo
A
We
basically
locate
people
into
teams
that
can
be
easier
for
us
if
we're
more
compressed,
so
the
people
who
say
basically,
if
you
could
fill
the
seats
towards
the
front,
the
front
rows,
are
reserved
for
well
see
some
of
the
seats
for
those
with
accessibility
needs,
but
other
than
that.
If
you
could
try
and
fill
out
the
front
rows.
It'll
just
save
us
time
when
we
come
to
see
medication
soon,
and
if
people
will
cover
that
when
we
get
there.
A
A
Okay,
I
think
people
are
still
filing
in,
but
I
think
we
should
get
started
because
we've
only
got
so
much
time
right.
We've
got
a
lot
to
get
through.
So
first
of
all
welcome
and
thank
you
for
coming
slightly
relieves
that
the
registered
counts
of
640
as
of
last
night,
hasn't
quite
eventuated.
So
that's
good,
and
so
we
have
a
lot
of
clusters
who
spun
up
for
this,
which
thankfully
won't
all
be
necessary,
but
that's
probably
gonna
work
out
just
about
right
now.
A
B
And
this
is
Luke
Luke
bond.
He
is
a
co-founder
of
control.
Plane
he's
been
working
a
lot
in
the
industry
for
quite
a
few
years,
and
control
plane
is
a
consultancy
around
kubernetes
and
security
and
all
things
cloud
native,
all
right.
So
the
plan
for
today
what
we're
going
to
cover
we're
going
to
talk
about
a
few
things
that
you
should
keep
in
mind
when
we
are
thinking
about
kubernetes
security,
then
we'll
go
into
allocating
everyone
into
teams
with
your
own
clusters
and
then
we'll
do
some
hacking
yeah.
A
B
A
Specially,
even
you
dig
into
any
of
them
the
huge
subject,
something
like
cluster
deployments,
just
like
when
you
think
can
in
your
organization
what
are
the
controls
around
a
developer,
putting
any
olds
vulnerable
piece
of
software
into
your
cluster.
That's
I
mean
it's
a
big
problem
space
in
itself,
right
so
focusing
here
mostly
about
the
runtime
stuff
today,
but
some
yeah,
it's
a
big
space.
A
So
we
can
have
kernel
exploits
itself
so,
as
I'm
sure
we
all
know,
containers
are
just
processors
running
on
Linux
with
a
few
few
kernel
features
that
gives
them
some
isolation,
namespaces
and
C
groups.
But
that
means
that,
although
we
have
mount
namespaces
and
Network
namespaces,
they
give
us
partition
between
some
segregation,
some
degree
of
segregation
between
between
our
applications
in
terms
of
what
they
can
do
and
what
they
can
access
on
the
system.
A
We
are
sharing
one
kernel,
so
containers
don't
give
us
we're,
not
we're
not
we're
not
immune
to
kernel
bugs
basically
so
kernel
exploits
a
dirty
cow
are
just
as
valid
inside
containers
without
further
configuration,
and
then
we
are
outside
and
various
misconfigurations
around
the
cluster
like
whether
how
good
your
are
back
is
whether
you
have
certain
old
versions
of
kubernetes
that
have
certain
bugs
in
them.
If
you're
mounting
Mountain
things
too
freely,
that's
something
to
look
for
when
you're
looking
into
the
clusters
that
we
have
today,
and
obviously
your
application
security
as
well
too.
A
So
that's
what
we
mean
by
pivoting
here
from
there
you
want
to
see
you
want
to
see
what
tools
you
have
inside
the
container,
how
they
have
ami
be
useful
to
access
other
things
in
the
system
there
we're
going
to
look
at
there
is
where
we're
going
to
find
out
how
good
a
network
policy
and
things
like
that
are
in
our
clusters.
So
if
you
think,
for
example,
what
you
want
to
avoid
is,
if
you
someone
breaks
into
a
web
front-end,
for
example,
gets
shell
and
then
is
able
to
query
the
database.
A
If
there's
no
need
for
that
application
to
query
the
database,
you
should
add
network
policy
that
locks
it
down
just
talking
about
putting
layers
of
defense
all
the
way
through,
especially
when
it
comes
to
the
protection
of
data.
Only
the
services
that
should
be
able
to
talk
to
the
database
should
be
able
to
do
it
with
network
policy.
So
yeah
you
can
get
into
container
and
see
what
we
can
access.
We
probably
want
to
have
a
look
around
for
various
ports.
A
B
So
in
terms
of
what
you
can
do
to
protect
the
production
cluster,
is
there
some
best
practices
that
were
probably
published
by
a
cloud
next
in
2018?
So
when
you
set
up
a
cluster,
you
should
make
sure
that
you
restrict
access
to
keep
CTL
to
only
the
people
in
your
team
that
really
need
it.
You
should
always
always
use
our
back,
no
matter
what
and
most
of
the
big
cloud
platform
so
like
AWS,
TCP
and
Azure.
B
At
the
moment,
they
all
support
her
back
by
default,
as
your
was
a
bit
late
to
the
game,
but
they
do
it
now.
So
that's
good
use
network
policies
to
make
sure
that
more
privileged,
less
privileged
pods
cannot
get
access
to
more
privileged
workloads
and
databases
and
stuff.
Like
that
push
drop
TLS
and
use
names
vices,
then
you
should
always
keep
your
kubernetes
updated.
If
use
the
managed
version
that
shouldn't
be
much
of
a
problem,
you
should
always
use
a
minimum
of
minimal
operating
system
with
as
little
features
as
possible.
B
Follow
the
list
privileged
access
in
terms
of
a
and
roles
use,
private
IP
s
on
your
node,
always
audit
everything
and
have
logging
available
again
disable
dashboards
disable.
The
default
service
account
tokens
that
on
GCP
comes
comes
by
default,
with
the
full
compute
access
which
you
won't
want
on
your
communities.
Clusters
protect
node
metadata.
You
don't
have
to
do
that
anymore,
scan
images,
it's
totally
a
mask
and
also
make
sure
that
you
protect
your
secret
and
use
the
service
mesh
for
authentication
and
encryption.
B
A
A
Okay
moment
it's
gonna
take
some
time
so
well.
What
I
need
to
do
is
split
us
up
into
22
teams,
because
that's
the
number
of
clusters
that
we
have,
we
have
24
tables,
so
I
will
basically
like
pair
a
few
of
them
up
and
I'm
gonna
come
around
and
I'm
going
to
come
around
and
give
you
team
names
because
you'll
need
those
names
to
get
your
credentials.
So
someone
in
each
team
can
take
a
note
of
the
team
name.
I
give
them
so.
A
C
A
A
A
All
you've
got
to
go
off
is
the
fact
that
there
are
some
IP
addresses
and
in
the
cheat
sheet
you
might
find
some
ideas
for
things
you
could
try
like
I
said,
if
you're
new
to
security,
that
might
be
a
bit
of
a
thin
brief.
So
at
some
points
we'll
give
you
some
hints
to
move
it
along
because
you
want
to
make
sure
they.
Everyone
gets
something
out
of
it.
So
do
you
worst
for
now.
A
A
B
A
C
B
C
A
B
A
A
C
A
I'm,
basically,
where
we
want
to
start
with
this
scenario
is
we've
all
you've
got
to
go
on
is
that
there
are
some
IPS.
You
might
think
what
kind
of
you
bish
you
want
to
know
what's
running
on
which
ports
anyone
know
a
tool
that
is
useful
for
scanning,
open
ports
and
and
map.
Yes,
nm
APN
map
will
give
you
a
little
thing
you
can
copy/paste
in
a
moment,
so
you
can
run
that
yourself.
I
can't
even
think.
A
Thirty
thousand
and
above
someone
suggested
yes,
that's
a
good
one,
because
they
are
that,
if
that's
the
range
for
node
ports
right,
not
all
not
all
of
our
workloads
are
going
to
be
running
with
node
ports,
but
it's
a
good
place
to
start
so
shortly.
We'll
give
you
an
example
of
something
you
can
something.
You
get
an
nmap
script
that
you
can
run
to
look
for
ports
in
that
range
and
that's
probably
a
good
place
to
start
for
this
scenario.
A
How's
that
more
MORE,
why
not?
Let's
go
all
the
way
so
these
these
are.
These
are
batch
functions
if
you're
on
a
machine
that
doesn't
have
any
map
and
it's
Linux
then
and
bunchy
based,
then
that
might
be
how
you'd
install
any
map
you
don't
have
to
leave
it
as
an
exercise
for
you,
you're,
using
a
different
different
system
and
pasting
these
functions
in
well,
we'll
define
those
functions
for
you.
You
could
then
say
for
after
pasting
the
end
map
cube
one.
A
A
Gonna
be
a
little
different
and
then
we've
got
some
ones
down
the
bottom
here.
So
this
is
you
don't
use,
cube
and
E
that's
from
another
exercise,
but
these
are
so
much
some
more
commands
where
you
might
want
to
scan
for
particular
ranges.
This
range
here
is,
you
might
say,
it's
probably
a
bit
a
bit
large,
but
it
gives
you
an
idea
of
the
syntax
so
that
you
can
use
it
to
scan.
For
example,
the
30,000
range.
A
B
A
C
B
C
A
So
the
the
hint
that
it
gives
you
is
a
link
to
a
CVE
from
memory
for
shell-shocked,
which
is
a
vulnerability
that
you
can
eat
well,
in
this
case
that
you're
able
to
use
to
exploit
to
break
city
get
get
shell
into
the
container,
basically
so
that
hint,
the.
Obviously
it's
not
really
representative
in
the
real
in
the
real
world
of
something.
Quite
so
it's
only
quite
so
clear,
but
you
will
generally
find
hints
of
what
kind
of
service
that
is
and
then
you
think
of
what
kind
of
attacks
you
can
make
on
it.
A
A
B
A
A
A
So
these
commands
from
earlier
you,
you
are
using
them
earlier
to
okay,
we'll
come
to
you
in
a
sec,
we're
using
these
commands
earlier
to
scan
the
the
notes
from
the
outside,
and
you
will
likely
have
found
a
note
port
that
was
open.
You
can
also
use
these
to
scan
for
what
you
can
access
from
inside
the
container
so
and
map
from
that
compromise
workload
and
see
what
you
can
reach
and
then
have
a
look
around
a
cluster
from
there.
A
B
A
D
B
D
C
A
A
Cheat
sheets,
which
is
basically,
if
you're,
having
trouble
doing
the
shell
shop,
exploit
to
get
a
shell
into
container.
You
can
use
what's
in
here,
so
our
support
scanning
will
have
identified
thirty
thousand
and
eighty
one
is
got
something
running
there
when
we
curl
it,
it
tells
us
about.
Shell-Shocked
were
like
okay.
Let's
try
that
so
this
number
one
check
shell-shocked
is
a
curl
command.
You
can
use
with,
obviously
your
host
IP
and
it
will
thank
you.
Then
you
will
start
to
see.
A
Okay,
so
then,
once
you've
done
that
what
we
want
to
start
looking
for
next
is
look
at
what
mountains
you
will
find
that
the
docker
socket
is
mounted
in
there,
which
is
a
bit
of
a
goldmine,
but
you
don't
have
access
to
it
right
away,
or
at
least
not
that.
Obviously,
what
you'll
then
want
to
do
is
yes,.
A
So
you'll
want
to
think:
okay
I
am
in
a
container
what
how
how
contained
am
I,
what
kind
of
how
have
I
been
locked
down?
What
can
I
do
from
here?
There's
a
tool
called
a
Meyer
contained
which
you
can
use.
This
is
in
the
cheat
sheet
as
well.
That
will
that
will
give
you
some
useful
information
about
some
of
your
avenues
for
exploit
from
there.
A
B
A
C
B
A
C
B
A
A
One
thing
to
look
for
is
you'll
find
that
in
run
secrets,
if
it's
there,
this
is
a
reason
to
always
make
your
are
back.
Read
it
really
fine-grained,
really
tight
tight,
don't
give
anyone
access
to
things
they
don't
need
to
if
you're,
using,
if
you're,
not
using
our
back,
then
that
service
token
is
probably
going
to
be
really
powerful.
So
it's
something
to
look
for
when
you
get
in
there
and
then
we're
using
that
some
people
had
asked
some
people
that
asked
if
they
had
got
hold
of
a
service
account.
A
What
could
they
do
with
it
and
how
to
form
that
into
a
request
that
they
can
make
to
kubernetes?
So
that's
how
you
can
do
that
here
we
can
use
the
queue
control
command
that
we
created
up
above
earlier.
You
can
find
it
in
this
document.
Slash
attempt
such
k
and
then
you
can
get
past
the
token
in
like
that,
and
then
you're
able
to
see
what
kind
of
requests
you
can
make
on
the
kubernetes
server
secrets
is
something
the
first
thing
you
want
to
look
for,
although
they're
secret
to
be
encrypted
in
that
CD.
A
It's
all
a
bit
contrived
for
what
we're
trying
to
highlight
here
is
the
kind
of
the
kind
of
process
you
can
go
through
and
what
that
teaches
you
about
how
to
secure
your
clusters
and
in
fact,
the
kind
of
the
kind
of
vulnerabilities
we've
exploiters,
if
you
can
even
call
them
those
they're
sort
of
lazy,
misconfigurations
and
there's
a
lot
you
can
do
to
avoid
getting
yourself
into
that
situation.
This
at
the
end
of
the
slides,
you
don't
have
a
slice
to.
A
You
will
tweak
them
out
after,
but
there
is
a
link,
a
few
useful
links,
one
of
which
is
this
one
by
my
colleague
Andy
on
kubernetes
blog,
which
is
basically
just
like.
If
you
want
to
be
given
like
a
you
know,
top
end
list
of
basic
things
you
can
do
to
in
your
cluster
to
prevent
to
protect
you
against
these
kind
of
things.
Then
I
think
it
covers
up
very
well.
A
It's
basically!
Well
you
can
you
can
really
for
yourself
I
guess
we
haven't
really
got
the
time
for
it.
Some
people
had
asked
if
they
can
get
the
the
the
docker
image
that
was
that
was
vulnerable
for
the
nginx
one.
I
will
tell
you
that
if
you
can
open
the
docker
hub
there,
please
it
might
be
a
useful
exercise
for
you
to
take
back
and
challenge
your
friends
and
family.