►
From YouTube: Walls Within Walls: What if Your Attacker Knows Parkour? - Tim Allclair & Greg Castle, Google
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
Walls Within Walls: What if Your Attacker Knows Parkour? - Tim Allclair & Greg Castle, Google
What happens if an attacker escapes a container and compromises your node? Is it game over for the whole cluster, or can you limit the blast radius? Whether it be for defense in depth or multi-tenancy, it is important to understand the security boundaries in your cluster. In this talk, we’ll discuss various isolation approaches and evaluate them through the eyes of an attacker who has compromised a node and is looking to propagate. We’ll deep dive on ‘node isolation’: using Kubernetes scheduling to execute workloads on separate nodes, and demonstrate live attacks and defences to educate about strengths and weaknesses of this strategy. We’ll also discuss progress made by SIG-Auth in this area over the past few releases. After this talk you will understand when node isolation is or isn't an appropriate security mechanism, the steps to implement it, and what some alternatives are.
https://sched.co/UaeM
A
A
This
sport
of
freerunning,
where
you
know
these
athletes
are
looking
at
the
urban
built
environment
and
looking
at
buildings
and
HVAC
systems
and
railings
and
staircases
in
ways
that
the
architects
and
builders
kind
of
never
intended
them
to
be
looked
at
and
used
in.
So
we're
gonna
kind
of
keep
this
theme
throughout
talk
and
we're
going
to
talk
about
node
isolation
and
how
we
can
attack
it
and
maybe
how
we
can
do
better
than
note
isolation.
So
we're
gonna
start
out
by
talking
about
basically
two
containers.
A
So
this
the
fundamental
problem
is,
you
have
a
trusted
thing
and
an
untrusted
thing,
and
you
want
to
separate
them
somehow.
So
one
way
to
do
that
is
to
use
what
we're
calling
node
isolation,
where
you
put
one
set
of
things
on
one
node
and
then
be
able
to
set
of
things
on
the
other
node,
and
that
seems
pretty
separate,
except
in
kubernetes.
It
isn't
really
that
separate.
A
So
we
have
two
containers
and
for
the
purposes
of
this
talk
we
also
have
a
fake
company.
That
does
like
a
really
specific
web
hosting
thing,
so
they
just
host
parkour
gym
websites.
So
it's
may
not
be
the
best
business
model,
ever
a
total
addressable
market,
probably
fairly
small,
but
that's
what
they
do.
So
they
have
things
that
are
in
to
the
company
and
one
of
those
things
is
a
payments
pod
that
does
payments
things,
and
then
they
have
the
customer
workloads
which
you
know.
A
For
the
purposes
of
this
talk,
we
tried
to
come
up
with
the
best
possible
pum
name.
We
could,
with
the
intersection
of
parkour
and
kubernetes
and
I
present
you
maximum
uptime,
I
hope
you
like
it,
and
so
the
the
red
container
here
or
pinkish
container
here
is
a
customer
website.
That
is
basically
an
untrusted
workload
that
this
hosting
company
is
running.
So
if
we
don't
do
anything,
they
get
scheduled
right
next
to
each
other
or
they
could
be,
and
the
threat
model
is
basically,
we
expect
that
thing
to
get
owned.
A
Like
the
these
kind
of
people
are
running
these
websites.
May
not,
you
know
patch
regularly,
I,
don't
know.
Maybe
competitors
are
actually
going
to
try
and
attack
each
other
at
one
point
or
another.
That's
probably
going
to
be
malicious
code
in
this
untrusted
container
at
some
point
and
if
that
happens,
and
it
breaks
out
and
it
can
access
other
stuff
on
the
node
so
like
container
breakouts.
A
Is
that
a
thing
that
we
need
to
worry
about
and
yeah
I
think
it
is
in
this
in
this
scenario,
where
you
have
a
trusted
thing
and
an
untrusted
thing
running
together?
If
you
look
at
kind
of
just
this
year,
there
was
a
vulnerability
and
run
C
that
broke
this
boundary,
and
so,
if
you
were
running
in
this
situation,
where
you
had
the
two
things
like
right
beside
each
other
with
just
a
container
boundary
in
between
you
would
have
probably
had
a
bad
day
in
your
production
system.
A
A
Here
then,
that's
sort
of
it,
so
this
leads
people
to
especially
security
people
who
used
to
separating
things
with
VMs
to
think
okay.
Well,
let's
just
stick
them
on
separate
nodes
in
and
put
VM
boundaries
in
between
been
doing
this
for
a
long
time
so,
payments
stuff
on
payments,
node
customers,
stuff
on
customer,
node,
whoo
and
there's
like
non
security
benefits
here.
So
you
get
separate
failure
domains
you
get
some
resource,
isolation
that
you
don't
get
with
C
groups.
A
So
that's
not
bad
from
that
perspective,
but
is
it
actually
good
enough
for
security
like
it
trusted
and
untrusted
like
this,
and
this
is
where
we're
gonna
focus
for
the
rest
of
the
talk,
so
we're
gonna
kind
of
walk
through
how
you
set
this
up
and
then
we're
going
to
attack
it.
So
how
do
you
set
it
up?
There's
a
few
different
pieces
and
labels
and
taints
are
key,
and
then
you
also
kind
of
need
to
deep
privilege,
the
cubelet
quite
a
bit
to
make
this
like
any
sort
of
reasonable
boundary
at
all.
A
So
in
terms
of
labels,
you
would
say
all
right:
I'm
gonna,
add
a
label
to
my
nodes.
So
that
the
payments
pods
can
target
target
the
payments
nodes,
that's
how
the
payments
fall
to
make
sure
they
end
up
on
the
payments
nodes
and
then
I
also
need
to
add
a
taint,
and
this
is
kind
of
like
a
little
counterintuitive
that
I
have
to
do
both
of
these
things,
but
basically
the
first
one
saying
please
land
here
and
then
the
second
one,
which
is
the
taint,
is
saying
anything
that
isn't
a
payments.
A
Node
should
never
be
scheduled
on
this
node.
So
that's
what
the
no
schedule
says
like
don't
put
anything,
don't
put
not
non
pain.
Things
on
this
note,
and
so
once
you've
done
that,
then
in
your
PUD
spec,
you
can
target
those
things,
so
you
would
say
in
your
PUD
SPECT,
please
put
me
on
payments
nodes
using
the
label,
and
then
you
would
also
say
I
can
tolerate
the
the
tainted
node
that
is
allowed
for
payments
and
that's
basically
enough
to
say
all
right
payments
things
land
on
a
payments
node.
A
So
then
switching
into
the
kind
of
like
the
API
sort
of
the
protections
here
and
the
and
the
Qod
privileges.
So
the
node
authorizer
is
pretty
key,
so
no
two
authorizer,
which
you
know
is
not
sort
of
on
by
default
with
kubernetes
but
is
on
by
default
in
lots
of
places
such
as
gke
sits
between
the
cubelet
and
the
api
server.
A
So
there's
also
an
admission
controller
which
I'll
get
to
in
a
sec,
and
so
Cupid
request
from
the
cubelet
goat-like
through
this
through
this
sort
of
request
path
and
the
idea
of
the
Noda
authorizer
is
to
limit
cubelet
to
lease
privilege.
So
it's
really
saying:
hey,
cubelet
you're
only
allowed
to
do
the
things
that
are
necessary
to
do
you
a
job
and
that's
things
like
right,
so
the
node
Eliza
is
constraining
what
the
the
cubelet
is
allowed
to
do,
including
like
which
things
that
can
write
to
and
especially
relevant,
is
which
secrets
that
can
read.
A
We'll
talk
more
about
that
in
a
minute,
and
then
admission
is
more
fine-grained
controls
over
that.
So
it's
okay,
the
couplet,
can
modify
the
node
object,
which
parts
of
the
node
object
should
the
people
that
really
be
allowed
to
modify,
and
so
you
need
both
of
those
things.
And
then
you
like
kind
of
deep
privilege,
the
cubelet
a
reasonable
extent.
So
this
is
the
full
picture
of
labels
and
taints
to
do
the
things
and
remove
some
Qibla
privileges
so
that
what
kind
of
now
sit
up
for
this
to
work.
A
So,
let's
talk
about
how
we
can
attack
it
so
I'll
hand
it
over
to
Tim
all
right
thanks
so
yeah.
So
we've
got
this
set
up
our
payment
spot
or
our
payment
spot
is
on
a
separate
node
from
our
maximum
uptime
node,
which
is
what
got
compromised.
So
the
attacker
has
access
to
the
newett
on
the
right
and
the
goal
of
this
attack
is
going
to
be
to
get
access
to
the
payment
secret.
A
The
payments
pod
or
the
payments
node
can
act
that
payments
secret.
It
has
to
be
able
to
because
it's
referenced
by
the
payments
pod,
but
the
compromise
note
can't
get
access
to
it
because
the
note
authorizer
blocks
it,
and
so
the
goal
of
this
attack
is
actually
going
to
be.
What?
If
we
can
get
that
payment
squad
to
reschedule
on
to
the
attacker
node,
then
the
note
authorizer
would
say:
okay,
you
have
an
access
to
the
payment
secret,
so
I'll,
let
you
access
the
payment
secret.
So
that's
gonna
be
the
first
step
of
the
attack.
A
We
have
to
modify
the
node
so
that
the
payments
pod
can
be
scheduled
onto
that
node
from
there
we'll
kill
off
the
real
payments
pod
and
then
let
it
be
rescheduled
to
the
node.
So
let's
take
a
look
at
that
first
step.
In
order
for
the
payments
pod
to
get
scheduled
on
to
that
customer
node,
we
have
to
first
remove
the
customer
tape
and
then
we
need
to
add
the
class
equals
payments
label
that
we're
going
to
be
using
so
I'll
switch
over
to
the
demo.
Now.
A
So
we
are
running
as
root
on
the
node,
and
that
means
that
we
have
access
to
everything,
that's
on
that
node
and
cute,
including
the
cubelets
credentials.
So
the
first
thing
we'll
do
is
we'll
just
set
up
cube
cuddle
to
use
the
cubelet
config
and
credentials
and
then
we'll
be
using
that
through
the
rest
of
the
demo.
Let's
take
a
look
at
the
current
set
up
in
the
payments
namespace.
A
So
now,
let's
try
and
modify
the
node
first
thing
we
have
to
do
is
grab
the
current
node
object
and
then
I'm
going
to
do
this
jQuery
command.
You
could
do
this
in
an
editor.
It
was
easy
to
script
easier
to
script
up
with
jQuery
we're
just
adding
a
class
equals
payments
label.
That's
the
first
line.
We
are
deleting
all
of
the
taints
on
the
spec
and
then
we
have
this
little
bookkeeping
thing.
A
So,
let's
jump
back
to
slides
here.
So
at
this
point
we've
sort
of
succeeded.
We
have
removed
the
the
taint
added
the
label.
At
this
point.
The
payments
pod
could
schedule
on
to
this
node
and
if
we
wait
long
enough,
it
might
eventually
have
a
scaling
event
or
do
an
upgrade
or
just
crash,
and
maybe
it
will
get
rescheduled
on
our
node.
A
But
we
can
do
better
than
that
and
I'll
hand
it
off
to
Greg,
to
tell
you
how
ok
so,
the
next
steps
we
want
to
actually
kill
off
that
real
payments
pod
and
the
way
we're
gonna
do.
That
is
we're
gonna
create
a
fake
pod,
make
it
older
put
it
in
a
replica
set,
have
rific
a
set,
kill
the
newest,
so
let's
just
step
through
those.
So
the
first
thing
we're
gonna
do
is
create
this
fake
payments
pod.
A
So
kid
was
just
not
allowed
to
create
regular
pods,
but
it
can
create
static
pods,
so
we're
gonna
create
a
static
pod,
which
is
basically
just
like
cubelet
managing
its
own
pod
running
on
the
node,
and
then
these
are
mirrored
in
the
in
the
API.
So
you
may
have
heard
this
like
concept
of
a
mirror,
pod
and
basically
cublas
creating
a
pod
on
its
own
and
then
there's
a
a
mirror,
object,
that's
being
created
in
the
API,
so
the
API
server
knows
what's
going
on.
A
So
if
you
queue
control,
get
pods
and
you
can
still
see
these
static
pods.
So
once
we
have
this
kind
of
like
fake
payments,
we're
gonna
start
abusing
replicas
set
to
do
our
bidding.
So
replica
said
job
in
this
in
this
kind
of
scenario,
is
to
keep
one
copy
of
the
payments
pod
running
and
what
we're
gonna
try
and
do
is
make
a
kill.
The
legitimate
one
and
have
our
one
be
the
only
one:
that's
there
so
replicas
say:
hey
I've
got
two
of
these
I
need
to
kill
one
off.
A
Hopefully
it
kills
the
other
one,
but
there's
a
wrinkle
here
so
replicas
it
actually
kills
the
newest
part
and
the
logic
there
is
well.
You
know
this
other
part
has
been
ready
for
a
long
time.
It's
been
running,
it's
fine,
I
I,
don't
need
this
new
pod
that
just
started.
I'll
just
kill
that
one
off,
so
we
actually
need
to
make
our
pod
older.
So
our
pod
needs
to
be
like
the
og
payments
like
it.
A
It
needs
to
be
like
the
payments
that's
been
around
for
the
longest
time,
and
so
we
definitely
don't
want
that
one
killed
off
and
please
kill
off
the
a
the
much
newer
one.
So
we
need
to
actually
modify
the
ready
time
on
that
fake
payments,
pod
and
then
kind
of
like
the
final
piece
of
this
is
like
once
we've
got
all
that
set
up,
then
we're
going
to
delete
ours
and
then
have
replica
set,
recreate
it,
and
hopefully
it
recreates
on
us.
So,
let's
step
through
it
and
demo.
A
My
windows
right
in
here
so
the
first
thing
I'm
gonna,
do-
is
look
at
the
fake
payments
pod
that
we're
creating.
So
that's
this
mirror
pod.
It's
like
super
boring
pod.
It
doesn't
do
anything.
This
just
calls
pause
which
just
sleeps-
and
this
is
just
a
shell,
so
that
we
can
use
that
replica
set.
So
we're
just
going
to
try
creating
that
and
as
we
expect
people
it's
not
allowed
to
do
that.
So
we
get
this
very
helpful
error
message
that
says:
hey.
You
can
only
create
mirror
pods
great,
let's
create
a
mirror
pod.
A
A
So
next
we're
going
to
get
set
up
to
mess
with
a
replica
set,
so
a
big
giant,
long,
pod
name
here
and
we're
gonna
grab
the
JSON
representation
of
the
the
mirror
pod
out
of
the
API
server
so
again,
mess
with
it
and
the
first
thing
we're
going
to
do
is
make
our
pod
the
the
og
payments
pod.
So
this
one's
been
running
since
2018,
API
server,
please
believe
us.
So
we
set
that
up
and
here
we're
actually
just
going
to
interact
with
the
API
directly.
A
What
we're
doing
can't
actually
be
easily
done
with
Q
control,
so
we're
setting
curl
up
to
use
the
cubelets
client
suit
and
just
grabbing
the
api
server's
IP
address
and
then
we're
just
going
to
patch
that
mirror
pod
object
with
that
new
ready
status
time.
So
this
tells
the
API
server
I've
been
ready
since
2018
I've
been
doing
this
a
long
time
and
we're
going
in
through
the
status
sub
resource
of
the
pod.
A
So
the
next
step
that
worked,
the
next
step
is
we
need
to
be
in
the
replica
set.
So
the
way
we
tell
a
replica
said
to
adopt
this
part
is
just
add
this
label,
so
hey
replica
set
payments
processor.
That's
your
name!
We'd
like
this
pod
to
be
part
of
your
responsibility,
and
so
as
soon
as
we
do
that
it's
gonna
be
looking
at
two
pods
and
making
a
decision
about
which
one
to
kill.
A
So
if
that
worked,
which
should
just
be
our
mirror
pod
running
and
the
real
payments
pod
should
be
gone
so
yeah
you
can
see,
we
only
got
one.
It's
just
us,
there's
a
mirror
pod.
So
now
we've
effectively
dust
the
the
legitimate
payments
pod
and
just
pause
this
for
a
second,
and
so
it's
not
running
anymore.
It's
a
it's
down
and
the
the
mirror
pod
is
the
only
thing
running.
A
So
the
final
step
steps
in
the
attack
here
now
that
we're
the
only
payments
part
if
we
delete
ourselves,
there's
gonna
be
zero
payment
spots
left,
and
so
the
replica
sets
gonna
say
well.
I
need
one,
and
this
is
a
you
know
erase
then
about
like
which
payments
node
is
gonna
get
scheduled
on
is
it
it
could
get
scheduled
on
the
legitimate
payments
node
or
it
could
get
scheduled
on
us.
A
So
if
we
delete
it
and
then
we
check
kind
of
like
where
it
gets
scheduled
like
as
we
were
kind
of
running
this
demo
and
getting
it
ready,
I'd
say
probably
like
better
than
half
the
time
it
landed
on
us
some
of
other
times
it
landed
on
the
actual
payments.
Node-
and
you
can
see
here
that
it's
actually
landed
on
our
our
demo
node,
but
if
that
hadn't
happened,
we
could
just
do
it
again
and
we
could
just
scripted
until
it
did
so
everything
works.
Then
we
should
be
able
to
get
access
to
the
secret.
A
A
So,
like
sound
scary,
so
we've
actually
been
working
on
in
sigilyph
kind
of
protecting
against
these
type
of
attacks.
So,
as
in
Tim
section
of
the
demo
I
mentioned
that
you
can't
just
modify
the
he
couldn't
make
a
modification
directly,
he
had
to
delete
the
node
and
then
recreate
it,
and
that
protection
was
brought
in
and
111,
and
this
attack
that
we
just
demonstrated
actually
only
works
on
112,
because
we
fix
the
delete,
the
node
and
recreate
things
so
like.
If
you
thought
well,
that's
dumb
yeah.
A
A
If
you're
trying
to
rely
on
the
node
isolation
to
kind
of
have
this
separation,
you're
kind
of
gonna
have
a
bad
time,
and
so
it's
like
I'm
gonna
head
it
over
to
Tim,
to
talk
more
about
sort
of
how
we
can
think
about
not
pod
versus
node
separation
and
what
the
alternatives
are
thanks,
yeah.
So,
let's.
A
Let's
generalize
a
bit
so
yeah,
we
just
saw
this
attack
using
the
cubelets
credentials
to
talk
to
the
API
server
and
we
saw
how
the
new
authorizer
can
prevent
this
type
of
an
attack.
But
there's
a
lot
more
going
on
on
the
node
than
just
running
the
cubelet
you've
probably
got
some
other
demon
sets
running
on
the
node
like
the
node
problem
detector
and
those
demon
sets
don't
actually
go
through.
A
The
nude
authorizer
you've
got
some
external
networking
coming
in
through
the
node,
and
we
actually
had
to
cut
a
second
demo
for
time
that
showed
how
to
man
in
the
middle
and
intercept
some
traffic
bound
for
another
node
you've
got
other
nodes
in
the
cluster,
doing
all
sorts
of
things.
You
can't
rely
on
network
policy
necessarily
to
protect
those
API
endpoints,
because
we're
outside
of
a
pod
we're
outside
the
limits
of
network
policy.
You've
got
some
external
services,
like
a
credential
provider,
providing
bootstrap
credentials
to
the
node.
What
can
an
attacker
do
with
that?
A
You've
got
some
sort
of
metrics
pipeline.
What
happens
if
your
attacker
reports
incorrect
metrics?
What
can
they
do?
Logging
pipeline?
You
can
no
longer
trust
your
audit
logs
from
the
node
and
finally,
there's
probably
some
remote
storage,
and
what
can
an
attacker
do
with
access
to
that
remote
storage?
So
the
point
of
this
big
complicated
picture
isn't
to
actually
understand
everything
that's
going
on
here.
The
point
is
that
it's
complicated
and
also
the
attacker
on
the
node
now
has
access
to
the
union
of
all
of
these
different
things
going
on.
A
So
even
if
we're
running
our
node
in
a
leased
privileges
model
like
those
are
still
a
lot
of
privileges
ending
comp.
If
we
compare
that
to
a
pod,
we
see
this
theme
kind
of
again
and
again
we're
in
authorization.
We
have
all
of
the
permissions
on
the
node
on
the
node
side,
whereas
in
the
pod
case
we
can
scoop
that
down
a
lot
more
to
just
the
containers
running
in
that
pod.
Similarly,
with
network
access,
can
you
similarly
with
network
access,
we
have
the
union
of
everything
on
the
node.
A
B
A
Monitoring
is
probably
running
on
the
node,
and
so
if
your
nude
is
compromised,
you
can't
trust
your
monitoring.
In
the
pod
case,
your
monitoring
is
still
running
on
the
node,
but
now
your
attacker
is
contained
in
the
pod
and
we
can
rely
on
those
metrics.
A
little
more
one
point
for
node
isolation
is
that
you
have
stronger
resource
isolation.
We
have
some
isolation
through
C
groups
on
the
pod,
but
we
don't
hit
everything
and
so
you're
still
going
to
be
subject
to
noisy
neighbors
in
the
pod
case,
but
we
are
still
left
with
this
problem.
A
So
in
practice
the
two
main
implementations
used
in
kubernetes
today,
our
G
visor,
which
runs
a
sort
of
user
space,
emulated,
kernel
and
kata
containers,
which
is
a
lightweight
per
pod
VM,
and
we
abstract
this
away
with
runtime
class.
That
represents
the
underlying
runtime,
and
then
you
can
just
reference
the
runtime
class
from
your
pod
to
use
that
and
there's
a
lot
of
links
in
here.
If
you
want
to
learn
more
about
that,
so
node
isolation
seems
like
kind
of
scary,
but
okay,
all
right,
node
isolation
might
seem
kind
of
scary.
A
At
this
point,
but
remember
those
like
starting
assumptions
that
we
sort
of
glossed
over
at
the
very
beginning
before
the
attacker
can
get
to
escaping
your
node.
They
first
need
to
compromise
your
application.
Get
remote
code
execution
then
escape
the
container
escalate
to
root,
and
then
they
can
actually
attack
the
cluster
from
the
node.
A
So
can
we
make
those
first
two
steps
harder
for
the
attacker
on
the
application
side?
This
is
really
going
to
depend
on
the
specific
application,
but
some
general
pieces
of
advice
are
to
stay
on
top
of
patches.
If
you
choose
a
minimal
base
image,
then
staying
on
top
of
patches
is
a
little
easier
and
then
apply
application.
Specific
hardening,
like
using
a
secure
web
framework
on
the
container
side
running
as
non-root,
should
really
be.
A
The
first
thing
that
you
try
and
do
in
addition
to
that
resource
limits
can
help
prevent
some
local
denial
of
service
attacks
lease
privilege.
Authorization
is
always
a
good
good
choice
and
restrict
the
network
with
something
like
Network
policy
or
sto,
and
if
you
still
want
more
hardening
beyond
that,
we
recommend
sandboxes,
especially
if
you
don't
trust
your
application.
If
you
don't
have
that
first
boundary
of
the
application.
Well,
this
can
add
a
second
layer
at
the
pod
itself.
A
C
A
So
there's
definitely
a
lot
more
container
hardening
that
you
can
do
and
there's
a
lot
of
guides
out
there
for
that.
We
we
wanted
to
just
keep
it
simple
here
because
partly
for
time,
and
also
because
we
think
that
running
as
non-root
is
kind
of
the
the
strongest
recommendation
there
and
sometimes,
if
you
suggest
too
many
really
hard
to
implement
controls,
then
the
most
important
ones
can
get
lost
in
that,
but
but
yeah
read-only
and
set
comp
and
there's
lots
of
other
things.
We
can
advise
on
to
you.
A
Yeah
I,
think
I,
just
sort
of
that's
gonna
help
you.
So
it's
gonna
make
the
attackers
job
harder
when
I
land
in
the
container
when
they
get
that
execution.
But
it
doesn't
really
help
you
when
they're
sort
of
looking
to
propagate
from
there.
So
if
they
have
like
beaten
that
in
some
way,
like
that's
a
good
thing
to
do,
but
it
it's
also
sort
of
not
enough
for
the
isolation
piece
of
thing.
F
What
do
you
hear
about
the
discussion
around
namespace,
remapping
I
know
it's
something
we
can
do
in
containers,
but
it's
not
something.
That's
really
supported
through
kubernetes,
at
least
as
far
as
I've
seen
it
I
think.
Sandbox
is
kind
of
the
way
people
go,
but
do
you
mean
user
namespace,
yeah,
user,
namespace,
remapping,
yeah.
A
So
that's
another
great
way
of
hardening
the
container.
In
particular,
it
makes
that
step
of
running
as
non-root
a
lot
easier
if
you're
already
running
as
non-root,
it
doesn't
help
a
whole
lot.
We
are
there's
a
proposal
out
for
remapping
at
the
node
level,
so
all
containers
will
be
running
with
the
same
remapping
and
in
particular
again
it
just
like
makes
you
run
as
non-root
it's
hard,
because
kubernetes
has
persistent
volumes,
and
so
now
you
need
to
like
maintain
that
remapping
across
volumes
across
nodes.
So
that's
why
we
haven't
done
it
yet.
B
A
B
A
A
E
A
Think
the
short
answer
is
no
I.
Think
we've
heard
some
discussions
about
it.
I
haven't
heard
of
anyone
doing
that
for
real,
maybe
they
exist.
Okay,
one
thing
to
add
is
I
think
that
security
enclaves
kind
of
solves
a
slightly
different
addresses,
a
slightly
different
threat
model
than
what
container
isolation
does
and.