►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
our
group
conversation
for
the
container
security
group
today,
we're
going
to
be
let's
see,
looks
like
wayne.
Has
the
first
item.
Does
anyone
want
to
volunteer
to
read
what
he
has
here?
Actually,
maybe
we
should
skip
that
one
for
the
sake
of
the
recording.
B
Apologies,
I
do
have
the
first
follow-up
from
previous
discussions
too.
Can
you
guys
hear
me?
Okay,
I'm
having
audio
issues?
Okay,
so
this
is.
This
could
have
been
done,
asynchronously
and
sam
you've.
Probably
already
given
me
a
pretty
clear
answer
here.
This
issue
has
been
opened
for
a
long
time
around
proving
some
documentation.
B
I
did
get
ping
from
nick
the
other
day,
also
asking
about
progress
or
his
contribution,
so
we
can
sync
up
with
him
about
ways
that
he
can
help
out
in
this
process.
That
was
sort
of
what
was
the
reason
I
added
it
to
the
agenda.
Sam.
A
Yeah,
so
I'm
working
on
it,
you
know
writing
documentation
is
not
my
full-time
job,
so
I'm
kind
of
doing
that
in
between
everything
else.
So
it's
moving
rather
slowly,
but
we
have
a
number
of
pages
that
are
effectively
orphaned
that
don't
show
up
anywhere
in
the
nav.
We
have.
A
You
know
a
lot
of
information,
that's
scattered
across
a
lot
of
different
places,
and
then
we
have
some
information.
That's
just
missing
altogether,
so
I'm
trying
to
pull
all
that
together,
especially
since
I
did
that
demo
for
the
ebpf
summit.
Recently
I
ran
into
all
of
those
probably
many
of
the
same
problems
that
wayne
ran
into
doing
his
demo
and
there
are
just
a
lot
of
gotchas
about
trying
to
set
up
what
we
have
that
are
not
well
documented.
So
I'm
just
trying
to
go
through
and
structure
it
in
a
way.
A
That's
a
little
bit
more
clear
chatting
with
nick.
It
sounds
like
there's
a
pretty
hefty
process
around
making
any
kind
of
changes
to
the
navigation,
I'm
not
really
sure,
but
it
seems
rather
daunting.
So
I'm
just
trying
to
work
through
what
I
want
to
change
first
and
get
my
mind
around
that
before
I
make
a
proposal,
but
yeah
I'm
working
on
it,
I'm
hoping
to
have
it
done
this
milestone,
at
least
for
gke,
and
we
can
branch
out
to
the
other
cloud
providers
in
the
future.
B
A
For
wayne's
comment:
should
we
clarify
this
one
to
only
focus
on
proportions,
important
based
on
our
post
restructuring
priorities?
Aka,
don't
cover
things
specific
to
what
you
the
minimum
for
network
security
and
focus
on
container
host
security.
I
think
everything
that
we
have
needs
to
be
well
documented,
so
I
I
don't
know
that
we
want
to
cut
corners
with
network
security
with
waff,
where
that's
going
away.
A
A
A
All
right,
so
I
have
the
next
one.
I
just
wondered:
how
are
things
progressing
with
alert
management
looks
like
we
don't
have
the
mirror
on.
Unfortunately,
I
know
he's
the
one
evaluating
that,
so
we
may
need
to
handle
that
one
asynchronously,
but
the
first
question
was
mostly
for
zamir.
Are
we
ready
to
finish
the
research
spike
and
start
development?
I
don't
know
john
or
mo
if
you
know
where
we're
at
on
that.
If
not,
we
might
have
to
just
wait
for
zamir
on
that.
One.
C
I'm
not
quite
sure
I
know
he's
doing
some
digging
in
some
golang
code.
I
think
around
the
agent
and
so
just
getting
his
head
around
that,
but
that's
the
best
I
can
offer
at
this
time.
A
Okay
and
probably
actually
the
next
one
is
for
zamir
as
well.
I
was
just
wondering
if
there's
anything
here,
that
a
front
end
engineer
can
help
with.
I
know
the
plan
is
to
use
the
monitor
team's
front,
end
ui
as
much
as
possible,
so
I'm
hoping
that
the
front
end
work
is
really
minimal,
but
you
know
if
there
is
something
that
they
can
help
with.
A
It
would
be
good
to
to
offload
that
onto
the
front
end
team,
because
I
think
the
front
end
team
is
going
to
be
ahead
of
the
back
end
team
on
the
next
issue,
which
is
the
policy
level
scheduled
scan
policy.
So
if
we
can
kind
of
balance
things
out
that
way,
that
would
be
nice,
but
probably
won't
have
to
wait
for
zuma
on
that
one.
A
Sounds
good
and
that's
one
that
we
we
talked
a
lot
about
that
one
before
the
reorganization
before
we
had
a
front
end
engineer
so,
and
a
lot
has
changed
in
our
plans
too,
regarding
how
we
implement
it.
So
yeah
it'd
be
good
to
just
get
an
update
from
him
on
that
all
right
and
then
the
last
one
do
we
have
anything
to
discuss
related
to
the
dash
schedule
scan
policies?
I
know
we've
had
a
lot
of
asynchronous
and
synchronous
communication
on
this.
A
Outside
of
the
meeting
I
know,
kyle's
got
max
pretty
well
finalized,
alexander
refined
the
issues
I
think
he's
starting
work.
What
now
right
now
that
he's
back
from
he's
back
from
pto
this
week
right
lindsay,
so
I
think
he's
probably
starting
that
he's
got
research
spikes
going
on
on
the
back
end,
I
just
want
you
know,
there's
a
lot
going
on
with
this
one.
It's
a
pretty
complex!
B
Is
there
any
reason
that
alexander
should
delay
the
front-end
work
given
any
of
the
back-end
dependencies
that
you
just
mentioned?
At
least
that's
a
question
more
for
for
mo
and
john.
C
B
D
Maybe
set
up
that
sinkhole
with
I
don't
know
if
we
have
a
dri,
yet
I
think
john
you've
been
doing
that
research.
A
E
B
Cool
I'll,
let
alexander
know
that
and
if
any
questions
come
up
I
will
just
tell
them
to
post
them
in
the
container
security
panel
for
anyone
on
the
back
end
to
respond
to
that
or
the
issue
itself.
E
B
Yeah
it
looks
like
it's
ready
to
start.
You
know,
he's
completed
the
planning,
breakdown
and
everything's
been
refined.
It
would
be
good.
It
would
be
good
to
get
usually
with
our
refinement.
We
get
another
engineer
to
take
a
look
at
the
implementation
plan
and
the
weight
and
just
kind
of
give
it
a
thumbs
up.
So
I'm
I'm
wondering
if
maybe
it
makes
the
most
sense
to
have
zamir
do
that,
since
he's
been
acting
full
stack
up
until
now.
A
Great
yeah,
I
think,
you're
fortunate
on
the
swimweanly,
the
I
think
the
front
end
is
fairly
straightforward
and
you
know
decided:
there's
a
lot
less
unknowns.
On
the
back
end.
We
have
a
lot
of
unknowns,
we're
doing
a
res
we're
not
even
starting
the
refinement
for
what
we're
doing
for
the
mvc
yet
because
there's
so
much
complexity
around
where
we
want
to
go
in
the
long
term
that
we've
just
taken
a
step
back,
we're
doing
a
research
spike
to
just
draw
out
a
rough
architecture
for
where
we
want
to
be.
A
You
know
18
to
24
months
from
now,
so
that
we
don't
get
too
nearsighted
in
the
backend
implementation
and
just
you
know,
kind
of
paint
ourselves
into
a
corner.
If
you
will.
A
I
don't
know,
I
think,
really
all
the
complexity
is
just
on
the
back
end.
It's
about
where
we're
storing
things
you
know.
Do
we
store
things
in
yaml?
Do
we
store
things
in
the
database?
How
do
we
there's
just
a
lot
of
back
end
decisions
to
be
made?
The
front
end
is
fortunately
a
little
bit
more
cut
and
dry.
B
Sounds
good,
so
it
sounds
like
we'll
need
a
feature
flag
then,
for
whatever
front-end
work
is
completed
until
the
back
end
catches
up.
A
A
A
All
right,
anyone
have
anything
new
to
demo
mo
looks
like
you're
up
you're
the
last
one.
So
you've
got
the
rest
of
the
time.
C
I
don't
have
anything
to
release
screen
share,
but
I'll
just
call
it
that
fips
support
has
been
merged.
All
the
mrs
related
to
fip
support
has
been
merged.
That's
rolling
up
to
staging
there's
been
documentation,
updates
to
talk
about
potential,
breaking
changes
for
anyone,
that's
using
afterscript
or
before
script
blocks,
because
we
switch
from
alpine
to
centos
and
we
do
have
a
gitlab
runner.
That's
now
running
integration
tests.
So
if
we
may
introduce
any
changes,
we
should
be
able
to
catch
that
if
we
break
fip's
support
going
forward.