►
From YouTube: CNCF Security TAG Policy WG 2021-06-09
Description
KubeArmor by Rahul Jadhav
B
C
D
D
E
D
A
Good
to
me
all
right,
hi
everyone-
this
is
jim
beguardia
and
we
are
kicking
off
our
working
group
meeting
for
june
9th.
So
welcome,
and
we
have
quite
a
few
topics
on
the
agenda
so
we'll
dive
right
into
it.
I
think
the
first
topic,
thank
you.
Rahul
rahul
from
aquinox
is
joining
us
to
do
a
presentation
on
coupe
armor
and
there's
a
link
to
the
presentation
in
the
docs
I'll
stop
my
screen
share
and
hand
it
off
to
rahul.
B
F
B
Right,
so
let
me
let
me
start
my
video,
so
I'm
going
to
talk
about
cube
armor,
but
you
know
just
before
going
into
cube
armor
a
quick
introduction
about
you
know
myself
and
equinox.
So
you
know
at
economics,
we
have
been
working
on
container
runtime
security,
so
network
policy
enforcement
system
policy
enforcement
and
data
policy
enforcement
put
together
is
what
we
are
working
on
360
degree,
runtime,
security
controls
and
cube.
Armor
comes
in
the
context
of
systems
policy
enforcement.
B
Okay,
so
the
problem
statement
here
is:
we
have
several
alerting
engines
when
it
comes
to
systems
policy,
controls
but
cube.
Armor
is
the
first
systems
policy
enforcement
control.
I
know
that
there
are
few
organizations
out
there
who
do
policy
enforcement
as
well,
but
none
of
that
is
available
in
open
source.
So
we
decided
to
keep
this
project
in
open
source
so
that
we
can
get
all
the
feedback
that
we
can
possibly
from
the
devops
development
community.
B
The
next
the
the
point,
the
primary
problem
statement
that
we
came
across
with
system
policy
enforcement
is
that
you
know
it's.
It's
extremely
difficult,
getting
silence,
app,
armors
deployed
and
even
if
you
get
it
deployed,
if
you
have
to
make
any
changes
at
a
later
point
of
time,
it's
extremely
difficult.
It's
extremely
hard,
there's
a
lot
more
chances
that
you'll
get
it
wrong
and
the
impact
not
only
has
on
that
particular
container,
but
it
has.
The
impact
could
be
on
the
overall
host.
So
it's
it's!
It's
pretty
tricky
most
of
the
times.
B
B
B
B
Quickly,
you
know
from
the
mitre
attack
framework.
What
I
wanted
to
depict
from
this
particular
slide
is
that
when
it
comes
to
network
versus
systems
based
attacks
techniques,
this
is
the
snapshot
from
miter.
What
we
see
here
is
that
a
lot
of
lot
of
defense
techniques,
which
are
which
are
specifically
in
the
context
of
net
systems,
policies
that
network
policies.
Yes,
of
course,
the
network
policies
have
an
important
place
role
to
play
that
you
know.
B
If,
if,
if
a
deployment
or
platform
is
configured
properly,
without
with
the
best
network
policies,
you
might
you,
may
you
will
be
able
to
prevent
the
attacker
coming
into
the
coming
into
your
network?
But
if
you
assume
that
the
attacker
is
already
in
your
network,
what
you
need
is
you
know
how?
How
do
you
prevent
the
lateral
lateral
movement,
and
how
do
you
make
sure
that
your
existing
systems
are
hardened
enough,
such
that
none
of
the
you
know
none
of
the
data
exploits
or
data
exfiltration
can
happen.
B
So
that's
where
systems
based
policies
comes
into
picture,
and
you
know
what
we
have
done
is
we
have
tried
to
go
through
all
the
miter
based
defense,
primitives
that
are
mentioned
in
the
mitra
attack
framework.
We
try
to
check
if
we
can
map
it
to
cube
armor
policies.
Now
we're
not
only
depending
upon
so
alerting
is
of
course
important,
but
in
some
cases
the
rules
are
so
straightforward
that
blocking
it
makes
more
sense,
for
example,
deleting
the
system's
binary
files
in
a
predefined
place.
B
If
someone
tries
to
delete
some
some
binary,
it's
better
to
lock
it
than
to
simply
give
an
alert
and
I'll
tell
locking,
is
or
preventing
or
blocking
an
access
in
context
of
falco
or
tracy
is
possible.
I'll.
Try
to
explain
in
this
subsequent
slides
how
cube
armor
will
be
different
in
that,
but
before
going
there,
some
of
the
challenges
with
respect
to
systems
criminals-
and
you
know
that
we
faced
now
the
best
primitive
out
there
available
for
sisters.
Policy
enforcement
is
of
course
lsm's.
I
guess
there
is.
B
There
is
absolutely
no
doubt
about
it
and
there
are
several
other
lessons
available:
app
armor
s,
linux,
mac,
tumor
and
so
on.
There
is
a
new
breed
of
lsm
that
is
coming
up
in
the
form
of
bp
of
ellison,
essentially
krs
and
kernel
security
instrumentation,
which
allows
one
to
insert
the
ebp
of
white
code
at
lsm
hooks.
B
The
biggest
advantage
of
linux,
security,
modules
or
lsms
are
that
they
do
not
support
from
top
down
or
time
to
checkout
time
to
time
to
use
problem.
It's
not
an
asynchronous
enforcement,
it
is
inline
enforcement.
I've
got
a
slide
which,
which
talks
about
it.
But
the
problems
are
these.
These
primitives
are
not
integrated
with
kubernetes
or
docker
container
platforms.
B
The
learning
curve
for
these
policy
languages
is
extremely
steep.
It's
it's.
It's
very
easy
to
get
it
wrong.
If
someone
unknows
or
tries
to
tries
to
attempt,
where
tries
to
raise
an
attempt
to
specify
this
policy
and
and
then
the
bigger
problem,
is
that
every
lsm,
even
within
app
armor,
there
is
version
one
two
and
three
and
depending
upon
your
platform,
you
might
have
version
one
two
and
three
and
the
behavior
differs
drastically.
What
kind
of
system
policies
that
can
be
enclosed
infrastructure.
B
So
it's
all
sorts
of
complexity
with
cube
armor,
where
we,
the
the
aim,
is
that
we
try
to.
We
try
to
hide
this
complexity
behind
the
declarative
language
of
yamls
and
make
sure
that
the
user
can
specify
gammas
as
the
policy
and
internally
cube
armor
will
ensure
that
the
right,
primitive
is
used
for
system
policy
enforcement.
Indeed,
armor
slings,
depending
on
the
platform
that
you're
using
or
bpa
1sm
in
the
future
or
both
bpf
lsm,
is
a
stackable
lsm,
which
means
that
it
can
work
with
our
power
and
ac
linux.
B
So
so
there
is
a
chance
of
using
either
or
and
as
well.
In
this
case,
then
there
are
other
primitives
available,
of
course,
because
that
comp
is
available.
But
but
you
know
the
second:
the
primary
problem
is
that
it's
a
one-way
transition
to
restricted
state.
Once
you,
you
know
the
dynamic
changes
once
the
container
starts,
it's
not
possible,
so
you
have
to
enforce
all
the
primitives
that
you
want
during
the
start
of
the
containers.
B
This
is
the
primary
reason
why
it
has
limited
adoption
till
date
and
then,
of
course,
the
user
space
controls,
which
I
won't
go
into
the
details
in
the
preload.
It's
a
very
you
know
it
doesn't
even
come
into
the
same
strata,
but
I've
seen
this
mentioned
in
in
couple
of
calls
before
so
so
that's
why
I
put
it
up
here.
I
know
it's.
It's
basically
application
based,
you
can
override.
You
can
hook
to
the
library
calls
not
the
system
calls.
The
library
calls
like
glibc,
any
dynamic
library
call
can
be
hooked
up
using.
D
B
B
So
I
talked
about
a
synchronous
control
versus
in
line
control.
Now
with
falco
and
tracy,
it
is
possible
to
get
an
alert
if
something
goes
wrong
or
if
a
rule,
fires.
The
only
way
to
do
some
enforcement
is
that
the
alert
is
sent
there
is
an
audit
alert
handler,
and
then
there
is
a
policy
engine
which
says
that
if
I
see
something
like
this
and
you
can
kill
the
malicious
process
and
then
you
know
you,
you
block
the
attack,
but
the
problem
is
by
the
time
this.
B
B
B
Krsi
is
something
that
we
we
are
working
towards
now,
which
will
allow
the
ksi
is
available
only
from
kernel
version
5.8
and
above
and
it's
still
here.
We
are
yet
to
see
that
kernel
in
production
environment,
but
we
are
hoping
that
in
another
year
or
so
it
will
be
the
goodness
and
we
are
hoping
to
make
use
of
kiara's
as
the
primary
point
of
policy
control
policy
enforcement.
B
What
are
the
key
design
elements
of
cube?
Armor
one?
Is
that
it
it's
of
course
the
kubernetes
native
engine,
which
is
it's
it's
a
kubernetes
operator
for
system-wide
security
policies.
You
specify
a
yaml
policy
as
an
input
internally
cube
armor
will
make
will
check
what
is
the
best
lsm
to
use.
What
is
the
best
primitive
to
use
in
the
context
of
linux
kernel
and
use
that
primitive
to
enforce
that
yaml
policy
specification
internally,
it
will
convert
that
yaml
into
app
armor,
possibly
or
it
might
convert
it
into
s
linux,
depending
on
the
platform
used.
B
Ebp
of
engine,
like
I
mentioned
before,
is
to
couple
audit
information
with
audit
alerts
with
the
kubernetes
metadata,
so
it
handles
lsm
deployment
complexity
like
here
I've
mentioned
you
know
the
app
armor.
There
is
version,
one
two
and
three,
and
even
in
case
of
s
linux,
there
are
several
versions
which
has
very
different,
very
different
policy
language,
very
different,
app
armor
and
s
linux
by
themselves
are
completely.
You
know,
they're
very
different
in
terms
of
how
they
enforce
policies.
B
We
don't
expect
an
administrator,
a
kubernetes
administrator
to
understand
app,
armor
and
silence,
and
also
you
can
see
that
by
default
gk
a
container
optimized.
Oh
it
ships
with
app
armor
versus
eks,
amazon,
linux,
2
ships
with
sln
x
by
default,
amazon,
2
linux
amazon,
doesn't
have
a
predefined
image
which
supports
our,
which
makes
it
even
difficult,
because
an
administrator
is
expected
to
know
both
armor
as
well
as
an
excellence
which
is
which
is
which
is
very
difficult
to
get
in
there.
B
You
know,
which
is
very
diff,
which
is
a
very
difficult
task
to
begin
with,
and
then
in
the
future.
As
we
see
the
maturity
of
krsan
or
bp
of
lsm,
as
we
call
it
now,
things
will
get
even
more
complicated,
even
though
it
will.
Even
though
there
is
a
possibility
of
things
getting
more
flexible
or
the
policy
enforcement
becoming
more
flexible,
it
will
also
become
more
complicated.
B
B
It
is
possible
to
audit
all
access
in
a
particular
path,
of
course,
falco
entries.
You
can
also
do
that.
We
we
can
also
block
any
credential
access
by
unknown
processors
to
this
particular
wordpress
configuration
file.
So
we
can
say
that,
apart
from
wordpress
configure
wordpress
processes,
no
other
process
should
be
able
to
cat
or
open
this
particular
file
we
can
block
during
the
computer.
We
can.
We
can
block
the
access
of
kubernetes
api
server
outside
of
certain
processes
and
we
can
block
the
execution
of
specific
processes.
B
B
This
is
how
the
demo
policies
look
like
for
the
for
the
demo
scenarios
that
I've
mentioned.
You
can
see,
you
know,
and
it's
it's.
If
you
go
to
the
github
page
of
cube,
armor
you'll
see
the
detailed
policy
specification,
but
essentially
the
block
action
is
what
use
cubomber,
it's
all
its
powers
now.
One
thing
to
note
here
is
that
cube.
Armor
also
has
alerting
engine,
which
means
that
not
only
can
it
block
things,
but
it
can
also
audit
things.
So
it
is
it
is.
B
Again,
I
I
just
wanted
to
you
know
one
of
the
challenges
that
we
felt
was
that
you
know
it's
extremely
difficult
to
for
anyone
to
come
up
with
a
set
of
systems.
Policy
build
a
set
of
systems
policy,
so
one
thing
that
we
are
also
developing
is
a
common
discovery
policy
discovery
engine
which
is
not
only
for
cube
armor,
but
which
can
also
auto
discover
systems
policy.
It
can
auto
discover
network
policy
and,
in
the
whole,
in
the
future,
hopefully
even
the
data
policies.
B
What
we
are
trying
to
do
here
is
we
are
taking
all
the
feeds
that
are
available
from
celium
calico
cni's,
cube,
armor
and
matching
it
with
the
metadata
from
kubernetes
client
and
we
are
building.
We
are
building
a
generic
policy
output.
This
generous
generic
policy
output
can
be
converted
into
cube
armor
system
policy.
It
could
as
well
be
converted
into
falco
policy.
It
can
be
converted
into
calico
network
policy
or
salem
network
policy
depending
upon
what
the
policy
type
is.
B
E
A
Next
steps:
yes,
sorry,
just
a
quick
question
on
that
last
point:
I
understand
it
correctly.
So
is
the
idea
that
when
you
say
to
detect
things
like
calico
network
policy,
so
network
policies
I
get
because
they're
fairly
standard,
although
there
are
some
extensions
that
calico
and
cilium
put
on
top
of
them,
but
other
policies
like
with,
if
there's
falco
rules
and
things
like
that
configured,
would
all
those
also
be
considered
detected
or
those
are
outside
of
the
scope
here.
B
B
Cube
armor
has
a
mode
called
a
visibility
mode
in
which
it
will
it
will
it
make
sure
that
it
imposes
least
control
overhead
by
making
use
of
ebpf
mechanism,
but
it
checks
for
file
file,
accesses
process
spawning
events
capability,
accesses
events
such
as
these
and
then
all
this
is
sent
a
system
logs
to
the
policy
discovery
module
which
in
turn
generates
a
generic
system
policy.
I'm
calling
it
knock
system
policy,
but
it's
it's
it's
a
it's
a
generic
language
and
then
from
this
we
can.
We
can
have
either
falco
or
cube
armor
system.
B
A
B
So
so
the
existing
rules
from
falco
we
are
not
touching.
We
are
not
even
going
there.
So
what
we
are
seeing
is
you
know
through
visibility,
what
we
see
that
these
are
the
possible
accesses
and
then
you
you
come
up
with
a
set
of
so
the
example
that
you
gave
is
with
falco.
If
someone
does
an
ssh
send
an
alert,
so
those
policies
remain
as
it
is,
those
won't
be
impacted,
so
it
doesn't
mean
here
that
the
discovered
policy
set
is
the
only
policy
set
which
is
allowed.
B
E
B
B
With
cube
armor,
what
we
are
trying
to
do,
additionally,
is
enforcement
as
well.
So
what
I
meant
here
was
that
you
know
you
have
falco
and
tracy
in
the
kernel
space,
the
evp
of
modules
of
falco
and
tracy.
In
the
kernel
space
they
can
send
an
alert
so
falco
and
tracy.
They
use
k,
probes,
other
ebp
footpoints,
which
cannot
do
enforcement.
B
They
can
look
into
the
metadata,
but
they
cannot
do
enforcement.
The
only
place
where
you
can
possibly
do
any
enforcement
in
kernel
space
is
lsm
hooks.
What
cube
armor
is
doing?
Is
it
it
does
both
one?
Is
it
has
auditing
engine
as
well,
because
auditing
engine
is
required.
Anyways,
we
don't
expect
administrators
to
directly
go
and
you
know
enforce
rules
block
or
deny
based
rules
directly.
So
auditing
engine
is
required.
Anyways
so,
but
but
falco
is
only
about
auditing
engine
cube.
Armor
is
trying
to
do
both.
B
Yeah
that
that's
a
good
question,
that's
an
ex!
So
so
we
internally,
you
know,
thought
as
to
what
we
should
be
doing
about
this.
Shall
we
be
using
falco
as
it
is
as
an
auditing
engine,
or
shall
we
be?
Shall
we
shall
we
be
restricting
cube
armor
as
it
is
for
enforcement
just
for
the
enforcement
purpose,
but
eventually
we
found
certain
use
cases
which
requires
that
you
know
certain
rich
auditing
to
be
in
place,
for
example,
rate
based
control.
B
A
A
One
is
that,
with
your
on
the
left,
you're
showing
that
tools
like
falco
and
tracy
would
require
some
enforcement,
some
separate
tool
for
enforcement
in
user
space,
and
that's
not
part
of
the
open
source
toolkits,
and
I
think
the
second
one
is
to
have
to
move
well,
the
second
one
I
also
mentioned,
which
is
to
move
that
enforcement
into
kernel
space
itself.
So
it's
not
an
asynchronous
process.
D
B
E
Yeah
so
then
my
follow-up
question
is,
then:
why?
Wouldn't
this
work
also
be
contributed
to
falco,
rather
than
creating
it
another?
Because
one
of
the
things
you
know
when
we
look
at
the
area
of
focus
that
I
am
focused
on
as
well
as
gus
from
my
team
who
is
on
skull,
is
multi-cluster
governance
right
and
security
and
compliance,
and
then
you
know-
and
we
are
looking
at
okay,
what
are
all
the
various
controls
we
have
to
put
in
place?
E
What
are
all
the
various
enforcement
points
we
have
to
put
in
place
right
and
it
seems
like
we
are
adding
more
and
more
of
different
kinds
of
things.
So
my
question
is:
if
falco
is
doing
a
piece
and
okay
falco
doesn't
do
enforcement?
Why
wouldn't
we
contribute
this
to
the
falco
community?
Why
are
we
creating
another
one.
B
Yeah,
so
that's
that's
a
good
question.
We
have
given
it
a
substantial
thought
before
starting
working
on
a
separate.
You
know,
project
altogether.
The
reason,
one
good
reason
that
I
mentioned
you
know
even
within
alerting
we
found
that
the
fundamental
design
of
falco
and
tracy
doesn't
allow
us
to
do
certain
things.
If
we
have
to
make
those
changes,
it's
going
to
basically
change
the
way,
the
fundamental
structures,
the
way
in
which
the
ebpa
modules
work.
It's
going
to
create
a
lot
of
change.
B
Yeah
an
example
would
be
like
a
rate-based
control,
let's
say,
for
example,
I
want
to
put
in
a
rule
which
says
that
I
I
want
to
allow
anything
about.
10
connects
per
second
from
this
particular
container
is
a
problem
if
you
have
to
apply
such
kind
of
rules,
and
this
kind
of
rules
are
best
applied
in
kernel
space,
because
if
you
are
sending
a
cisco
event
to
user
space
is
going
to
have
an
extreme
overhead.
B
D
A
G
D
D
So
I
think
the
the
legacy
of
having
that
early
days
prior
to
kubernetes
is
you
know
that,
yes,
it
has
a
big
community,
but
it
was.
It
was
purpose
built
with
a
different
purpose.
I
think
at
least
that's
from
my
opinion
again
having
used
it.
The
the
other
feature
that
I
liked
is
this
notion
of
kind
of
a
simplified
policy
language
trying
to
map
falco
rules
to
your
frameworks
and
the
specific
policy
goals
is
a
bit
tedious,
doable
but
tedious.
D
A
B
One
point
here:
we
we
found
that
even
this
is
this.
This
is
easy
to
understand,
but
coming
up
with
this
kind
of
rules,
it
is
it's
still
difficult.
You
know
and
that
that's
why
we
thought
that
giving
we
have
to
give
a
serious
thoughts
towards
auto,
discovering
such
policies,
enabling
something
called
as
visibility
mode,
which
visibility
mode,
allows
us
to
see
a
wide
variety
of
events
with
least
control
over,
and
we
make
sure
that.
A
So
one
other
kind
of
question:
you
know.
One
of
the
things
you
mentioned
earlier
like
in
the
presentation,
was
that
lsm's
are
difficult
to
configure
today
and
you
know:
there's
differences
in
those.
So
are
there
standard
set
of
policies
that
you
have
that
the
team
is
building,
which
translates
some
of
those
into
things
a
kubernetes
admin
can
understand
and
manage.
A
B
So
there
are
two
points
here:
one
is
you
know,
so
the
standard
policies,
the
the
good
news
here
is
that
with
s
linux,
there
are
already
a
lot
of
standard
policies
that
are
built,
but
those
are
built
primarily
from
the
host
perspective,
not
from
from
the
workload
perspective,
not
from
the
containers.
Individual
containers
perspective,
so
you
know
even
for
individual
containers
perspective
like
apache
and
nginx.
There
are.
There
are
s
linux
policies,
but
those
apaches
or
nginx
are
are
supposed
to
be
executed
directly
on
the
host.
B
So,
yes,
my
answer
would
be
to
some
extent
we
can
reuse
those
policies
already
defined
by
s
linux,
but
the
other
approach
that
we
are
looking
at
is
we
are
trying
to
look
at
sticks
which
define
workload,
specific
policies
already
rules
and
we
are
trying
to
convert
those
into
cube.
Armor
policies,
not
cube,
armor,
actually
degenerate
policies
and
then
make
sure
that
you
know
those
policies
can
in
turn
be
exported
to
either
or
factory.
A
Okay,
so
if
I
recall
correctly
in
the
pod
security
standards,
the
the
the
you
know,
recommendation
for
se,
linux
and
app
armor
is
okay.
Don't
change
the
defaults.
Whatever
is
configured
on
the
host
you're
gonna
you're
not
allowed
to
change
that
if
you're
running
in
in
a
restricted
mode
right,
but
here
what
you're
saying
is
okay
for
certain
workloads.
I
need
that
flexibility,
so
it's
better
to
control
it
on
a
per
workload
basis
versus
on
a
shared
host
yeah.
B
So
if
you,
if
you
see
the
cube
armor
policies
already,
they
are
at
the
name
space
level.
You
know
you,
you
can
have
either
a
host
based
policy
or
or
a
policy
which
is
at
a
particular
name
space
only
applied
for
a
particular
set
of
labels.
You
know
so
so
that
flexibility
with
that
does
that
will
that
be
good
enough
for
multi-tenancy
or
are
there
any
more
problem
statements.
A
B
D
E
So
rahul
just
so
I
I
know
I
got
it
right
right,
so
it
seems
like
we
can
use
this
to
provide
or
or
discover,
falco
rules
and
map
them
into
more
declarative
policies.
And
then
we
can
also
update
those
policies
and
get
them
get
it
to
update
the
underlying
falco
rules
and
make
sure
it's
in
place.
Did
I
get
that
all
right.
B
Well,
that's
that's
a
statement
I
would
make
in
the
context
of
this
slide,
but
this
this
particular
work
item.
You
know
it's
it's
I
would
say
this
is
a
highly
decoupled
work
item.
In
fact,
this
could
be
a
completely
different
world,
even
though
we
are
managing
it
as
part
of
armor
today,
but
this
discovering
a
policy
set
in
which
you
know
once
the
discovered
policies
could
be
mapped
eventually
to
falco
rules,
tracy
rules
or
trace
or
q
bomber
rules.
D
E
I
agree
with
you
robert,
because
the
way
I
think
about
that
is
almost
like
how
gatekeeper
bridged
oppa
rego
to
kubernetes
right.
It
allowed
you
to
specify
operega
policies
using
kubernetes
constraints,
which
then
from
our
open
cluster
management
project,
which
provides
that
multi-cluster
capability.
We
were
able
to
then
apply
that
across
multiple
clusters
right.
So,
if
this
gives
me
the
ability
to
represent
falco
rules
as
kubernetes
crs,
I
think
that
will
be
powerful.
E
B
Oh
well
well,
this
is
the
visibility
mode
in
cube.
Armor
is
already
there,
but
this
overall
engine
we
haven't
open
sourced
as
yet,
but
we
intend
to
open
source
this
whole
engine.
We
we
already
have
systems,
policy,
discovery
and
networks
policy
discovery,
but
the
data
policy
discovery
is
also
something
that
we
wanted
to
build
in
this,
but
but
that
could
be
a
future
to
do
just
with
the
network
policy
discovery
and
system
policy
disclosure,
it
would
be
powerful
enough.
You
know.
B
E
No,
no,
what
I
was
saying
is,
I
think
the
multi-cluster
capability
is
something
we
have
in
our
open
cluster
management
project
right.
So
we
have
a
built-in
country
policy
controller
that
can
deploy
capabilities
on,
to
manage
clusters
and
also
can
make
sure
it's
configured
etcetera
as
long
as
it's
all
represented
as
stupid
as
crs
right.
E
D
Just
one
thought
that
jaya
and
rahul
correct
me:
if
I
misunderstand
or
mistake
something
I
think
I
think
the
goal
there-
and
this
is
why
I
started
looking
at
q
bombers
so
falco
because
of
its
the
limitations
that
you
know,
rojo,
can
has
explained
and
can
go
into
much
deeper
weeds.
It's
not
going
to
work
for
highly
regulated
environments
that
have
really
really
stringent
requirements
on
user
space
versus
kernel,
synchronous,
inline
versus
async.
D
So
I'd
say
you
probably
want
to
look
at
if,
if
coupe
armor,
which
itself
has
operator
support
built
in
like
you,
don't
have
to
have
a
gatekeeper,
because
that
was
a
a
stove
pipe
exercise
because
it
wasn't
natively
kubernetes.
If
coupe
armor
is
natively,
kubernetes
correct
me.
If
I'm
wrong,
then
then
you
get
that
out
of
the
box
and
you
don't
have
to
create
falco
rules
via
this
tool.
D
B
A
A
Armor
policy
natively
right,
but
when
you,
what
you're
deploying
on
your
clusters,
is
no
longer
than
falco
rules
and
there's
no
need
to
wrap
a
falco
rule
into
a
cr
for
that
right
because
you're,
not
you,
don't
necessarily
need
to
run
falco
if
you're
running
group
armor
at
least
that
was
my
understanding
and,
of
course,
there's
a
lot
more
details
there
and
there's
probably
a
lot
of
other
trade-offs
to
consider,
but
at
a
high
level.
That's
one
interpretation
of
this
picture.
B
C
B
Know
you
know
describe
one
one,
one
thing
that
you
know
so
when
we're
working
on
the
miter
defense
framework
micro
attack
framework,
you
know
finding
out
the
defense
rules
in
most
of
the
defense
rules.
We
found
that
there
was
a
need
for
correlating
events
which
were
temporarily
situated.
You
know
we
had
to
apply
a
rate
limit
based
factors
so
as
to
reduce
the
number
of
false
positives.
We
were
trying
to
check
if
it
is
possible
to
do
this
with
tracy
or
falco,
and
we
found
that
you
know
it.
It
would
be
difficult.
B
You
know,
that's
where
you
know
a
lot
of
things
changed
for
us.
You
know
that's
where
we
went
into
this
and
in
case
of
mitre,
they
also
specify
in
what
all
things
have
to
be
blocked.
So
it's
not
only
about
alerting.
They
also
specify
that
there
is
no
reason
why
a
processor
should
access
this
or
delete
this
particular
file.
B
A
A
B
Yes,
we
certainly
would
like
to
you
know,
bring
this
to
cncf
and
that's
where
the
first
step
of
becoming
a
cncf
member.
I
cannot
took
that
first
step
of
becoming
a
cncf
member.
We
are,
we
are
hoping
in
eventually,
so
our
priority
today
is
to
make
sure
that
the
lsm
engine
which
q
armor
uses
is
robust
enough.
B
We
could
have
few
deployments
based
on
that
policy
engine.
The
policy
constructs
would
be
expanded
while
this
happens.
So
that
is
what
our
focus
is
today.
If
you
ask
me,
krsi
is
one
of
the
key
key
thing
with
krsi.
The
way
I
think
about
krsi
is
the
way
ebpf
changed.
You
know
the
net
filter
was
in
a
way
obsoleted
by
ebpf
based
policy
control
student
network
policy
enforcement.
I
see
the
same
thing
happening
in
the
context
of
lsm
the
s,
linux
and
app
armor.
B
A
A
Thank
you.
I
know
we
only
have
15
minutes
left,
but
this
is
awesome
also
happy
to
see.
You
know
the
the
pr
that
you
have
listed
or
the
issue
report.
I
should
say
we
don't
have
a
pr
yet,
but
let
us
know
how
we
can
help
with
you
know
the
policy
report,
mapping
or
any
other
thoughts
or
ideas
on
you
know:
potential
collaboration
with
efforts
with
the
work
group.
Surely.
A
A
Yeah,
I
saw
your
prs.
Thank
you
and
robert.
I
say
you've
already
added
it's
a
few
comments.
So,
let's
we
can
continue
those
discussions
and
there's
also
you
know,
there's
a
few
other
sections
I
know
aradna
you
had
mentioned.
You
were
interested
in
contributing
to
a
few
sections
and
there's
others,
which
you
know
I
was
going
to
self-assign
a
couple
this
week,
so
we
can
continue
to
make
progress.
Robert
you
had
asked
about
timelines.
I
I
did
not
specify
any
dates,
but
maybe
it's
a
good
idea.
A
D
C
D
A
D
A
A
D
A
Right
he
also
saw
the
announcement
I
posted.
I
saw
something
on
linkedin
as
well
on
oscar,
so
would
be
interesting,
maybe
in
again
in
a
upcoming
meeting,
if
anka
or
robert,
if
you
want
to
sort
of
give
an
output
or
update
on
if
things
have
changed
in
nascal,
1.0
or
any
interesting
highlights
from
that.
D
F
D
G
A
All
right,
okay
and
then
yeah,
I
think
the
other
items
we
had-
and
you
know
as
a
quick
demo
of
the
coop
bench
adapter
by
martin
j,
who
has
completed
his.
You
know
spring
mentorship,
and
then
we
can
quickly
just
cover
status
from
anushka
as
well.
As
you
know,
on
on
sunday,
we'll
cover
the
falco
and
then
stephen
can
cover
you
know
what
we're
doing
for
evaluating
image
scanners
in
terms
of
mapping
those
to
the
cr
as
well.
I
know
we
only
have
a
nine
minutes
left
merchandise.
Do
you
have.
F
F
Take
just
a
couple
of
minutes
so
if
the
screen
share
is
working
so
just
sharing
the
screen,
thank
you
so
much
to
the
to
everyone
and
to
the
entire
community
for
allowing
me
to
for
for
helping
me
to
complete
this
project.
So,
amazingly,
and
now
I'm
going
to
share
the
screen.
I
hope
my
screen
is
visible
and
my
terminal
is
visible.
Yes,
okay,.
A
F
So
I
have
already
created
the
cluster
now,
what
I'm
going
to
do?
Let
me
just
show
you
the
steps
that
we
follow.
So
what
is
cube
bench
adapter
so
that
the
cube
bench
adapter
will
run
the
cis
benchmark
checks
by
cube
pinch,
which
is
a
tool,
and
it
will
run
it
as
a
job,
a
job
then
that
job
will
run
inside
of
inside
our
binary
itself.
So
we
don't
need
to
worry
about
that
and
it
will
map
it
with
our
policy
report.
Custom
resource
definition
and
create
the
policy
report
object.
F
F
F
So
after
that
we
do
that.
That
is
also
done.
The
rbs
is
authorization
run.
Now
we
are
going
to
create
the
console.
So
what
does
that
cron
job
will
do
this?
Cron
job
will
run,
will
create
the
cube
bench
adapter
job
pods
running
and
they
will
get.
They
will
create
the
policy
report
that
we
needed
on
its
own
and
right
now
I
have
fixed
the
schedule
for
one
hour,
so
we
will
just
have
one
policy
report
created
for
now
and
after
every
hour
there
will
be
a
new
policy
report
created.
F
F
F
F
You
know
actually
I'm
showing
the
live
demo
itself,
so
it's
taking
some
time
to
create
the
job.
I
don't
know
why
right
now
is
because
it's
mainly
because
I
guess
the
speed
has
the
processors
are
running
on
zoom
as
well
as
vs
code
is
open.
So
maybe
that
may
be
the
reason,
but
that's
why
it
is
showing
no
resources
found
in
default
names.
For
suppose.
Let
me,
let's
see,
is
it
running
or
not
get
jobs.
So
what
will
happen
after
that?.
F
So
it's
scheduled,
but
it's
not
showing
as
of
now,
but
what
will
happen
after
that
that
that
this
crown
job
will
run
this
caller
cron
job
will
pull
our
policy
report
and
a
policy
report
docker
image,
and
it
will
run
the
job
inside
that
and
will
fetch
the
equipment's
outputs
and
after
fetching
those
cubans
output,
it
will
map
with
a
custom
resource
definition
and
create
a
policy
report,
so
what
I
can
do,
rather
than
running
it
inside
cron
job.
I
can
also
build
it
using
the
binary.
F
So
just
using
this
binary
policy
report,
it
will
get
created.
Hopefully,
let's
see
yeah
so
now.
This
is
what
is
happening
right
now
if
it
is
visible.
This
is
an
internal
job
that
is
ready
running
that
that
was
cuban
job
and
as
we
see
the
policy
report
is
created.
So
this
is
our
policy
report
that
has
been
created,
creating
policy
report,
and
this
policy
report
is
known
by
the
name
cubans.
F
So
we
can
see
that
we
are
getting
70
passes,
11
fail,
38
warnings
and
if
you
want
it
in
the
form
of
a
yml
file,
what
we
can
do
is
just
we
can
use
cubic
to
get
policy
reports
by
ml
in
the
form
of
a
particular
file
like
rest
dot
by
email.
So
we
can
use
that
q
vector
command
name
now.
Our
pi
ml
will
be
present
here
as
rest.ml.
F
So
this
is
our
policy
report
that
has
been
created
by
this
program
by
this
adapter,
so
that
that
policy
report
is
basically
created
based
on
the
mappings
of
the
custom
resource
definition.
So
that
is
how
it
looks,
and
the
cron
job
is
also
running
at
the
back
end.
Hopefully,
if
I
am
able
to
show
it,
I
guess
it
should
run
now
so
still
isn't
showing,
but
it
is
running
in
the
background
and
what
will
happen?
F
This
crown
job
will
automatically
create
the
policy
report
on
its
own
after
every
hour,
and
it
will
update
it
with
whatever
and
it's
not.
It
will
not
only
create
the
policy
report.
It
will
also
update
the
policy
report
on
its
own
if,
if,
if
the
policy
report's
name
is
same
like
here,
the
name
is
cubans,
and
if
the
another
policy
report
that
is
being
created
is
the
same
name,
it
will
be.
It
will
be
updated
with
the
latest
that
it
is.
F
That
was
a
project.
It
will
soon
be
pushed
in
the
official
repository.
I
have
already
created
the
pull
request
and
is
being
reviewed
by
jim
and
after
a
few
more
reviews,
it
will
hopefully
be
the
part
of
our
working
group
policy
report.
I'm
sharing
the
link
so
that
you
can
definitely
try
this
project
and
share
the
feedback.
F
A
C
I
don't
have
any
demo
yet
to
show
for
my
which
will
be
coming
up
next
next
meeting.
So
basically,
I'm
working
on
image
of
an
origin
scanner
for
focal
point
for
proper
finances,
so
I'll
be
using
trivia.
Basically,
we
are
meant
to
compare
between
truvia
and
claire,
so
claire
has
to
be
run
on
what
is
it
called
major
services?
C
Ytv,
you
know,
can
be
done
locally
for
us
to
create
a
policy
resource
group
for
that.
So
I
think
obvious
doing
that,
because
this
week
was
actually
for
the
comparison
so
more
on
the
development
to
be
coming
as
from
next
week.
So
I
think
that's
that's
what
we're
doing
and
also
the
themes
from
from
aqua.
They
actually
say
because
they
brought
this
up.
C
This
project
called
stable,
so
starboard
basically,
is
like
a
two
kit
for
for
for
for
crg
for
custom
resource
which
doesn't
have
the
policy
for
for
from
the
policy
and
custom
resource.
Actually
building
for
for
our
image
are
totally
thinking.
You
know
viewing
something
like
that
working
on
their
stubble
to
view
the
political
resource
definition
for
their
for
their
stafford.
So
that's
that,
and
I've
checked
on
on
discover
I've
not
actually
tested
it
locally.
C
On
myself
about
I've
checked
on
it
is
a
nice
project
by
the
way
which
has
is
not
just
any
vulnerability.
It
also
has
reports
from
some
other
stuff.
I'm
going
to
share
the
link
right
here.
So
basically,
that's
just.
I
don't
have
any
demo
to
show
you
for
for
my
test
of
trivia
locally
and
you
know
and
clever
to
be
coming
out.
It
will
be
coming
up
next
next
meeting.
So
that's
just
what
I
want.
Okay
update.
G
Hi
everyone
I'll
make
this
quick,
so
hi-
I
am,
I
am
summer
mentee
working
with
jim
on
issue,
51
that
looks
into
building
a
falco
adapter
that
will
take
output
from
falco
and
well
map
it
with
a
policy
report
crd
and
generate
a
policy
report.
So
the
up
the
update,
the
thing
that
I
have
been
working
on
is
mapping
the
first
draw.
G
G
Secondly,
we
are
discussing
an
approach
to
capture
data
from
falco.
The
two
things
that
we
are
looking
into
are
grpc
server
and
palpa
psychic.
Initially,
I
was
under
the
impression
that
falco's
grpc
server
would
be
better
given
that
it's
in
in
falco-
and
it
just
has
to
be
externally-
enabled
for
it
to
work
and
give
a
good
output.
But
I
have
come
to
like
falco
psychic,
the
two
tradeoffs
that
we
have
considered
as
of
now
plus
one
for
falco
psychic,
given
that
you
can
run
it
in
just
one
minute.
G
G
Otherwise
we
further
plan
to
work
on
studying
the
code,
understanding
how
our
future
code
will
look
and
finalizing
an
approach
to
capture
the
data
and
finally
start
preparing
a
prototype
of
the
code
and
maybe
show
something
next
meeting,
and
just
one
more
things
discusses
on
this
call.
I
would
really
like
to
know
if
I
can
discuss
with
you,
have
a
dialogue
with
you
over
mapping.
Since
most
of
my
initial
mapping,
work
was
done
using
the
pr
that
you
had
created.
That's
all!
Thank
you
so
much
you
guys.