►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Seccomp Security Profiles and You: A Practical Guide - Duffie Cooley, VMware
Have you wondered what a seccomp security profile is, and how it relates to Linux Capabilities? Folks often dismiss seccomp profiles and Capabilities as a way of hardening applications as it is too difficult to determine what syscalls are in use by a given application. In this session we will explore a couple of tools designed to make this more approachable. Dockersl.im is an opensource project that can take a Dockerfile and an image and produce a smaller image containing only the necessary bits, a seccomp security profile derived from the system calls the application made while under test. Inspektor Gadget is an opensource project by the folks at kinvolk that enables to make use of BPF to inspect a number of things about pods that are deployed. Providing better visibility into what pods are accessing from a syscall and filesystem perspective. Come learn about these super powers!
https://sched.co/ZetL
A
A
So
I
am
a
staff
cloud
native
architect
at
vmware
and
I've
been
working
with
kubernetes
since
about
2016..
I've
worked
at
a
few
companies
that
are
really
interested
in
the
space,
obviously
core
os
heptio
and
I'm
now
at
vmware
every
week.
I
I
work
on
a
couple
of
different
things
to
kind
of
get
the
word
out
about
the
cloud
native
stuff
in
general.
One
of
them
is
tgik.io.
A
You
can
go
there.
Fridays
at
one
o'clock
and
kind
of
interact
with
us
live
and
help
us
and
explore
all
kinds
of
cool
stuff
happening
in
the
ecosystem.
Today
and
then
the
podlist
is
a
audio
podcast
with
a
bunch
of
really
amazing.
Co-Hosts,
definitely
check
it
out
if
you're
interested
in
understanding
more
about
what's
happening
in
the
e-cloud
native
ecosystem
or
just
you
know,
staying
up
to
date,
you
can
find
me
anywhere
at
maui
lion,
so
cube
slack
twitter
whatever.
A
A
So
a
container
is
an
interesting
construct
because
it
is
effectively
a
process
and
when
we
containerize
a
process,
we
create
a
container
so
in
the
linux
kernel
every
process
is
effect
has
effectively
makes
the
use
of
these
same
primitives
and
if
we
just
look
through
them,
real
quick
they'll
start
to
make
sense
to
us
right.
So
we
have
a
c
group.
A
A
A
If
I
were
to
give
net
admin,
which
is
the
ability
to
manipulate
network
devices
and
change,
routing
tables
and
all
kinds
of
stuff
like
that,
I'm
actually
only
giving
the
that
access.
When
I
grant
that
capability,
I'm
only
giving
that
access
to
the
to
the
network,
namespace
that
the
process
is
associated
with
or
set
a
different
way,
the
network
name
space
that
the
container
is
running
in.
A
Now
I
was
talking
about
net
admin.
Let's
talk
a
little
bit
about
what
these
things
are
right.
So
back,
I
look
back
for
for
a
very
long
time
when
we
considered
the
permissions
model
of
of
most
unix
systems,
there
was
kind
of
it
was
like
it
was
all
or
nothing
right.
It
was
either
that
you
were
root
or
you
were
not
root
and
you'll
see.
There's
lots
of
vestiges
of
this
still
around.
This
is
still
pretty.
A
This
is
still
pretty
normal
for
the
implementation
of
users
within
analytic
system,
and
so,
when
you
ssh
into
a
linux
system
as
a
regular
user,
you
might
see
that
you
are
you're
not
root
and
that
we're
able
to
secure,
like
the
devices
that
the
that
the
node
has
access
to
we're
able
to
secure
things
behind
a
permission
set
and
if
you
wanted
to
say,
create
a
new
directory
outside
of
your
home
directory.
You
needed
to
escalate
your
user.
A
You
need
to
escalate
your
privileged
by
sudoing
to
root
or
doing
something
like
that.
Well,
we
have
since
kernel
2.2.
We
have
a
bunch
of
other
things
that
we
can
do
right,
specifically
we're
going
to
dig
into
capabilities
in
setcomp
here,
so
capabilities
are
a
way
of
granting
like
kind
of
a
chunk
of
access
to
a
process
and
we're
going
to
talk
about
them
a
little
bit
more
here
and
and
they're
granted
on
a
per
thread
basis.
So,
just
like
I
said,
containers
are
basically
process
isolation.
A
So
let's
take
a
couple
of
these
and
just
kind
of
compare
them
like
we
said
before
the
capnet
admin,
one
right
that
gives
us
the
ability
to
manipulate
network
interfaces
and
routing
tables
and
dump
ip
tables
and
do
kind
of
stuff
and
do
all
the
all
that
kind
of
stuff.
So
anything
with
the
word.
Admin
has
quite
a
lot
of
privilege,
but
in
a
container
context,
usually
it's
just
the
network
name
space
that
the
container
sees
now.
If
you
had
hostnet
turned
on,
that
would
be
the
and
you
granted
net
admin.
A
That
would
mean
that
you
could
really
manipulate
the
network
interfaces
of
the
underlying
node
interesting
stuff.
Another
one,
that's
really
important
is
a
capsis.
Boot
gives
you
the
ability
to
reboot
the
node
and
capsis.
Admin
is
probably
the
most
scary
of
all
of
these
capabilities,
because
capsis
admin
is
like
all
the
things
right.
A
Capsis
admin
is
effectively
root,
so
when
you
grant
capsis
admin
to
a
container
which
you
should
probably
never
do,
you're
giving
that
container
like
root
access
to
any
of
the
namespaces
that
it
has
access
to,
and
so
there's
I've
been
some
pretty
interesting,
exploit
exploits
associated
with
capsis
admin.
So,
if
you're
interested
in
that
kind
of
stuff
definitely
check
that
out,
so
we've
introduced
capabilities
and
we've
talked
a
little
bit
about
what
they
are
they're
a
way
of
like
granting
like
a
chunk
of
permission
to
a
given
process.
A
And
so
here
we
have
a
pod,
a
pod
spec
we're
gonna,
create
like
the
node,
hello
container,
I'll
run
it
as
a
pod
and
inside
of
the
security
context,
which
is
part
of
the
pod
api.
We're
going
to
grant
capabilities,
we're
going
to
grant
netadmin
and
system,
and
that
means
that
when
this
container
starts
up,
it's
going
to
have
its
own
network
namespace,
which
is
the
default
within
kubernetes
and
with
netadmin
it'll,
be
able
to
manipulate
the
interfaces
in
there.
A
It'll
be
able
to
manipulate
the
route
table,
it'll
be
able
to
manipulate
ip
tables
all
that
good
stuff
by
default.
Netadmin
is
not
granted
to
a
pod,
but
when
we
add
capabilities
we
can
add
that
capability
in
we
can
also
drop
capabilities
right.
We
could
do
kind
of
a
drop,
all
capabilities
and
then
just
add
specific
ones
that
we
know
the
application
needs.
But
these
are
really
kind
of
broad
sweeps
of
permissions
right,
there's
big
chunky,
stuff
that
we're
granting
access
to
so
grant
so
capability
to
grant
access
to
stuff.
A
But
it's
like
big
stuff,
like
capsus
admin
or
capnet
admin.
That
kind
of
stuff
setcomp
is
an
interesting
one,
and
it's
and
it's
it's
a
little
more
granular
than
what
capabilities
grant
right.
So
capabilities,
grant
you,
like
a
permission
or
access
to
kind
of
a
big
chunk
of
permission.
Setcomp
can
work
in
a
different
way.
Suck
comp
can
be
used
in
an
allow
list
or
deny
list
option
or
both
at
the
same
time
and
the
in
the
both
models.
Actually,
I
think,
probably
the
most
interesting
one
of
the
bunch.
A
Against
the
linux
kernel
now,
the
challenge
is
that
you
need
to
like
understand
what
system
calls
that
application
is
going
to
make
and
that's
not
trivial.
There
are
345
system
calls
in
the
x8664
architecture
as
of
kernel
5.8,
and
we
need
to
determine
for
any
given
application.
What
system
calls
are
being
used
or
being
made
now
before
we
get
into
like
how
to
determine
that?
Let's
look
at
some
interesting
hacking
tools,
all
right
so
like
this
is
one
that
this
is
a
project
that
was
put
out
by
jessie
frizzell.
A
It's
called
amma
contained,
and
it
gives
us
a
really
good
kind
of
introspection
into
how
into
the
permissions
that
have
been
granted
to
the
process
running
inside
of
our
container
right.
So,
let's
kind
of
check
out
what
happens
here
so
in
docker
other
work
by
jesse
and
a
bunch
of
other
folks
at
docker.
A
They
built
a
kind
of
a
default
set
comp
profile
that
could
be.
That
would
be
loose
enough
to
allow
most
applications
to
run
inside
of
a
container
but
tight
enough
to
kind
of
block.
Some
of
the
really
important
syscalls
that
you
wouldn't
necessarily
want
to
run
from
inside
of
a
container
by
default
right,
and
so
let's
take
a
look
at
that.
That
list
real
quick
right.
So
we
have
a
capabilities
list:
we're
granting
chone
deck
override
if
owner
set
pcaps.uid
these
sorts
of
things
we're
grabbing
netra
we're
grabbing
netbind
service.
A
This
is
an
interesting
capability
set
because
netbind
service
allows
you
to
bind
a
port
that
is
lower
than
1024,
so
like
port
80
or
port
443.
If
you
don't
have
that
capability,
you
won't
be
able
to
bind
those
things.
You'll
only
be
able
to
find
high
ports
and,
as
you've
ever
run,
docker
run
nginx.
You
don't
have
that
problem,
and
this
is
why
right
we're
granting
that
bind
service
and
then
down
below.
A
Would
you
want
to
be
able
to
allow
for
somebody
to
like
run
a
container
and
run
reboot
inside
of
that
container
and
have
it
reboot
the
node
right
I
mean
there
might
be
use
cases
where
that
makes
sense,
but
it
wouldn't
be
all
of
them,
so
you've
got
to
really
watch
out
for
those
things
right.
So
these
are
the
these
are
the
blocked
syscalls
that
are
implemented
by
docker's
default
setcomp
profile.
A
A
So
why,
mostly
it's
an
implementation
detail
of
multiple
containers
in
a
pod?
Each
pod
has
at
least
two
containers,
an
infra
or
pos
container,
and
the
containers
that
you
define
and
the
pause
container
handles
shared
things
like
network
name
spaces
and
those
sorts
of
things
and
and
so
by
default.
We
were
kind
of
granting
more
and
more
privilege
to
that
construct
and
that's
not
such
a
great
thing.
So
what
do
right
like?
What
do
we
do
here?
A
So
it's
a
pretty
good
model
and
then,
after
119
we're
going
to
talk
a
little
bit
more
about
the
future.
Here
we
changed
that
api,
so,
instead
of
having
to
specify
it
as
an
annotation.
Now
it's
a
first
class
thing
inside
of
the
pod
and
container
spec
and
you
and
you
have
that
capability
to
set
that
inside
of
the
security
context,
the
second
profile
and
what
type
you
can
set
that
type
to
localhost
and
use
like
one.
A
A
So
let's
go
back
and
look
at
that.
Kubernetes
pod
without
runtime
default
enabled,
and
we
see
that
there
are
only
22
blocked
system
calls
and
then
after
enabling
runtime
default,
we
have
67
block
system
calls
right.
So
all
we
did
was
specify
runtime
default,
which
is
a
built-in
setcom
profile.
We
got
67
block
calls
and
things
are
still
able
to
operate
so
definitely
check
that
out.
It
greatly
increases
the
security
of
your
of
your
runtime.
A
Why
is
this
stuff
important,
though
like?
Why?
Why
would
you
even
do
it
like?
What's
the
point
right,
so
there
are
a
bunch
of
different
attacks
against
containers
that
are
interesting.
Some
of
the
more
obvious
ones
are
the
supply
chain
attacks
right
like
if
you
have,
if
you
have
folks
just
deploying
images
into
a
kubernetes
kernel,
where
are
those
images
coming
from?
Are
they
coming
from
docker
hub?
Are
they
coming
from
a
trusted
source?
A
Were
they
built
and
were
they
validated
against,
like
cbe
lists
and
those
sorts
of
things
supply
chain
attacks
are
kind
of
like
a
really
a
juicy
bit
of
attack
surface
for
contain
for
container
orchestration
systems.
Another
one
is
exploitation,
application
bugs
this
one's
been
around
forever
right
if
you're
running
an
application
and
you
expose
it
to
the
internet.
If
somebody
figures
out
how
to
get
it.
Pat,
you
know
to
exploit
like
perhaps
like
a
reverse
tunnel,
or
something
like
that
once
they
do,
that,
can
they
get
a
shell
right?
A
Did
somebody
who
was
creating
the
image
leave
a
bath
shell
behind
and
if
they
did
sweet
right?
The
attacker
now
has
a
bash
shell
to
explore
what
else
they
can
do
against
that,
given
linux
kernel
or
against,
or
just
you
know,
figuring
out
how
to
do
other
attacks
on
other
containers
and
then
the
last
one
is
really
what
we're
here
to
protect
right,
syscalls
and
the
shared
linux
kernel.
Remember
that
containers
are
process
isolation.
A
A
So
the
the
the
obvious
next
question
is
like
what
cis
calls
are
being
used
like
what.
So,
if
I
were
going
to
create
a
second
profile
that
was
a
little
more
specific
right,
then
I
wouldn't
kind
of
need
to
know
what
syscalls
were
being
used
so
that
I
could
define
that
second
profile
and
we're
going
to
kind
of
go
through
some
examples
of
this
in
the
demonstration
here.
A
So
one
way
to
finding
that
out
is
by
leveraging
the
s
trace,
command
right
and
so
in
this
example,
I'm
actually
running
the
curl
curl
ss
google.com
and
I'm
grabbing
the
syscalls
that
are
being
used
by
that
process
right.
So
this
is
one
way
of
doing
it
and
it's
a
pretty
handy
way.
There
are
a
bunch
of
projects
out
there,
including
docker
slim,
which
is
actually
really
trying
to
solve
this
problem
amongst
a
bunch
of
others.
A
Docker
slim
gives
you
the
ability
to
minify
a
container
and
basically
only
mix
like
reproduce
that
container,
with
only
the
content
of
that
container
that
was
tested
against
right.
So
if
you
bring
up
a
container
and
it's
like
an
nginx
container,
you
would
test
to
make
sure
that
you're
able
to
like
curl
against
that
nginx
container,
that
sort
of
stuff
and
then
that
would
actually
result
in
a
minified
container,
getting
rid
of
everything
in
the
in
the
container
that
you
don't
use,
and
it
can
also.
You
can
also
use
docker
profile
against
the
container.
A
Even
if
you
don't
want
to
slim
it
right,
even
if
you
don't
want
to
go
through
the
process
of
like
reducing
the
size
of
it,
you
can
just
profile
it
and
it
will
actually
output
a
second
profile
and
a
selinux
profile
and
also
a
app
armor
profile.
So
it's
a
great
way
of
learning
like
what
you
need
to
customize
or
create
that
custom
profile.
A
So,
let's
get
into
our
demonstration,
we
don't
have
too
much
time
left
for
about
18
minutes,
let's
kind
of
get
into
the
demonstration
here.
So
my
demonstration
is
going
to
play
a
little
bit
with
the
future.
I'm
going
to
show
you
what's
going
to
happen
in
119,
which
will
be
pretty
exciting.
It's
right
around
the
corner,
but
the
demonstration
environment
also
has
like
what
it
looked
like
for
118.,
so
we're
going
to
kind
of
play
a
little
bit
with
the
future
we're
going
to
play
with
some
other
interesting
projects
in
space.
A
A
So,
first,
if
you're
gonna,
if
you're
interested
in
this,
you
can
go
to
docs.kh.io
look
into
the
tutorials
under
the
cluster
section
and
there's
a
new
piece
that
was
just
put
up
by
daniel
mungum.
It's
not
merged
with
mainline
yet,
but
it
will
be
in
the
very
next
release.
119,
that's
called
restrict
a
container
system
syscalls
with
setcomp,
and
it
takes
you
through
an
entire
profile
about
how
to
do
this
stuff.
It's
great
documentation.
A
I
I
can't
say
enough
about
about
that
work
and
like
what
the
whole
team,
sasha
gonna,
daniel
man,
gum
and
polygram
are
doing.
It's
amazing
right.
It's
really
great,
to
see
kind
of
the
improvement
in
the
way
that
we
do
these
things.
So
here's
our
kind
cluster
I've
gone
ahead
and
brought
it
up.
I've
got
three
worker
nodes
and
one
control
plane,
though
so
cube
kettle
get
pods.
A
We've
got
all
good
nodes.
We
can
see
that
we're
running
119
here
and
that
we
have
three
workers
and
one
control,
plane,
node,
and
so
the
the
next
thing
I'm
going
to
do
is
I'm
going
to
go
ahead
and
start
up
a
couple
of
containers,
but
what
we're
going
to
explore
here
is
some
sitcom
profiles.
So
let's
go
do
that
first
right.
So
here
are
some
demonstration
second
profiles
and
I'm
going
to
take
you
through
a
couple
of
them.
A
A
It's
also
really
helpful
in
diagnostics
and
stuff,
when
you're
trying
to
figure
out
like
how
what
worked
and
what
didn't
right.
So,
let's
take
a
look
at
the
fine
grained
one.
This
is
an
example
second
profile
that
does
sort
of
what
we
were
talking
about
before.
So
we
have
a
default
action.
That
is
a
block
right,
scmp
act,
error
number
means,
don't
allow
anything
and
then
down
here
we
have
a
group
of
syscalls
by
name,
and
here
are
all
the
syscalls
that
we're
allowing
and
then
we're
and
then
for
those
syscalls.
A
We
have
an
action
of
scmp
activity
allow,
and
that
means
that,
as
long
as
the
process
is
living
within
the
means
of
this
set
of
syscalls,
then
the
process
will
be
allowed
to
run,
but
if
it
tries
to
make
any
cis
calls
outside
of
this,
it
will
be
denied
and
likely
bad
things
will
happen.
It
might
die,
I
might
do
all
kinds
of
wacky
stuff
and
then
the
last
one
is
the
violation
json,
and
this
one
is
basically
a
explicit
deny
right
the
default
action.
A
One
liner
is
a
scnm
scmp
act
error,
no,
which
means
deny
all
syscalls
all
of
them.
That's
our!
That's
part,
that's
our
explicit
deny
that
we
see
in
the
top
of
the
custom
one
all
right,
let's
go
ahead
and
get
these
things
deployed.
The
way
we're
going
to
do
that
is
we're
going
to
actually
deploy
the
setcomp
operator.
Isn't
that
project
sigs
dot
k
is
to
I
o.
A
This
is
going
to
create
us
a
namespace,
it's
going
to
create
service
accounts
and
role
bindings,
that
kind
of
stuff,
and
then
we're
also
going
to
go
ahead
and
deploy
a
config
map
that
has
those
that
has
those
those
different
profiles
within
it
and
that's
the
demo
profiles
diamond.
So
let's
go
ahead
and
deploy
that
apply.
Dash,
f
profiles,
demo
profiles
and
then,
let's
take
a
look
at
that
one
last
thing
there.
So
what
I'm
looking
at
here
is
a
config
map
is
scheduled
to
be
in
the
namespace
seccomp
operator.
A
It's
called
demo
profile
and
then
inside
of
there
we
have
a
few
different
files,
or
we
have
representations
of
those
three
files
that
we
saw
right,
the
audit.json,
the
fine
grained
one
and
then
there's
our
violation.json
right.
So
those
three
files
are
being
are
now
represented
inside
of
this
config
map
and
the
way
the
operator
works
is
it's
going
to
actually
persist
those
files
to
disk
inside
of
var
lib,
cubelet
setcomp,
and
that's
actually
where
we
can
reference
them
from
within
our
pods.
A
Okay,
first,
I'm
going
to
go
ahead
and
dip
these
two,
because
I
want
you
to
understand
the
difference
here
like
we
talked
about
before
in
118.
This
is
how
I
would
reference
a
given
a
a
profile.
The
runtime
default
is
the
built-in
one
so
that
one's
not
super
interesting
for
our
output.
But
how
about
this
one
here
right?
So
here's
our
second
profile
for
the
pod
and
we're
actually
specifying
localhost,
which
in
this
context,
means
on
the
local
node
and
then
cubelet
right
so
var,
lib,
cubelet,
setcomp,
slash
operator,
demo
profile
find
grain.json.
A
That's
where
we
can
find
that
file
and
we
can
go,
look
and
see
if
it's
there,
but
in
119
and
after
once
it's
actually
a
stable
api.
Then
we
can
perf.
Then
we
can
provide
it
like
this
right.
So,
instead
of
actually
using
this
annotation
model,
we
can
just
specify
that
in
the
spec
for
the
for
the
pod,
which
is
great
all
right,
let's
go
ahead
and
get
this
done.
A
A
A
This
is
our
fine
grain
pod,
and
this
one
is
a
little
different.
Alright,
the
fine
grain
pod
is
actually
running
our
echo
server.
This
was
actually
written
by
mario
lauria.
It's
a
great
little
tool
that
allows
us
to
kind
of
interact
with
the
cluster.
So
let's
go
ahead
and
see
if
this
one
runs
right.
So
this
one
I've
actually
listed
a
very
specific
set
of
syscalls-
is
my
application
able
to
live
within
that
construct
right?
So
if
we
do
cube
kettle
expose.
A
And
then
what
this
will
do
is
it'll,
create
up
a
get
request
and
I'll
proxy
it
through
to
the
pod
using
the
api
server,
and
so
it
looks
like
things
are
working
right
like
I
can
actually
get
results
back
from
this
echo
server.
Pretty
neat
tool
gives
me
the
ip
address
of
the
requesting
ip
shows
me.
Headers
shows
me
the
environment
inside
of
the
running
pod.
It
shows
me
the
resolve.com,
it's
actually
pretty
handy
and
it's
built
by
mario
laureate.
I
really
like
it
a
lot.
A
A
A
Describe
pod
violation
pod,
you
can
see
that
it's
restarting
and
restarting
and
restarting
it's
not
great
output
from
the
logs
yet
on
this
kind
of
stuff.
But
it
is
telling
me
that
the
process
died
inexplicably,
and
I
know
that
the
reason
is
because
it
can't
make
any
system
calls,
and
so
it's
not
a
great
ux
yet,
but
we're
working
on
it.
We're
trying
to
make
it
better.
So
yeah,
okay,
shout
outs,
come
see.
A
Ian
coldwater
and
I
present
at
security
day
shout
out
to
the
community
behind
the
kind
project,
the
magnificent
mr
daniel
mangum,
who
really
helped
me
with
this
particular
demonstration,
the
amazing
paula
gomez
and
the
incredible
sasha
gunner.
Thank
you
very
very
much
and
thank
you
for
watching
and
giving
feedback
here
are
the
references
for
all
the
projects
and
things
that
I'm
looking
at,
including
the
seccomp
and
kubernetes
articles
that
were
written
by
pablo
definitely
check
those
out.