►
From YouTube: The Path Less Traveled: Abusing Kubernetes Defaults - Duffie Cooley, VMware & Ian Coldwater, Heroku
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
The Path Less Traveled: Abusing Kubernetes Defaults - Duffie Cooley, VMware & Ian Coldwater, Heroku
While the industry and the community are starting to pay attention to Kubernetes security, there are many attack paths that aren’t well-documented, and are rarely discussed. This lack of information can make your clusters vulnerable.
In this live demonstration-filled talk, we are going to provide an overview of the Kubernetes control plane before using sigs.k8s.io/kind to show some of the attack surface exposed by a default configuration of Kubernetes. There will be multiple exploits involving various moving parts, including cluster takeovers and host escapes. We’ll show you mitigations, and then show you how to get around those.
The audience will walk away from this talk with a better understanding of Kubernetes’ default attack surface, how it can be exploited, and how to keep their clusters safer.
B
Everyone
I
came
right
here,
us,
okay,
sweet
this
talk
is
called
the
path,
less
traveled
abusing
kubernetes
defaults,
and
it
is
going
to
be
demonstrating
to
you
some
interesting
things
that
can
happen
with
the
kubernetes
cluster
set
up
out
of
the
box.
So,
let's
get
to
it.
My
name
is
Ian
Coldwater
I
am
a
lead
platform
security
engineer
at
Heroku
before
that
I
was
an
independent
penetration
testing
consultant
specializing
in
hacking
and
hardening
kubernetes
containers
and
cloud
infrastructure.
B
A
Name
is
Duffy
Cooley
and
my
staff
cognitive
architect
at
VMware.
I
came
there
as
part
of
the
hefty
acquisition
I've
been
working
on
kubernetes
since
about
2016,
just
jumping
into
the
community
channel
and
helping
everybody
that
I
can
I'm.
Also
a
co-host
of
TGI
kada
I/o.
If
you're
interested
in
the
space
around
kubernetes
or
pretty
much
anything
in
the
cloud
native
ecosystem,
I
highly
recommend
that
we
do
it
every
Friday
at
one
o'clock,
so
check
it
out.
B
So
the
first
thing
we
want
to
say
is
check
your
assumptions.
A
lot
of
people-
maybe
not
necessarily
and
people
in
this
room,
but
a
lot
of
people
assume
that
kubernetes
is
secure
by
default
and
it's
not
Cooper
Nettie's
by
design
is
designed
for
granular
control.
So
the
defaults
are
actually
quite
open
and
allow
for
you
to
be
able
to
customize
your
cluster
according
to
your
needs
in
your
use
case,
and
that's
not
bad,
but
it
isn't
secure
out
of
the
box
and
neither
are
the
applications
deployed
upon
it.
B
So,
let's
break
that
down
a
little
bit
for
one
thing:
it's
a
little
bit
of
a
misnomer
to
talk
about
kubernetes
defaults
because
there
is
no
singular
set
of
kubernetes
defaults.
All
of
the
distributions
have
slightly
different
default
out
of
the
box,
and
every
cluster
is
going
to
be
slightly
different
according
to
what
kinds
of
configurations
plugins
and
other
things
you
have
running
in
it.
So
it's
a
little
hard
to
give
one-size-fits-all
security
advice,
either
on
attack
or
on
defense.
But
there
are
a
lot
of
commonalities
and
so
we're
going
to
talk
about
those
today.
B
A
Talk
uses
a
cluster,
that's
actually
user
defaults,
as
defined
by
cube
a
DM
cube
medium
is
a
project
that
is
actually
meant
to
provide
common
tooling.
That
gets
you
from
the
place
where
you
have
infrastructure
up
to
the
point
where
you
have
kubernetes
and
the
benefit
of
having
that
common
tooling,
is
that
we
can
extend
that.
B
Important
to
note
here
that
coop
ADM
actually
is
designed
for
having
relatively
sane
defaults,
and
so
this
is
the
thing
that
we're
going
to
be
exploiting
out
of
the
box
today,
many
kinds
of
configurations
or
like
installers
will
actually
have
defaults
that
are
weaker
and
that's
important
to
note.
It's
also
important
to
note
that
kubernetes
by
default,
overrides
Dockers
defaults
at
comp
profiles
and
the
security
position
that
docker
sets
up
by
default.
A
lot
of
people
assume
that
that's
inherited,
and
it's
not
it's
actually
overridden
to
avoid
breaking
changes.
B
So
we
wanted
to
point
that
out
because
it's
important
what
do
we
mean
when
we're
talking
about
kubernetes
here?
Presumably,
if
you're
at
cube
con,
you
have
a
general
idea
that
kubernetes
is
a
container
Orchestrator.
You
know
that
it
does
all
these
things,
but
for
the
purposes
of
talking
about
it
as
an
attack,
surface
kubernetes
is
two
different
things.
B
It
is
both
an
application
and
its
associated
set
of
binaries
and
in-district
like
a
loosely
coupled
distributed
system
and
it's
an
API
platform
defined
by
gamal
so
like
it's
both
and
both
of
those
are
attack,
surfaces
but
they're,
not
necessarily
the
same
attack
surface,
so
we're
going
to
cover
that
as
a
whole
today,
so
anybody
want
to
attack
some
stuff.
Let's
tag
some
stuff,
it's
gonna
do
it
so,
what's
going
on
here.
A
So
this
first
session,
what
I'm
going
to
use
for
this
for
the
first
demonstration
we're
going
to
talk
about
a
tool
that
I
wrote.
It
helps
me
diagnose
or
debug,
what's
happening
with
with
sed,
if
there's
actually
a
problem.
So
what
this
tool
does?
Is
it
basically
it's
just
a
static
pod
or
a
pod
that
you
can
actually
deploy
as
a
as
a
deployable
pod
and
it's
going
to
grab
the
sed
binary
from
that
it's
actually
being
used
within
the
cluster.
A
So
just
a
version
of
sed
I
set
some
environment
variables
and
I'm,
making
use
of
host
path
here
to
be
able
to
pull
in
all
of
the
certificates
necessary
to
allow
sed
client
to
authenticate
to
the
sed
cluster
that
is
hosted
inside
of
the
system.
I'm,
actually
targeting
localhost
here,
to
connect
to
it
and
to
that
end,
I
actually
need
to
make
sure
that
this
pod
is
running
you,
the
host
network,
so
that
I
can
actually
provide
that
access.
A
B
That's
a
legitimate
use
case
for
a
sysadmin
or
somebody
who's
trying
to
debug
a
cluster.
But
what
else
could
you
do
with
a
list
of
members
and
their
associated
permissions?
Let's
find
out
so
I'm
dumping,
all
of
the
secrets
from
this
at
CD
and
that's
interesting.
What
do
we
have
here?
We
have
various
kinds
of
things
under
cube
system
namespace.
One
of
the
things
we
have
is
called
cluster
roll
aggregation
controller.
This
has
been
patched
as
of
1.16,
but
in
previous
versions
it
still
works.
B
Cluster
roll
aggregation
controller
because
its
role
is
literally
to
aggregate
cluster
rolls
has
access
to
everything.
It
has
administrative
control
over
the
cluster
by
default,
so
that
one
looks
interesting.
Let's
see
if
we
can
get
a
token
out
of
it
as
it
turns
out.
Yes,
we
can
so
with
this
token,
let's
see
what
kind
of
permissions
we've
got
on
it.
Coups
ETL
of
auth
can
I
list,
which
is
the
best
tool
for
pen
testers.
That's
come
out
in
years.
B
As
far
as
I'm
concerned,
handily
enumerates
all
of
the
possible
permissions
that
we
have,
so
we
can
figure
out
exactly
what
we
can
do.
With
this
token,
in
a
very
neat,
automated
fashion
previously,
when
we
were
pen
testing
a
cluster,
we
would
have
to
do
every
single
call
individually
to
figure
out
what
kinds
of
permissions
we
had,
and
that
was
annoying.
It
took
a
long
time
so
thanks
kubernetes
for
helping
our
enumeration
process.
So
what
kinds
of
access
does
this
have?
B
Well,
as
it
turns
out
one
of
the
things
that
has
is
wildcard
wildcard,
which
that
seems
like
that
could
be
potentially
useful.
So
with
our
lovely
cluster
role,
aggregation
controller
wildcard,
we
will
now
take
over
not
only
this
cluster
but
the
underlying
node,
because
we
have
mounted
it
on
host
path
and
it's
mine
game
over
I
get
to
go
home
too
bad.
So
there's
that.
B
One
of
the
things
we're
going
to
keep
talking
about
here
is
how
a
lot
of
the
time
things
that
are
very
useful
debugging
things
for
sis
admins,
for
example,
or
like
legitimate
use
cases
for
somebody
who
is
like
trying
to
operate
a
cluster
can
be
used
exactly
the
same
way
but
for
nefarious
purposes
by
somebody
who
is
maybe
up
to
something
else.
So
that's
an
important
thing
to
be
able
to
think
about
and
I'm
good.
B
This
is
what
my
keynote
on
Thursday
is
about,
so
we
directly
scheduled
that
that,
on
the
underlying
note,
because
the
couplet
was
running
in
the
same
node
and
that
is
problematic,
because
if
you
run
a
couplet
on
your
control
plane
note
if
you
take
over
the
underlying
node
there,
you
go
okay.
So
what
do
we
take
away
from
this
demo?
For
one
thing,
if
you're
authorized
to
create
pods,
you
can
do
a
hell
of
a
lot
by
default
because
it
just
allows
you
to
that's.
A
Right,
you
can
also,
and
to
your
point,
scheduling
it's
not
a
security
boundary.
You
can
directly
schedule
any
pod
that
you
want
namespace
isolation,
especially
in
the
absence
of
admission
control
is
not
enough.
Isolation
right
if
you
have,
if
you
have
the
ability
to
make
you
supposed
to
pass,
it's
very
scary.
It's
not
this
and
the
mitigations
that
we
can
do.
B
For
me,
so,
okay
yeah
make
sure
that
you
are
applying
appropriate
forms
of
isolation
and
don't
assume
again
check
your
assumptions
that
any
one
of
them
is
going
to
be
enough.
So
we'd
mentioned
host
path.
A
couple
of
times
and
I
wanted
to
talk
more
about
it,
because
host
path
is
wild
host
path
is
so
wild
that
we
named
this
talk
after
it.
Host
path
is
defined.
To
this
day
you
can
look
at
it
on
the
site.
This
is
a
screenshot
from
it
in
the
kubernetes
documentation
as
a
powerful
escape
hatch.
They
are
not
kidding.
B
It
is
an
incredible
powerful
escape
hatch.
You
can
escape
all
kinds
of
things
with
it.
Host
path
has
legitimate
use
cases
and
is
used
fairly
commonly
in
a
couple
of
use
cases
that
we'll
talk
about
in
a
second,
but
it
is
so
powerful
and
so
ripe
for
abuse
that
it's
really
important
to
understand
that,
so
that
you
can
protect
against
how
easy
and
how
powerful
a
path
it
is
for
an
attacker.
A
B
People
use
doctor
and
doctor
a
lot,
but
it's
important
to
know
that
exposing
the
doctor
socket
allows
users
who
have
access
to
the
docker
group
pretty
much
root
access
on
the
host
and
like
immediately
like
an
exposed,
docker
socket
as
a
pen.
Tester
means
that,
literally
by
the
time
I'm
done
pushing
the
k-cup
button,
I've
got
root
and
I
can
go
home.
B
So
all
of
the
container
runtimes
of
stuff
he
said,
have
this
kind
of
socket,
and
it's
really
important
to
know
that
like
have
giving
users
access
to
this
socket,
even
if
you
are
running
them
as
non-root
as
non-privileged,
actually
gives
them
read
access
to
the
underlying
host.
It's
it's
important
to
know
that,
because,
even
if
you
are
setting
up
things
that
aren't
privileged,
they
can
escalate
the
privileges
remarkably
easily.
We're
gonna
demonstrate
this.
A
So
when
this
part
of
it
we're
going
to
show
we're,
gonna
show
a
doctor
and
doctor
example
here
we're
going
to
show
exactly
why
it
is
kind
of
a
scary
thing.
So
in
this
this
is
a
pod
manifest
that
I'm
going
to
use
to
explode,
to
express
this,
and
you
can
see
that
I'm
doing
a
lot
of
the
like
reasonable
security
things.
A
I've
got
a
set
comp
profile
defined,
leveraging
the
docker
default
I'm
running
as
not
root
within
the
context
of
the
container
and
the
interesting
thing
about
this
security
context
is
I
can
actually
fill
in
these
numbers.
However,
I
want
I
get
and
when
the
container
starts
up,
it
will
be
operating
as
that
user.
As
that
group,
that's
being
defined,
we're
gonna
get
more
into.
Why
that's
interesting
in
just
a
minute,
but
the
other
thing
I'm
doing
is
I'm
going
and
I'm
counting
in
that
var
run,
docker
socket
and
I'm
again
specifying
that
node
name.
A
A
We
can
see
that
when
I
jump
in
here
and
I
type
ID
I'm
running
as
that
user
in
that
group
that
we
saw
before
and
the
reason
I
picked.
That
particular
GID
is
because
in
this
install
of
docker,
as
with
most
installs
of
docker,
there's
going
to
be
a
docker
group.
That's
been
defined
right
and
the
group
ID
for
this
particular
install
was
132.
So
I
just
specified
that
in
my
pod
spec,
so
that
I
could
actually
go
ahead
and
impersonate.
Someone
in
that
you
in
that
group
inside
of
the
context
of
the
container.
A
So
with
this
setup,
I
can
do
things
like
build
and
push
images
which
is
kind
of
the.
The
key
use
case
for
a
doctor
in
docker
implementation
and
and
I
can
go
ahead
and
start
things
so
I.
If
I
exact
into
that
container,
I
can
run
a
command
like
docker,
run,
nginx
and
point
it
to
a
particular
image
and
it
will
go
ahead
and
start
up,
but
because
I
actually
targeted
a
specific
node
I,
actually
targeted
my
laptop
here
and
if
I
do
dr.
PS
on
the
underlying
node.
A
B
A
So
in
this
example,
I'm
going
to
go
ahead
and
create
a
file
inside
of
the
sed
directory,
and
you
can
see
that
to
create
this
file.
I
have
to
have
sudou
access
because
I'm
not
running
I'm,
just
running
as
a
normal
user,
but
I
can
actually
use
that
same
access
to
go
ahead
and
remove
this
file
just
by
running
a
container.
Within
the
context
of
that
of
that
doctor
and
doctor
socket.
A
Right
so
if
you're
running
docker
and
docker,
you
have
the
underlying
host,
you
can
do
pretty
much
anything
to
the
underlying
file
system,
because
everything
that
you
express
in
against
that
docker
API
inside
the
container
contextually
is
represented
by
the
underlying
host
stuff.
So,
if
I
mount
in
a
volume
like
at
CD
for
the
/se
directory,
for
example-
that's
the
underlying
hosts
at
sea
directory-
it's
not
the
one
that's
actually
expressed
inside
of
the
container,
because
that
docker
socket
is
running
on
the
underlying
host.
B
An
attacker,
if
I'm
able
to
do
whatever
I
can
dream
up
there's
a
lot.
I
can
do
there,
because
I
was
an
attacker.
I
have
a
pretty
good
imagination
and
there's
a
lot.
I
can
dream
up.
That's
not
necessarily
the
kind
of
access
you
want
to
give.
So
what
can
I
take
away
from
this
demo?
Doctor
and
docker
gives
a
lot
of
access
to
the
underlying
host
by
default
like
a
lot
like
root,
and
it
allows
an
attacker
or
a
legitimate
admin
to
gain
full
access
to
the
kernel
when
used
in
that
way.
B
B
A
B
A
B
A
knocker
attack
it
because
container
because
kid
kubernetes
is
a
container
Orchestrator
attacks
on
containers
are
still
viable.
You
can
still
do
them
and
it's
important
to
know
that,
because
if
we
understand
how
to
attack
containers,
we
can
understand
better
how
to
attack
kubernetes,
and
if
we
understand
how
to
attack
linux,
we
can
understand
better
how
to
attack
containers
and
also
how
to
secure
them,
because
it's
containers
aren't
magic,
they're,
just
Linux,
and
if
you
understand
the
low
levels
it
can
help,
you
both
be
able
to
understand
how.
B
B
A
kernel
attack
surface
in
a
single
container
or
on
that
host
is
a
shared
kernel,
attack,
surface
and
so
container.
Security
is
a
holistic
thing,
it's
only
as
secure
as
the
individual
container
as
the
applications
that
are
running
on
it
as
the
underlying
node
as
the
host
as
the
OS
as
the
silicon,
and
so
it's
important
to
think
about
that
holistically
when
you're
trying
to
secure
it
to
make
sure
that
all
of
those
layers
are
actually
being
secured
and
as
an
attacker,
it
means
that
I
have
a
wide
multi
variate
attack
surface.
B
It
means
that
I,
if
I,
can
attack
that
kernel.
If
I
can
attack
that
the
application
in
that
container,
if
I
can
attack
anything
along
that
stack,
I
get
access
to
a
lot
of
it.
People
are
doing
really
interesting
work
with
process,
isolate
with
container
isolation
right
now
that
I
want
to
acknowledge.
But
if
you're
not
doing
that,
it's
important
to
know
what
kinds
of
access
somebody
can
get
if
they
compromised
that
container
or
that
cluster,
because
your
resources
make
for
a
shared
attack
surface.
B
A
So,
as
you
can
pointed
out,
like
containers
are
basically
to
process
isolation,
if
you
take
nothing
away
from
this
talk
other
than
that,
that's
that's
enough
right
when
we
actually
think
about
container
orchestrating
containers
really
what
we're
just
doing
is
putting
a
process
on
a
server
and
we're
associating
that
process
with
these
sets
of
primitives.
So
if
that's
the
invest
the
important
part
here
right,
we
can
give
it
its
own
file
system.
We
can
give
it
its
own
Network.
We
can
give
it
its
own.
A
B
To
demonstrate
this
a
little
bit,
this
is
a
single
tweet
that
allows
us
to
get
route
on
the
underlying
node,
not
using
host
path.
So
we're
gonna
go
through
this,
because
it's
interesting
and
it
illustrates
some
things
about
how
you
can
interact
with
and
also
attack
containers
on
the
underlying
you
know,
if
you
understand
the
low
levels
of
them,
so
we're
gonna
get
route
via
an
ax
Center
here.
So.
A
Let's
take
a
look
at
this
manifest.
This
manifest
is
actually
just
generated.
Basically,
from
that
same
one
treat
lines,
it's
a
little
easier
to
read
and
it's
a
very
simple
one
again
I'm
doing
a
direct,
a
direct
target,
I'm
tired
I'm
targeting
a
particular
node
name,
I
have
specified
host
pid',
true
and
the.
A
What
that
allows
me
to
do
is
it's
inside
of
the
containers
context
and
you
type
PS,
minus
EF,
you'll,
see
all
of
the
processes
of
the
host
I'm,
also
giving
privileged
access,
which
is
like
God
mode
for
these
processes
right
like
if
you
have
privileged
access.
That
means
that
you
have
the
ability
to
understand
to
interact
with
pretty
much
any
system
call
that
is
available
to
you
in
the
side
of
the
Linux
kernel.
A
All
of
it
and
I'm
not
I
mean
I'm,
just
an
authenticated
user
here,
like
without
the
in
the
absence
of
admission
control,
there's
nothing
that
you
can
do
to
keep
that
keeps
a
user
from
being
able
to
exit
exercise
this.
This
is
not
a
magic
thing,
might
be
fun
to
operate
this
on
your
own
cluster
and
see
what
that
looks
like.
So
let's
go
ahead
and
deploy.
A
And
if
I
jump
in
it'll
actually
I
wanted
to
kind
of
give
you
a
quick
view
into
the
kind
of
the
tool
that
I'm
using
to
do
some
of
this
work.
This
tool
is
called
enna
Center
and
you
can
think
of
it
like
a
Swiss
Army
knife
for
all
of
those
namespaces
that
comprise
that
isolation
model
for
processes
that
we
talked
about
right.
A
So
you
can
see
the
list
here
on
the
left,
and
it
looks
very
similar
to
the
list
that
you
might
or
that
that
that
represents
all
of
those
processes
and
we're
going
to
show
that
here
in
a
second
for
any
given
process
within
the
Linux
kernel.
It
gives
you
the
ability
to
enter
into
any
one
of
those
namespaces
and
I've
used
it
to
actually
solve
kind
of
some
mysteries
around
how
containers
are
actually
operating.
So
in
my
example,
I'm
going
to
go
ahead
and
pull
the
pit
of
an
engine
X
process
we
can
jump
in.
A
We
can
identify
once
we've
identified
that
Pig
I
can
use
NS
enter
to
enter
into
the
network
name
space
associated
with
that
process
and
do
a
list
of
listening,
sockets,
right
and
so
I
can
see.
In
my
case,
I
was
trying
to
figure
out
why
this
host
wasn't
or
why
this
container
wasn't
listening
on
port
443.
It
looks
like
it's
just
not
configured
to
write.
It's
only
listening
on
port
80,
so.
B
As
an
attacker,
we
can
do
other
things
with
this
as
an
attacker
if
I'm
trying
to
get
into
somebody's
container,
and
they
don't
put
shell
access
in
the
container,
which
is
common.
That
makes
my
job
much
more
annoying,
because
I
would
really
like
text
exactly
to
that
container
and
see
what's
going
on
and
be
able
to
interact
with
it
and
then
I
have
to
like
it's,
you
know
figure
out
how
to
do
that,
and
a
center,
as
it
turns
out,
is
one
way
to
do
that.
B
You
can
just
interact
with
that
container,
even
if
it
doesn't
give
you
shell
access
and
if
it
has
something
like
host
pit,
then
we
can
interact
with
that
process
on
the
underlying
node,
because
of
the
way
that
Linux
treats
a
filesystem.
Everything
is
a
file.
You
can't
interact
with
that
filesystem
in
interesting
ways,
so
yeah
we
did
that,
and
this
allows
us
if
we,
if
we
exec
that
cube
CTL
manifests
that
he
made.
It
just
allows
us
to
get
rid
immediately
on
the
underlying
node
by
way
of
being
able
to
interact
with
that
kid,
and.
A
Then
I'll
put
here
on
the
bottom
of
the
screen.
I
just
wanted
to
point
out
like
if
you're
looking
for
a
way
in
it
to
visualize
what
a
container
is.
This
output
describes
what
a
container
is,
so
all
of
those
namespaces
that
are
associated
with
this
particular
process.
Id
are
actually
going
to
be
unique
on
each
container
like
some
of
them
will
be.
Some
of
them
will
be
common,
but
most
of
them
will
be
unique,
and
that
was
part
of
the
point
of
what
I
wanted
to
show
up
here.
Yeah.
B
This
kind
of
thing
can
help
you
understand
how
containers
work,
which,
as
we
said,
is
really
important
as
a
pen,
tester
I
feel,
like
I,
really
leveled
up
a
lot
in
terms
of
being
able
to
attack
clusters
and
containers
in
kubernetes
context
when
I
understood
the
low
levels
better,
because
if
the
better,
you
know
how
that
works,
the
better
you
know
where
the
rough
edges
are
and
those
rough
edges
are
where
the
attack
surface
often
lives.
So
we're
gonna
do
this.
We
can
take
it
over
and
just
like
that.
We're
route.
A
B
Well,
did
you
just
do
that?
Okay,
all
right,
so
what
are
we
taking
away
here?
Restrict
use
of
privileged
containers?
It's
very
common
you'll
see
it
in
every
tutorial
in
existence
to
run
docker
privileged
doing
that
allows
all
kinds
of
access
for
you,
but
also
all
kinds
of
access
for
an
attacker,
and
you
don't
necessarily
want
that.
B
You
want
to
restrict
the
use
of
hosts
pit
as
well
as
host
paths
in
your
admission
control
setup,
because
that's
an
issue
so
is
host
network
and
also
NS
enter
really
cool,
and
it
allows
you
to
enter
any
process
on
the
underlying
good.
So
can
we
fix
this?
Yes,
mostly,
and
the
way
that
we
have
to
fix?
This
is
by
use
of
admission
control,
which
is
basically
the
only
line
of
defense
against
a
lot
of
the
stuff
that
we've
demonstrated
here
today.
It
lets
you
limit
what
a
user
or
controller
can
do
in
depth.
B
You
get
a
lot
of
granular
control
over
it
and
muscian
control
can
be
validating
or
mutating.
Real
quick
I
want
to
note
that
mutating
admission
control
is
really
interesting
as
an
attack
surface
much
in
the
same
way
that
LD
preload
is
because,
if
you
can
turn
anything
into
anything
with
the
imagination
of
attacker,
you
could
potentially
be
able
to
make
a
legitimate
process
turn
into
something
that
can
be
used
for.
I
can
turn
it
something
a
bit
used
for
my
purposes.
B
A
B
Pod
security
policies
but
rest
to
say
there
was
a
pod
security
policy
on
and
I
tried
to
do,
the
same
attack
that
we
did
earlier
and
it
didn't
work
because
I
was
forbidden
from
doing
it
so
put
on
your
pod
security
policies.
It's
important,
the
UX
is
not
always
as
easy
as
it
could
be,
and
we
see
that
and
we
validate
it
so
to
speak.
But
it's
still
really
important
to
do.
A
A
B
Okay,
but
there
is
one
thing
about
admission
control,
though,
which
is
that
it
doesn't
actually
work
in
relation
to
static
pods
because
of
the
way
that
pod
priorities
are
set
static,
pods
actually
go
into
effect
before
admission
control
takes
into
effect.
So
because
kubernetes
is
a
loosely
coupled
distributed
system,
you
can
schedule
directly
on
to
the
underlying
node
without
use
of
the
controller
like
manager
scheduler
at
all,
and
if
you
are
able
to
directly
schedule
a
static
pod
that
actually
bypasses
admission
control
entirely
so
admission
control
doesn't
fix
everything
and
static.
B
Pods
are
an
interesting
attack
surface
that
we
also
don't
have
time
to
cover
today.
So
it's
important
to
be
aware
of
that,
but
really
it
is
the
best
line
of
defense.
So
it's
really
important
to
do
and
it's
important
to
do
well,
because
it
can
be
hard
to
configure
there's
a
lot
of
moving
parts
and
it
can
be
easy
to
miss
configure.
So
we
know
that's
real,
but
it's
also
really
important
sub
coming
full
circle.
We're
really
not
trying
to
scare
you
here.
B
It
is
possible
to
secure
kubernetes
clusters
at
least
a
lot,
but
it's
not
going
to
happen
that
way.
Out
of
the
box,
it's
going
to
take
some
work
on
your
part
that
work
won't
always
be
easy
and
we
should
not
assume
that
kubernetes
is
going
to
be
secured
by
default
without
doing
that
work
because
it's
not,
and
if
we
assume
that
it
is,
we
are
leaving
wide-open
paths
for
an
attacker
to
happily
travel
down
and
that's
gonna
be
happy
for
the
attacker,
but
not
necessarily
happy
for
you.
Kubernetes
is
powerful,
it's
complex.
B
It's
got
a
lot
of
moving
parts
and
a
lot
of
things
that
need
configuration
and
can
be
easy
to
miss
configure
the
attack
surface
is
wide
and
varied
as
an
attacker.
I
love
this.
It's
like
it's
like
an
orchard.
I
just
have
all
kinds
of
fruit:
I
can
run
around
picking
as
a
defender
that
can
make
it
really
complicated,
but
it's
still
really
important
to
do,
because
otherwise
I
have
free
rein
of
your
orchard
and
I'm
eating
all
of
your
apples.
B
B
Peep
security
minded
people
need
to
be
involved
in
all
the
things
across
all
the
levels
of
the
stack,
because
we
all
need
to
be
looking
at
the
project
in
that
way
and
you're
gonna
hear
me
say
this
again
in
a
couple
of
days,
but
I'm
cüneyt
security
posture
has
been
improving
over
time.
There
is
a
bug
bounty
coming
up.
There
was
a
security
audit
that
happened
to
this
summer
that
put
out
some
really
interesting
deliverables
and
a
threat
model,
and
that's
worth
taking
a
look
at
and
reading
yep.
B
So
again,
here's
your
takeaways
check
your
assumptions:
kubernetes
not
secure
by
default.
If
you
understand
well,
though,
how
it
works,
you
can
understand
it
better
as
an
admin
or
an
operator,
and
you
can
understand
it
better
as
an
attacker,
you
can
understand
the.
If
you
understand
the
attack
surface,
you
can
also
understand
how
to
prevent
those
kinds
of
attacks
and
yeah.