►
From YouTube: Entitlements: Understandable Container Security Controls - Justin Cormack & Nassim Eddequiouaq
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).
Entitlements: Understandable Container Security Controls - Justin Cormack & Nassim Eddequiouaq, Docker (Intermediate Skill Level)
In this talk, Justin Cormack introduces a new system of security entitlements for container workloads. These specify the types of access a pod should have in a human readable way. He will also demonstrate an example implementation running in Kubernetes. The current pod security configuration is very low level, and does not really make any sense to users of the system. How can we make security configuration understandable? One route comes from the model of application entitlements that Apple uses on the iPhone to control things like access to Push Notifcations and Payments. The open source libentitlement library, being developed at Docker, enables similarly high level controls to be used for managing containers. The talk will also cover the relationship with Open Policy Agent and other access control frameworks, and relation to Linux Security Modules and PodSecurityPolicy.
About Justin
Justin is a Senior Software Engineer at Docker, working on security. He is based in Cambridge, UK. He is a maintainer of the Moby engine and LinuxKit, and has worked across many open source container projects. He was involved in the work to include Kubernetes in Docker for Mac. He has been to Kubecon twice before. He spoke at KubeCon EU last year on Containerd https://www.youtube.com/watch?v=cfhnioURGdE and has spoken at many events: Devoxx, Codemotion, CodeMesh, DockerCon, QCon and more.
About Nassim
Nassim is a security engineer at Docker where he focuses on designing and creating new security features for the container ecosystem and making existing ones as usable as possible. Nassim previously spent a couple of years working on hobby kernels and reverse-engineering competitions before interning in the Trusted Execution team at Apple.
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
Okay,
welcome
everybody,
I'm
Justin
come
back.
This
isn't
an
assumed.
We
work
in
the
Security
Perlman's
at
docker,
and
we
can
talk
about
making
security
controls
understandable
so
that
users
can
actually
work
out.
What's
going
on
with
security
container
security
is
often
viewed
as
a
really
kind
of
complicated
subject.
A
sort
of
maze
of
difficulty
and
and
we'd
like
it
to
be
kind
of
something
security,
should
be
something
simple
like
just
putting
your
finger
on
your
iPhone
to
unlock
it.
A
A
You
have
all
these
different
security
controls
in
containers
and
you
may
have
you
know,
come
across
them
in
the
documentation,
and
maybe
you
know
what
they
are,
and
maybe
you
understand
what
one
or
two
of
them
do
and
maybe,
but
it
it
takes
a
lot
of
effort
to
actually
understand
in
detail
what
they
all
are.
And
so,
if
you
ask
your
developer,
make
sure
your
container
is
securely
configured.
They
don't
really
know
how
to
apply
all
those
controls
to
it.
A
I
mean
these
are
the
these
are
the
this
is
the
help
page
for
docker
run,
and
it's
just
got
a
ridiculously
large
number
of
options.
There's
a
comment
on
I
think
on
the
LS
man,
page
and
Linux,
saying
bugs
has
too
many
command
line
options,
and
this
kind
of
has
almost
that
many,
and
so
you
know
you
get
into
the
details
of
what
capabilities
are
capabilities,
for
example,
are
different
ways
of
dividing
up
the
root
permissions,
the
permissions
of
the
root
user,
so
you
can
make
more
fine-grain
control.
A
A
A
Namespaces
are
the
pieces
which
we
make
containers
out
of
and
then
cut
down.
What
you
can
actually
see
inside
of
container
and
what
what
names
you
can
reach
again,
they're
like
seven
or
eight
of
them,
and
they
they're
kind
of
complicated
to
understand
and
deal
with,
and
it's
very
unclear
for
a
general
user
what
the
security
properties
are,
and
there
are
some
combinations
of
capabilities
and
namespaces
that
will
let
you
escape
from
a
container
and
other
ones
don't
set
comp.
A
If
you
look
at
the
docker
set
comp
policy,
which
we
spent
a
lot
of
time
working
on,
it's
a
very,
very
large
JSON
file,
or
that
is
extremely
long
and
it
could,
it
could
usefully
do
with
being
even
more
complicated.
But
for
various
reasons,
it's
it's
not.
But
it's
very
difficult
to
write
and
people
who
try
and
modify
it
soon
get
very
frustrated.
A
No
so
and
then
you
can
say
well,
I'll
just
use
my
privilege,
because
that
works
for
everything.
That's
perfect
and
that's
really
not
ideal,
so
that
the
aim
of
this
kind
of
dogger
to
come
up
with
it
talk
about
some
proposal
for
doing
this
in
a
better
way,
and
that's
is
going
to
talk
through
some
details-
have
a
quicker
yeah.
B
B
You
have
to
make
sure
that
the
the
the
the
users
focus
on
what
makes
sense
at
their
level
right.
They
don't
need
to
understand
the
kernel
and
the
kernel
constructs
and
how
the
namespaces
interact
with
such
capability,
because
someone
did
a
hack
in
the
kernel
at
that
point.
And
people
don't
care
about
that.
People
want
to
make
sure
that
their
app
is
secure
and
that
they
can
easily
explain
why
they
decided
to
create
such
security
profile
for
the
wrap.
So
we
decided
to
divide
that
these
permissions
into
resources
or
domains
that
make
sense
for
end-users.
B
So,
basically
the
network
should
the
network
access
be
completely
confined.
Does
my
container
of
had
need
to
two
very
simple,
like
user
type
of
of
network
access?
Is
it
an
a
proxy?
Is
it
a
full
admin,
same
thing
for
security
and
also
same
thing,
for
host
resources
so
devices,
for
example,
and
yeah?
That's
basically
it
you
should
have
to
to
choose
between
a
very
simple
set
of
permissions.
B
B
The
the
the
thing
that
is
going
on
behind
the
scene
is
as
simple
as
you
would
expect,
is
basically
the
job
of
the
platform
to
to
handle
all
the
translation.
Making
stuff
simple
is
the
work
of
is
basically
the
work
of
people
who
work
on
humanity's
darker,
the
different
the
different
runtimes
abstracting,
the
obstructing
the
the
complex
stuff
is
the
the
is
not
the
the
role
of
the
the
user
themselves.
B
So
behind
the
scene,
when
a
user
will
say
hey
I
want
my
I
want
my
container
or
pod
to
be
completely
confined
so
makes
more
sense
for
for
a
container
you
would,
you
would
actually
enforce
at
the
second
level,
which
is
a
Cisco
firewall.
Basically,
you
would
want
you
to
prevent
any
operation
on
network
sockets,
but
making
sure
that
the
the
unique
socket
still
works.
B
So
you
can
actually
do
regular
actions,
making
sure
that
the
apparmor
profile
adds
restrictions
on
the
the
network
capabilities
same
thing
at
the
kernel
capability
level,
tuning
the
the
pass,
the
the
path
that
contained
that
the
container
has
access
to
and
so
on.
There
are
various
things.
Of
course.
This
depends
on
the
the
Linux
security
modules
that
are
supported
and
various
things,
but
it
should
be
the
work
of
the
platform
to
to
make
it
completely
abstracted
for
the
end
user
same
thing
for
an
admin,
an
admin
is
basically
a
network.
B
But
there
is
actually
more
to
do
because
the
the
you
can
provide
the
user,
some
some
simple
set
of
permissions,
but
we
should
also
leverage
the
knowledge
that
the
developers
have
on
the
application
that
they
are
creating
right.
So
they
can
pass
along
information
to
the
people
to
the
operations,
people
who
are
going
to
run
that
into
production.
B
So
here
it's
darker,
build,
but
any
any
image
builder
and
the
image
designer
should
do
the
trick.
Basically,
if
you
take
your
image
and
the
list
of
entitlements-
and
you
bake
that
into
you-
create
a
bundle
that
hides
the
two
together,
you
actually
get
a
an
image
with
its
own
security
profile
that
is
independent
from
the
from
the
the
underlying
machine.
B
If
you
decide
to
sign
that,
you
actually
get
a
trusted
bundle
that
content
publisher
can
actually
deliver
to
the
air
to
the
end-users,
because,
for
example,
if
I
want
to
run
nginx
with
the
with
the
the
best,
the
best
sound
boxing
environment
Ingenix
people
are
certainly
the
the
best
people
to
actually
do
that.
They
have
all
the
knowledge
about
what
is
going
on
behind
the
scenes
inside
the
application
and
I
would
want
to
run
the
application
with
the
best
advertised
security
configuration
possible.
B
B
B
B
You
pull
your
you
pull
your
trusted
bundle
and
you
get
instantly
the
best
protection,
the
expertise
by
the
by
the
content,
publisher
and
also
the
support,
because
if
there
is
any
vulnerability
that
that
shows
up
in
your
in
your
application,
also
I
also
don't
want
you
to
go
monitor
every
single
vulnerability
I
would
want.
I
would
want
the
the
content
publisher
to
take
care
of
updating
the
the
security
profile
for
me
in
order
to
block
the
inner
ability,
if
possible.
B
So
key
goals
of
this
is
basically
providing
the
best
user
experience
possible.
This
is
really
the
goal
number
one.
We
need
to
make
sure
that
people
use
the
the
the
security
options
available
and
we
want
the
observe
the
the
end-user
not
to
opt
out
of
the
security
configuration
if
this,
if
they
get
a
permission
denied
for
some
reason
during
running
the
application,
we
also
need
to
empower
the
the
the
people
who
write
the
application
themselves
right.
They
had
the
knowledge
on
the
application.
B
We
need
to
provide
them
a
way
to
easily
understand
what
are
the
permissions
that
they
can
hand
over
to
the
people
who
are
going
to
run
to
deploy
that
in
production
and
maintain
that,
if
possible,
we
would
like
to.
We
would
like
to
create
a
standard
that
would
be
widely
adopted
so
that
all
the
platforms
and
all
the
that
supports
all
the
platforms.
B
All
the
operating
systems
out
there
so
yeah,
basically
kubernetes
swarm
any
other
scheduler
that
people
want
to
want
to
create
that'd
be
great
if
we
were
to
actually
provide
security
profiles
along
with
images
that
can
run
on
any
single
platform
and
would
be
translated
into
low-level
bit
the
way
the
platform
understand
them
and
yeah.
We
really
want
to
make
sure
we
ditch
at
some
point
the
privilege
flag,
because
this
is
this-
is
really
a
bad
habit.
B
Yeah.
It
basically
disables
most
of
the
most
of
the
the
sandboxing
that
you
that
you
create
around
the
container
and
it
leaves
the
the
packaging,
the
packaging
feature
and
a
few
security
guarantees,
but
pretty
much
everything
else
is
disabled.
Also,
security
is
often
about
least
privileged
principle.
You
want
to
give
the
list
the
smallest
amount
of
privileges
that
an
application
needs
in
order
to
run
properly
right,
and
this
is
not
the
case
currently.
Currently,
everyone
runs
with
defaults
that
work
for
ninety
eight.
B
Allowing
sis
calls
that
are
not
used
by
by
applications
access
to
the
paths
in
the
file
system
that
are
that
shouldn't
be
needed
in
plenty
of
application.
This
is
really
something
that
needs
to
be
fixed
and
yeah.
We
need
to.
We
need
to.
We
need
a
way
to
create
actual
security
profiles,
along
with
images
that
we
can
hand
over
to
people
who
want
to
adopt,
and
that
might
be
scared
about
the
security.
B
B
Api
access
control
and
service
to
service
communication
control,
basically,
maybe
providing
a
way
to
say,
hey
this
this
this
container
or
this
service
should
only
be
able
to
talk
to
these
kind
of
services
the
same
way
as,
for
example,
on
iOS.
You
can
say
this
app
has
the
right
to
talk
to
only
these.
These
demons
yeah,
basically
the
ID
to
have
the
idea
directly
inside
the
security
profile.
Information
on
which
service
does
your
app
has
the
right
to
talk
to
yeah
if
you
have
any
additional
IDs.
This
is.
B
This
is
still
a
very
open
discussion
and
everyone.
We
need
everyone
to
participate
to
make
the
the
better
out
of
the
environments
so
who's
down
for
a
quick
demo.
No
everyone
here,
sleeping,
okay,
so
I'm!
Sorry,
we
didn't
have
time
to
have
it
work
on
Cuba
notice,
so
it's
gonna,
be
it's
gonna,
be
on
docker
and
we
needed
to
we
needed
to
actually
implement
that
inside
darker.
B
First
four:
in
order
to
provide
the
base
name
mechanism,
basically
for
for
Cuban
itis
in
our
own
environment,
so
we'll
try
to
run
our
nemesis,
which
is
a
darker
and
darker
darker
and
darker
needs.
A
lot
of
privileges
accessing
security,
filesystem
mounting
the
C
groups
having
privileged
access
to
to
the
interfaces
various
level
of
privileges.
This
translates
into
if
I,
if
I
were
a
developer,
writing
the
darker
and
darker
I
would
need
Network
admin,
because
I
know
that
I
do
sensitive
work
on
the
network
security
admin
because
I
need
an
admin.
B
B
B
B
B
Yeah
sorry
helping
people
that
was
it
against
you
and
yeah.
So
here
we
are
inside
the
ADL
time
inside
the
darker
and
darker,
and
now
we'll
just
run
a
doctor
update
just
to
see
yeah.
We
can
fetch
everything
so
yeah,
that's!
Basically
we
have
the
we
had
network
capabilities
inside
the
the
container.
Everything
is
working
red
and
we
didn't
have
to
actually
disable
all
these
second
profiles
or
the
upper
normal
profiles
and
everything.
B
So
now
we're
going
to
switch
to
the
second
part
of
the
the
the
the
proposal,
which
is
basically
building
an
image
with
the
entitlements
inside
it
so
that
end
users
can
actually
run
a
container
without
we
specified
all
the
all
the
security,
the
security
stuff
again.
So
if
we
inspect
the
image
that
we
just
created
by
the
way,
the
images
just
from
darker
and
darker.
B
Okay
sounds
good,
so
yeah,
it's
basically
the
idea
and
as
an
end,
user
I
would
just
pull
the
the
image
the
trusted
image
and
run
it.
So,
of
course,
you
should
have
a
way
to
specify
if
you,
you
are
trusting
this
content
publisher
but
yeah.
The
idea
is
I,
don't
want
to
run
I,
don't
wanna
dive
into
the
documentation,
etc.
Everything
is
provided
by
the
darker
and
darker
people,
so
yeah,
that's
basically
the
the
ID
and
this
one
so
yeah.
This
is
this.
B
Is
the
the
exact
same
behavior
that
we
want
you
to
achieve
on
Cuba
notice,
so
making
sure
that
people
can
run
through
Cuba
CTL
that
in
deploying
pods
with
the
the
best
security,
the
best
security
configuration
right
away
yeah.
So
what
about
kubernetes?
Sorry,
cuban
'this
has
the
same
the
same
usability
issues,
the
the
security
features
from
the
the
from
the
security
context
and
the
part
security
policy
met
pretty
much
one
to
one.
B
B
Where
would
be
the
user
input
happen?
Basically,
it
would
most
likely
happen
either
through
the
security
context
itself.
That
would
be
that
would
be
extended
or
through
an
admission
controller
which
would
prevent
from
having
conflicts
basically
between
the
ii
profile,
that
is
provided
inside
the
degree
context
and
the
the
the
one
that
you
that
would
be
generated
from
the
the
environments
that
themselves.
B
Currently
in
docker,
it's
basically
keep
keep
security
options
in
the
form
of
environments
as
much
as
possible,
and
then
the
translation
in
to
low-level
bits
is
done
right
before
handing
over
to
continuity,
who's,
the
which
is
the
the
and
then
to
run
see
creating
the
container
basically
into
OCI
specs
again,
the
the
emission
controller
would
be
the
the
best
place
to
to
create
that
to
do
that.
So,
if
you
have
any
opinion,
feel
free
to
share
your
your
opinion
on
the
lib
entitlement
repository.
A
Yeah,
so
we've
got
a
bit
of
work
to
do
to
integrate
in
skipping
this
one
took
a
little
bit
about
some
of
the
kind
of
the
pain
points
as
well.
I
mean
I
think
that
there's
still
a
bit
of
work
to
do
to
define
standards
and
working
out
kind
of
how
things
how
different
rules
work
together.
There's
a
particularly
set
comp
is
a
real
pain
to
work
with
to
do
complicated
policy,
stuff
and
II
BPF
based,
learn.
A
Security
modules
are
something
that's
been
talked
about
for
quite
a
long
time
and
actually
would
make
it
much
easier
because
you
can
you
get
a
lot
more
kernel
context
to
actually
make
security
policy
decisions
with
EPF,
because
you
get
to
know
things
like
what
file
you're
trying
to
open
and
what
your,
what
kind
of
file
descriptor.
You
are
working
on
things
like
that,
and
that
would
make
it
much
easier
to
deal
with
kind
of
conflicts
between
different
types
of
policy
that
want
to
restrict
the
same
system.
A
A
G
Weiser
was
announce,
obviously,
which
is
emulation
based,
but
the
thing
is
that,
while
it
locks
your
stuff
down
a
lot,
it
won't
actually
let
you
do
host
privilege
operations.
So
if
you
really
want
to
do
something
like
running
sidecars,
debugging
things
where
you
really
want
to
actually
control
stuff,
you
still
obviously
need
to
set
real
capabilities
and
run
real
stuff
and
and-
and
so
this
is
more
useful.
A
But
if
you
just
want
to
really
lock
things
down,
things
like
you
guys
are
all
really
restrictive
policies
of
what
you
want
open
policy
agent
is
a
really
nice
project.
If
you
haven't
looked
at
it
yet
there's
been
a
bunch
of
talks
today
over
the
last
few
days,
definitely
worth
looking
at.
We
were
it's
a
really
nice
way
of
writing
policies,
but
you
still
need
something
to
define
what
the
user
understandable
things
that
you're
going
to
write.
A
Those
policies
over
are
up,
but
it
would
be
nice
to
look
at
integrating
the
two,
because
it's
really
nice
framework
to
use
and
definitely
recommend
it
stuffs
in
the
repo.
Please
come
and
have
a
look
and
give
us
feedback
and
I
think
we've
got
a
little
bit
of
time
for
questions
Paul.
Just
very
briefly.