►
From YouTube: The Route To Rootless Containers - Ed King, Pivotal & Julz Friedman, IBM (Any Skill Level)
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
The Route To Rootless Containers - Ed King, Pivotal & Julz Friedman, IBM (Any Skill Level)
Rootless containers are a new and exciting development in the container community, offering the ability to create and manage containers as a completely unprivileged, non-root user. This is appealing both in terms of security, as well as in making container-based workloads accessible to a much wider audience. During this presentation, Julz and Ed will share their learnings from the journey to adopting rootless containers in production for a large multi-tenant PaaS (Cloud Foundry). The talk contains a technical overview of rootless containers - what they are, how they work and how to enable them in runC as well as a discussion of the limitations of rootless containers and how we overcame those limitations. If you’re interested in using rootless containers in production, this talk is for you!
About Ed
Ed is a Systems Engineer currently working on the Cloud Foundry Garden project. He has spoken at CFSummit Santa Clara 2016.
About Julian
Julian Friedman (julz) is an IBMer and the project lead for Cloud Foundy's low-level container engine (""Garden"") and the Application Autoscaler component. Over a long career he has worked on early cloud environments, Map/Reduce, performance optimisation for AI systems and, of course, most currently and importantly, building container engines for fantastic multi-tenant platforms as a service. If you have several free hours and enjoy the sound of a rant delivered in a British accent, ask him whether he thinks pushing mongodb to a cloud platform is a good idea.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
You
deserve
this.
Let's
get
ready
to
rootless.
There
you
go.
I
was
literally
dead
to
start
the
talk
that
way.
I
always
like
I'm,
like
I,
love
this
conference,
because
this
many
people
have
turned
out
to
talk
about
rootless
containers
and
the
fact
that
this
many
people
are
interested
in
such
a
low-level
topic
is
absolutely
amazing.
So
thank
you
so
much
for
coming.
Let's
get
started
so
alright,
that's
not
going
to
work!
So
I
am
dr.
Jules
I'm,
an
IBM
a--.
I
am
the
PM
for
garden,
which
is
cloud
foundries
container
engine.
A
B
Right
and
and
of
course
we
did
have
a
few
other
talk
title
suggestions.
Every
talk
has
to
have
a
good
title,
so
this
is
Jules.
My
name
is
Edie,
but
I
quite
often
go
by
the
name
of
Ted,
and
so
one
other
idea
we
had
was
this
one
here
chosen
Ted's
ruthless
adventurer,
but
we
thought
that
maybe
that
wouldn't
be
sending
out
quite
the
right
message.
So
so
we
went
with
the
the
rudeness
all.
A
Right
so
this
talk
is
in
three
parts.
First,
we're
going
to
talk
about
why
we
care
why
we
got
interested
in
rootless
containers
and
why
we
did
this,
then
we're
going
to
talk
about
container
security,
what
we
already
do
to
secure
containers
and
why
that
wasn't
quite
enough
for
us
and
then
we'll
talk
about
actually
how
far
we
are
down
the
journey
of
rootless
containers.
So
all.
B
B
Well,
there's
really
three
concerns.
I!
Think
the
first
one
is
the
Cloud.
Foundry
is
a
public
cloud,
which
means
we
have
no
idea
who
is
running
applications
on
the
platform.
The
second
one
is
that
it's
multi-tenant,
which
means
that
we
absolutely
cannot
trust
any
of
the
code.
That's
pushed
to
the
platform
at
all,
and
then
thirdly,
it
allows
us
to
run
docker
images.
B
A
So
container
security
so
far.
Well,
we
already
do
for
container
security,
and
in
order
to
do
that,
we
need
to
talk
about
what
a
container
actually
is
or
famously
isn't
so
the
thing
about
containers
is,
they
don't
exist,
they're.
Actually,
just
processes
made
up
of
some
low-level
primitives.
So
what
is
a
container
I
always
like
to
start
by
just
referencing
the
fact
that
we've
invented
this
idea
about
seven
times
before,
starting
with
jar
files,
several
members
right
once
and
run
anywhere,
and
it's
going
to
be
great,
didn't
quite
work
out
that
way.
A
So
we
wanted
to
do
this
lower
level
with
processes
more
generically,
but
we
couldn't
just
use
processes
in
the
operating
system.
We
need
to
think
about
isolation,
so
he
said
some
I
guess
metaphorical
Lilith
Lilith.
Can
you
give
us
a
primitive?
The
less
has
run
lots
of
processes
rather
feeling
with
each
other.
So
we
have
namespaces
to
talk
about
later,
which
give
us
isolation
between
different
processes
on
a
machine,
and
then
we
wanted
to
share
resources
between
those
processes
fairly.
A
So
we
also
have
C
groups
which
let
us
share
those
resources
or
talk
about
those
a
bit
more
later
as
well.
That
gives
us
fair
sharing
between
the
process
on
the
machine,
and
so
we've
got
namespaces
and
C
groups.
We've
got
this
container
image
yeh,
and
that
was
containers
and
that's
everything
about
containers
right.
Well,
not
quite
something
happened.
Next,
some
people
may
know
about
those
a
disturbance
in
the
force,
and
now
it's
docker.
So
what
did
dr.
A
do
above
this
namespaces
and
C
groups
think
I
would
say
what
they
did
was
encapsulation
and
they
added
this
idea
of
ship
aboard
units.
These
container
images
that
you
could
move
around
between
machines
efficiently
so
that
you
could
run
the
same
image
in
lots
of
different
places
using
these
low
level
primitives
and
by
adding
this
big
thing
on
top.
A
B
So
when
we're
talking
about
isolation
with
regards
to
containers,
I
think
what
we're
really
talking
about
is
Linux
namespaces,
so
Linux
namespaces
at
a
high
level.
They
provide
isolation
of
global
system
resources
between
processes
running
on
a
host
and
the
way
this
works
is
there
every
single
process
that's
running
on
a
Linux
machine,
it's
running
in
a
corresponding
set
of
namespaces
these
ones
here.
So
some
of
these
are
kind
of
more
interesting
than
others.
I
think
I
think
particularly
the
user
name.
B
Space
is
relevant
with
regards
to
rootless
containers,
so
we're
going
to
talk
a
lot
more
about
that
a
little
bit
later.
Just
to
give
you
like
a
solid
example
of
what
we're
talking
about
now,
let's
take
the
PIP
namespace,
so
the
pit
namespace
isolates
the
process
ID
number
space.
We
just
had
a
notification
that
the
battery
is
about
100
black
talks
about
run
out
a
battery,
but
surely
find
a
pin
namespace
right.
B
So
essentially,
what
this
means
is
that
two
processes
running
on
the
same
host
can
share
the
same
pit
as
long
as
they
are
in
two
different
namespaces,
and
so
in
the
example.
Here
we
can
see
that
the
containers
pit
one
actually
maps
back
to
a
much
higher
pit
in
the
initial
namespace,
but
the
important
thing
to
know
is
that,
from
the
view
of
the
container,
it
thinks
that
the
PIDs
start
at
one
right
and
it
has
no
knowledge
of
pit
1-2-3
in
the
host.
Let's
take
another
example:
the
mountain
aim
space,
so
the
mountain
aim.
B
Well,
what
happens
if
someone
breaks
out
of
that
isolation
right
it's
a
case
of
like
hey
nice
isolation.
You
got
there
be
a
shame
if
someone
break
out
of
it
right,
like
what
other
things
do
we
have
available
to
help
us
then,
and
to
that
I
say
security
onion?
What
the
hell
is
a
security
onion.
Well,
this
is
really
all
about
adding
layers
of
security
and
when
we're
talking
about
containers,
there
are
a
few
other
layers
that
we
have
available
to
us,
namely
capability
dropping
asset
comp
and
app
armour.
B
We
had
the
all-powerful
root
user,
who
had
the
privilege
to
do
absolutely
everything,
and
then
every
other
user
who
was
running
on
the
host,
who
didn't
have
privilege
to
do
anything
at
all
and
these
days
that
those
privileges
have
actually
been
split
up
and
divided
into
little
chunks,
known
as
neat
sorry
capabilities,
and
just
to
give
you
some
examples
of
what
those
capabilities
look
like
what
means
service
example:
we've
got
cap
set
you
it
previously.
If
you
wanted
to
change
or
you
it,
you
basically
had
to
be
the
root
user.
B
B
Basically,
if
you
have
caps
this
admin,
you're
like
more
or
less
root
user
and
the
reason
I
mention
this
is
because
when
it
comes
to
containers,
we
can
drop
capabilities
right,
and
that
means
that,
even
if
you
break
out
of
that
isolation,
if
you
don't
have
the
capability
to
do
anything
like
this,
there's
a
limit
to
the
amount
of
damage
that
you
can
actually
do
next
up
is
set
comp.
Sitcom
allows
us
to
limit
the
system,
calls
that
a
process
can
make.
So
this
is
pretty
cool
like
if
we
think
about
it.
B
Really,
we
are
relying
on
the
security
of
the
kernel,
the
connect,
the
kernel
has
a
pretty
big
surface
area
and
so
by
limiting
the
actual
number
of
Siskel's
that
our
container
processors
can
make.
That
leads
us
in
a
much
much
safer
position
as
well,
and
then,
finally,
we
have
apana
so
app.
Armor
is
a
form
of
mandatory
access,
control,
sort
of
simple
it's
a
selinux,
and
this
allows
us
to
confine
our
container
processes
even
further
to
the
way
this.
B
This
generally
works
is
you
have
an
apartment
profile
with
a
bunch
of
rules,
and
then
you
apply
that
profile
to
your
container
process.
So
we've
got
an
example.
We'll
there
deny
app
proc,
slash,
star,
W,
basically
means
that
you
are
not
allowed
to
write
directly
to
any
file
inside
/proc,
and
thus
we
have
security,
onion
and
just
to
sort
of
show
that
we're
not
just
doing
this.
B
A
So
that's
isolation,
we'll
talk
quickly
about
resource
sharing,
so
this
is
mainly
done
with
secret
in
the
kernel.
Quite
like
main
spaces.
You've
got
a
set
of
C
groups,
one
for
sharing
CPU
fairly
between
applications,
one
for
sharing
memory
fairly
between
applications,
various
others.
This
holster
fair,
sharing,
quite
well.
The
other
thing
we
have
to
do
because
we're
a
multi-tenant
platform
as
a
service
is
disk
quotas.
A
You
can't
just
let
you
to
contain
a
write
as
much
as
it
likes
to
the
disk,
so
we
have
to
somehow
limit
the
amount
rights
they
can
do,
and
this
turns
out
to
be
a
train
wreck.
This
is
where
a
lot
of
the
rootless
stuff
ends
up
exploding,
and
so
we're
going
to
talk
quite
a
lot
more
about
that
later.
But
for
now
that's
resource
sharing
and
so
we'll
talk
about
encapsulation
yeah.
B
And
I
and
I
think
when
it
comes
to
encapsulation
I,
think
that's
really,
there's
really
two
parts
to
this
I
think
the
first
part
is
encapsulation
of
an
applications
dependencies
inside
the
container.
So
in
the
example
there
we've
got
run
washer
that
has
slash
bin,
slash
dependency,
1,
etc,
etc,
and
then
I
think
there's
also
encapsulation
of
all
of
this
together,
like
they
like
the
container
itself.
How
do
we
package
all
of
that
up
together
into
some
thing
that
is
quick,
safe
and
efficient
to
ship
around
and
so
to
answer?
B
So,
at
the
end
of
the
day,
every
every
dependency
is
probably
going
to
be
on
the
file
system
somewhere,
but
we
know
that
different
applications
have
a
different
set
of
dependencies.
So
what
do
we
do
about
that
and
I
think
the
solution
is
this
pivot
route
Cisco.
So
I
briefly
mentioned
this.
There's
a
little
bit
earlier.
B
Pivot
route
is
the
Cisco
that
allows
us
to
change,
or
a
container
sees
a
slash,
so
just
to
sort
of
give
you
a
very
contrived
example:
we've
got
this
process
Rundle
sure,
and
it
asks
what's
it
slash
and
under
normal
circumstances,
it
just
sees
the
boring
host
file
system
right,
but
what?
If
our
application,
has
dependencies
that
aren't
on
the
host
file
system
and
instead
we
don't
want
to
use
this
a
bun
to
distribution.
We
want
to
use
like
this
is
cool
container
Alpina
image
instead.
B
B
That's
for
the
second
part.
How
do
we?
How
do
we
sort
of
encapsulate
all
of
this
together?
It's
maybe
let's.
Like
take
another
example.
Let's
say,
we've
got
run
da
and
run
two
Daksha,
and
both
of
these
applications
actually
do
depend
on
like
a
full
massive
Ubuntu
OS
in
order
to
work
properly,
and
so
you
might
look
at
that
and
think,
ok.
B
A
And
with
that
we
have
most
of
resource
sharing,
we
don't
quite
have
all
the
sauce
sharing.
Oh
sorry,
thank
you,
this
encapsulation,
but
we
just
need
a
side
notes.
So
this
is
all
based
on
standards,
and
one
of
the
big
things
that's
happened
in
recent
years
is
all
of
this
container
stuff
has
begun
to
get
really
great
standards
around
it.
We
have
the
OCI
image
and
runtime
standards,
there's
R
and
C,
which
is
a
small,
simple,
runtime
pulled
out
of
docker
which
we're
using.
A
So,
although
this
is
in
cloud
foundry,
which
uses
a
different
Orchestrator,
most
of
the
concepts
here
will
work
for
all
of
these
other
orchestrators,
because
most
of
this
is
in
run,
C
garden,
which
is
what
this
is
based
on.
You
just
a
bit
of
glues,
kind
of
like
CRI
for
Cloud
Foundry,
the
glues
run
seed
to
the
rest
of
the
platform,
but
under
the
covers
is
just
OCI
and
run
see,
so
we've
got
isolation,
resource
sharing
this
security,
onion
encapsulation,
so
we're
secure
right.
You've,
probably
guessed
not
quite
so.
Why
are
we
secure?
A
A
At
the
moment,
it's
using
elevated
privileges
to
do
it,
and
so
that
starts
to
look
like
the
weak
point
in
the
system
and
that's
why
we
need
to
start
thinking
of
how
do
we
secure
the
thing
that
creates
those
secure
containers
and
that
takes
us
to
the
roots
of
rootless,
which
will
be
the
rest
of
the
talk.
Yeah.
B
A
A
Who've
contributed
massively
to
the
route
list,
containers
work
upstream
in
run,
seed
and
the
rest
of
the
container
community
and
we're
very,
very
much
standing
on
the
shoulders
of
giants
with
this
work,
and
it's
just
a
huge
amount
in
that
community
that
we
just
get
to
integrate
into
our
system,
so
Jessie
for
sale,
I
like
sorry,
they
think
I'm
pronouncing
it
right,
but
I'm,
probably
not
a
key
hero,
sudha
Phyllis
T's
as
well
among
others.
So
how
does
this
work?
A
The
big
trick
turns
out
to
be
user
name
spaces
that
we
talked
about
a
bit
earlier,
I'm.
So
in
the
same
way
as
the
kid
names
basis
that
we
talked
about
earlier
maps
have
hidden
the
host
to
a
pit
in
the
container.
So
you
have
a
different
pit
in
the
container
from
the
host
the
usernames
basemaps,
a
different
user
in
the
host
and
the
container
so
inside
the
host
you're,
a
random
user
with
no
particular
privileges,
but
inside
the
container.
A
You
are
Ruth,
you
have
all
permissions,
you
are
UID
0.
So
how
does
that
work?
There's
a
UID
map
similar
to
that
pit
map
which
Maps
the
user
IDs
in
the
container
in
the
host
and
we're
mapping.
In
this
case,
we've
just
picked
the
highest
possible
user
ID
on
the
system.
It's
the
least
likely
to
have
any
privileges
at
all.
A
In
the
host
I
say:
host
I
mean
the
init
namespace
to
UID
0
in
the
container,
and
the
last
column
is
the
number
to
map,
starting
from
that,
so
we've
mapped
one
of
0
to
the
highest
and
then
all
the
others
in
this
configuration
we've
map,
starting
from
65536
up
for
all
the
other
users.
So
that
means
that,
although
in
the
container
you
have
this
UID
0,
you
don't
have
any
particular
user
ID
in
the
house
in
the
container,
then
you
have
all
these
permissions,
but
only
in
the
container
in
its
namespaces.
A
The
really
great
thing
for
us
for
rulers
is
that
since
linux
3.8
had
to
look
to
remember
which
linux,
since
since
we
put
8
any
user,
can
create
user
name
space.
So
you
don't
need
to
be
roots,
to
create
a
user
name
space
and
become
UID
0
in
it
and
that's
safe,
because
you
only
have
root
in
your
bubble.
Namespace,
you
don't
have
roots
in
the
host,
so
you
can
do
it
as
a
regular
user,
and
once
you
have
done
it,
you
have
collapses
admin,
which
is
that
capabilities
then
talked
about
earlier.
A
The
very
expansive
capability
in
that
namespace
and
the
namespaces
that
you
created
at
the
same
time
and
that
lets
you
do
seccomp
and
a
Parmer
and
everything
else
that
we
want
to
do
so.
That's
pretty
great
the
big
trick.
Then,
as
a
user,
any
user
can
create
user
name
space.
You
become
roots
in
that
user
name
space,
but
only
in
that
namespace.
So
it's
a
secure
thing
to
do
so
problem.
What
problems
do
you
hit?
Well?
First,
when
you
do
that,
you
only
actually
get
one
UID.
A
So
by
default,
when
you
create
this
namespace,
your
UID
can
be
mapped
to
one
UID
in
the
container.
So
you
can
map
yourself
to
roots,
but
there's
no
other,
you
IDs
in
the
container
that
exist
because
they're,
not
maps,
we
only
use
it
in
the
host,
because
if
you
map
them
to
a
user
in
the
host,
you
would
suddenly
have
a
way
of
having
permissions
on
a
UID
that
you
didn't
have
permissions
on
in
the
host.
A
So
if
I
map
UID
500
in
the
container
to
UID
2
in
the
container
I'll
be
container,
ooh
I
can
become
UID.
Two
I
will
then
in
the
house,
be
UID
500
and
now
I've
got
permissions
that
I
wasn't
supposed
to
have.
So
you
can't
do
that,
and
we
really
want
to
do
that,
because
we
actually
have
multiple
users
in
the
containers
that
we
run
so
the
solution.
A
There's
a
binary
called
new
UID
map,
it's
something
that
the
OS
supports
and
ships
and
what
that
does
is
it
looks
in
a
special
file
called
Etsy
sub
UID,
which
tells
it
which
you
IDs,
a
particular
user,
is
allowed
to
map
and
then
as
root.
It
writes
the
mapping
for
you
so
because
it
has
permissions,
it
can
map
some
users
that
you
can't
and
it
will
do
that
if
they're
in
the
file.
A
So
this
is
kind
of
cheating
because
we're
using
a
set
UID
binary
with
the
elevated
permissions,
but
it's
something
that
ships
with
the
host
OS
and
secured
by
the
host
OS.
So
it's
kind
of
okay
and
we
PR
Drancy
Runcie-
has
support
for
this
now.
So
Runcie
can
use
new
idea
new
UID
map,
if
you're
in
su
sub-
u
ID
so
that's
great
and
that
pretty
much
gives
us
isolation,
Anna,
Parma
and
all
those
other
things
without
needing
to
be
roots.
So
resource
sharing.
B
B
A
virtual
file
system
typically
mounted
at
sis
MST
group,
and
whenever
you
want
to
apply
some
limit,
you
usually
do
that
by
writing
to
a
file
inside
the
C
group
somewhere,
and
the
problem
is
that
all
of
these
files
are
owned
by
hosts
root,
which
means
that
our
container
root
user
doesn't
have
permission
to
make
the
changes
it
needs
to.
So
what
do
we
do
about
this?
Well,
the
way
that
we
kind
of
got
around
this
is
by
joining
a
subdirectory
inside
the
C
groups,
as
part
of
like
a
privileged
set
up
phase.
B
So
this
phase
runs
before
any
of
the
containers
are
like
even
created
on
the
system,
but
it
just
means
that
when
it
comes
to
creating
the
containers,
we
tell
run
C
to
point
to
our
chand
C
group
inside
the
file
system,
and
then
it
will
kind
of
works.
It
has
the
permissions.
It
needs
to
write
the
limits,
and
so
again
like
like
this
would
be
impede
our
P
Arden
to
run
C,
and
it's
seems
to
be
working
pretty
well
and
with
that
we
have
isolation
and
resource
sharing
awesome.
So.
A
We
have
results
written,
but
not
quite
because
you'll
remember
disk
quotas,
which
I
promise
you
we're
going
to
explode
and
sure
enough.
They
are
about
to
explode
and
this
actually
tastes
into
file
systems
as
well,
so
we'll
do
sort
of
disk
quotas
and
file
systems
to
for
the
price
of
one
so
file
systems.
If
you
remember
the
way
this
works,
we've
got
this
mount
namespace
and
the
pivot
root
to
change.
A
What
the
root
points
to
the
pivot
root
bit
is
fine,
because
we
can
do
that
in
a
user
name
space,
because
we
own
caps
this
admin
in
the
mountain
in
space,
because
we
created
it
inside
the
user
name
space
so
that
B
is
fine.
The
problem
is
downloading
those
file
systems
in
order
to
pivot
root
into
and
there
we
have
these
layered
file
systems
and
in
order
to
download
these
low
layer
file
system
sufficiently,
you
need
to
use
a
copy-on-write
file
system.
A
If
you
have
to
copy
a
bun
to
every
time,
you
want
to
create
a
bun
to
container
that's
going
to
be
far
too
slow,
so
you
need
a
file
system
that
can
make
that
copy
go
fast
and
you
basically
need
a
copy
and
write
file
system.
So
there's
a
few
of
these,
the
ones
we're
going
to
talk
about
our
AFS,
better
FS,
an
overlay
FS,
the
trick
that
all
of
these
really
do
is
as
soon
as
I
say
copy.
A
They
pretend
that
they've
done
the
copy,
make
Reed's
go
to
the
layer
and
then
store
up,
writes
in
a
dis
layer.
So
a
OFS,
a
FS
is
what
we
ran
in
production
for
ages.
It
works
out
really
well
for
us,
unfortunately,
one
in
the
mainline
kernel,
so
we
were
already
getting
a
bit
worried
about
supporting
that
long
term.
But
much
worse.
You
just
can't
do
this
for
that
route.
You
just
need
roots
in
order
to
mount
a
ufs,
and
there
just
isn't
a
good
way
around
that.
So
we
moved
to
better
FS
and
Barre
FS.
A
Has
this
great
feature
where,
as
a
non
privileged
user,
you
can
snapshot
a
directory?
And
you
don't
need
any
special
permissions
to
do
it.
It
can
just
do
a
copyright
snapshot,
so
you
need
a
bit
of
roots
at
startup
to
do
some
setup
of
that.
But
then
you
don't
need
roots
at
all.
So
we
were,
we
were
thinking
great.
This
is
fantastic.
This
is
all
solved.
A
Unfortunately,
it
then
exploded
at
scale
really
badly
and
we
had
to
revert
it
very
quickly
so
back
to
the
drawing
board
and
we
had
no
way
of
actually
doing
the
filesystem
layering
until
we
found
overlay
FS.
So
overlay
FS
is
very
similar
to
a
u
FS.
It's
a
similar
way
of
doing
things.
It
is
in
the
mainline
kernel,
but
the
really
great
thing
is
that
it's
allowed
to
be
mounted
inside
a
user
name
space
on
a
Bunty,
so
not
in
every
OS.
A
Unfortunately,
it
doesn't
work
generically,
but
talking
with
the
developer
of
overlay,
FS
canonical
and
the
developer
decided
that
it
was
safe
to
allow
mounts
of
overlay
FS
inside
a
user
name
space.
So
it's
added
to
the
white
list
of
file
systems
that
container
roots
can
mount
without
needing
to
be
roots
in
the
init
namespace.
So
what
that
means
is
we
had
to
change
things
so
they,
instead
of
doing
the
mount
outside
the
container,
where
we
don't
have
any
permissions.
We
now
do
the
mount
inside
the
container.
A
So
in
the
container
configuration
that
we
passed
the
run
C,
we
say
to
run
C
as
soon
as
you
start
up
this
container.
When
you
have
permissions,
please
mount
this
overlay
filesystem,
which
it
can
do
because
it
has
elevated
permissions
in
the
container,
and
then
it
runs
the
user
process.
Now
in
the
right
filesystem
and
says
how
this
seems
to
work,
it's
pretty
great,
so
we
then
have
isolation,
resource
sharing
and
encapsulation
pretty
much
without
needing
roots.
But
there
are
a
few
remaining
roadblocks
which
we
will
talk
about.
B
So
first
roadblock
is
dis,
quitters.
So
right
now,
as
Jules
mentioned
earlier,
we
have
to
apply
disk
quotas
club
boundaries.
A
multi-tenant
thing
means
we
have
to
limit
that,
and
so
we
are
currently
using
X
of
s
in
order
to
provide
that
and
the
problem
is
this
requires
privileges
fundamentally,
so
how
do
we?
How
do
we
get
around
that?
Well
right
now
we
extract
that
bit
interest
into
just
a
very
small
focus
to
set
you
at
binary.
B
That
literally
is
just
responsible
for
applying
the
quota,
and
then
we
run
that
at
the
appropriate
time
during
the
container
create
a
life
cycle.
So
there
is
a
bit
of
route
there.
It's
not
entirely
rootless,
but
you
know
it's
it's
what
it
is.
The
big
one
is
probably
networking,
so
we've
kind
of
conveniently
stepped
over
networking
in
this
talk,
and
that's
because
there's
no
way
to
do
it,
rootless
right
now
so
yeah,
the
problem
is
like
when
you
create
the
new
network.
B
Namespace
doesn't
have
any
external
network
connectivity
and
in
order
to
set
any
of
that
up
again,
you
just
have
to
have
root
privileges.
I
think
there
has
been
some
progress
or
there
is
some
progress
being
made
in
this
area,
but
I
think
as
of
right
now
you
do
need
that
privilege
and
so
again,
at
least
in
Cloud
Foundry.
We
kind
of
extracted
the
bit
of
the
system
that
does
the
networking
into
its
own
external
plugin,
and
then
we
just
had
to
apply
the
second
you
had
binary
to
that.
B
You
may
be
noticing
a
theme
of
applying
the
set
you
had
binary
to
stuff
final
thing:
is
this
I
kind
of
talked
about
this
setup
phase
like
the
churning
of
the
sea
groups,
so
again,
I
think
there
has
been
a
little
bit
of
work
done
to
try
and
address
this
and
to
sort
of
solve
this
properly.
As
for
us,
we
just
have
to
do
the
setup
in
like
a
pre
start
script.
B
A
A
Yet
there
are
some
missing
pieces
that
we
don't
quite
have,
but
actually
we've
been
able
to
reduce
privilege
a
lot
where
we
can
we're
breaking
apart
the
bits
where
we
can't
and
there's
just
this
fantastic
amount
that
we've
been
able
to
achieve
because
of
the
technologies
that
already
in
the
community
and
the
huge
amount
of
work,
that's
already
there,
so
we're
pretty
confident
that
we're
going
to
get
the
rest
of
the
way.
So
things
are
getting
better.
I
think
the
question,
that's
probably
never
one's
mind
is:
does
it
work?
A
A
You
can
try
out
right
now,
there's
if
you're
using
Cloud,
Foundry,
there's
just
a
flag,
experimental
route,
this
mode,
you
can
turn
it
on
and
it
should
just
work
we're
going
to
test
it
a
little
bit
more
before
we
do
that.
So
with
that,
thank
you
very
much
and
I
think
we
have
a
little
bit
of
time.
Is
there
any
questions.
A
A
So
the
question
is:
what
are
the
challenge
is
for
using
ruthless
mode
for
Network
namespaces
and
basically
we
can
create
the
network
namespace
without
needing
routes,
and
we
can
create
devices
in
the
network
namespace.
But
in
order
to
actually
route
out
anywhere
interesting,
you
need
to
be
able
to
configure
the
networks
on
the
host,
because
those
are
the
ones
that
actually
have
a
real
cable
plugged
in
and
you
need
routes
to
configure
those
and
then
move
a
V
F
pair
into
the
container.
At
the
moment,.