►
From YouTube: Piloting Around the Rocks: Avoiding Threats in Kubernetes - Robert Tonic & Stefan Edwards
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
Piloting Around the Rocks: Avoiding Threats in Kubernetes - Robert Tonic & Stefan Edwards, Trail of Bits
Over three months in 2019, Trail of Bits completed the first-ever security review of Kubernetes, consisting of source review, dynamic testing, and threat modeling. One artifact, the threat model, lets users understand the risks of any given feature or deployment. We’ll show attendees how to make the most of this invaluable resource. First, we’ll break down the architecture of Kubernetes into trust zones. These are security boundaries where controls should be enforced. Incorrectly implemented controls can result in catastrophic security failures. After we describe the trust zones, you’ll find the architectural issues are easy to identify. We’ll discuss a few! We’ll also situate vulnerabilities we found in our code review into each trust zone. Finally, we’ll teach you how to review your own Kubernetes environment using our threat model to get simple answers to your security questions.
https://sched.co/Uabz
A
My
name
is
Robert
tonic
I'm,
a
security
engineer
at
trail
of
bits
and
with
me
I
have
Stefan
Edwards.
He
is
technically
my
boss
and
he
is
also
the
assurance
practice
lead.
So
if
you're
interested
in
the
Sussman's
talk
to
him,
someone
who
unfortunately
couldn't
make
it
today
is
Dominick.
He
is
also
security
engineer
at
celibates.
He
worked
closely
with
me
and
was
my
counterpart
on
this
assessment.
He's,
unfortunately,
not
here
because
of
another
conference,
but
figured
we'd
include
him
anyways,
so
we're
gonna
go
through
a
quick
disclaimer.
A
So,
even
though
we
performed
this
assessment,
we
don't
use
kubernetes
every
day.
So
we
have
the
majority
of
our
knowledge
related
to
core
kubernetes.
So
not
including
CN,
is
or
c
our
eyes
those
types
of
things,
and
there
might
be
third
party
who
mitigations
for
a
lot
of
things
that
we
talked
about,
but
we're
trying
to
scope
things
specifically
to
kubernetes.
C
A
C
It
better
with
this
yeah,
so
I
think
one
of
the
more
interesting
things
is
is
what
we
were
actually
attempting
to
do
with
the
report
itself.
Right
I
think
quite
a
few
people
had
a
different
view
of
what
we
would
be
doing.
What
we'd
be
looking
for.
Our
mandate
from
the
CN
CF
was
actually
to
find
low-hanging,
fruit
and
new
bugs.
So
we
couldn't
just
scour
github
issues
and
report
them.
C
C
We
were
supposed
to
find
new
code
and
design
level
issues
that
we
saw
either
through
discussions
with
developers
or
with
actually
just
Bobbie
myself
and
Dominic
reading
through
the
kubernetes
code
itself,
and
then
we
were
meant
to
evaluate
the
assumptions
and
the
design
decisions
that
kubernetes
has
put
in
place.
Many
of
these
design
decisions
that
kubernetes
has
made
are
not
necessarily
the
ones
that
you
would
make
when
you
were
rolling
this
out
in
your
environment
or
if
you
were
developing
these
things
yourself.
So
we
really
wanted
to
go
through
and
document
the
design
decisions.
C
Whilst
writing
it
in
order
to
understand
your
own
threats
and
your
own
risks
and
which
controls
you
want
to
put
in
place
and
policies
and
those
sorts
of
things,
and
then,
lastly,
we
read
a
lot
of
documentation
and
a
lot
of
configuration
options
and
bobby
took
lead
on
this.
We
actually
put
together
and
we'll
discuss
what
it
is:
a
white
paper
on
ease
of
use
with
kubernetes
itself.
You
can
hit
the
next
one
next
one
it
is
it
not.
C
This
is
how
hard
it
is
to
mess
up.
We
can't
get
chrome
to
work
there
we
go.
So
what
do
we
actually
do?
I
mean
quite
a
few
people
here
have
actually
read
it,
but
we
had
37
what
I
call
technical
findings
or
source
level
findings.
These
are
things
that
range
from
integer
parsing,
bugs
that
allow
us
to
bypass
policies
to
issues
in
core
DNS
and
other
things
that
that
came
out.
These
are
the
assessment
team
sitting
down
reading
code,
running
kubernetes
and
looking
for
edge
cases
that
we
thought
were
problematic.
A
C
Then
we
also
had
17
of
the
paper
exercise
threat,
modeling
of
sorts
of
findings
and
interestingly
I,
as
I
mentioned
for
those
of
you
who
came
in
towards
the
beginning
of
the
talk
before
I
started.
I
mentioned
that
I
actually
have
released
all
of
my
notes.
So
all
of
my
discussion
with
the
Etsy
folks,
all
of
my
discussions
with
the
various
teams
that
make
up
the
special
interest
groups
that
make
up
kubernetes
those
notes-
are
all
open-source.
C
So,
if
you're
interested
in
in
the
discussions
and
the
the
commentary
that
came
during
the
threat
model,
you
can
actually
just
see
the
raw
developers
notes
there
in
github
itself,
and
these
were
obviously
mostly
designed
related
problems.
I,
don't
think
they're
surprising
to
most
people
who
have
run
kubernetes
before
or
who
have
looked
at
the
edge
cases,
but
there's
a
number
of
interesting
discussions
that
came
out
and
I
think
Aaron
small
who
may
be
floating
around.
He
gave
a
talk
earlier
and
I.
Think
that
was
the
interesting
part
and
Aaron
always
said
this.
C
The
the
really
interesting
things
are,
the
templates
are
the
developers.
Notes
are
those
sorts
of
things
for
the
threat
model,
at
least,
and
then,
as
I
mentioned,
we
also
released
a
white
paper
on
the
ergonomics
of
kubernetes.
So
basically,
where
do
we
see
things
that
are
hard
to
use
that
are
surprising
to
us
and
how
to
avoid
those
sorts
of
things
and
Bobby
took
points
on
that
one?
C
You
can
go
by
me
so
I'm
sure,
because
there's
such
a
large
threat,
modeling
crowd
here,
we've
all
heard
of
trust
owns
rightmost
most
folks
are
familiar
with
these
sorts
of
things.
Yes,
so
we're
we're
going
to
go
through
basically,
I'll
talk
about
what
trust
zones
are
for
those
folks
who
haven't
worked
with
trust
owns
and
then
we'll
talk
about
the
ones
that
we
actually
put
in
place
for
for
kubernetes
itself.
C
You
know
so,
if
you're
not
familiar
a
trust
zone
is
basically
a
logical
grouping
of
components
and
then
controls
that
sit
at
the
boundary,
though
they
may
sit
in
other
locations,
but
mostly
we're
concerned
about
those
sorts
of
boundary
edges,
and
we
want
to
group
these
components.
We
want
to
group
things
together
so
that
we
can
do
other
activities
against
them.
C
We
can
do
control
analyses,
as
you
might
see,
in
the
kubernetes
threat
model
we
can
do,
we
can
actually
understand
which
actors
which
location
which
policies
need
to
be
applied,
and
if
you
threat
model,
you
are
familiar
with
all
of
these
activities.
You
may
call
it
something
different
I've
heard
these
called
logical
boundaries.
C
I've
heard
these
called
many
others
different
things,
but
basically
we're
looking
for
logical
groupings
of
components,
of
controls,
of
data
of
actors
that
we
can
put
together
and
then
group
them
and
discuss
them,
and
this
is
something
similar
to
if
you've
read
the
threat
model
you'll
see
at
CD
is
in
a
master,
controlled
data
zone.
If
I
recall
correctly,
it
was
the
term
we
gave
it
and
we
wanted
to
be
able
to
discuss
where
at
CD
should
live.
Who
should
be
able
to
talk
to
it?
What
sorts
of
off
N
and
Ozzie
controls?
C
We
should
have
those
sorts
of
things
and
really
analyze
where
@cb
should
be,
who
should
have
access
to
it
and
what
sorts
of
controls
at
a
design
level
that
we
can
have?
And
then
obviously
these
can
be
nested
right.
There
are
certain
components
within
kubernetes
that
may
live
on
the
same
host
as
cube
api
server,
but
are
not
logically
of
the
same
permission
as
cube
api
server
itself.
So
think
of
CCM
and
KCM
of
controllers
of
admission
controllers
web
hooks
those
sorts
of
things
they
have
different
permissions.
C
They
have
different
access
to
data
and,
logically,
we
want
to
analyze
and
Gus
those
controls
there
for
those
different
components.
So
we
group
them
into
trust
zones,
hit
the
next
one,
so
there's
many
small
components
as
I
mentioned
and
so
trying
to
analyze
each
one
of
these
would
be
hugely
problematic.
Can
anyone
think
of
how
many
components
are
actually
in
kubernetes
like
off
the
top
of
your
head?
We
only
had
a
handful.
We
did
not.
If
you
read
the
report
you've
seen,
we
did
not
actually
have
all
kubernetes
components.
C
There
was
a
focus
set
of
things
that
we
were
interested
in
and
even
with
that,
we
ended
up
with
hundreds
of
pages
of
issues
of
documentation,
changes
of
code,
things
that
we
were
interested
in
discussing
with
the
team.
So
a
small
number
of
components
can
lead
to
a
large
number
of.
You
know,
findings
of
analysis
of
all
those
sorts
of
things,
so
we
wanted
to
group
them
logically,
and
in
order
to
do
that,
we
actually
started
with
a
data
flow
diagram.
C
There
were
several
NASA
sent
data
flow
diagrams
previously,
and
so
what
we
actually
started
with
was,
if
you
look
at
the
the
repo
I
started
with
a
graphviz
I
sat
down,
I
looked
at
kubernetes
I
ran
it
with
Bobbie.
We
figured
out
how
to
how
things
connected
and
we
started
to
work
on
this
data
flow
throughout
from
me
running,
cube,
cuttle,
all
the
way
through
to
etsy
D,
to
see
what
talked
to
who
and
how
and
when
we
broke
these
components
down.
C
We
talked
about
the
actors
and
all
those
sorts
of
things
that
you
would
normally
do
in
threat
modeling
itself.
So
this
is
the.
This
is
the
version
that
ended
up
in
the
actual
report.
It
elides
certain
information
because
obviously
kubernetes
has
a
large
number
of
components,
a
large
number
of
protocols,
but
we
wanted
to
capture
the
main
portions
of
actors
that
we
would
see
here.
C
As
you
see,
in
the
we
have
an
external
actor,
we
may
have
an
administrator
in
the
middle
there,
some
user,
who
has
to
deploy
something
and
then
an
internal
attacker
who
had
transited
from
an
internet
zone
internally,
and
then
we
broke
down
the
components
into
various
trust
zones
and
annotated
their
connections
back
and
forth
to
things.
So
we
were
very
curious
as
we
were
going
through.
C
What's
talking
HTTP,
what's
using
TLS,
what's
using
gr
PC
with
insecure
connection
or
not,
and
breaking
down
this
data
flow
and
discussing
what
was
using
IP,
see
all
those
sorts
of
things,
helped
us
understand,
design
decisions
and
understand
controls
that
we
expected
to
be
in
place
there.
Does
that
make
sense
to
everyone
perfect
you
can
edit.
C
So
as
most
people
who
have
done
threat,
modeling
are
aware.
The
whole
reason
why
we
care
about
trust
zones
is
to
then
understand
what
happens
if
they
break
what
happens
if
I
as
a
external
attacker,
have
transited
an
Internet
zone
and
now
I'm
an
internal
attacker
with
pod
access
or
something
of
that
nature.
What
can
I
do?
What's
the
actual
criticality
of
this
zone,
what
sorts
of
data
does
it
process?
C
What
can
I
do
with
these
sorts
of
things,
we're
really
interested
in
what
happens
when
these
things
fail,
and
so
in
processing
these
sorts
of
trust
zones
and
breaking
things
down
and
talking
about
connections?
We
really
started
to
dive
into
the
internals
of
kubernetes
itself,
so
one
of
the
things
that
we
found,
if
you
read
the
technical
assessment,
is
that
there
there
are
credentials
stored
by
default
within
pods,
and
so
when
we
were
going
through
the
threat
model
and
discussing
these
sorts
of
things,
we
really
did
have
an
actual
scenario
there.
C
It
wasn't
like
well
what
happens
if
you
get
it,
it
wasn't
a
tabletop
exercise.
We
literally
were
looking
at
credentials.
So
now,
what
can
I
do
with
that?
How
can
I
parlay
that
access,
that
sort
of
criticality
became
very
real,
and
so,
if
you've
done
threat,
modeling
it's
kind
of
the
ideal
scenario
you
don't
have
to
come
up
with
it.
What
if
it's
literally
we're
looking
at
this
credential
here,
I
am
now
an
internal
attacker.
What
can
I
do
and
that
sort
of
criticality
is
extremely
important
for
kubernetes.
C
A
So
once
we
actually
built
out
some
of
the
trust
zones
and
we
analyzed
some
of
the
like
dead
flow,
we
were
actually
able
to-
then
you
know
meet
with
the
different
special
interest
groups
and
discuss
our
assumptions
versus
theirs,
and
we
were
also
able
to
begin
analyzing
the
source
code.
Now
this
was
all
done
mostly
asynchronous,
so
a
lot
of
things
are
happening
at
the
same
time,
but
it
was
a
very
bi-directional
communication
flow,
so
I.
A
C
A
Cool
so
policies
when
we
were
going
through
the
threat
modeling,
we
asked
ourselves
how
do
policies
actually
apply
right
because
there
are
different
levels
that
could
affect
policy
cluster
configuration
as
well
as
like
at
runtime,
when
you're
using
cube
Caudill
to
try
to
apply
these
policies
that
should
propagate
what
we
found
was
in
certain
situations.
These
policies
can
be
ignored
on
the
pod
security
policy
side.
If
you
don't
have
the
admission
controller
enabled,
then,
even
if
you
make
that
particular
configuration,
it
might
not
stick
well,
it
actually
won't
stick.
A
C
It
wasn't
a
discussion
finding.
This
was
me
trying
to
figure
out
how
kubernetes
works,
so
I
could
actually
understand
things
and
reading
the
documentation
and
there's
a
little
note,
a
little
footnote
in
the
network
policy.
Documentation
that
says,
depending
on
which
CNI
you
choose
you
may
not
actually
have
a
network
policy
applied.
I
was
like
well
that's
curious,
and
so
we
led
to
other
areas
that
we
found
other
policies
that
just
fail
silently
so
kubernetes
will
parse
them.
C
A
And
then,
once
we
started
to
look
further
into
the
actual
pod
security
policy,
we
actually
found
that
there
is
a
documentation,
discrepancies,
so
allowed
paths
effectively
are
supposed
to
prevent
pods
from
mounting
specific
paths
on
a
given
host.
However,
there
are
ways
to
bypass
this
through
PVC
mounting.
So
if
you
have
a
persistent
volume
that
is
of
type
host
path,
you'll
effectively
get
the
same
functionality,
it's
just
a
different
method
of
like
mapping,
so
it's
effectively
the
same
thing,
but
that's
not
actually
covered
by
the
allowed
paths
on
the
pod
security
policy.
A
So
the
documentation
wasn't
exactly
consistent.
Now,
when
we
actually
look
about
I'd
like
TLS,
most
components
except
inbound
HTTP
and
don't
strictly
enforce
HTTPS
now,
even
the
ones
that
do
the
TLS
connection
isn't
secure,
so
they
won't
necessarily
verify
hosts
and
things
along
those
lines
and
then,
when
we
actually
look
at
deploying
with
certificates
in
similar
kubernetes,
doesn't
natively
support
certificate
revocation.
So
if
a
certificate
is
compromised
and
you
have
to
rotate
it,
it
might
not
be
as
trivial
as
one
might
think.
A
Configuration
might
not
be
as
trivial
as
you
would
think,
and
what
we
found
was
some
of
the
documentation
was
also
slightly
misleading
as
far
as
like
which
ones
to
use.
When
we
actually
look
at
other
areas,
where
secrets
might
be.
We
took
a
look
at
the
logs
and
we
found
when
we
enable
debugging
higher
levels.
Error
tokens
were
just
dumped
and
that
was
actually
a
problem
with
a
third-party
dependency.
C
Of
curiosity
of
people
in
the
room,
if
you
found
a
developer,
was
passing
around
secrets,
passwords
key
keys.
Any
of
that
sort
of
thing.
How
many
of
you
would
enter
a
finding
against
that
application
for
doing
that?
So,
if
you
actually
look
at
how
kubernetes
does
this
there's
multiple
different
mechanisms
by
which
it
passes
environment
variables?
C
In
fact,
it
was
very
interesting
to
look
through
the
code
for
those
sorts
of
things,
but
there's
a
number
of
locations
that
just
assume
that
the
box
is
locked
down
there
for
environment
variables
are
okay,
and
this
may
not
be
the
same
design
decision
that
you
would
make
in
your
environment,
since
a
vast
majority
of
the
room
said
that
they
would
enter
a
finding
against
a
developer.
For
that.
A
So
the
key
takeaways
for
this
was
that
kubernetes
is
large
and
complex,
both
in
design
and
implementation.
There's
a
lot
of
code
and
there's
a
lot
of
components,
and
when
we
actually
look
at
the
security
controls
that
are
available,
most
of
them
are
pretty
minimal.
In,
like
the
default
deployment
of
kubernetes,
you
can
have
a
lot
of
things
with
third-party
additions,
but
by
itself
it's
pretty
bare
and
that
cascades
to
the
effectiveness
of
a
lot
of
the
controls
that
you
may
implement
right.
A
A
Then,
once
you
have
that
you
want
to
actually
define
some
of
those
trust
zones,
identify
the
controls,
the
policies,
all
the
placement
information,
they
have
related
to
those
components
so
that
you
can
then
start
to
identify
interaction
requirements.
So
just
one
component
need
to
talk
to
another.
What
are
the
failure
modes
of
that
particular
component
right
and
then
once
we
have
that
we're
able
to
go
through
and
determine
criticality
what
would
happen
if
a
zone
interaction
were
to
stop
right?
What
other
components
fail?
A
Would
it
potentially
cause
workloads
to
fail,
and
then
we
can
actually
look
at
some
of
the
security
implications
of
this
right?
So
the
first
one
has
like
denial
of
service
stuff,
but
specifically,
if
we
have
a
component
that
store
sensitive
information,
that
might
be
a
way
for
an
attacker
to
get
some
more
leverage
on
the
cluster
or,
if
that
particular
component
has
access
to
other
things
that
the
attacker
previously
didn't
have.
That
might
be
a
way
to
put
it
through.
So
all
of
these
things
matter,
especially
with
the
placement
right.
A
So
if
we
take
into
account
this
first
two
things
resource
exhaustion,
right,
one
component
might
use
more
resources
than
another
and
if
one
could
influence
the
other
the
resources
option,
that
could
be
a
problem
and
are
there
certain
locations
that
components
just
shouldn't
run
on
right?
Should
the
at
CD
server
run
on
the
same
hosts
as
most
of
your
workloads?
That
may
be
concerning.
A
A
And
that
when
you
actually
go
through
to
confirm
these
assumptions,
so
you
can
go
through
review
your
notes
review
the
documentation
review
all
the
assumptions
that
each
team
made.
You
can
actually
then
look
at
the
source
code
right.
This
is
a
very
approach
because,
instead
of
just
looking
at
random
places,
you
can
look
at
the
most
critical
components
where
a
lot
of
the
teams
think
that
there
could
potentially
be
problems
that
might
not
even
be
documented,
and
this
could
be
failure
modes.
This
could
be
component
dependencies
so
on
and
so
forth.
A
And
then,
finally,
the
most
important
part
is
remediation.
This
is
the
part
that
is
really
tough
but
trying
to
make
short
and
long
term
goals
for
remediation
is
important
right,
because
you
want
to
fix
the
problem
instantly,
especially
for
the
high
criticality
ones
and
then
long
term.
You
also
want
to
have
rock-solid
goals
to
preventing
it
from
ever
happening
again
and
then
ensuring
documentation
reflects.
A
So,
in
summary,
our
modeling
doesn't
necessarily
have
to
be
complex
to
yield
results.
A
lot
of
these
meetings
were
relatively
quick
because
it's
surprisingly
difficult
to
get
open-source
developers
to
come
together
and
chat
about
the
stuff
that
they
like
doing
source
reviews
can
also
be
more
targeted
when
you
pair
it
with
threat
modeling
right
we're
not
running
around
trying
to
look
through
a
million
lines
of
code,
just
randomly
looking
for
problems
and
then
finally,
it
also
helps
you
improve,
not
just
your
security,
but
also
your
documentation.
A
I
mean
these
are
actual
findings,
but
you
can
just
use
them
as
a
template
and
with
that
we
have
some
resources.
So
I
want
to
give
a
huge
shout
out
to
Aaron
small
JBL,
Craig
Ingram
and
Joelle
Joel
I
forget
his
last
name,
every
time,
I'm
so
sorry
Joel
so
yeah.
They
basically
were
our
clients
for
this
assessment
and
they
were
absolutely
awesome.
I
would
definitely
suggest
going
and
looking
at
the
talk
that
Aaron,
small
and
JBL
gave
it
goes
over
a
lot
of
the
things
that
we
did
not
discuss.
A
Now
you
won't
be
able
to
see
it.
This
cube
con
because
it
gave
it
yesterday.
So
if
you
weren't
at
that
talk,
you
can't
go
back
in
time.
The
repository
with
all
of
our
notes
is
the
audit
kubernetes
under
the
trail
of
bits
or
repository
sets
that
has
all
of
our
notes:
the
raw
rapid
risk
assessments
and
a
bunch
of
other
fun
stuff.
So
if
you
actually
look
at
the
github
issues
that
are
closed,
you'll
see
all
of
our
discussions
about
a
lot
of
the
findings.
A
Jill
Smith
there.
We
go
the
final
report,
so
you
can
actually
find
on
the
kubernetes
community
repository
and
then
the
last
two
links
that
we
have
here
one
is
attacking
go.
We
recently
released
some
of
the
basic
tools
that
you
can
use
to
attack,
go
systems
and
then
understanding,
docker
container
escapes
that
was
written
by
Dominic,
and
that
was
an
awesome
analysis
of
one
of
the
random
Twitter
like
one-liners.
A
That
allowed
you
to
jump
out
of
a
privileged
container,
so
some
interesting
things
to
think
about
as
you're
going
through
and
thinking
of
potential
vulnerabilities
and
then.
Finally,
if
you
want
to
talk
to
us
on
Twitter
or
just
you
know,
say
hello,
you
can
find
our
handles
there.
So
awesome
so
I
think
we'll
open
it
up
to
questions
cool.
A
So
the
reckon
she
asked
what
is
the
recommended
approach
for
secrets-
and
this
highly
depends
on
the
environment-
that
you're
running
in
right,
I
think
as
far
as
like
compliance
standards
go
there's
a
lot
of
implications
there
in
general,
I
think
the
documentation
is
now
updated
to
reflect
best
practices.
So
if
you
were
to
go
to
the
official
keeper
nineties
documentation,
it
will
actually
give
you
like
a
list
of
potential
providers
that
you
could
use
and
configure
and
I
would
probably
go
with
that
list
right
there
in
the
left.
A
So
secrets
management
has
always
been
tough,
I
think
as
a
whole,
recommending
the
use
of
some
sort
of
kms
to
manage
a
lot
of
your
secrets,
your
certificates
and
things
like
that
will
be
incredibly
useful,
especially
for
doing
things
like
managing
the
underlying
cluster
infrastructure.
So
if
you
use
like
an
OCSP
server,
then
you're
able
to
like
revoked
certificates
a
little
bit
easier
and
I
think
like
hash.
Core
vault
has
support
for
this
and
in
general,
just
trying
to
offload
it's
just
something
that
does
it
better
than
any
one
of
us
can
implement
ourselves.
C
C
So
no
I,
don't
think
you
should
go
through
and
do
a
threat
model
of
kubernetes
itself.
What
I
do
think
you
should
take
away
from
this,
though,
is
that
there
are
certain
in
heretic
like
if
I
give
you
a
Linux
box
and
I
say:
please
configure
this
you're
going
to
say:
I
need
SC,
Linux
I
need
some
etc.
What
we
attempted
to
do
is
hey.
These
are
the
these.
Are
the
inherited
controls
you
get
from
kubernetes?
These
are
the
things
that
you
need
to
bandage
over.
C
A
Sure
so
I
think
that
comes
down
to
economics
right.
So
the
question
he
asked
was,
if
you
have
secrets
in
a
namespace,
and
you
have
two
different
types
of
pods
and
one
of
them
gets
compromised
and
it
potentially
compromises
that
particular
secret.
That
could
be
a
problem,
but
this
kind
of
encapsulates
a
couple
of
problems
right
because
first
of
all,
namespaces
should
be
application-specific.
A
So
if
one
pod
is
running
something
else,
then
technically
you
have
I
don't
like
calling
at
this,
but
for
lack
of
better
terms
like
multi-tenancy
in
the
same
day,
in
space
in
respect
to
the
actual
workloads
right,
because
you
have
one
pod
doing
one
particular
thing
in
another
pod
doing
another
particular
thing
and
if
they
both
have
access
to
the
same
secret,
then
if
one
gets
compromised,
but
the
other
one
doesn't
then
well.
You
still
have
the
problem
of
broken
secrets.
Is
that
what
I
am
understanding
correctly?
A
Okay,
so
right
totally?
That's
what
I
was
trying
to
break
that
down
a
little
bit
long
but
okay,
so
the
quick
answer
to
that
one
is
namespaces
should
ideally
have
one
set
of
applications
that
encapsulate
like
you
shouldn't
mix
like
you
know
what
application
a
with,
what
allocation
be
in
the
same
namespace
and,
let's
there
logically
like
they
should
logically
be
together
or
depend
on
each
other.
A
A
Probably
the
person
to
ask
would
be
Aaron
small
on
this
one,
but
in
general
manage
providers
tend
to
differ
and
how
they
actually
manage
each
of
the
components
of
kubernetes.
So
it's
really
difficult
to
say
whether
or
not
they
actually
affect
gke
or
whether
they
don't
I
think
Aaron
actually
released
a
blog
post
discussing
that
as
to
whether,
like
certain
findings
affected
gke
and
how
they
handled
that,
so.
C
A
B
A
We
don't
necessarily
want
to
bog
them
down
with
eight-hour
discussions
about
every
granular
control,
like
that's,
not
something
that
we
want
to
do
in
this
process
because
that's
well,
it
is
effective
for
certain
organizations.
It
might
not
be
effective
for
most,
especially
the
smaller
ones,
because
realistically
you
can't
pull
a
senior
dev
from
a
team
and
sit
them
down
for
eight
hours
and
then
just
go
through
all
of
the
stuff,
because
that's
like
an
entire
day
wasted.
So
nobody
really
wants
to
do
that
and
plus
it's
really
boring.
A
A
A
Think
so
the
question
was
is:
are
there
any
risks
that
could
only
be
mitigated
through
third-party
plugins
or
applications
and
that's
kind
of
a
tough
one,
because
some
of
the
risks
are
actually
presented
by
the
third-party
right?
So
if
we
actually
look
at
the
CN
hi,
the
CNI
itself
is
just
an
interface,
but
the
provider
is
what
gives
us
a
function
now
gives
it
its
functionality.
So
if
that
functionality
is
abusing
a
certain
thing
right
now,
you
need
a
third
party
for
a
third
party.
A
C
Think
one
control
family,
that
is,
it,
is
a
little
bit
more
lacks
in
kubernetes
itself.
Even
if
you
tuned
it
up
is
is
awed
it,
at
least
with
within
the
version
that
we
were
looking
at
auditing
controls.
Now,
there's
there's
plenty
of
logging.
We
I'm
sure
have
all
seen
our
Splunk
logs
or
sumo
logic
or
whatever
explode
with
with
kubernetes,
but
specifically
this
user
at
this
time
undertook
this
action
with
this
thing
on
this
component
is,
is
not
something
that
is
universally
applied
across
kubernetes.
C
A
Also,
to
kind
of
complement
that
something
that
he
kind
of
glossed
over
and
that
answer
was
actually
often
an
Aussie
authentication.
Authorization
is
pretty
tough,
there's
tons
of
third-party
things
that
help
you
do
this
and
kubernetes
itself
doesn't
really
help.
You
do
this
in
any
real
impactful
way.
So.
B
A
I
think
it's
easier
to
go
with
surprisingly
bad,
because
that's
what
kind
of
we
were
focused
on
right
and
I,
wouldn't
even
say
surprisingly
bad,
because
that
sounds
like
we're
bashing
the
developers,
and
that
is
not
our
intent.
What
our
intent
is
is
to
identify
areas
of
improvement
and
specifically
I,
think
the
cubelet
is
probably
the
area
that
I
would
suggest
improvement
and
that's
mostly
because
there
were
lots
of
subtle
interactions,
because
the
the
couplet
is
interesting.
It
interacts
with
the
host
right
and
because
it
interacts
with
the
host
underneath
it.
It
has
interesting
implications.
A
So,
for
example,
we
found
a
problem
with
command-line
parsing,
so
the
people
that
depends
on
IO
nice
and
if
I,
oh
nice,
faults
or
something
it
will
just
work
the
cubelet
and
then
another
one
was
actually
the
talk
towel.
That
Dominic
found
where
there
was
a
problem
with
how
they
hard-coded
links
to
docker,
PID
files,
I
think
it
was
in
progress
and
that
caused
some
potential
areas
where,
if
a
attacker
has
like
an
unprivileged
host
access
but
root
container
access,
they
can
use
that
to
elevate
permissions.
So
there
oh
and
integer
overflows
yeah.