►
Description
Learn from Liz Rice and Thomas Graf about the future of security observability with eBPF
0:00 Headlines
4:35 Open sourcing Tetragon
21:35 Tetragon CLI example
A
A
So
let's
quickly
talk
about
the
headlines
as
always,
if
you're
here
with
us
today,
do
you
say
hello,
I
see
sachin
joined
pretty
early
so
good
to
have
you
with
us
sachin.
As
always,
we
love
to
hear
your
questions
and
get
your
comments
and
and
know
where
you're
watching
us
from
so
yeah.
It's
been
a
busy
week
in
the
world
of
ebpf,
the
linux
kernel
developers,
bpf
conference
happened.
A
I
think
it
was
last
week
there
was
a
lot
of
folks
there
from
the
I
surveillance
team,
so
we
saw
some
pretty
good
pictures
coming
in
and
in
fact,
on
this
website
you
see
a
picture
of
these
folks
who
are
building
ebpf
for
the
rest
of
us
to
to
build
tools.
On
top
of
so
we're
grateful
to
all
those
folks-
and
I
think
they
probably
had
some
really
interesting
discussions
last
week
and
speaking
of
interesting
discussions
next
week-
it's
kubecon
in
valencia.
A
So
if
you're
going
to
be
there
do
say
hello,
tell
us,
you
know
now,
if
you're
going
to
be
there,
we'll
we'll
look
out
for
you
next
week,
so
psyllium
is
going
to
be
there
with
a
psyllium
project
booth
and
we're
also
going
to
be
there
in
the
form
of
isovent
as
well.
There
are
loads
of
talks
about
psyllium,
many
of
which
are
by
end
users.
So,
for
example,
we've
got
ikea
speaking
at
the
ebpf
co-located
event.
A
On
monday,
there's
bell
canada
talking
about
psyllium
at
the
telco
event,
also
on
monday
and
several
other
end
user
stories,
which
I
think
are
going
to
be
really
exciting,
also
you'll
be
able
to
come
and
talk
to
us
about
how
to
get
involved
with
the
psyllium
project.
I
want
to
particularly
highlight
this
session
on
thursday,
where
we're
hoping
to
meet
developers,
technical
writers,
folks,
who
want
to
get
involved
in
psyllium
in
any
form,
we'd
love
to
see
you
there.
A
If
you
have
ideas
things
that
you
want
to
see
implemented
in
the
project,
that's
a
great
place
to
come
and
discuss
those
ideas.
I
can
see
loads
of
people.
Who've
joined
us
today,
so
just
quickly
running
through
to
say
hi
to
sachin
hi,
to
nicola
hi,
to
quentin,
who
is
moderating
for
us
as
as
always
hello
to
tony
russell.
We've
got
some
regulars
here.
This
is
really
great
hello
to
naveen
hi,
to
kamaraju,
watching
us
from
india.
A
A
A
A
A
But
I
think
this
time
it
was
a
really
great
opportunity
to
talk
about
the
topic
of
security.
Observability
folks,
who've
been
paying
a
lot
of
attention
and
who've
been
following
us
on
social
media
and,
following
the
blog
might
have
seen
natalya's
blog
about
a
security
observability
book
that
we've
published
we'll
be
giving
away
copies
of
those
at
q
con
next
week.
So
do
come
and
talk
to
us
for
one
of
those
yeah.
A
So
really
the
topic
that
we're
going
to
talk
about
today
is
psyllium
observability
and
a
tool
that
what
we're
describing
it
as
new.
But
it's
not
so
much
brand
new
as
something
that
has
been
part
of.
I
surveillance
offering
for
quite
a
while,
but
we're
now
bringing
to
open
source
as
well
so
thomas
introduce
us
to
tetragon.
B
B
So
many
know
us
or
many
know
I
surveillance
for
having
created
psyllium
on
the
cni
on
networking
now,
service
mesh
they've
always
been
also
doing
runtime
security,
in
particular
around
observability,
and
also
a
bit
on
the
enforcement
side
and
today
or
next
week.
So
this
is
a
preview
of
what
we
will
announce
next
week
at
kubecon,
we're
essentially
open
sourcing
major
parts
of
tetragon
and
making
it
available
for
contribution
to
the
open
source
community.
B
Hopefully,
a
lot
of
this
will
make
sense
very,
very
quickly
and
very
soon,
so
I
think
ebpf
is
obviously
a
amazing
technology
to
introspect
the
system
and
applications.
So
essentially,
what
we
want
to
build
with
tetragon
is
bring
all
the
eppf
experience
we
have
as
a
team.
Many
of
our
team
members
have
been
involved
with
ebpf
since
2014
2014
when
it
was
created,
we've
created
psyllium
d,
major
c9
plugin,
using
ebpf,
we're
now
bringing
all
of
that
knowledge
to
the
observability
space,
in
particular,
with
a
heavy
security
focus.
B
So
if
you
look
at
kind
of
where
ebpf
can
hook
into,
we
see
all
of
this,
this
batches
of
the
ebpf
logo
on
it.
These
are
all
places
in
the
system
where
we
can,
where
we
can
hook
in
and
actually
gain
visibility
from
the
lowest
level
storage
network
like
disk
access
network
packets
name
spacing
whether
it's
network
name,
spaces,
mount
name,
spaces,
username
spaces,
the
virtual
file
system,
the
network
stack
and
so
on,
and
so
on.
B
B
A
B
Exactly
absolutely
and
we're
bringing
that
so
it's
the
same
underlying
edpf
technology
that
we
that
we
use
and
we
bring
that
and
actually
look
at
a
very
security,
specific
or
kind
of
security.
Centric
observability
focus
here.
So
this
is
one
level
down
and
we
can
kind
of
look
at
what
are
the
types
of
observability
and
or
observable
data
that
we
could
extract.
B
I
mean
talked
about
data
access,
for
example,
when
are
certain
devices
accessed
or
looking
at
the
network
level
parsing
individual
protocols,
whether
it's
http
dns,
tls
tcp,
but
then
very
interesting,
actually
observing
the
name
spacing
layer.
This
is
the
linux
kernel,
subsystem
that
essentially
enables
containers
and
because.
B
That
there
are
software
box
and
when
a
user
or
an
attacker
attacks
these
software
box,
kernel,
kernel,
vulnerability,
escapes
or
breakouts
can
happen
and
with
ebpf
and
with
tetragon
we
can
actually
observe
them.
So
we
can
see
when
a
container
is
escaping
its
name
space
isolation.
We
can
also
see
when
a
container
is
escalating
its
privileges.
Maybe
it's
allowed
to
do
so.
Maybe
it's
not.
We
can
see
both,
but
then
we
can
also
look
into,
for
example,
tcp
sequence
number
attacks
or
we
can
observe
when
certain
file
system
or
certain
files
are
being
accessed.
B
What's
very
unique
and
what's
very
specific
and-
and
I
think
interesting
with
tetragon-
is
that
a
lot
of
the
observability
logic
around
collecting
actual
signal,
so
not
just
looking
at
the
raw
observability
data,
but
a
lot
of
this
processing,
for
example,
creating
metrics
or
creating
stack
traces
or
creating
histograms
or
aggregating
data
together
doing
filtering
a
lot
of
that.
Additional
logic
is
usually
run
in
a
user
space
agent.
B
B
Actually
be
very
flexible
and
use
the
extendability
to
provide,
and
we
can
zoom
in
a
little
bit
to
actually
provide
a
lot
of
integrations
into
interfaces
that
already
exist,
where
we
can
extract
our
observability
data
too,
for
example
for
metrics.
We
want
to
export
that
into
prometheus
or
maybe
into
a
sim.
We
want
to
have
like
a
raw
json.
A
B
For
events,
but
then
also
fluent
in
fluent
integration
same
for
logs,
you
might
want
to
export
that
into
a
grafana
instance
or
into
elasticsearch
for
traces.
They
could
go
into
open,
telemetry
and
so
on
and
with
ebpf.
We
have
this
flexibility
because
we
can
extract
the
data
in
the
form
we
need
and
then
a
tetragon
agent
can
export
them
into
kind
of
the
the
relevant
formats.
So
that's.
A
B
Entire
observability
piece
to
summarize
this,
I
think
this,
the
deep
observability
key
aspect
of
tetragon.
We
can
see
everything
from
lower
levels,
all
the
way
into
applications,
the
transparency,
so
no
application
changes
are
needed.
It's
all
done
from
within
the
code
of
ebpf,
so
the
application
does
not
even
know
when
it
is
being
monitored.
It's
actually
a
difference,
for
example,
to
petras.
If
an
application,
if
you
use
ptrace,
to
trace
an
application,
the
application
can
detect
this,
that
it
is
being
pre-traced.
B
But
then
it's
also
the
low
overheads,
because
we
can
do
so
much
in
kernel
very
close
to
where
the
observability
data
is
actually
produced,
and
this
helps
us
actually
to
gain
this
deep
observability
data.
Because
often
when
you
go
deeper
in
terms
of
visibility,
it
becomes
more
expensive
so
having
a
very
high
level
of
issue
of
efficiency,.
A
B
Important,
that's
the
observability
part,
which
is,
I
think,
exciting
on
its
own,
and
I
think
this
is
where
tooling,
like
bcc
and
bpf
trace
and
like
pixie
and
others
have
already
done
quite
a
bit,
we're,
I
think,
bringing
in
a
more
security
centric
focus
here
as
well.
So
I
think
it's
a
nice
complementary,
complementary,
complementary
project
to
a
lot
of
existing
projects
already
out
there,
but
then
we
actually
bring
the
second
aspect
in
as
well,
which
is
the
enforcement.
B
So,
besides
extracting
visibility
data,
we
can
also
take
policies,
and
I've
listed
three
examples
here:
kubernetes
crds
or
just
json
policy,
and
also
something
like,
for
example,
a
policy
created
by
open
policy
agent.
That's
this
logo
here
can
be
fed
into
into
the
tetragon
agent,
and
the
tetragonation
then
enforces
these
rules
in
kernel.
So
this
is
very,
very
different.
We'll
look
at
an
example
in
a
second
on
how
usually
that's
done
in
kind
of
traditional
system.
B
B
The
system
observes
behavior,
that
is
not
correct.
The
process
is
immediately
terminated
or
the
action
is
immediately
stopped,
which
is
very
different
to
a
system
such
as
petra's
page
trace,
based
enforcement,
where
ptrace
is
used
to
extract
visibility
and
then
a
user
space
agent
processes
that
asynchronously
and
then
kills
a
process
reactively
and
in
the
meantime,
until
that
that
kill
signal
has
been
sent,
the
process
can
continue
and
actually
do
more,
more
damage.
A
A
Your
data
could
have
already
been
exfiltrated
so
being
able
to
prevent
the
malicious
event
from
occurring
rather
than
just
saying:
hey
sorry,
something
really
bad
happened,
but
it
was
you
know,
200
milliseconds
ago,
it's
a
huge
difference
in
in
power
and
the
the
real
defensiveness
of
that
security
tool.
Yeah.
B
It
can
do
enforcement
actually
in
a
variety
of
kernel
subsystems.
We
are
kind
of
used
to
doing
enforcement
at
the
system
call
level,
so
this
would
be
something
like
setcomp
bpf
being
able
to
allow
like
allow
certain
system
calls
to
be
made
and
that's
a
great
way
to
reduce
the
attack
surface
of
the
kernel.
So
if
an
application
attempts
to
exploit
the
vulnerability
in
the
kernel
can
only
do
so
if
the
system
call
that's
vulnerable
is
actually
allowed,
another
example
would
be
something
like
else
lsm
or
sc.
B
Linux,
which
has
enforcement
points
deeper
down
in
the
in
the
kernel
and
tetragon
is
more
like
this.
It
can
actually
observe
and
enforce
across
the
entire
stack,
not
just
at
the
system
call
level
you
can,
of
course,
do
a
system
call
enforcement.
What
is
allowed,
what
is
not
allowed
if
tetragon,
but
you
can
do
more,
you
can,
for
example,
say
I
want
to
limit
access
to
certain
files
and
not
at
the
system
code
level,
further
down
when
the
file
system
is
actually
being
accessed.
B
So
even
if
the
file
excess
would
happen
through
some
other
mechanism,
that's
not
a
system
call.
We
could
still
detect
and
block
that
as
well.
An
even
better
example,
I
think,
is
the
name
spacing
and
the
the
escape
of
of
of
of
say
the
username
space
or
the
the
file
system
namespace.
So
let's
actually
scroll
down
and
skip
a
bit
and
look
at
that
specific
example,
because
I
think
that
will
make
a
lot
of
sense,
but
here's
the
picture
so
a
very
common
example.
I
think
this
is
the
main
way.
B
How
containers
usually
escape
is
there's
a
kubernetes
part
running
or
just
a
container,
and
this
container
is
aware
of
some
vulnerability
in
the
linux
kernel
and
it
will
make
a
system
call.
That
does
then
exploits
the
kernel
vulnerability,
and
this
vulnerability
allows
to
execute
code
to
escalate
its
privileges.
B
So
an
unprivileged
part
which
does
not
have,
for
example,
caps's
admin
capabilities
or
is
not
running
as
root
can
gain
these
capabilities,
even
though
it's
not
supposed
to
do
so
and
then
break
out
of
the
container
and
tetragon
can
essentially
observe
when
this
scope
of
privilege
changes
in
real
time
and
immediately
kill
the
process
before
it
can
even
continue.
So
essentially
before
the
system
call
even
returns.
B
The
process
is
killed.
Typically,
a
system
like
a
a
part
here
would
exploit
the
kernel
and
then
wait
for
the
system
call
to
return,
and
then
you
can
do
something,
for
example,
install
a
rootkit
or
make
that
make
the
damage
permanent,
install
a
system
unit
file
or
deploy
a
static
pod
onto
the
node,
like
a
variety
of
ways
to
then
make
the
attack
permanent,
but
for
that
it
needs
to
be
able
to
execute
further
code.
B
We
do
have
an
example
down
here
on
how
that
actually
looks
like
so:
let's
scroll
down
and
we'll
go
back.
So
how
does
this
automatic
mitigation
of
privilege
and
container
escapes
actually
look
like
and
we're
using
here
an
example,
the
cv?
This
is
a
vulnerability
in
the
net
filter
in
the
iptables
kernel,
subsystem
that
essentially
allows
to
gain
capsis
admin
privileges.
B
If
the
kernel
is
vulnerable
to
this
book
with
tetragon,
we
can
create
a
policy
that
looks
it's
a
bit
shortened,
but
it
will
look
like
this,
which
is
essentially
a
kubernetes
crd,
and
if
you
read
through
this,
it's
kind
of
easy
to
understand.
It
basically
says
if
the
capabilities
of
the
process,
change
and
capsis
admin
is
now
allowed,
then
execute
an
action
and
kill
the
process
like
send
sent
to
signal,
kill
which
will
kill
the
process.
B
If
we
install
this
policy
into
into
tetragon
and
then
we,
for
example,
run
this
cv.
This
exploit
script
is
essentially
the
demonstration
that
this
cv
works.
I
will
essentially
set
up
a
container
name
space
and
then
exploit
the
kernel
block
and
pop
a
rule
root
shell,
and
we
can
see
that
when
we
run
that
script,
usually
it
would
actually
succeed,
and
then
you
have
a
root
shell.
In
this
case
it
just
gets
killed
and
the
rutgeole
never
happens,
because
tetragonal
observed
that
the
capability
change
happened
and
immediately
killed
the
process.
B
B
A
B
This
can
be
done
on
for
any
workload
on
linux.
Essentially,
there
is
tetragon
is
kubernetes
aware,
so
it
does
actually
understand
part
data
and
so
on,
but
that's
why
I
listed
here
in
the
policy.
If
we
go
back
here,
the
policy
api
there's
also
just
json,
so
you
can
actually
just
feed
in
a
json
policy
that
is
not
does
not
contain
anything
about
kubernetes.
It
could
be
my
binary
x
can
do
these
type
of
system
calls
or
if
a
binary
matching
this
pattern
escalates
privileges
kill
it.
There's
nothing
cubanetta
specific.
B
With
about
tetragon
itself,
the
agent
does
have
kubernetes
integration
and
I'm
using
kubernetes
as
an
example,
because
I
think
it's
one
of
the
primary
use
cases
that
tetragon
targets
is,
but
you
can
of
course,
use
tetragon
outside
of
kubernetes
as
well.
You
could
use
it
with
other
container
runtimes
or
choose
container
runtimes
native
processes,
or
even
inside
of
virtual
machines
as
well.
A
And
I
think,
having
that
kubernetes
awareness
is
what
makes
the
output
from
tetragon
so
useful.
You
know
you're
gonna,
see
if
you're
in
observability
kind
of
mode,
if
you're
not
killing
things
you're
still
gonna
see
traces
being
generated.
That
will
show
you
exactly
what
process
inside
which
part
in
which
namespace
is
responsible
for
the
potentially
suspicious
event,
yeah.
B
B
B
So,
let's
scroll,
let's
zoom
in
a
bit
there
we
go
so
we
see
each
line
essentially
represents
an
event.
So
we
see
that
there's
a
process
execution
use
a
local
bin,
curl
dasher
github.com.
Then
we
see
the
dns
resolution
what's
happening.
We
see
the
ip
that
is
being
returned,
so
this
is
an
example
of
tetergon
actually
understanding
the
dns
protocol
resolution.
What
happens
on
the
wire
there?
Then
we
can
see
the
connect
system
call.
We
see
it
connects
to
the
ip
that
was
returned
on
port
80
because
we
did
not
specify
https.
B
So
it's
going.
Actually
it's
unencrypted
port
80.
github
doesn't
like
that.
So
we
see
the
http
processing.
We
see
an
http
request.
We
see
this
as
a
get
to
slash,
but
then
because
github
wants
us
to
use
ssl
tls,
it
returns
a
301.
Hey,
please
actually
not
go
here.
You
need
to
talk
to
me
on
port
443,
which
means
then
coral
does
another.
Dns
look
up
gets
the
same
ip
again
and
now
it
does.
It
connects
to
port
443
on
github,
and
then
it
gets
even
better.
B
We
then
tetragon
understands
the
tls
handshake
of
the
protocol,
so
it
actually
understands
okay,
you're
talking
to
github.com,
that's
the
sni.
This
is
using
tls
1.3
and
we
have
negotiated
this
cipher.
We
actually
have
even
deeper
visible.
This
is
just
a
summary.
We
would
have
all
the
aspects
of
the
handshake
that
have
has
been
ongoing
here,
so
we
actually
see,
for
example,
if
this
was
using
tls,
pls,
1.1.0
or
something
we
would
see
that
as
well.
B
Let
me
see
that
the
process
actually
exits,
so
the
the
the
curl
process
exits
with
error
code
zero
and
then
we
also
see
the
the
tcp
connections
and
that
they
have
terminated,
and
we
see
that
the
amount
of
data
that
was
transmitted
and
received
on
those
as
well
like
they.
As
soon
as
a
tcp
connect
or
a
close,
is
observed.
It
will
actually
accumulate
the
data
and
understand
how
much
was
actually
transferred
as
well.
B
So
that's
an
example
of
the
of
the
of
the
cli
showing
the
the
kubernetes
integration.
The
kubernetes
integration
is
essentially
this
left
part.
Here.
We
can
see
that
this
is
the
d
in
the
default
namespace
a
part
running
or
a
pawn
name
test
dashboard.
If,
if
this
was
not
running
as
a
part,
you
would
simply
see
the
process
id
and
the
binary
name
here.
A
B
So
actually,
it's
maybe
a
good
point
to
talk
about
kind
of
why
we
have
created
central
goal,
because
a
major
reason
is
actually
this.
So
let's
go
back
and
because
the
short
answer
is
no,
it
can
actually
run
on
much
much
older
kernels
and
the
reason
why
that's,
why
that's
possible
is
because
we
have
invested
quite
a
bit
in
understanding
and
creating
something
that
does
not
require
very
recent
kernels.
So
let's
go
back
up
here.
Why
a
tetragon?
B
So
traditionally
these
were
kind
of
ways
of
gaining
visibility
into
the
system,
so
app
instrumentation,
changing
your
app
or
ld
preload
or
ptrades,
which
is
a
it's
an
early
on
debugging
interface,
that
the
kernel
allows
to
trace
processes.
What
system
calls
they're
making
they
provide
some
visibility,
they're
quite
efficient
and
ptrace,
is
also
transparent,
but
there
they
have
very
limited
enforcement
capabilities.
B
You
can
do
some
enforcement,
for
example,
with
ld
preload
like
loading
a
library,
but
an
app
can
simply
bypass
that
by
doing
static
linking
and
then
whatever
enforcement
capabilities
built
into
lt
pre-laws
preload
would
not
work.
Ptrace
itself
is
no
enforcement,
so
you
can
observe
and
then
do
asynchronous
enforcement.
But
that
leaves
that
race
window,
where
more
damage
can
happen,
which
is
why
the
kernel
team
or
the
alliance
chrono
actually
imposes
or
creates
or
provides
a
variety
of
built-in
mechanisms
to
do
security.
B
I
think
well-known,
is
second,
I
think,
which
is
15
16
years
or
even
older.
By
now.
Sc,
linux
and
lsm.
Lsm
is
a
framework,
so
specifically
in
this
case
would
be
something.
For
example,
like
lsm
ppf
secump
is,
is
great,
it's
transparent,
it's
efficient,
but
it's
only
enforcement
at
the
system
call
level
and
it's
very
limited
in
what
you
can
see.
B
They
need
to
understand
the
actual
attack
vector
so
they're
they're,
very
much
focusing
on
oh,
I
I
want
to
only
allow
what
is
known
and
what
is
good,
they're,
not
able
to
understand
okay,
privilege
escalation
has
happened
that
shouldn't
happen.
Let
me
just
kill
the
process
which,
for
most
security,
vendors
left
essentially
the
kernel
module
path
which
is
efficient.
It
is
transparent
and
it
is
extendable,
but
it
has
downsides
as
well.
In
many
environments,
you
cannot
load
a
kernel
module
loading,
a
kernel
module
is
a
security
thread
on
its
own
right.
B
I
think
it
can
crash
your
kernel.
It
can
compromise
your
kernel
and
it's
also
very
challenging
to
upgrade
a
linux
kernel
module
without
actually
turning
off
the
functionality
and
then
turning
it
on
again.
Ebpf
solves
all
of
these
problems,
which
is
wonderful,
and
that's
essentially
why
we
have
created
tetragon
right.
So
it
gives
us
this
efficiency.
It
gives
us
the
transparency,
the
app
doesn't
even
notice.
It
is
being
observed,
it's
being
monitored.
B
It
gives
us
the
synchronous
enforcement
that
lsm,
that
that
I
mean
that
acid
linux
has
as
well,
but
it's
also
extendable,
so
we
can
actually
make
the
kubernetes
we
can
make
the
kernel
cubeness
aware
or
we
can
build
in
concepts,
new
concepts
or
new
protocol
parsers
that
are
needed
now
and
when
the
kernel
version
that
somebody's
using
was
created
when
were
kind
of
unknowns
or
not
expected,
and
it
also
gives
us
this
deep
visibility
into
all
layers
of
the
stack.
So
tetragon
works
even
with
four
point
x.
B
A
B
Exactly
right,
so
in
this
picture
we
see
this
kernel
runtime
box
with
the
ebpfb
logo
in
here,
and
what
this,
what
this
kernel,
runtime
or
ebpf
runtime
provides,
is
a
couple
of
things.
First
of
all
of
list
mentions
a
verifier.
The
verifier
will
ensure
that
it's
not
allowed
to
load
any
programs
that
can
harm
the
kernel,
so
you're
not
allowed
to,
for
example,
load
a
program
that
loops
forever
ebpf
does
support
loops,
but
they
need
to
be
bounded,
so
you
cannot
actually
load
a
program
that
would
then
spin
forever
and
just
halt
your
kernel.
B
You
can
also
not
just
unless
you
have
very
specific
privileges.
You
can
also
not
just
access
random
kernel
memory.
You
can
also
not
just
write
into
code
random
kernel
memory,
kernel
modules
can
do
this
and
if
they
do
that's
when
they
crash
the
kernel,
ebpf
programs
are
also
subject
to,
for
example,
all
the
variables
that
an
ebpf
program
uses
they
need
to
be
initialized
like
the
verifier
ensures
that
there
is
no
random
kernel
memory
state
in
evpf,
program,
variables
and
so
on.
B
B
So
a
good
example
is,
let's
say,
facebook
and
google.
They
use
ebpf
at
the
lowest
levels,
for
example,
to
mitigate
gcp
xeros
tcp.
Serial
data
is
do
low,
polarizing,
ddos
protection
security
issues
in
the
bpf
runtime
are
would
be.
Are
a
major
would
be
a
major
problem
for
for
this
company,
so
there's
a
lot
of
eyes
on
ebpf
and
and
and
the
verifier.
So
I
think
that's
that's
essentially
the
main
difference
to
a
linux,
kernel,
module
and
ebpf.
A
And
I
think
we
could
see
you
know
in
the
bpf
conference
that
happened
last
week.
You
know
there's
folks
from
google
and
meta,
and
some
of
these
really,
you
know
high
scale
companies
who
are
extremely
involved
in
in
how
ebpf
works
precisely
because
they're
so
reliant
on
it
and
it
needs
to
be
safe
for
them
to
use.
B
A
So
speaking
of
how
people
use
a
product
like
tetragon,
now,
of
course
this
is
something
that
we're
open
sourcing,
but
it's
been
used
in
production
for
a
while.
So
I
think
we
we
have
some
experience
that
we
can
use
to
talk
about
how
we
imagine
users
will
leverage
tetragon
you
know.
Is
it
just
to
protect
tactically
against
particular
cves,
or
are
people
using
it
more
broadly
to
defend
an
entire
cluster
against
a
broad
range
of
possible
attacks.
B
Yeah,
let's
look
at
a
couple
of
views
because
we
have
listed
them
down
here.
Let's
look
at
them:
let's
do
the
let's:
let's
do
the
monitoring
of
access
to
sensitive
files
first,
this
is
a
good
start,
something
that
a
lot
of
users
are
doing
relatively
early
on.
This
is
showing
tetragon
integration
with
splunk.
This
is
the
sim
integration
that
exists
and
in
this,
in
this
version
of
like
we're,
essentially
monitoring
access.
In
this
case,
it's
monitoring,
access
to,
etc,
password
other
good
examples
would
be.
B
So
I
think
this
is
the
first
level
where,
across
the
fleet
of
of
cluster
systems,
whether
it's
with
cubans
or
without
you
can
gain
values
from
observing
monitoring
access
to
sensitive
files,
even
in
this
case
it's
actually
highly
useful
to
understand
kubernetes
context
right
in
this
case,
we
not
only
understand
like
the
name
space
and
the
pod
name
of
the
of
the
workload
that
has
made
the
access.
We
can
also
understand
the
the
container
image,
so
they
can
actually
see
the
version
of
the
application.
For
example,
we
see
the
uid
and
so
on.
B
This
is
just
showing
a
couple
of
columns.
We
have
a
lot
of
metadata
visibility
that
we
can
that
we
can
extract.
Another
example:
is
detection
of
weak
tls
ciphers
so,
for
example,
to
enforce
tls
compliance
monitoring?
So,
yes,
great,
your
apps
are
using
tls.
How
do
you
know?
Maybe
I
can
zoom
in
a
little
bit,
so
we
see
this
a
bit
better.
How
do
you
actually
know
whether
whether
your
apps
are
using
a
tls
library
that
is
using
a
modern
version
of
tls,
and
how
do
you
know
whether
the
ciphers
they
use
are
secure?
B
How
do
you
know
whether
the
key
length
that
are
being
negotiated
are
above
128
bits,
for
example,
and
with
the
tls
monitoring
here
we
can
actually
see
what
is
being
what
is
being
negotiated,
and
if
any
parts
use
insecure,
ciphers
or
weak,
keel
length
or
cipher
key
length,
then
we
can
tell,
and
we
can
tell
exactly
which
pod,
which
container
image
version
and
so
on.
We
even
see
the
sni,
so
we
even
see
okay,
what
was
the
remote
destination
when
this
was
was
used?
B
B
B
This
is
available
as
a
splunk
app,
for
example,
and
it
combines
the
view
we
had
in
the
cli
before,
like
the
network
visibility
with
the
system
call
and
runtime
visibility,
it
actually
builds
a
tree
of
what
an
app
is
actually
doing
and
we
can
see
if
we
zoom
in
a
bit.
We
see
that
there
is
an
and
kubernetes
name
space,
a
par
name,
and
then
we
see
the
container
runtime
outside
we
see.
This
is
a
node
app,
and
this
node
app
was
then
compromised
and
a
reverse
shell
was
invoked
using
netcat.
B
You
see
the
nc
binary,
which
is
reaching
out
to
an
external
domain
here,
which
the
name
says:
it's
not
a
reverse
shell,
of
course
right
and
we
see
the
attacker.
The
attacker
are
using
curl
to
actually
access
in
this
case,
elasticsearch
and
then
use
curl
again
to
do
an
hdb
put
to
upload
something
onto
an
sf3
bucket.
So.
B
Level,
so
not
just
monitoring,
but
now
we're
also
investigating,
maybe
for
forensic
use
cases
right.
So
you
can
store
all
of
this
data
in
a
sim
and
then
looking
back.
Oh,
what
actually
went
wrong
like
this
part
behave
really
for
some
reason
or
like.
Apparently,
there
was
an
attack
from
this
time.
Time
to
this
time
step,
you
could
really
dig
in
and
figure
out
what
was
executed,
who
reached
out
to
whom
and
so
on,
and
then
at
the
last
level
is
a
section.
B
That's
what
we
have
added
most
recently
is
this
enforcement
capability,
where
we
use
all
of
this
visibility
for
in
for
enforcement
and
our
goal,
and
what
we
are
looking
to
solve
is
to
go
away
from
having
to
understand
every
single
cv,
every
single
attack
vector
and
instead
actually
say.
Well,
we
have
isolation
guarantees
that
users
want
such
as
the
container
name
space
boundary
or
this
process
is
supposed
to
be
not
running
privileged
and,
if
that's
violated,
kill
it.
B
A
A
B
Exactly
yeah,
and
I
think
network
policy
is
a
very
good
example
where
we
can
actually
combine
tetragona
and
network
policy
together,
which
we
call
runtime
awareness
or
policies.
So
what
let's
just
mention
is
cubanez
network
policies
like
if
you
oversimplify
it
a
ton,
it's
essentially
a
policy
that
I
can
show
one
here.
That
essentially
says.
Oh,
I
want
my
front
end
pause
to
be
able
to
talk
to
my
backhand
parts,
or
it
could
be
my
front-end.
A
B
Should
be
able
to
talk
to
cider,
10-8
or
something,
but
the
granularity
of
kubernetes
network
policies
on
the
pod
level.
It's
written
here,
like
the
the
network
policy,
doesn't
care
whether
it's
curl,
that's
invoked
in
the
pod
or
whether
it's
the
python
script,
or
whether
it's
a
node,
app
or
something
else,
or
if
it's
multiple,
a
multiple
container
pod,
they
can
all
do
and
produce
network
packets
or
receive
them.
The
network
policy
won't
care.
B
It
will
just
allow
based
on
part-to-power
level
or
based
on
the
ip
level,
adding
tetragon
to
the
to
and
combining
that
with
psyllium
and
to
the
psyllium
network
policy,
which
is
the
crd
that
offers
we
have
richer
network
policy
options.
We
can
actually
add
runtime
context.
So
if
we
scroll
in
here
and
look
at
this
from
runtime,
so
we
can
see
that
this
policy
says
that
this
policy
should
apply
to
all
positive
label
name
frontend,
and
it
should
then
allow
egress
outgoing
connections
to
all
parts
with
the
label
name
packet.
B
But
then
we
want
to
lock
it
down
further.
We
want
to
say
yes,
you
can
do
so,
but
only
if
the
binary
is
called
app.pi
or
pi
here,
in
this
case
a
python
app,
and
it's
only
if,
if
the
app
is
not
privileged
and
it's
just
an
example,
we
could
use
other
filtering
language
here
as
well.
We
could
also
parse
and
match
on
the
arguments
given
to
them
or
we
can
match
on
the
uid
or
a
gid
or
other
runtime
aspects,
but
essentially
allows
us
to
lock
it
down
further.
B
Another
good
example
would
be
just
a
container
name
inside
of
the
pod,
so
if
you
have
multiple
containers
inside
a
part,
just
okay,
I
only
want
my
init
container
to
do
this
connection,
but
not
the
actual
workload.
It's
actually
very
common
that
users
are
running
an
init
script,
a
patch
script
that
will
may
pull
some
secrets
from
world
or
do
this
and
this
and
this
and
this
in
its
crypto.
This
in
a
container
may
need
additional
privileges
and
additional
rights
that
the
workload
afterwards
should
not
have.
B
So
if
the
workflow
gets
compromised,
it
should
not
be
able
to
access
wall
just
because
the
inner
script
required
access
to
world.
While
it
was
bootstrapping
and
with
runtime
or
combining
these
policies,
we
could
actually
achieve
that.
I
think
this
is
very
exciting,
which
means
that
if
we
take
this
example,
if
the
car
gets
compromised,
it
gains
privileges
and
then
it,
for
example,
extracts
data
from
the
local
disk.
B
It
could
not
upload
that
data
anywhere
and
you
could
not
even
talk
to
the
back
end
paul
here,
because
it's
no
longer
unprivileged,
so
I
think
that's
also
very
powerful.
It's
a
good
example
just
like
if
the
visibility
we
saw
before
combining
runtime
information,
network
security
or
network
level
information
is
incredibly
powerful.
A
All
right,
if
you're
out
there
and
you
have
questions
about
tetragon
and
everything
we've
been
talking
about
today-
do
type
them
in
get
get
your
questions
in
now
and
we
do
have
a
question
here:
it's
it's
a
little
bit
off
topic,
but
let's,
let's
go
with
it
anyway.
It's
about
the
difference
between
a
service
proxy
and
a
service
mesh
in
kubernetes,
and
we've
been
talking
about
service
mesh
quite
a
lot
recently
as
well,
and
so
I
guess
it's
it's
reasonable
to
try
and
talk
about
this.
A
B
B
Is
known
kind
of
maybe
if
we
go
back
to
a
picture
here
that
helps
to
understand
a
bit
better
if
we
zoom
in
on
the
part
here
right,
so
we
have
paul
running
service.
Mesh
is
known
to
traditionally
run
so-called
sidecar
proxies
and
the
side
car
proxies
of
running
inside,
of
the
pod
kind
of
where
the
yellow
ebpfvs
right
now
essentially
inside
of
the
pot
they
get
injected.
B
A
B
To
give
to
gain
visibility
and
also
allows
to
do
enforcement,
but
it
comes
at
the
very
high
cost
and
it
requires
to
run
if
you're
on
a
thousand
parts,
you
need
to
run
a
thousand
sidecar
proxies,
which
for
some
people
can
be
worth
it.
But
it's
also
it's
not
a
very
efficient
way
of
achieving
this.
So
with
psyllium
service
mesh,
we
are
looking
to
provide
the
same
functionality.
B
A
And
I
guess
we're
in
some
ways
making
this
question
a
little
bit
more
confusing
to
answer
in
psyllium
service
mesh,
because
the
distinction
between
a
service
proxy
and
a
service
mesh,
the
functionality
will
be
provided
by
psyllium.
So
it's
going
to
be
harder
to
draw
a
line
and
say
this
is
service
mesh,
and
this
is
service
proxy,
because
they'll
be
offered
by
by
the
same
components.
A
B
Yes,
we
just
pushed
that
rc2,
I
think
last
week.
Absolutely
yes,
I
think,
there's
one
release
block
left
on
the
service
mesh
side
before
we
can
push
out
1.12,
so
we're
getting
very
close
to
the
final
final
release
I
mean.
Obviously
next
week
is
kubecon.
The
team
will
be
busy
with
that
as
well,
but
I
think
112
will
come
shortly
after
kubecon.
B
A
I
think
this
is
really
going
to
be
a
question
about
making
sure
that
your
policies
that
you're
installing
are
well.
You
have
trusted
code.
If
you're
loading
ebpf
code
into
your
kernel
make
sure
it's
code
that
you
trust,
don't
just
you
know,
download
an
ebf
program
from
the
internet
and
you
know
ebpf
is
powerful,
so
use
with
care.
Yeah.
B
A
B
A
I
don't
think
there
is
a
a
way
to
say
read,
you
know
some
part
of
user
space
memory
or
kernel
memory,
but
you
do
need
to
be
a
little
bit
cognizant
of
what
your
what
you're
extracting
and,
where
you're
putting
it
and
when
you're
logging
data
you
want
to
make
sure
that
that
those
logs
don't
contain
secret
information,
for
example.
So
there's.
B
B
A
So
we've
got
a
great
question
here
about
why
it's
called
tetragon
and
I
actually
have
a
picture
that
I
want
to
to
show
to
explain
this
one.
This
is
actually
from
my
talk
that
I'm
going
to
be
giving
at
securitycon
next
week,
so
tetragon
is
or
tetragoniska
is
actually
a
category
of
bees,
and
so
there
are
these
tetragoniska
bees
that
are-
and
I
love
the
description
of
this
particular
one,
because
I
think
it's
very
apt.
It's
a
very
small
bee
and
it
builds
unobtrusive
nests.
A
It
produces
large
amounts
of
honey
and
it's
not
a
threat
to
humans.
I
feel
like
that's
a
very
good
kind
of
parallel,
for
what
tetragon
is
it's
very
small
probes?
It's
using
very
you
know
small
amount
of
resources,
it's
very
efficient,
and
yet
it's
going
to
produce
a
large
amount
of
very
sweet
information.
A
A
I
will
be
showing
at
least
one
or
two
cases
in
my
talk
on
tuesday,
so
if
you're
there
at
security
con
the
co-located
event
at
kubecon,
do
you
come
and
watch
that
the
videos
will
be
available
shortly
afterwards?
I'm
sure
we'll
be
showing
it
in
a
future
episode
of
echo
as
well
so
yeah.
There
will
be
examples.
There's
also
going
to
be
an
online
tutorial
that
we're
putting
together
so
that
people
can,
you
know,
try
it
out
for
themselves
all
right.
A
So
I
think
I
mean
there's
a
lot
of
people
saying
some
really
like
nice,
positive
things
about
tedcon,
which
is
which
is
wonderful.
So
thank
you
very
much
everyone
for
your
positive
comments
and
I
think
that's
pretty
much
everything
we
wanted
to
cover
today
right
unless
you
have
any
last
words,
you
want
to
add
thomas.
B
I
would
say
we're
super
excited.
We
can
now
also
engage.
We've
been
engaging
with
customers
on
this
for
a
long
time
several
years
and
we're
super
excited
that
we
can
now
collaborate
with
the
entire
open
source
community
so
help
us
take
us.
Take
this
to
the
next
level.
I'm
sure
we
there
is,
we
see
so
much
potential
with
tetragon,
and
I
really
feel
like
now
is
the
perfect
time
to
let
as
many
people
as
possible
to
try
it
out
to
contribute
and
to
build
stuff
with
tetragon
right.