►
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
Crafty Requests: Deep Dive Into Kubernetes CVE-2018-1002105 - Ian Coldwater, Heroku
You may have heard about CVE-2018-1002105, one of the most severe Kubernetes security vulnerabilities of all time. But how does this flaw work? How can it be exploited, and what does it all mean? This deep dive will walk the audience through the Kubernetes back end, going over relevant concepts like aggregated API servers, the kubelet API, and permissions for namespace-constrained users. We will explain the details of how this flaw works, how a cluster’s moving parts can fit together to create a vulnerable context, and the risks involved in leaving this CVE unpatched in the wild. A live demonstration will show the audience exactly how easy it is to exploit this vulnerability. After explaining the attack pathways, the audience will leave with practical advice about mitigation and how to protect their clusters.
https://sched.co/MPdc
A
Hi
everybody.
Can
you
hear
me?
Okay,
awesome,
I'm,
really
out
of
breath,
because
this
building
is
really
big
and
I
ran
all
the
way
here
before
I
start
and
while
I
catch
my
breath
a
little
bit.
I
wanted
to
take
a
second
to
say
thank
you
to
the
room
emcee
and
the
organizers
and
the
program
chairs
and
everybody
who's.
Doing
such
amazing
work
to
bring
us
this
amazing
conference.
So
thank
you
to
them.
Can
we
all
give
them
a
round
of
applause.
A
And
yeah,
and
thank
all
of
you
for
being
here
and
taking
time
out
of
your
day
before
lunch,
I
really
appreciate
it.
So
my
name
is
Anne
Coldwater
and
this
talk
is
called
crafty
requests,
a
deep
dive
into
kubernetes
CVE
1
2002
18,
one
zero,
zero,
two
one,
zero!
Five!
If
you
are
not
here
for
that
talk,
you
are
in
the
wrong
room
and
that's
okay.
We
could
hang
out
anyway,
so
hi.
A
It
was
q4
which,
if
anyone
here
has
ever
been
pen,
testing
consultant
or
maybe
any
kind
of
consultant
q4
is
like
hella
busy
crunch
time,
because
everybody's
trying
to
get
all
their
boxes
checked
by
the
time
of
the
year's
up.
So
it's
very
busy
and
my
phone
blew
up
like
a
lot
and
I
was
like
what
is
happening
and
eventually
I
figured
it
out.
What
happened
was
what
was
advertised
as
the
first
kubernetes
container
or
security
vulnerability.
A
That's
not
true,
had
just
blown
up
and
everybody
wanted
their
stuff
been
tested
or
everybody
wanted
to
talk
about
it
so
because
that
got
a
lot
of
attention
and
because
I
think
it's
really
interesting.
That's
what
I'm
here
to
walk
you
through
and
tell
you
all
about
so
big
news,
Germany's.
First
major
security
hole
discovered
as
I
said.
That's
a
lie,
but
it
is
actually
the
first
one
that
got
that
level
of
attention.
It
got
a
lot
of
press
a
lot
of
people
who
hadn't
previously,
perhaps
pay
attention,
do
kubernetes
at
all
or
kubernetes
security.
A
A
So
we're
going
to
look
at
it
holistically
and
we're
going
to
deep
dive
through
it
together.
I'm
gonna
try
to
slow
down
a
little
mix,
I'm
still
slightly
on
breath.
So
this
was
a
big
deal
as
I
said,
a
lot
of
press
a
lot
of
attention,
the
CBS
s
spores,
which
are
scores
that
one
could
argue
about
how
accurate
they
are,
but
they
attempt
to
gauge
the
severity
of
different
kinds
of
vulnerabilities.
Those
were
quite
high.
They
go
on
a
scale
of
10.
A
This
one
got
a
9.8
so
point
to
shy
of
perfect,
but
still
pretty
severe
and
it
affected
until
the
time
of
it
fix
all
kubernetes
versions,
full
stop
all
of
them.
So
it
affected
a
lot
of
clusters
and
a
lot
of
people.
So
let's
hear
more
about
this
and
figure
out
how
it
worked
when
you
take
a
sip
of
water
and
I'm
gonna
catch
my
breath
a
little
bit.
A
So
what
was
this
thing?
Cve
one,
zero,
zero,
two
or
2018
one
zero,
zero.
Two
one
zero
five,
which
is
very
human,
readable
and
even
more
human
saleable,
was
originally
discovered
by
Darren
Shepherd
and
file
directly
as
an
issue
with
Ranger,
not
through
any
kind
of
security
channel,
because
they
didn't
realize
that
it
was
a
security
vulnerability.
Originally,
it
was
filed
as
a
bug.
I
was
like
an
edge
case
in
a
proxy
component,
said
in
there
issues
for
awhile,
like
a
couple
months.
Eventually,
Rancher
figured
out
that
it
was
not
a
proxy
vulnerability.
A
It
were
a
proxy
issue.
It
was,
in
fact
an
up
scream,
kubernetes
vulnerability
and
it
was
in
fact,
a
security
issue,
and
so
they
privately
disclosed
it
through
the
kubernetes
security
reporting
process
to
security
at
and
then
the
security
working
group
did
the
triage
for
it
and
dealt
with
it.
They
ended
up
just
closing
it
on
December
30
2018,
which
is
my
mom's
birthday
and
I,
didn't
call
her
until
really
late
at
night.
A
Maybe
it
affected
some
of
yours,
maybe
it's
still
affecting
some
of
yours
today
and
I
hope
not
because
if
you
leave
with
one
thing,
if
you
haven't
updated,
we
knew
that
so
there's
one
bit
of
good
news
here,
because,
as
I
said,
it
was
pretty
severe
affected
a
lot
of
people.
You
can't
actually
have
a
privilege
escalation
vulnerability.
If
you
run
everything
is
privileged.
So
if
everybody
is
already
an
admin,
it's
fine,
nobody
can
make
themselves
I've
been.
This
is
a
terrible
idea.
A
A
There
was
a
lot
of
interest,
but
they
had
a
lot
of
confusion
about
what
exactly
this
meant,
because
security
people
haven't
understanding,
often
of
vulnerabilities
as
being
like
it
can
be
a
local
privilege,
escalation,
vulnerability
or
where
you
know
you
start
out
as
a
regular
user,
and
then
you
can
escalate
your
privileges
to
being
root
or
admin
or
system
or
whatever,
and
there
are
remote
code
execution
vulnerabilities
where
you
can
go
in
and
execute
arbitrary
code,
often
completely
unauthentic
ated.
This
one
was
both.
A
There
are
multiple
attack
paths
and
one
of
them
was
a
local
guerrilla
escalation
vulnerability
and
one
of
them
was
a
remote
code.
Execution,
vulnerability
and
people
were
really
confused
by
this.
How
could
it
be
both?
And
this
Twitter
exchange,
which
I
got
permission
to
use,
is
where
they're
trying
to
figure
out
what's
going
on?
A
Eventually,
they
figured
it
out,
which
is
that
if
you
know
how
kubernetes
works,
this
actually
does
make
sense,
because
of
the
way
that
the
API
server
interacts
with
our
back
and
allows
for
different
kinds
of
authorization
schemes,
depending
on
the
permissions
that
are
assigned
the
way.
This
flaw
ultimately
worked
was
that
when
an
attacker
sent
a
specially
crafted
request,
that
said
connection
upgrade,
which
attempted
to
escalate
a
regular
HTTP
connection
to
a
WebSocket
which
stayed
open
those
it
did.
A
Those
connections
did
not
validate
whether
or
not
that
returned
error
or
success,
and
so
it
was
just
like
all
right.
These
are
the
droids
you're
looking
for
opened
up,
stayed
open
and
allow
people
who
sent
them
request
to
communicate
directly
with
back-end
servers,
whether
that
be
the
couplet,
whether
that
be
extension,
API
servers,
it
allowed
them
to
bypass
the
authorization
that
the
API
server
performs
and
just
communicate
directly
with
it
and
do
whatever
they
wanted.
A
So,
let's,
in
order
to
figure
out
how
this
happened,
let's
take
a
look
at
the
moving
parts
involved.
It's
this
cube
con
I'm
guessing
a
lot
of
people
have
probably
seen
a
picture
like
this
before,
but
for
the
people
in
the
room
who
haven't
seen
a
picture
like
this
before
this
is
a
sort
of
general
diagram
of
kubernetes
architecture,
and
you
can
see
the
API
server
in
the
middle,
touching
pretty
much
everything.
A
The
API
server
was
the
affected
component
in
this
CV
as
a
penetration
tester.
The
API
server
is
the
best
thing
to
attack
because
it
touches
everything
it
touches
that
city.
It
touches
the
couplet,
it
touches
the
different
parts
of
the
worker
nodes
and
the
master
nodes,
and
so
you
are
able
to
get
access
to
more.
If
you
can
get
a
hold
of
that,
then
you
can,
if
you
can
get
a
hold
of
other
parts,
a
lot
of
the
time.
A
So
in
this
case
it
actually
didn't
allow
you
to
get
a
hold
of
it
so
much
as
it
allowed
you
to
bypass
entirely
and
therefore
be
able
to
ignore
all
of
the
authorization
and
mutual
TLS
connections
that
the
API
server
performed
and
ok.
So
what
is
the
API
said?
What
does
it
do?
It
is
the
REST
API
endpoint
through
which
pretty
much
all
kubernetes
operations
are
performed.
A
So
it's
a
gateway
between
the
user,
sending
those
requests
to
the
API
server
and
the
backend
servers
where
it
takes.
The
request
from
the
user
makes
sure
they're
authorized
to
give
2
semanas
requests
and
then,
if
they
are
considered
authorized,
it
goes
and
communicates
with
the
back-end
server.
Does
its
back-end
thing
and
then,
when
the
backend
server
responds
back,
it
makes
sure
that
that
TLS
connection
is
valid
and
it
communicates
back
to
the
user.
So
everything
goes
through
it.
It's
a
gateway
in
the
middle
kind
of
an
old-school
firewall
model
which
we'll
talk
about
later.
A
If
you
can
convince
the
API
server
that
you're
authorized,
you
might
be
able
to
communicate
with
it
if
you
can
bypass
the
API
server
entirely
so
that
you
don't
have
to
be
authorized,
you
can
just
communicate
directly
and
execute
on
to
those
pods
onto
those
notes
in
theory.
The
way
that
the
connection
flow
works
is
this:
the
user
sends
the
request
to
the
API
server,
the
API
server
authenticates
and
authorizes
make
sure
that's.
A
A
So
the
way
that
reverse
proxies
often
work
is
it's
not
actually
efficient
to
constantly
open
and
close
HTTP
connections.
It's
just
not
it's
not
a
good
use
of
bandwidth.
So
a
lot
of
the
time.
What
they'll
do
if
they
know
that
communication
is
going
to
be
ongoing,
is
they'll
upgrade
that
connection
to
a
WebSocket
which
is
kind
of
a
dumb
pipe.
A
It
opens
up
it
stays
open
and,
and
that
way
just
the
communication
is
allowed
to
continue
back
and
forth
without
having
to
open
and
close
anything
until
for
the
length
of
that
connection,
until
it's
done,
if,
in
theory
again,
the
way
that
it's
supposed
to
work
is
if
a
connection
upgrade
request
is
sent,
that
is
not
valid,
it
will
be
like
nah
this.
This
returns
an
error,
this
isn't
a
valid
request
and
it
will
not
open
and
turn
into
a
WebSocket
if
it
does
open
if
it
does
return
success.
A
If
it's
like
this
is
an
authorized
request,
this
is
actually
what
we're
trying
to
accomplish
here.
Then
it
will
open
and
it
will
stay
up.
In
theory,
that's
how
that
works,
and
in
theory
this
does
work.
It's
not
bad.
Behavior,
it's
common
behavior
for
things
like
load
balancing,
because
you
want
to
be
able
to
make
those
connections
efficiently.
A
It
only
becomes
a
problem
when
those
dumb
pipes
that
get
opened
meet
kind
of
smart
routers
like
the
kubernetes
api
server
that
are
responsible
for
things
like
authentication
and
authorization,
as
well
as
just
moving
things
from
place
to
place
because
dumb
pipes
are
dumb
and
if
you
are
trying
to
perform
kind
of
granular
authorization
or
things
like
that
over
one.
It
may
not
always
work
right,
such
as
in
the
CVE.
A
And
kubernetes
does
exactly
this,
so
it
allowed
people
to
escalate
their
privileges.
There
were
multiple
attack
vectors
for
it
and
it
allowed
people
to
bypass
authorization
of
the
API
server
to
just
communicate
directly
with
that
and
be
able
to
do
absolutely
whatever
they
wanted
again.
Dumb
pipes
are
dumb.
A
Pot,
exact
pot
attached
pod
port
forward
just
slow
way
down
I'm
talking
way
too
fast
on.
It
is
again
users
who
are
authorized
via
our
back
or
other
means
to
be
able
to
do
that.
So,
if
you
had
access
to
the
pub
that
you
were
on
that,
you
were
able
to
do,
you
could
escalate
to
broader
cluster
API
access
via
the
coolant
and
be
able
to
pivot
from
there
to
be
able
to
go
to
execute
things
on
different
nodes
or
different
plugs
that
you
weren't
necessarily
supposed
to
have
access
to
per
the
namespace
authorization.
A
This
one
affected
absolutely
aku
Bernays
deployments,
because
it's
just
October
Nadia's
works
before
the
fixed
versions,
the
other
one
and
the
nasty
r1,
which
was
the
one
that
was
more
rare
but
more
severe,
was
through
extension
and
aggregated
API
servers
which
it
required
being
authorized
for
API
discovery
and
by
defaults
back
then,
and
still
to
this
day,
I'll
talk
about
this
in
a
sec.
This
was
absolutely
anybody
authenticated
or
not,
and
so
you
could
actually
just
go
curl
in
or
you
know,
go
into
a
thing
that
you
had
no
authorization
for
whatsoever.
A
They
were
completely
unaffected
and
then
be
able
to
take
over
the
cluster
from
there.
This
could
escalate
to
anything
on
downstream
API
servers.
This
really
allowed
for
total
cluster
compromised
total
cluster
takeover,
but
it
did
only
affect
that
minority
of
deployments,
but
it
was
bad.
Nine
point
eight
out
of
ten
is
a
pretty
severe
vulnerability
because
it
was
on
authenticate.
It
was
easy
to
exploit
and
it
you
know
you
can
do
anything
with
it.
So,
let's
talk
about
how.
A
This
default
works.
So
can
everybody
read
that
kind
of
yeah?
So
this
is
a
get
cluster
role
system
discovery.
So
you
know
what
can
you
can
discover
certain
things
about
the
system,
and
this
is
designed
for
things
like
being
able
to
get
metrics
being
able
to
check
on
the
health
of
the
coolant
and
by
default
again.
This
is
absolutely
anybody
who
can
just
curl
in
and
do
this,
so
it
included,
for
example,
actually
have
a
laser
pointer
here.
A
A
No
big
deal
right,
like
that
seems
kind
of
specific
well
who
has
access
to
system
just
every
system
on
authenticated,
which
means
literally
anybody
who
is
sending
you
a
crawl
into
your
cluster,
has
access
to
system,
discovery
and
systems
every
has
access
to
anything
that
has
an
API
on
it,
which
because
communities
API
based-
and
that
is
how
you
control
the
thing,
allows
you
to
control
the
cluster
in
that
way.
This
is
still
the
default.
This
is
how
it
works
out
of
the
box.
A
So
it's
important
to
be
able
to
you
know,
put
your
PSPs
on
it.
Do
your
back
right
and
make
sure
that
you
can
prevent
people
from
being
able
to
execute
commands
by
just
doing
that.
The
thing
is
that,
when
you're
doing
that,
all
of
those
policies
are
getting
routed
through
the
API
server,
which
are,
which
is
the
component
that
is
making
sure
that
that
authorization
is
correct
and
when
you
bypass
it,
it's
a
good
point.
So
that's
how
the
CVE
happened.
A
It's
why
it
was
pretty
great
as
an
attacker,
but
why
it's
pretty
serious
as
a
defender?
What
could
go
wrong?
Maybe
you
could
leave
this
unpatched.
Maybe
it'd
be
fine,
well
things
that
could
go
wrong.
If
you
leave
this
unpatched
could
potentially
include
people
crypto
mining,
putting
compromised
containers
into
your
cluster
hijacking,
compute
resources,
stealing
secrets
stealing
for
sensitive
data.
Customer
data
cloud
metadata
it
could
people
could
inject
malicious
code.
A
They
could
push
things
up
to
your
registry
and
create
supply
chain
attacks
that
could
be
stayed
further
down
the
line
and
they
could
take
over
the
cluster
and
do
actually
just
absolutely
whatever
they
wanted
and
as
an
attacker
was
an
evil
imagination.
Let
me
tell
you
we
can
come
up
with
a
lot,
so
anything
in
attacker
can
dream
up.
They
could
do
in
here
with
us
unpatched,
that's
not
ideal,
especially
with
the
unauthenticated
version.
With
the
authenticated
version.
A
They
have
to
be
authorized
to
communicate
with
the
pod,
but
from
there
they
could
escalate
their
religious,
and
all
of
this
can
happen
in
order
to
demonstrate
this
I'm
going
to
play
you
an
exploit
demo,
which
is
I,
will
narrate
it,
for
you.
I
think
that
I
actually
have
to
break
the
fourth
law
for
half
a
second
and
go
into
this
terminal
in
order
to
make
that
work.
So.
A
I'm
gonna
play
this
for
you.
This
is
somebody
from
twist
slack
demo,
because
my
demo
is
totally
broken.
So
thank
you,
tryst
luck.
What
this
person
is
doing
is
they're,
creating
a
default
nginx
pod
in
a
cluster
and
they're
getting
the
namespaces
for
all
of
the
pods.
So
oh,
no,
okay!
Well,
let's
see
anybody
who
has
AV
stuff
know
how
to
make
it
work
anyway.
A
Wait
I
do
what
now.
Okay
well
I
have
a
double
broken
demo,
but
let
me
tell
you
what's
going
on
here,
which
is
that
I'm
gonna
hit
play,
and
so
basically
what
happens
when
this
works
is
the
person
creates
a
default
engine,
X
pod
and
just
it's
just
totally
generic
Hamel.
It's
like
you,
know,
name
engine
X,
you
know
just
it
creates
it
coupe,
CTF
great
and
from
there
it
gets
the
list
of
namespaces
in
the
pods
that
it
has
available,
which
is
not
everything
it
downloads
this
exploit.
A
It
literally
is
just
exploit
POC
RB
at
that
point.
What
the
thing
does
is
it
sends
that
up
accrued
request
and
the
WebSocket
is
opened,
and
then
it
gets
a
long
list
of
JSON
metadata.
That
is
from
all
of
the
namespaces,
with
all
of
the
secrets
and
all
of
the
other
metadata
in
the
entirety
of
the
cluster.
Still
don't
know
why
that
didn't
work.
But
that
is
what
happened.
It
is
a
short
demo
and
basically,
what
that
is
is
literally
just
okay.
A
A
There
are
a
lot
of
published
exploits
for
this.
I
ran
out
of
space
on
this
slide
and
there
are
one
two,
three,
four
five,
six
seven
and
I
had
to
leave
off
like
six
more.
There
are
many
ways
to
pop
a
box
and
I
think
it's
really
interesting,
because
at
first
when
the
exploit
started
coming
out
as
I
said,
security
people
tend
to
be
a
little
bit
farther
behind.
Then
then,
cloud
native
folks
do
so
because
everybody
moves
here
at
the
speed
of
light.
A
So
at
first
they
were
written
and
go
and
they
were
written
by
people
like
chris
nova,
who
you
know
had
who
knew,
go
and
had
devops
experience
and,
as
there
started
to
be
more
attention
on
this,
and
as
people
were
starting
to
understand
how
it
works
better,
they
started
to
be
written
in
python
and
ruby
and
different
kinds
of
languages,
and
they
all
deal
with
it
differently,
which
is
super
interesting
to
me.
Just
as
like
a
nerd
and
somebody
who
loves
what's
like
one
of
them
did
DNS
tunneling,
one
of
them
did
it
through
SSH.
A
A
So
how
did
this
get
fixed?
It
was
actually
a
really
short
was
a
37
line,
commit
change
and
all
it
did
was
just
validate
for
whether
or
not
that
code
returned
valid.
So
if
a
connection
request
was
sent
that
said
connection
upgrade,
then
it
would
check
to
see
whether
it
was
real
and
if
it
wasn't
authorized,
then
it
wouldn't
open
the
connection
and
upgrade
it.
It
would
just
stop
and
if
it
was
real,
which
it
made
sure
it
was,
then
it
would
open
it
up,
and
business
and
communication
would
continue
as
usual
and.
A
So
if
you
are
on
a
cloud
provider,
if
your
clusters
are
managed,
this
got
patched
in
December
if
you're
rolling
your
own
I
hope
that
you've
updated
by
now.
If
you
haven't,
please
do
that
when
you
have
the
chance.
So
what
are
the
mitigations
for
this?
Updating
really
is
the
only
practical
mitigation
because
of
the
way
that
the
you
know,
one
kind
of
workaround
people
were
saying.
A
It
wasn't
unauthorized
use
because
of
the
way
that
our
back
treats
that
so
do
that
and
the
other
workarounds
that
they
had
were
really
impractical
and
would
just
rake
your
cluster,
so
I
they're
not
recommended
I'm,
not
even
gonna,
go
into
them
because
they
don't
really
make
any
sense.
It
was
like
okay
make
it
so
that
nothing
can
communicate.
A
Probably
if
you're
running
a
cluster,
you
probably
want
things
to
be
able
to
communicate,
and
so
I,
don't
necessarily
suggest
that
really
the
way
to
do
this
is
to
update
if
you're
managed,
quad
writer
did
it
for
you.
If
you
aren't
managed,
you
can
do
it
yourself
and
I
hope
you
have
by
now.
So
how
do
we
now
that
we
understand
how
this
works,
which
again
it's
pretty
simple?
A
If
you
understand
the
way
that
these
connections
work
and
the
way
that
flaw
happened
and
the
way
that
it
got
fixed,
how
can
we
mitigate
fails
like
this
plus
like
this
in
the
future,
because
the
thing
is
that
we're
going
to
connection
reduce
is
not
necessarily
an
uncommon
problem.
This
isn't
unique
to
kubernetes,
and
you
know
we'll
probably
see
things
like
this
again.
How
can
we?
How
can
we
make
our
architecture
better
so
that
the
next
time
we
see
something
like
this?
It
isn't
as
catastrophic.
A
We
need
to
practice
defense
in
depth,
so
anybody
here
like
played
a
tower
defense
game
or
plants
versus
zombies,
or
anything
like
that.
A
couple
of
you.
Nobody
plays
video
games
in
this
room,
so
you
know
how,
if
you're
playing
a
tower
defense
game,
you
don't
want
one
line
of
defense
right.
You
want
your
walls
and
then
you
want
stuff
behind
the
walls,
and
then
you
want
stuff
behind
it.
A
Defense
and
depth
is
like
that,
where
you
want
to
make
sure
that
it's
not
you're
you're,
not
depending
on
your
firewall
in
the
middle
you're,
not
hoping
that
as
long
as
nobody
breaches
the
perimeter,
it's
fine
and
everything
in
there
is
all
soft
and
juicy
and
unprotected.
You
want
to
make
sure
that
that
you
are
hardening
the
different
parts
of
your
attack
surface
such
that
you're,
making
your
attack
surface
more
difficult
to
get
into,
and
if
somebody
like
me
manages
to
get
into
it,
you're,
making
your
blast
radius
as
small
as
possible.
A
A
It
sits
in
the
middle,
it
tells,
you
know,
tells
the
computer
or
whoever,
what
what
kind
are
allowed,
what
connections
are
denied
and
if
that
can
be
penetrated
or
bypassed
it's
gone,
and
you
can
just
be
able
to
take
over
that
cluster
if,
for
example,
on
the
other
end
of
it,
if
the
user
could
communicate
directly
with
the
back-end
server
and
the
backend
server
was
like
I'm
also
authenticating
you.
This
is
not
a
valid
request.
What
are
you
doing
and
prevented
the
user
from
being
able
to
successfully
make
those
kinds
of
requests?
A
Then
this
CDA
wouldn't
have
been
severe,
and
if
we
start
thinking
about
operating
on
a
you
know,
don't
trust
and
verify
kind
of
model
where
you
know
every
time
a
request
is
made
it's
getting
authenticated
in
different
ways.
In
some
ways
it's
less
efficient,
but
it
can
be
more
secure.
So
obviously
that
can
be
a
balance
in
terms
of
the
way
that
you
are
constructing
your
things
and
you
know
trade-offs
of
speed
and
convenience
versus
being
able
to
harden
it
as
much
as
possible.
A
But
if
we
start
moving
more
towards
zero
trust
architecture,
this
can
allow
us
to
be
able
to
if
we
see
flaws
like
this
in
the
future.
We're
not
it's
not
going
to
be
as
much
of
an
issue
and
it
can
allow
us
to
practice
more
defense-in-depth
and
make
our
architecture
harder,
and
that's
the
thing
that
you
can
do
as
a
cluster
operator
is
watch
your
dependencies,
because
one
of
the
things
that
you
know
how
did
people
get
these
extension
API
servers.
A
Some
of
them
probably
set
their
clusters
up
that
way
on
purpose,
some
of
them
set
their
clusters
up
that
way,
not
necessarily
on
purpose,
because
it
was
the
default
that
came
out
of
the
box
when
they
put
their
plugins
in
or
when
they
did
their
setup.
You
want
to
make
sure
that
you
know
what
is
in
your
clusters
and
what
it's
doing,
and
if
you
don't
need
it,
maybe
consider
whether
or
not
it
needs
to
be
there.
A
Basically
you're
keeping
things
to
need-to-know
communication
and
whether
or
not
it
needs
to
be
in
their
supply
chain
attacks
are
real.
We've
seen
things
like
that
recently
with
the
docker
hub
breach
that
could
you
know
if
that
got
bad
if
everybody
is
pulling
down
alpine
from
like
the
stock
images
and
alkyne
is
compromised
that
can
have
cascading
failures
down
the
line,
so
it's
really
important
that
we
watch
our
supply
chain
and
they
were
watching
the
dependencies
that
using
and
making
sure,
they're
good
and
again
keep
uptodate
kubernetes
moves
really
fast.
A
And
what
else
can
we
learn
from
this?
The
kubernetes
security
working
group
did
a
post-mortem
on
this
about
what
went
well,
what
went
wrong?
What
could
be
learned
from
it?
There's
a
lot
of
really
interesting
information
there
they
talked
about.
You
know
the
CVE
itself,
the
vulnerability,
how
it
worked
and
how
it
affected
the
project,
but
they
also
talk
about
their
Incident
Response
process
and
the
things
that
went
well,
which
you
know
they
were
like.
We
really
feel
like
we
triage
this.
A
Well,
we
dealt
this
with
as
well
as
a
group,
but
also
the
things
that
went
not
as
well
like.
Maybe
the
original
outbound
communication
was
kind
of
confusing
to
people
and
that
confusion
led
to
you
know
things
being
patched
slower
or
people
not
understanding
what
to
do,
and
so
that's
a
really
interesting
thing
to
read
and
I.
Think
one
thing
that
we
can
learn
from
this
is
that
cloud
native
people
and
security
people
generally
need
to
communicate
better
and
explain
things
better
to
one
another,
because
a
lot
of
the
time
that
doesn't
happen.
A
Cloud
native
people
do
move
really
quickly
and
are
you
know
moving
so
fast
that
they
can't
write
documentation
to
keep
up
with
it
and
I
get
it,
but
I
think
that
the
general
public
sometimes
has
a
hard
time
keeping
up
with
that
rate
of
change
and
I
think
people
want
to
understand
and
security
people
want
to
do
well,
like
nobody's
trying
to
slow
your
down
and
make
your
day
sad.
Everybody
is
trying
to,
like
you,
know,
figure
out,
what's
going
on
and
do
well
with
it.
A
We
can
do
in
the
future,
so
yeah,
greater
communication,
radiator
understanding-
and
we
can
all
do
that-
there's
a
double
rainbow,
I
believe
in
everyone.
In
this
room
we
can
secure
our
architecture,
we
can
communicate
better.
All
of
us
can
do
it.
This
is
a
resource
slide.
It's
got
a
lot
of
stuff
on
it,
both
how
you
know
the
CVE
itself,
the
details
around
it.
Also
a
couple
of
blog
posts
with
exploits
attached
and
people.
A
You
know
kind
of
dissecting
it
figuring
out
how
it
works
and
explaining
it,
people
also
Darren
Shepherd,
who
discovered
it
tells
his
story
and
the
one
on
the
bottom,
which
is
pretty
cool,
because
you
can
kind
of
hear
about
the
history
of
that
and
how
it
worked.
And,
if
you're
nerdy
about
that,
like
me,
that
could
be
fun.
So
that
is
my
talk
and
I
probably
went
through
it
really
fast.