►
Description
Protect Kubernetes? As Kubernetes matures, security is becoming an important concern for both developers and operators. In this talk, Loris Degioanni will give an overview of cloud native security, discuss its different aspects, with particular focus on runtime, and explain what inspired the development of Falco, the CNCF container security project. Through demonstration, he will educate the CNCF community on the ways Falco is being used for real-world workloads. Lastly, he will share the latest on Falco’s adoption, maturation within CNCF and what’s on the horizon.
Presenter:
Loris Degioanni, CTO and Founder @Sysdig
A
Okay,
let's
get
started
I'd
like
to
thank
everyone
for
joining
us
today.
Welcome
to
today's
cncf
webinar,
getting
started
with
container
runtime
security
using
foul
copy,
I'm
jerry,
fallon
I'll,
be
moderating.
Today's
webinar
we'd
like
to
welcome
our
presenter
today,
loris
dejani,
cto
and
founder
at
sysdaig,
just
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee
there's
a
q,
a
box
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
A
A
B
Thank
you
very
much
and
welcome
everyone
to
this
webinar.
Today,
we're
going
to
talk
about
runtime
security
and,
in
particular,
runtime
security
with
a
an
open
source
tool,
which
is
also
a
cncf
incubating
project,
which
is
called
falco.
B
My
name
is
loris
de
joanni,
I'm
cto
and
founder
of
sysdig
sisdig
is
my
second
company.
My
first
company
was
called
the
case
technologies
and
was
the
commercial
entity
behind
an
open
source
network,
analyzer
called
wireshark,
so
I
have
done
open
source
for
my
whole
career
in
the
networking
space.
First
and
now
in
cloud
native
right
now,
I
work
for
a
company
called
csd.
B
Sysdig
offers
visibility,
observability
and
security
tools
for
cloud
native
kubernetes-based
and
cloud
and
container-based
applications.
Sysdig
is
based
heavily
on
open
source,
but
offers
also
commercial
solutions.
On
top
of
our
open
source.
Projects
like
like
falco
were
heavily
integrated
with
the
rest
of
the
ecosystem,
and
we
tr.
B
We
tend
to
focus
on
enterprise
customers
and
we
have
essentially
products
that
scale
and
offer
solutions
to
any
scale
when,
when
it's
a
matter
of
security
and
visibility
for
for
kubernetes,
today,
we're
going
to
talk
about
an
overview
of
runtime
security,
comparing
different
approaches
when
dealing
with
instrumentation
for
runtime
security
and
understanding,
essentially
the
pros
and
cons
of
instrumenting,
your
containers,
your
applications,
your
workloads
with
the
with
these
different
approaches.
B
We're
then
going
to
dive
into
falco.
I
will
give
an
overview
of
falco
and
then
I
will
try
to
become
a
little
bit
more
practical
to
show.
You
know
a
little
bit
of
the
falco
architecture,
how
rules
work
and
so
on,
and
then
we'll
try
to
put
this
in
practice
quickly
in
terms
of
showing
file
connection
and
seeing
seeing
it
essentially
in
in
a
demo,
and
then
I
will
finish
the
presentation.
B
B
This
is
extremely
important
because
security
breaches
and
risks
happen,
while
our
software
is
running,
so
it's
very
important
to
protect
the
software
during
the
whole,
you
know
cicd
pipeline,
but
in
practice
the
risks
happen,
while
our
software
is
actually
deployed
somewhere
and
runs
right
example
of
stuff
that
you
can
accomplish
with
runtime
security,
detecting
malicious
behavior
understanding
if
an
image
is
drifted
from
when
we
created
it,
and
we
put
it
in
in
a
repository,
find
issues
or
vulnerabilities
that
are
only
present
in
and
only
surface
during
the
run
time
of
your
containers,
detecting
threats
that
are
like
zero-day
vulnerabilities
that
were
not
yet
exposed
and
documented
when
your
software
was
created
and
was
pushed
to
a
repository.
B
Runtime
security
is
an
integral
starting
point
for
things
like
incident
response
or
forensics.
Typically,
your
forensics
activity.
You
know
understanding
the
blessed
radios
of
an
of
an
attack
or
something
like
that
always
starts
essentially
from
signals
and
data
that
are
collected
that
are
collected
during
runtime
and,
of
course,
runtime
is
also
extremely
important
in
terms
of
compliance,
because
frameworks
like
pci,
nist
or
sock
essentially
depend
very
much
on
understanding
what's
happening.
While
your
containers,
your
applications,
are
running.
B
This
slider
depicts
a
little
bit
sort
of
the
cicd
journey
right
and
I
used
to
articulate
this
as
build
run,
respond
the
phases
of
life,
the
stages
of
life,
of
a
modern
application
and,
as
we
know
very
well,
security
in
cloud
native
is
not
only
one
of
these
items,
but
it's
making
sure
that
the
whole
journey
of
your
code,
from
your
laptop
to
a
production
environment
and
after
you
know,
production
after
maybe
the
containers
are
gone,
is
all
properly
monitored
and
secure
in
during
the
build
phase.
B
B
I
it's
important
to
clarify
that
all
of
these
are
essential
when
talking
about
the
correct
posture
for
cloud
native
applications.
This
webinar
focuses
specifically
on
the
middle
of
the
slide
on
the
green
part,
not
because
we
think
it's
the
only
important
one
or
not,
because
we
think
that
falco
is
the
only
thing
that
you
need
to
deploy,
but
because,
because
we
think
that
falco
is
is
an
important
piece
in
the
equation.
So,
as
you
think
about
these,
as
you
think
about
your
holistic
approach
to
these,
this
webinar
will.
B
The
technology
here
and
into
the
actual
implementation-
and
let's
start
talking
first
of
all,
about
what,
where
runtime
security
starts,
runtime
security
starts
from
being
able
to
collect
the
best
data
from
processes
and
containers
that
are
running
live
on
your
infrastructure.
B
B
You
know
multiple
applications,
multiple
processes
running
on
top
of
multiple
containers
running
on
top
of
multiple
machines,
so
this
is
just
a
little
piece
of
of
the
equation,
but
from
this
point
of
view,
essentially
it's
very
important
to
collect
signals
that
are
very
rich
for
this
application,
and
in
order
to
do
that,
essentially,
we
need
to
be
able
to
intercept
the
path
of
communication
between
the
application
and
the
external
world,
and
this
goes
through
the
operating
system
right
and
we
want
to
understand
what
this
application
does
on
the
network.
B
For
example,
we
want
to
understand
what
this
application
does
on
the
file
system.
We
want
to
understand
what
this
application
does
in
terms
of
activity
like
executing
commands,
spawning
processes,
doing
inter-process
communication
accessing
data,
all
of
this
kind
of
stuff,
and
typically
all
of
this
information
goes
through
the
operating
system,
and
so
we
want
to
be
able
to
intercept
it.
B
One
way
to
do
that
is
a
technique,
so
called
ld,
preload,
ld
preload
consists
in
taking
a
running
application
and
somehow
replacing
the
libraries
that
this
application
uses
to
talk
to
the
to
the
operating
system.
So
we,
instead
of
using
the
normal,
for
example,
c
libraries,
the
c
library,
is
what
what
is
typically
used
by
the
majority
of
the
applications
to
access
the
file
system.
Doing
everything
that
has
to
do
with
with
system
calls
like
opening
files
establishing
connections
all
this
kind
of
stuff.
B
We
can
somehow,
as
the
container
loads,
replace
the
lib
lipstick
that
is
inside
the
container
by
me.
Maybe
mapping
a
volume
or
something
like
that,
and
you
and
then
use
an
environment
variable
to
tell
the
container
okay
go
and
use
this
different
lipstick,
which
is
instrumented.
The
instrumented
lipsy
is
able
essentially
to
act
as
a
pass-through
for
all
of
these
calls
that
the
application
does
to
the
operating
system
and
collect
them
and
ship
them
somewhere,
so
that
they
can
be
analyzed
and
can
be
used
as
signal
a
signal
for
runtime
security.
B
Ld
preload
is
used
by
many
projects
and
vendors
because
it
has
the
benefit
that
it
works
pretty
much
everywhere.
It's
it's
efficient
and
it's
a
relatively
easy
and
relatively
low
risk
way
to
essentially
observe
any
anything
at
a
high
granularity
that
your
applications
are
doing.
It
also
has
limitations.
B
The
big
one
is
probably
the
third
one
here
on
this
slide,
which
is
in
order
for
you
to
be
able
to
replace
ipc.
Your
application
needs
to
you
use
libsy,
which
is
sort
of
a
traditionally
a
good
assumption.
You
know,
because
everything
c
applications
java
applications
python,
you
name
it.
They
all
use
libsy,
but
there
are
nowadays
whole
classes
of
applications
that
don't,
for
example,
go
as
a
programming.
B
Language,
very
interestingly,
really
implements
its
own
runtime
and
one
of
the
design
kind
of
architectural
choices
of
go
is
that
go
produces
fully
static,
binaries,
so
go.
Doesn't
use
external
libraries,
so
the
streak
of
loading
different
libraries
doesn't
work
for
application
which,
as
you
can
imagine,
is
a
pretty
strong
limitation
in
in
in
cloud
native,
and
of
course,
you
know,
nd
preload
requires
you
to
go
and
instrument
every
container.
So
let's
look
at
another
way
to
do
this.
B
Another
way
is
by
using
ptrace
ptrace
is
a
functionality
in
the
linux
of
operating
system,
and
it's
actually
the
facility
in
linux
that
is
used
to
create
stuff
like
debuggers,
so
gdb
is
essentially
a
glorified
user
interface
on
top
of
ptrace.
I
don't
want
to
diminish
what
gdp
does
it's
something
that
all
of
us
use
all
the
time,
but
the
magic
to
freeze
a
target
process
set
a
breakpoint
introspect
the
process,
the
registers,
the
memory
change
stuff
into
into
the
target
process.
This
is
all
stuff
that
gdp
essentially
just
calls
this.
B
This
linux
system
call
called
betrays
to
do
that.
Ptrace
is
nice
because
it
is
a
facility
of
the
operating
system.
So
it's
much
more
accurate.
For
example,
when
you,
when
you
use
b
tracing,
you,
don't
need
a
dynamic
library
to
do
the
instrumentation.
So
these
covers,
for
example,
go
processes.
B
P
trace
is
a
language
and
stack
independent
because
it
relies
on
linux,
on
the
operating
system
and
not
on
a
library
or
on
a
piece
of
functionality
or
on
the
language
that
you're
that
you're
using
it's
also
safer
than
any
preload,
because
it
doesn't
require
you
to
do
the
relatively
dirty
trick
of
repair,
replacing
libraries,
but
you
can
do
that
by
just
telling
petraeus.
B
Okay,
I
want
essentially
to
introspect
every
single
system
call,
so
beautiful
only
problem
is
ptrace
is
very
inefficient,
because
if
you
look
at
the
diagram
every
time,
there's
essentially
a
request
like
opening
a
file
or
establishing
a
connection.
B
You
need
to
do
a
bunch
of
stuff,
essentially
in
the
operating
system,
to
to
pass
all
of
this
data
to
a
separate
process
which
is
depicted
as
an
agent
here
in
the
diagram
to
that
can
receive
this
data.
So
ptrace
is
the
magic
bullet
for
for
everything,
with
with
the
only
problem
that
it's
it
it's
too
slow,
typically
to
be
used
in
production
and,
of
course,
with
bitrates
as
well.
We
need
to.
We
are
required
to
instrument
every
container.
B
Let's
look
at
another
possible
way
to
do
this,
which
is
a
kernel
based
instrumentation.
So
what
we
do
here
is
slightly
different
here.
We
have
still
a
diagram
of
the
machine
and
we
see
three
containers
on
the
on
this
machine
based
on
three
different,
essentially
container
runtimes,
and
what
happens
here
is
you
deploy
essentially
your
instrumentation
as
container
running
on
the
same
machine.
B
These
container,
what
it
does
is
it
instruments
the
operating
system.
Linux
nowadays
offers
a
functionality
called
ebpf.
Ebpf
is
the
acronym
for
extended
berkeley
filter
and
it's
essentially
a
full-blown
powerful
virtual
machine
that
can
be
used
to
execute
programs
inside
the
kernel
of
the
operating
system.
Ebpm
is
cool
because,
essentially,
it
allows
you
to
add
functionality
to
the
kernel
of
the
operating
system,
but
in
a
way
that
is
fully
validated
and
that
guarantees
that
you
are
not
crashing
the
operating
systems
or
generating
deadlocks
in
the
operating
system.
B
By
doing
this,
it's
possible
essentially
to
create
a
layer
of
instrumentation
that
now
sits
underneath
the
containers,
so
you
don't
need
to
live
inside
the
containers
and
that
is
able
to
without
any
change
without
any
sidecar
or
installing
anything
in
the
container.
It's
able
to
collect
the
data
that
is
required.
B
Kernel
instrumentation
is
the
advantage
of
being
extremely
accurate
because
it
runs
in
the
kernel
of
the
operating
system.
You
cannot
fool
it
you,
it's
extremely
efficient
and
extremely
scalable,
extremely
efficient,
because
the
data
is
collected
in
a
way
just
really
where
it's
generated
in
the
corner
of
the
operating
system.
It's
scalable
because
you
don't
need
it's
the
only
way
when,
where
you
don't
need
to
put
something
inside
every
every
container,
but
another
container,
an
external
container
can
do
that.
B
So
imagine
having
I
don't
know,
enter
containers
running
on
a
single
machine
with
ld
preload
and
with
ptrace.
You
will
need
to
instrument
under
different
things
with
kernel
level
instrumentation.
You
will
only
do
need
to
do
the
instrumentation
one
once
when
talking
about
instrumentation.
The
other
thing
that
is
important
is
metadata
collection
and
applying
metadata
to
the
detections.
B
So
this
slide
shows
a
bunch
of
hosts,
each
of
which
is
running
four
containers,
and
here
the
color
coding
is
essentially
the
service
that
these
containers
belong
to
when
working
with
anything
related
to
runtime
security.
You
typically
don't
want
to
approach
things
like
on
the
left
side
of
the
slide,
but
you
want
to
look
at
things
like
on
the
on
the
right
side,
so
service
by
service.
You
want
to
apply
rules
that
are
per
name
space
per
service
per
deployment
and
not
per
host
or
per
con
per
container.
B
All
right!
This
is
the
theory.
Okay.
Now,
let's
move
into
the
practice
and
let's
start
talking
about
falco,
what
is
falco
first
of
all.
Palco
is
a
runtime
security
engine
based
on
observability
from
the
kernel.
So
when
I
was
showing
you
the
different
options
before
the
one
that
falco
privileges
when
possible,
is
collection
based
on
access
to
the
kernel
of
the
operating
system.
Because
of
the
reasons
that
I
was
mentioning
before,
sometimes
this
is
not
possible
and
I
will
show
it
to
you
quickly
in
the
demo.
B
In
that
case,
we
switch
to
other
mechanisms
like
ptrace,
but
by
default,
falco
wants
to
be
as
scalable
and
efficient
as
possible.
So
when
bpf
is
available,
that's
what
we
use
falco
is
designed
to
be
consumable
and
modular.
So,
as
I
was
saying,
falco's
designed
not
to
be
your
complete
solution
for
kubernetes
security
for
cloud-native
security,
but
is
designed
to
be
a
component
in
it
that
can
be
orchestrated
and
can
be
composed,
together
with
other
stuff,
to
create
the
full
solution.
B
Falco
puts
a
lot
of
emphasis
not
only
or
on
using
the
kernel
as
a
source
of
truth,
but
also
on
enriching
the
data
with
metadata,
so
that
your
approach
can
be
service
oriented
and
it
essentially
allows
you
to
create
or
to
leverage
a
bunch
of
rules,
and
then
it
gives
you
alarms
when
one
of
these
rules
is
is
violated.
B
Falco
is
a
cncf
incubating
project.
We
released
falco
in
2016,
we
became
part
of
cncf
in
2018
and
it
was
promoted
to
incubation
in
2019..
B
We
are
strong
strongly
driven
as
a
community
by
community
principles.
In
particular,
we
are
inspired
by
everything
that
is
called
native
and
kubernetes.
First,
in
the
way
we
manage
our
community,
we
really
try
to
be.
You
know
like
the
voice
and
of
our
end
users
and
work
together
with
them,
but
we
also
want
to
be
vendor
friendly
and
vendor
neutral.
So
we,
as
you
can
see,
there
are
multiple
commercial
entities
that
take
falco
and
enhance
it
and
base
their
products
on
top
of
funko
a
couple
of
examples
of
using
falco
in
production.
B
One
is
shopify
big
production
environment,
it's
essentially
a
pci
compliant
environment
in
the
cloud
in
aws,
slash
eks-
and
this
is
you
know-
shopify
is
a
big
company
that
does
a
lot
of
transactions
and
they
are
you
know.
150
million
dollars
of
transactions
per
day
are
essentially
a
pro
in
an
environment
that
is
protected
by
falco
and
where
falco
contributes
to
establishing,
essentially
pci
compliance
and
making
environment
pci
a
pci
compliant
shopify.
Specifically,
I
recommend
to
go
to
the
cncf
youtube
youtube
channel.
B
There
was
a
wonderful
keynote
at
the
last
kubecon
in
in
europe
in
in
amsterdam,
where
the
shopify
team,
together
with
chris
nova,
showed
essentially
on
stage
falco
used
by
shopify,
and
it's
very
interesting
if
you
want
to
learn
more
about
their
use
case.
Another
use
case
is
sky
scanner.
B
Sky
scanner
has
a
200
plus
nodes
on
30
clusters
with
160
services
on
top
of
them,
and
I
have
a
link
to
the
blog
post
in
which
they
describe
essentially
how
they
use
falco
and
the
kind
of
evaluation
that
they
did
with
falco
before
putting
it
in
into
production.
For
example,
it's
very
interesting
to
look
how
important
for
them
the
overhead
of
this
instrumentation
was,
and
we
go
back
to
you,
know,
ptrace
versus
kernel,
module
and
so
on,
and
how
they
really
scrutinized.
B
You
know
falco
performance,
wise
and
overhead
wise
before
deploying
it
on
their
on
their
infrastructure
and
blog
posts
like
that
are
cool
for
me
to
see,
because,
of
course,
the
falco
community
and
the
falco
engineers
put
a
lot
of
effort
into
making
it
efficient.
So
seeing
how
it
can
be
used
in
production
is
always
very,
very
rewarding.
B
Architecturally
falco
is
relatively
simple:
it
has
inputs
an
engine
and
outputs
inputs
are
all
of
these
events
coming
from
from
instrument
in
the
application.
So
system
calls
kernel
events,
activity,
events,
user
user
activity,
network
data,
all
of
this
kind
of
stuff
and
also
kubernetes
events
in
the
form
of
audit
events
and
in
the
form
of
metadata.
B
All
of
this
goes
into
the
engine
which
receives
rules
as
as
its
other
input,
and
essentially
the
rules
are
matched
against
the
stream
of
data
that
is
constantly
coming
into
the
engine
and
if
rules
matches,
if
rules
match
a
an
alert,
is
generated
through
a
number
of
ways,
again
falco's
designed
to
be
composable
so
grpc
web
books,
syslog
sdk,
is
like
even
you,
you
name
it.
B
You
know
we
have
all
of
these
ways
essentially
to
notify
you
that
the
sun
rule
was
was
violated,
collection,
wise,
two,
great
sources
of
data,
as
I
was
saying
one
is
the
system
calls
the
other
one
is
the
kubernetes
events
and
rules
can
be
created
on
both
and
can
be
mixed
and
matched
so
you
can
mix
a
rule
that
is
specific
on,
for
example,
of
a
system
called
like
opening
a
specific
file
which
one
which
is
based
on
a
kubernetes
action.
B
Like
I
don't
know,
spinning
up
a
a
service
or
something
like
that
and
and
and
rules
essentially
can
take
these
two
sources
of
data
and
alert
on
on
either
one
or
both
together
rules.
So,
what's
a
rule
exactly
compared
to
other
tools
like,
for
example,
I
don't
know
an
oppa
to
mention
something
that
is
a
very
popular
rule.
B
B
Overwrite
system
binaries
there
there
needs
to
be
access
on
a
file
descriptor
in
a
directory,
and
this
directory
can
be.
You
know
one
of
the
directories
that
are
in
this
room.
So,
as
you
can
see,
it's
essentially
boolean
expressions
that
can
be
used
to
chain.
B
Checks
that
are
done
on
different
different
fields
and
the
list
of
fields
is,
is
pretty
pretty
big,
and
it's
essentially
documented
in
the
in
in
the
funko
guitar
example
of,
for
example,
spawn
a
shell.
A
database
spawns
a
shell.
B
There's
an
output,
which
is
what
you
see
when
you
receive
a
notification
when
this
is
violated
the
source
as
we
as
we
were
saying
it
can
be
kubernetes
or
system
called
description,
and
priority
and
text
rules
can
contain
lists
and
macros.
So
that
can
be
written
in
a
more
compact
and
reusable
way.
And
of
course
we
don't
expect
you
to
you,
know
download,
falco
and
then
to
write
your
own
rules
and
learn
the
syntax
and
so
on.
B
Of
course,
you
are
welcome
to
do
that,
and
we
try
to
document
this
as
well
as
possible,
but
falco
comes
packaged
with
tens
and
tens,
and
that's
probably
hundreds
at
this
point
of
rules
that
are
pre-packaged
for
you
by
an
active
community
of
people
that
maintains
these
rules
keeps
an
eye
on
the
noisiness
adds
new
or
constantly
new
applications
and
new
tools
and
and
and
stuff
like
that
rules
are
even
you
know,
aggregated
and
tagged
based
on
the
different
uses.
B
For
example,
there's
a
miter
rule
metrics
where
they,
where
rules
are
tagged
and
and
you
can
you
have
a
subset
of
rules
that
is
just
for
miter
framework.
You
know
and-
and
you
can
use
those
you
know
exclusively
with
falco
if
you
want
to
essentially
be
compliant
with
that
framework,
all
right,
let's
start
with
the
slides
for
a
second
and
let's
actually
take
a
look.
So
let
me
actually
go
into
my
virtual
machine
and
let
me
just
run
falco.
You
know
right
right
now.
B
This
is
the
possible
way
to
run
falco
and
and
give
it
a
try.
You
know
you
download
the
turbo
from
the
falco,
the
falco
repository,
and
then
you
just
run
it.
You
know
and
when
you
do,
that
nothing
happens.
But
I
can,
you
know,
start
operating
in
this
machine
and
I
say
I
can.
B
Generate
some
pseudo
malicious
activity
like
let's
modify
a
binary
file,
which
is
something
that
is
never
that
nice
and
immediately,
as
you
can
see,
focus
just
under
the
hood
here
in
this
machine
and
looking
at
at
what's
happening,
and
the
text
is
and
tells
me
essentially
file
below
binary
directory
open
for
writing.
It
tells
me
you
know
information
about
the
user
information
about
the
process
that
did
did.
That
was
the
target
for
this,
the
sorry
the
command
line
that
generated
this
the
process.
B
That
was
the
target
for
this
was
the
parent
all
of
this
kind
of
nice
information
that
right
now
I
just
get
on
standard
output,
which
is
one
of
the
many
ways
falco
keeps
out
its
output,
but
it
can
be.
You
know
anything
else
that
we
want.
B
Let
me
try
to
do
actually
to
start
a
container,
so
I'm
just
starting
in
a
ubuntu
container,
and
when
I
do
this
immediately,
falco
tells
me:
okay,
somebody
spawned
a
shell
in
a
container
which
is
normal
here,
because
it's
an
ubuntu
container,
but
you
would
agree
with
me
that
in
production
is
never
good.
When
somebody
just
spawns
a
shell
in
a
container
that
is
supposed
to
be
mutable,
so
falco
gives
me
a
notice
for
that.
B
You
know:
okay,
careful,
because
there's
a
container
now
and
somebody
that
has
a
root
share,
essentially
inside
the
container
and
again
inside
the
container,
I
can
generate
some
malicious
activity
like
garbage
into
slash
dev,
slash
fake
device,
for
example,
so
I
simulated
creating
essentially
a
file
under
dead.
B
You
know,
and
and
falco
essentially
tells
me
that-
a
program
that
it
doesn't
trust
has
done
it
so,
as
you
can
see
now,
I'm
inside
the
container
but
falco,
even
even
if
it's
running
in
the
host,
is
able
to
essentially
keep
track
of,
what's
happening
inside
this
specific
container
in
any
other
container,
and
it
doesn't
matter
how
many
have
running
on
this
machine
because
it
uses
it
it
installed.
B
The
target
processes.
Of
course,
I
can
also
run
falco
on
this
machine
as
a
docker
container.
So
now
falco
yeah
just
started
inside
a
container.
This
is
an
even
simpler
way
to
run
falco
but
notice.
How
I
can
again,
you
know,
generate
malicious
activity
anywhere
in
the
machine
and
even
if
it's,
if
it's
living
in
a
container
falco,
is
still
able
to
see
for
its
container
the
host
and
any
other
container.
B
So
the
beauty
of
this
is
that
yeah
at
that
point,
deploying
something
like
this
especially
orchestrating
the
deployment
of
something
like
this
becomes
very
nice.
You
don't
need
to
have
cycles.
You
don't
need
to
have
to
link
libraries,
you
don't
need
to
to
use
all
of
these
more
invasive
ways
to
deploy
it.
You
just
use
a
demon
set
on
kubernetes
and
you
tell
kubernetes.
B
I
would
like
to
have
one
of
these
running
on
each
of
my
physical
hosts,
and
then
you
know,
with
a
little
bit
of
glue
configuration
to
tell
essentially
falco
where
to
pipe
these
events.
You're
you're
good
you're
covered
right,
so
that's
the
the
power
and
the
richness
of
of
falco.
B
Similarly,
if
we
want
to
look
at
these,
actually
let
me
go
out
to
full
screen
here.
I
have
actually
a
more
like
realistic
deployment
of
falco
where
falco
is
running
on
aws
in
this
case
on
a
far
gate
task.
So
here
I
have
my
task
and
I
can.
B
There
it
is
and
then
go
inside
and
I
can
do
the
same.
I
can
just
simulate
slash
bin
slash
cat,
the
same
thing
that
I
did
before
so
now.
I
logged
into
into
the
container
and
I
activity
and
now
I
can
go
and
look
at
the
logs
in
cloud
watching
as
you
can
see,
I'm
getting
the
logs
of
falco,
essentially
detecting
this
in
particular
notice.
B
Here,
specifically,
falco
was
run
in
a
far
gate
task.
So
in
this
specific
instance,
we
don't
use
the
kernel
module
to
instrument
because
it's
not
possible
in
fargate
and
we
revert
to
a
technology
which
is
called
pdig
which
allows
falco
essentially
to
collect
this
information
by
sitting
inside
the
container
and
using
ptrace.
So,
as
you
can
see
from
one
point
of
view,
falco
tries
to
be
as
efficient
as
possible
by
defaulting
to
like
ebpf
and
kernel
module,
which
are
the
most
efficient
ways
when
possible.
B
But
when
not
possible,
it
can
also
go
into
like
orchestrated
container
technologies
in
the
cloud
like
fargate
and
and
still
work
by
using
other
technologies
like
ptrace
to
to
do
the
instrumentation.
So,
there's
quite
a
bit
of
sophisticated
stuff
going
on
under
the
hood
here:
okay,
just
another,
a
couple
of
slides
before
we
we
go
into
questions
so,
first
of
all,
a
little
bit
of
history.
B
We
actually
started
falco
in
2016
as
a
way
to
apply
some
of
the
concepts
in
network
security
to
broader
containers
like
slash
cloud
native
security,
as
I
was
mentioning
at
the
beginning
of
the
presentation,
my
background
is
pekka
capture
and
in
particular,
wireshark
and
another
very
important
class
of
things
that
you
can
do
with
packets
is
networking
through
intrusion,
detection
tools
like
snort
or
sturikata,
and
so
on
essentially
are
based
on
capturing
network
packets,
applying
rules
on
top
of
the
network
packets
and
giving
giving
you
alerts.
B
If
something,
for
example,
is
sending
you
malware
or
something
like
that,
and
of
course
you
know
doing
stuff
from
the
network
point
of
view
doing
this
kind
of
stuff
from
the
network
point
of
view,
it's
harder
and
harder.
You
know
in
a
world
where
we
have
a
heavy
orchestration
heavy
encryption
in
the
network
and
the
use
of
containers
that
that
make
everything
opaque.
So
falco
was
designed
with
a
similar
concept,
but
with
a
different
vintage
point.
B
The
system
calls
the
runtime
data
coming
from
the
operating
system,
which
is
much
closer
to
the
final
application,
and
it's
much
more
collectible
in
cloud
native
palco
evolved
quite
a
lot,
both
in
terms
of
you
know
becoming
part
of
the
cncf
and
in
terms
of
features
and
grew
quite
a
bit
in
terms
of
you
know,
contributors
and
number
of
users
among
the
things
that
we
added
recently
to
falco
like
in
the
last
six
months,
many
rules,
improvements
and,
in
particular,
a
group
of
groups
of
rules
for
like
post
security
policies
for
la
for
mitre
framework
for
crypto
mining,
which
is
another
one
that
is
pretty
popular
with
our
users.
B
B
We
also
worked
quite
a
bit
on
deployment
of
falco
trying
to
make
make
it
easier
and
easier,
for
example,
by
offering
helm
charts
that
come
essentially
pre-packaged
as
recipes
and
also
we've
been
spending
quite
a
bit
of
time
recently
on
petra's
instrumentation,
to
make
it
possible
to
collect
data
for
stuff
like
a
lambda.
Exactly
like,
I
showed
you
before
during
the
demo,
there's
a
blog
post
that
we
released
recently
with
stuff
that
we
added
recently.
I
encourage
you
to
go.
Take
a
look
if
you
want
to.
B
If
you
want
to
learn
more
roadmap
wise,
what
we
are
looking
into
is
falco
developers.
First
of
all,
the
most
important
thing
that
we
put
on
top
of
everything
else
is
expand
our
community
by
delighting
our
users.
So
we
are
focused
there
on
building
something
that
solves
the
problem
solves
the
problem
in
a
way
that
is
not
only
effective
but
also
elegant
and
and
and
cool
actually
and
nice
to
use
lowering
the
barrier.
Of
course,
falco
is
and
will
remain
a
distributed
tool
that
needs
to
run
everywhere.
B
If
you
really
want,
through
security
in
potentially
big
and
complex
infrastructure.
So
we
are
always
talking
to
users
that
struggle
with
ease
of
deployment
with
maybe
performance
in
particular
situations
or
maybe
with
stability.
So
the
team
is
really
focused
on
trying
to
just
making
this
experience
better
and
better,
so
that
falcon
can
be
used
more
confidently
by
people
integrations
and
being
able
to
plug
falco
into
many
different
things,
cloud
things,
kubernetes
things
and
so
on
and
placement
platform
coverage.
B
Fargate
that
I
was
mentioning
before
is
an
example,
but
for
sure
with
something
that
collects
the
the
data
in
such
a
rich
way,
and
that
is
really
based
on
the
idea
of
having
the
best
data
coverage
and
I
don't
know
fargate
lambda
cloud
run.
All
of
this
kind
of
stuff
is
always
a
focus
in
the
direction
for
us,
so
that
falco
can
really
be
used
broadly
and
cover
any
possible
use
case,
and
we
are
at
45.
B
So
I'm
going
to
just
put
some
links
on
the
screen,
and
I
am
going
to
stop
here
to
see
if
there
are
questions
from
the
audience.
A
Okay,
well,
thank
you
very
much
for
a
wonderful
presentation,
as
I
said
before,
feel
free
to
drop
some
questions
into
the
q,
a
section
it
looks
like
we
already
have
one
here
from
regest.
That
says:
when
is
the
ga
version
due.
B
Falco
is
has
been
ga
for
for
for
quite
a
bit
now.
So
if
you
go
to
falco.org
and
you
you
follow
the
instructions
you
can
install
it
on
your
cluster
and
falco
is.
B
A
B
I
recommend
you
just
go
to
our
github
here
and
open
an
issue
and
the
some
of
the
engineers
that
that
work
on
falco
will
be
able
to
to
help
you,
but
you
it
looks
like
you
have
some
some
kind
of
drops,
so
it
could
be
a
configuration
of
falco,
but
if
it's
just
one
one
system
called
that
is
dropped,
it's
probably
like
just
physiological,
but
it's
something
that
we
see
from
users
once
in
a
while
and
we'll
be
able
to
help
you
with
that.
B
Heavily
based
on
falco
for
runtime
security,
so
siddiq
secure
also
offers
a
bunch
of
other
functionality
like
image,
scanning,
forensics,
audi
stream,
compliance
and
all
of
this
kind
of
stuff,
but
for,
let's
say
commercial
use.
You
can
come
to
this
to
sysdig
for
both
essentially
support
with
running
falco,
as
as
in
as
an
independent
tool
or
for
commercial
tools
that
are
based
on
topo
farco.
B
So
istio
is
more
like,
let's
say
a
generic
network
mesh,
so
istio
is
a
mesh,
a
network
of
sidecars
that
you
put
of
little
proxies
that
you
that
you
deploy
as
cycles
near
inside
all
of
your
pots
near
your
your
containers,
near
your
your
applications
and
essentially
with
istio
all
of
the
network.
Traffic
of
of
your
applications
of
your
containers
in
in
kubernetes
will
go
through
the
istio
proxies
at
that
point.
Istio
can
do
a
bunch
of
stuff
that
ranges
from
observability.
B
A
circuit,
breaker
and
testing,
and
and
also
security
enforcement
and
micro
segmentation,
so
istio
is
very
much
network
oriented
and
it's
another
part,
important
part
of
the
runtime
security
equation
and
operates
from
the
especially
from
the
security
point
of
view
at
the
network
segmentation
level.
While
falco
is
more
like
able
to
see
inside
the
containers
and
to
notify
you
when
something
that
you
should
pay
attention
to
happens
inside
your
containers.
B
If
we
go
back
to
you
know
the
previous
world,
the
previous
data
center
world
istio
is
more
like
your
firewall.
Your
checkpoint,
firewall
falco,
is
more
like
your
intrusion
detection
system,
like
your
source,
fire,
cisco
intrusion
detection
system.
You
want
both,
because
one
essentially
is
your
lock
on
the
door.
The
other
one
is
your
security.
Camera
falco
is
the
security
camera.
Istio
is
more
like,
among
other
things,
that
the
lock
on
the
door.
B
Yes,
so
compliance
is
many
things
right
and
starts
at
the
csd
level.
You
know
starts
in
the
in
the
build
phase
of
of
of
ci
cd,
where
you
want
to
check
con
configuration
for
your
images
and
so
on.
But
then
compliance
is
also
a
runtime
and
essentially
making
sure
that.
B
Actions
that
are
a
concern
from
the
security
point
of
view
are
not
performed
at
runtime,
and
if
they
are,
you
are
notified
and
there's
a
trail
that
essentially
allows
you
to
document
them
and
improve,
essentially
the
the
the
compliance
of
of
your
infrastructure.
B
Examples
of
things
that
you
want
to
check
at
runtime
from
the
compliance
point
of
view
not
running
privileged
containers,
is
a
good
example,
a
specific
policies
on
the
data.
You
know
that
you
have,
or
on
the
on
the
processes
that
you
run
not
running
as
I
was
showing
before
shells
you
know
in
your
production
environment.
B
All
of
this
kind
of
stuff
can
be
detected
by
falco
and
falco
can
report
all
of
these
or
all
of
this
information
and
allow
you
essentially
to
create
a
paper
trail
of
of
anything
that
happened
in
in
your
in
your
environment
across
time,
so
that,
if
an
auditor
comes,
you
know
you
you,
you
can
show
that
in
the
last
six
months
you
didn't
have
any
privileged
container
that
was
executed
in
in
your
infrastructure.
B
Falco
is
a
set
of
rules
that
are
particularly
specifically
crafted
to
match
against
the
main
compliance
frameworks.
For
example,
pci,
so
if
you
go
to
the
falco
rule
set,
which
is
a
big
yaml
file,
and
you
look
at
the
tags,
you
will
see
that
many
rules
in
the
falco
rule
set
are
tagged
as
pci.
These
are
rules
that
have
been
created
by
security
professionals
by
members
of
the
of
the
falco
community.
B
That
will
notify
you.
If
something
that
happens
on
your
infrastructure
violates
a
specific
pci
rule.
You
know
a
specific
pc,
pci
entry
and
when
you
deploy
falco,
you
can
essentially,
if
you
want
choose
to
only
deploy,
deploy
rule,
sets
that
map
to
specific
compliance
frameworks
and
offer
a
certain
percentage
of
coverage
for
these
frameworks.
B
The
thing
that
falcon
serium
have
in
common
is
that
they're
both
based
on
ebpf,
so
they
both
use
these
powerful
and
revolutionary
functionality
in
the
linux
current,
but
selium
uses
ebpf
to
be
much
more
attached
to
the
networking
stack
while
falco
wants
to
be
again
a
broader
intrusion
detection
system,
so
psyllium
from
the
point
of
view
of
essential
integration
and
be
used
together
is
a
little
bit
more
like
something
that
that
matches
istio
rather
than
falco,
so
some
similar
technological
choices,
but
we
don't
really
have
deep
integration
among
among
the
tools.
C
B
Yeah,
there's
a
bunch,
I
mean
again
go
to
the
website.
I
cannot
list
all
of
them
here,
but
if
you
need
to
integrate
falco
with
something
very
good
chance,
it's
already
there
slack
was
an
example.
You
know,
but
there's
there's
you
name
it.
You
know
log
collection
systems
like
splunk
and
so
on,
stuff,
like
pagerduty
and
similar
chats
web
books
monitoring
to
prometheus.
B
No,
if
properly
configured,
no
because
they
do
the
same
thing,
so
we
give
you
the
choice
from
running
it
in
the
system,
for
example,
installing
it
in
the
host
as
a
tarball
or
running
it
inside
a
container
functionality
wise
performance
wise,
they
are
absolutely
equivalent.
So
whatever
works
best
for
you.
B
Okay
market,
the
answer
it's
low
in
practice,
the
overhead
depends
on
the
workload
profile
of
the
system
that
falco
is
observing,
so
if
falco
is
properly
configured
and
tuned
and
the
system
is
not
like
an
edge
case,
you
should
expect
to
see
something
like
a
handful
of
cpu
percentage
points
used
by
falco
and
an
amount
of
memory
that
varies
depending
on
what
you
do
with
falco,
because
if
falco
is,
is
configured
to
only
look
at
local
data
and
not
consume
the
kubernetes
state,
then
the
memory
footprint
is
tiny.
B
If
falco
is
configured
to
fetch
the
kubernetes
metadata,
because
you
have
service
oriented
rules
or
stuff
like
that,
then
there's
a
memory
requirement
in
terms
of
bringing
in
essentially
the
kubernetes
state
to
understand,
metadata
and
all
that
kind
of
stuff
and
memory
can
grow
higher
to
up
to.
Let's
say
hundreds
of
megabytes
or
or
something
like
that.
B
So
that
depends.
But
overall
again,
falco
has
been
designed
to
run
in
a
production
environment
in
a
way
that
whose
overhead
should
be
barely
measurable.
A
Well,
thank
you
very
much.
That's
about
all
the
time
we
have
for
today.
As
I
said
before,
today's
presentation
will
be
available
later
today
on
the
cncf
website.
Thank
you
again.
Everyone
for
your
time
have
a
wonderful.