►
Description
Using a custom seccomp profile is one of the most recommended ways to increase the security of our Kubernetes workload. However, to be able to do that, we need to know all the system calls that our application uses during its whole life cycle, which is not a simple task.
By default, Kubernetes asks the container runtime to create a container using the `Unconfined` seccomp profile, meaning that seccomp is disabled. Such default behavior ensures that our application will run without problems, but it leaves the containers exposed to remote code execution vulnerabilities.
In this talk, we are going to show how to use Inspektor Gadget to identify all the system calls used by an application and how to generate a custom seccomp profile that ensures it will continue working as intended and with the exact privileges it requires.
A
A
First
of
all,
I
will
make
a
brief
explanation
about
what
second
is
and
how
it
was
integrated
in
kubernetes,
and
then
I
will
introduce
you,
the
spectre
gadget
tool
and
it's
a
com
gadget
and
finally,
I
will
make
a
live
demo
to
show
how
to
generate
your
own
second
profiles
with
inspector
gadget.
Let's
start
with
that
introduction.
A
Okay,
first
of
all,
second
stands
for
secure
computing.
It
is
a
linux
kernel
feature
that
allows
us
to
restrict
the
system
calls
a
process
can
do
so
by
blocking
the
system
calls
that
our
app
does
not
need.
We
are
ensuring
that,
if
everybody
is
able,
if
we
have
a
vulnerability
in
our
app
and
everybody
is
able
to
do
remote
code
execution,
they
will
not
be
able
to
do
just
whatever
they
want.
They
will
be
limited
by
what
our
application
is
able
to
do
what
we
allow
using
second
to
do
to
that
application.
A
A
Work
in
this
environment
will
be
pretty
difficult.
This
is
why
we
have
a
second
mod,
which
is
called
filter
in
this
filter
mode.
We
can
specify
what
we
want
to
do
for
each
system
call.
We
will
use
a
bpf
filter
which
will
give
you
a
result.
We
will.
We
will
configure
a
result
for
each
system
call
so
for
a
given
system
call.
We
will
unload
the
system,
call
or
kill
the
process
or
the
threat
that
send
that
issue.
That
system
call
or
restore
an
error
or
log.
We
have
many
options.
A
Now,
let's
see
how
it
was
integrated
within
within
kubernetes
in
kubernetes,
we
have
a
security
context
section
within
the
the
container
and
the
port
definition,
and
we
can
set
there
the
second
profile
that
we
are
going
to
use.
This
is
a
feature
that
is
stable
from
kubernetes
a
1.19
okay.
We
have
three
options
to
configure
the
second
profile
types
unconfined,
which
is
basically
disabled.
Second,
this
is,
unfortunately
the
default
configuration,
but
it
will
change
in
the
long
term.
A
The
second
option
is
a
runtime
default,
which
is,
if
you
set
these
configurations
to
your
port,
it
means
that
your
port
will
run
with
the
default
profile
defined
by
the
runtime
configuration
by
the
content
right
time.
Runtime
you
are
using
in
your
cluster,
so,
for
example,
docker
has
its
own
container
a
default
profile.
A
That
is
what
most
runtime
use,
but
this
is
a
good
improvement,
because
you
are
now
using
a
second
profile
but
consider
that
it
is
a
default
profile,
so
it
needs
to
preserve
all
the
functionality
of
the
generic
containers
of
generic
containers.
So
it's
it's
okay,
but
if
we
are
having
it
will
not
be
fit
for
any
application.
We
are
developing.
That's
the
reason
why
we
have
a
sec,
a
third
option,
which
is
called
localhost.
A
A
This
is
how
a
second
profile
looks
like,
and
we
will
have
a
default
action
that
we
can't.
The
name
is
self-explain.
We
have
the
architecture
section,
which
is
very
important,
because
the
field
there
inside
the
kernel
is
done
using
the
cisco
ids
and
the
sd
they
did
vary
according
to
the
architecture
on
which
you
are
running
your
application.
A
So
it
is
very
important
to
configure
the
architecture
on
which
you
are
running
your
application
here,
and
then
we
have
the
syscall
field,
where
we
define
look
that
it
is
an
array,
so
we
can
define
for
a
subset
of
system,
calls
an
action
that
will
be
that
we
override
the
default
action.
So,
for
example,
in
this
example
I
put
here,
we
have
read
and
write
that
will
be
allowed
instead
of
being
return,
an
error
as
the
default
action
set.
A
We
can
have
many
of
these
here
and
specify
define
our
own
custom
second
profile
now
and
let
me
introduce
you
this
vector
gadget.
This
is
the
tool
that
we
are
going
to
use
to
generate
the
second
profile,
but
it
has
many
other
gadgets,
so
I
maybe
it
would
be
useful
for
you,
and
so
I
want
to
introduce
you.
A
A
First
of
all,
when
we
work
within
kubernetes,
we
want
to
debug
a
post
level.
Pits
are
not
useful
when
we
don't
know
which
is
the
pot
or
the
container
from
in
from
which
it
come
from,
and
therefore
we
need
something
that
translate
the
process
id
to
pods
and
containers.
This
is
what
inspector
gadget
is
trying
to
do.
Of
course,
we
also
want
users
want
to
filter
using
selector
that
they
normally
use
to
refer
to
coordinated
objects.
A
For
example,
I
want
to
filter
by
labels
by
namespace
and
not
to
have
to
deal
with
bits
and
understand
what
is
the
demanding
space
to
attach
it
to
a
container?
No,
we
want
to
make
it
easier
in
this
same
way,
the
user
is
already
working.
For
example,
the
user
is
working
with
cube
ctl,
like
with
cube
ctl.
A
We
want
to
provide
the
same
experience,
so
the
user
doesn't
need
to
association
to
the
node
and
maybe
deploy
a
pod
just
to
make
some
tests
on
that
node
or,
if
maybe
the
user
is
using
a
web
ui
to
control
the
cluster,
for
example
headlamp.
We
want
to
also
with
inspector
gadget
to
provide
a
way
so
that
this
the
web
uis,
can
integrate
our
tool.
Let
me
show
you
how
it
works
very
quickly
and
we
have
with
the
spectacular
two
pieces,
the
the
cube
ctl
plug-in,
that
runs
in
the
local
machine,
and
then
we
have.
A
When
you
want
to
install
inspector
gadgets
when
you
want
to
install
in
your
in
your
cluster
inspector
gadget,
you
will
use
the
cube
ctl
gadget
to
ask
the
kubernetes
control
plane
to
deploy
that
gadget
pod
inside
all
your
working
nodes.
We
use
a
demon
set
to
do
that
and
we
will
have
a
gadget
port
running
on
every
working
node
of
the
cluster.
A
Then,
for
example,
when
you
want
to
execute
any
gadget,
for
example,
the
second
gadget,
we
will
send
the
information
to
the
gadget
port
saying
that
we
want
to
execute
the
second
gadget,
and
then
we
will
pass
also
the
parameters,
the
filters
we
want
to
apply
on
which
node
we
want
to
apply
it,
and
then
the
gadget
port
will
generate
the
bpf
code
and
install
it
in
the
kernel
of
every
node.
This
will
be
replicated
in
all
the
all
the
nodes.
A
A
So,
for
example,
the
open
snoop
tools
that
will
show
you
every
time
an
file
is
being
opened
in
your
system.
We
will
enrich
that
information,
so
we,
you
will
see
the
repeat
of
the
process
that
is
open
in
a
file
the
name
of
the
file,
and
then
you
will
have
also
the
container
on
which
it
was
executed,
the
port,
the
namespace
and
all
the
kubernetes
information.
A
This
is
what
we
are
doing
for
the
bcc
tools
and
we
are
adding
more
and
more,
and
so,
if
you
have
any,
this
particular
need,
please
feel
free
to
contact
us.
We
will
try
to
add
that
tool
to
our
inspector
gadget,
and
here
this
is
the
list
of
the
gadgets
that
we
develop
ourselves,
trying
to
cover
the
use
cases
that
are
not
covered
by
the
bcc
tools.
For
example,
here
we
have
the
dns
gadget
that
will
show
you
the
dns
requests
that
are
being
triggered
inside
the
your
cluster.
We
have
the
second
gadget.
A
That
is
the
one
we
are
going
to
talk
today,
for
example
the
process
and
socket
collectors
which
will
show
you
a
snapshot
of
the
process
and
the
sockets
that
are
running
in
your
system.
Of
course,
for
our
gadgets
we
also
have
all
the
kubernetes
metadata
available
there
so
for
the
dns
request
you
will
see
from
which
cash
from
which
spot
it
comes
from
from
which
node
and
every
all
the
kubernetes
information
there.
A
A
So
the
web
ui
will
use
the
trace
custom
resource
which,
as
you
see,
provide,
contains
more
or
less
the
same
information
that
you
execute
when
you
are
using
the
command
line.
You
specify
the
gadget
that
you
want
to
run
the
node
and
specify
the
filters.
There
are
a
couple
of
a
couple
of
fields
that
are
different,
but
it's
more
or
less
the
same
information.
A
Let
me
show
you
introduce
you
what
exactly
the
second
advisor
gadget
does
and
why
we
do
it.
So
the
idea
is
to
generate
with
these
guys
to
generate
a
second
custom
profile
that
we
are
going
to
use.
What
for
our
application
in
order
to
avoid
using
a
generic
one
or
to
not
having
a
second
profile
at
all,
we
use
ppf
ebpf
to
record
the
system,
calls
that
are
issued
by
each
container.
A
A
I
would
like
to
say
that
it
is
important
that,
when
you're
running
the
gadget,
it's
important
to
cover
the
full
life
of
the
of
the
pod,
for
example,
you
should
start
the
gadget
to
start
monitoring.
The
system
calls
then
start
the
pod
so
capture.
The
system
calls
that
needed
to
bring
up
the
pod
then
terminate
the
pod,
and
then
you
will
have
all
the
system
calls
that
this
the
pot
needs
to
in
its
full
life
cycle,
how
to
use
the
gadget.
As
I
mentioned
before,
we
have
two
options.
A
The
profiles
are
generated
in
two
ways:
you
can
start
and
stop
the
gadget
and
then
a
profile
will
be
generated.
The
policy
will
be
generated
or
you
can
start
the
the
gadget
and
terminate
the
pot
if
to
cover
all
the
to
cover
all
the
life
of
the
pod.
For
example,
as
I
said
before,
you
start
monitoring
and
you
then
deploy
your
pod
interact
with
the
pod,
generate
all
this
issue,
all
the
system
code
that
it
will
need
to
execute,
and
then
you
close
the
pot.
A
A
A
B
A
A
B
A
Gadget
version
we
have,
this
is
the
latest
version
we
have
and,
for
example,
if
you
execute
help,
you
will
see
all
the
available
comments
that
we
have
the
gadgets
that
we
have
here.
The
second
advisor
this
is
the
one
that
we
are
going
to
use
today.
Okay,
now
that
we
have
the
cube
ctl
gadget,
we
need
to,
we
need
to
deploy
the
gadget
port
on
every
knot.
We
can
do
it
also
to
engage
it.
As
I
explained.
A
It
will
create
the
custom
resource
definition,
which
is
the
one
that
is
24.
This
is
a
trace,
so
this
is,
will
it
will
be
used
by
the
by
the
web
ui
to
to
drive
the
the
gadget
to
execute
the
gadget?
Then,
if
we
go
down
oops
too
much,
okay,
for
example,
here
we
have
the
demon
set.
That
will
be
the
one
in
charge
of
deploy
the
gadgets
here.
The
gadget
this
is
the
gadget
pod
that
we
will
have
on
every
working
note.
A
A
To
make
this
demo,
we
are
going
to
use
a
work
lock,
we
prepare.
We
have
also
this
available
in
our
repository.
It
is
available
in
the
examples
is
the
same
guide.
We
we
have
in
the
guide,
so
we
will
have
everything
running
in
the
second
demo.
Namespace
is
mainly
the
task
that
we
are
going
to
do.
We
are
listening
on
port
80
and
we
return
just
hello,
hello,
world.
Okay,
we
have
here
the
service,
that's
listening,
6000
board
and
the
talk
is
80..
Okay,.
A
This
is
the
port
that
using
the
what
we
defined
before,
but
the
most
important
point
is
here
is
here
is
the
second,
the
security
context.
Look
that
we
are
defining
that
we
will
not
use
second
for
now,
because
this
is
the
phase
where
we
are
going
to
monitor
what
the
our
application
is
doing
to
then
generate
a
second
profile.
So,
let's
apply
also.
A
A
Start
this
is
the
detroit's
id
we
are
going
to
use
to
stop
it.
So
now
we
are
going.
What
we
will
do
will
be
to
interact
with
the
gadget
okay,
so
that
we
can
generate
all
the
system
calls
that
our
workload
needs
so,
for
example,
port.
Let's
export
this
so
that
I
can
use
just
localhost
80
because
we
are
exporting
the
service
here,
and
here
we
are.
This
is
the
output
of
our
warlock.
A
Let's
kill
this
okay.
Now,
let's
consider
that
this
is
the
work
that
our
application
needs
to
do.
This
is
all
the
work
that
our
application
needs
to
do
so
we
start
monitoring.
We
collect
all
the
system,
calls
that
our
application
do
during
its
normal
life
and
then
we
stop.
We
can
stop
the
gadget.
We
use
this.
A
A
Okay,
look
the
er
the
profile
that
was
generated
with
what
we
just
did.
Okay,
we
have
the.
As
I
said,
the
default
action
is
erno.
We
will
return
an
error,
the
architecture
because
I'm
working
in
this
architecture-
and
then
we
have
here
the
list
of
the
system
calls
that
were
triggered.
While
we
execute
this
cure.
Okay,
it's
cool
and,
as
you
can
see,
the
list
is
quite
short,
but
it
is
because
we
start
monitoring
the
pod
after
the
pod
was
already
running.
Look
that
the
pod
was
already
there
when
we
start
monitoring.
A
So,
as
I
said
before,
we
recommend
to
do
it
to
include
also
the
startup
of
the
pod.
This
is
very
useful
when
you
just
want
to
check
where
the
system
calls
that
a
given
application
given
operation
generates,
but
let's
try,
let's
try
again
but
including
the
breakup
of
the
pod,
and
I
will
one
I
want
to
show
you.
What
is
the
difference
with
the
system?
Calls?
Okay,
let's
first
delete
the
board.
B
B
A
A
This
is
why
it
is
so
different,
because
this
is
why
we
have
more
season
calls
here,
but
now,
as
I
said,
in
order
to
use
this
system
call
to
secure
our
port,
we
will
have
to
copy
this
file,
put
it
in
the
file
and
copy
inside
the
node,
and
this
is
something
I
would
like
to
avoid
for
this
demo.
So
I
will
show
you
that,
as
I
told
you
I,
we
can
use
the
kubernetes
in
security
profile
operator
to
install
our
gadget.
Our
profiles,
sorry,
and
so
we
have
an
integration.
Also
for
this.
A
Okay,
so
now
we
will
start
the
gadget,
but
we
are
going
to
use
the
integration
with
me,
the
security
operator.
Let
me
show
you
help
you
have
you
have
here
the
output
mode.
You
can
have
it
the
output
in
the
terminal
as
we
did
before,
but
you
can
also
use
the
second
profile
mode,
which
will
interact
with
the
security
operator.
So.
B
A
A
A
Actually
they
are
not
exactly
the
same
because
this
time
we
terminate
the
pot
to
generate
the
policy
instead
of
stopping
the
monitoring
and
in
fact
in
fact,
we
have
kill
the
kill
system
call
here.
That
was
not
present
here.
Oh
okay,
here,
look
that
it
is
not
present
here,
so
the
best
way
to
to
always
cover
all
the
system
calls
that
are
needed
is
to,
as
we
did
here
start
the
policy
do
everything
we
need
to
do,
terminate
the
pot
and
then
the
policy
will
be
generated
automatically.
A
Okay.
Now,
let's
use
this
this
policy,
and
we
have
already
let
me
delete
this-
is
already
deleted,
so
we
have
already
prepared
another
yaml
file
with
the
confined
configuration.
Look
that
the
difference
between
these
a
pot
definition
is
that
first,
we
were
using
the
unconfined,
and
now
we
will
use
the
poly
the
profile
that
we
already
will
just
generate.
Look
the
name.
A
A
Okay,
so
the
functionality
that
we
cover
is
there
and
everything
is
there
now
skill
is
okay
and,
for
example,
if
we
try
to
do
no,
if
we
try
to
do
something
different,
for
example,
to
execute
bash
in
our
port,
let's
see
where's
the
output
and
we
have
an
error,
because
this
is
something
that
we
want,
for
example,
to
avoid.
We
want
to
ideas.
These
are
this
execution
requires
other
system
calls
that
we
didn't
monitor
in.
A
A
A
A
But
you
will
need
to
ssh
into
the
node
and
check
the
var
these
logs
there
to
see
what
are
the
system
code
that
you
are
executed,
and
this
is
something
one
of
the
principles
that
we
are
using
inspector
guys
that
this
is
something
that
we
want
to
avoid
the
users
to
do
so.
We
are
working
currently
already
working
on
a
new
gadget
to
allow
you
to
to
see
what
is
being
blocked
by
the
second
profile.
It
will
be
named
a
second
audit
or
will
be
an
option
also
to
execute
it.