►
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
container
security
group
meeting,
let's
see
alexander,
I
think
you
have
the
first
item.
B
Yeah
just
under
highlights
my
progress
on
the
ui
is
that
I
added
a
feature
flag
for
this
and
the
tab
exists
and
it
is
currently
showing
an
empty
div.
But
I
have
an
mr
up
to
show
the
initial
alerts
just
in
a
table
with
no
actions,
and
it
will
go
from
there.
C
D
B
No,
I
can,
if
you
want.
E
A
D
B
I've
I've
never
actually
used
the
chat.
Ops
thing
besides
be
like
test,
and
so
it'll
probably
be
good
for
me
to
turn
it
on
for,
like
a
small
project.
D
B
Yeah
yeah
yeah
tell
me,
give
me
a
project
link
me
a
project
and
I'll
turn
it
on.
I
mean
right
now:
it's
just
an
empty
tab,
so
not
the
most
exciting
thing,
but
certainly
in
the
future
there
will
be
more
actions.
C
B
For
you,
I
don't
feel
bad,
I
mean
I
don't
feel
bad
about
showing
an
empty
tab.
You
know
iteration,
but
just
give
me
a
project
I'll
turn
it
on.
D
C
I
have
the
next
agenda
item
and
that's
just
a
call
out
that
we've
made
the
decision
to
move
the
accomplishments
to
the
bi-weekly
threat
management
staff
meeting.
So
I
didn't
create
the
the
list
of
all
the
container
security
issues
that
were
closed.
I
think
it's
still
good
to
highlight
things
like
this
things
that
you're
proud
of,
but
we
will
do
the
complete
list
on
the
agenda
for
the
threat
management
staff
meeting.
A
All
right,
thiago.
D
So
I
had
to
catch
up
with
with
zamir
and
thank
you
thank
you
for
your
comment.
There,
sam
falling
on
the
sword,
but
I
can't
let
you
take
that
responsibility
on
your
own,
but
zamir
has
been
spending
a
lot
of
time,
building
a
relationship
with
the
with
the
configure
team
on
on
the
agent
k
and
kaz,
and
all
that
that's
needed
to
control
the
kubernetes
site
and
cilium
side
to
get
alerts
for
traffic
flows.
D
D
It
would
be
hard
to
get
it
done
for
for
the
413.7.
So
my
suggestion
there
is
to
do
something
that
sam
is
now
confirming.
That
was
already
the
idea,
so
definitely
a
miscommunication
there,
and
I
I
I
I'll,
take
some
responsibility
for
that
as
well.
But
it
looks
like
we're.
Okay,
then
samia,
do
you
want
to
add
context.
F
Yeah,
can
I
share
even
now
or
later
do?
Can
I
just.
A
D
F
Then
I
can
show
a
little
bit
of
what
we're
talking
about.
F
It's
a
terminal
with
a
bunch
of
windows,
okay,
so
so,
basically,
what
I
want
to
show
here
is
that
there's
a
difference
between
the
information
that
we
get
when
we
have
a
flow.
F
So
in
this
example
here
it's
very
simple.
F
I
just
have
a
couple
of
pods
here
in
this
case
here
we
have
tie
fighter
and
x-wing
that
they
are
going
to
try
to
access
death
star,
and
so,
if
I,
if
I,
if
I
just
run
hubble
how
about
that,
it's
the
one
that's
going
to
centralize
all
the
log
information
for
among
all
the
nodes
based
on
ceiling
and
if
I
try
to
to
just
go
with
x-wing,
we
are
going
to
have
a
policy
denied,
because
there
is
a
policy
that
doesn't
allow
x-wing
to
go
to
death
star.
F
And
if
I
just
highlight
here
policy
you're
going
to
see
that
there
is
a
drop
reason
here
and
then
it
mentions
that
the
policy
denied,
but
if
I
go
with
the
the
thai
fighter,
tie
fighters
is
allowed
to
go
to
death
star.
So
then,
let
me
just
refresh
here
now
we
have
a
flow.
F
It
just
means
here
that
the
the
verdict
it's
forward
the
tricky
part
here,
is
that
there's
no
information
in
regards
to
the
policy.
It's
just
this
is
just
the
label.
So
then,
what
means
is
that
if
we
have
a
policy
ingress,
that's
going
to
allow
this,
or
in
the
case
we
don't
have
any
policy
at
all.
The
log
information
that
we're
going
to
get
with
the
flow
is
the
same.
A
We
do
want
to
cover
that
use
case
at
some
point,
but
not
part
of
the
mvc
right
now
in
our
policy
editor
in
the
ui
that
we've
built,
we
don't
let
you
write,
allow
policies
anyway,
you
can
only
write
policies
that
block
things,
so
we
would
have
to
add
you
know
we
would
have
to
make
some
pretty
heavy
changes
to.
Let
the
users
write
allow
policies
now,
instead
of
just
block
policies,
and
then
you
know
another
step
to
create
alerts.
A
F
D
D
So
so
I
guess
we're
good,
then.
The
part
that
john
is
not
on
the
john
is
not
on
call,
but
the
part
that
he's
doing
is
is
under
control,
and
now
I
think
the
front
end
is
in
control.
We
just
saw
the
feature
flag.
The
mvc
will
have
we
reuse
the
ops
dashboard,
which
is
great.
It
will
just
there's
no
no
front-end
work
needed
for
that.
It's
just
populating
the
alerts
and
zamir
you
got
everything
that
you
need
now
as
well
right.
F
Yeah,
I'm
just
trying
to
see
if
I'm
able
to
get
the
policy
very
difficult
information
from
the
api.
So
then
it
would
reduce
a
little
bit
of
ambiguity
that
we
would
have
when
matching
the
network
policies
with
the
log
yeah.
F
That
yeah,
if
I
don't
get
the
information
on
policy
verdict,
we
can
have
a
little
bit
of
ambiguity
for
the
first
version
and
we
can
create
a
follow-up
issue
for
for
something
other
than
that
for
next
ten
days
or
something
I'm
in
touch
with
the
student
folks,
sometimes
just
take
longer
to
get
reply.
It's
a
lot
of
people
in
the
channel,
usually.
D
Cool
with
without
this
zamir,
if,
if
if
we
wanna,
have
the
ambiguity,
I
think
I
think
that
could
be
a
an
easier
that
would
increase
our
confidence
level.
Wouldn't
it
just
say:
don't
don't
worry
about
the
confidence
for
mvc.
F
F
Yeah
yeah:
if
is
this
a
matter
of
making
it
work
or
not?
If
I'm
not
able
to
get
the
api
running,
I'm
trying
to
with
the
new
version
now
1.9,
I
started
testing
1.9
yesterday
and
then
yeah.
We
can
make
a
decision
on
that
kind
of
day-to-day
issue.
D
B
Zamir,
have
you
containing
the
or
not
containing
with
reference
to
what
you
just
showed
us
about
the
issue
you
found
about
the
alerts
not
showing
up
for
allowed
and
like
flows?
Have
you
documented
that,
in
a
spike
or
somewhere.
F
No,
no,
I
didn't.
I
can
up
the
date
over
there.
I
think,
like
I
think,
arthur
mentioned
that
ages
ago,
and
at
that
time
I
was
thinking
we
were
talking
about
the
seedling
logs,
not
the
hubble
logs
and
then,
but
I
I
can
just
add
over
there,
just
to
make
sure
that
we
are
all
on
the
same
page,
especially
people
who
are
not
in
the
meeting
got
it
cool.
Thank
you.
B
B
B
D
A
I
am
just
a
little
bit
hesitant
about
releasing
with
our
alerts
showing
up
on
their
dashboard,
simply
because
this
is
a
feature
that
we
want
to
reserve
for
ultimate
and
git.
Lab
has
a
policy
that,
once
you
put
something
in
core
you're
not
supposed
to
ever,
pull
it
back
out
or
move
it
up
to
a
higher
tier.
So
it's
kind
of
a
one.
You
know
it's
a
one
directional
thing
for
the
most
part.
A
They
actually
might
have
softened
their
language
around
that
a
little
bit
recently,
but
it
would
be
a
lot
cleaner
if
we
can
just
say
you
know,
this
is
an
ultimate
feature,
and
you
know
it
always
was
ultimate
and
it
just
you
know
it.
It's
an
ultimate
feature.
D
Yeah,
the
the
the
follow-up
issue
has
a
feel
to
to
go
and
remove
that
from
there.
So,
if,
if,
if
we
wanted
to
show
that
there
and
and
still
still
obey
that
ultimate
restriction,
we
would
need
we
need
some
ideas
there
to
go.
Hey
you
don't
have
the
ultimate
there's
alerts,
but
we
can't
show
to
you
so
at
that
point
we
might
as
well
just
go
to
our
own
dashboard
right
is
where
you.
A
A
We
could
probably
argue
our
way
around
it
by
saying
you
know
we,
the
you
know
our
dashboard
was
always
an
ultimate.
You
know
you
and
the
monitor
team's
dashboard
was
always
in
core.
You
know
all
we've
changed
is
the
data
that
shows
up
natively,
but
I
don't
know
I.
It
would
certainly
be
a
lot
cleaner
if
we
could.
Just
you
know
from
our
first
release,
keep
it
all
squarely
and
ultimate
it
gets
a
little
bit
more
sticky.
Otherwise,.
D
Understood
I
don't
want
to
speak
for
for
for
the
frontend
team
on
on
the
likelihood
of
that,
making
it
so
I'll
shut
up
now.
B
I
john,
when
I
talked
this
morning
about
his
way
to
limit
that
make
sure
that
they're,
dash
or
list
only
gets
their
alerts
and
he's
working
on
he.
He
showed
me
that
he
had
an
mr
up
and
they
wanted
to
change
direction
on
it
and
he
seemed
to
think
that
it
or
you
know
up
until
now.
We've
thought
it
was
a
13-8
thing.
So
if
we
want
to
really
push
for
that,
we
should
say
now.
We
should
say
now
that
we
should
push
for
that
for
13-7.
D
Alerts
would
show
there
anyway,
so
I
guess
the
the
then
the
decision
becomes.
If
we
don't
have
it,
do
we
put
the
whole
feature
behind
a
feature
flag
or
do
we
let
you
know
if
some
people
happen
to
configure
celium
policies
and
and
alerts,
they
might
get
some
data
there.
They
will
disappear
on
the
next
release.
A
I'll
have
to
think
about
it,
I'm
leaning
towards
a
feature
flag.
I
think
it's
going
to
be
a
you
know.
It
seems
super
unlikely
that
people
are
going
to
do
that
right
away,
but
if
somebody
does
do
that
and
they
have
data
showing
up
and
then
it
disappears
and
then
it's
three
tier
and
you
know
our
answer
is
well
now
to
see
that
you
have
to
go
buy
ultimate.
A
D
Another
another
possibility
without
using
a
feature
flag
on
the
back
end,
is
amir.
Keep
me
honest
here.
Please
put
that
check
in
in
in
cas,
so
cas
will
receive
alerts,
but
if
it's
not
an
ultimate
installation,
it
will
just
drop
them.
F
F
It
could
be
a
feature
for
cass,
but
then
it
might
take
a
little
bit
of
time
to
get
approved
through
the.
D
F
Can
put
on
as
part
of
the
internal
api
but
yeah,
I
agree
with
alexander.
We
should
decide
it
now,
otherwise
he
might
just
ramp
her
up
all
the
mrs
going
to
get
merged.
A
Stewardship
promise,
I
think
I
think
we
should.
The
decision
is
that
we
should
not
release
with
displaying
the
alerts
in
the
monitor
teams
page
in
core,
so
if
it
displays
there,
but
only
for
ultimate,
that's
fine,
but
we've
got
to
filter
it
behind
ultimate
or
get
it
behind
a
feature
flag
in
some
way.
D
B
Cool
while
we're
talking
about
what's
available
during
core
and
what's
available
during
ultimate
sam,
I'm
gonna,
I
guess
I'm
putting
you
on
the
spot,
I
apologize,
but
in
the
epic
and
I'm
sorry
this
is
again
ad
hoc.
I
just
thought
of
this
thing.
So
again
I
apologize
where's,
the
epic
in
the
epic.
There
was
some
discussion
about
because
we're
putting
we're,
sharing
the
same
alerts
table
as
the
monitor
team
that
when
you
are
at
the
monitor
teams,
let
me
let
me
bring
up
a
thing.
B
Quick
and
zamir
will
know
what
I'm
what
I'm
talking
about
as
soon
as
I
start
share
this,
but.
B
And
so
I
can
whatever
change
this
number
to
whatever,
and
it
will
load
that
issues
details
if
we're
using
the
same
table
as
the
monitor
team
and
say,
say:
there's
like
five
alerts
that
a
user
sees
and
three
of
them
go
to
the
monitor
teams,
alerts
and
the
other
two
go
to
our
alert
table.
They
may
see
in
this
page.
B
You
know
one
three
five
and
wonder
where
the
other
two
alerts
are
coming
from
sure
and
that
might
be
hidden
well
wait.
Is
that
even
actually
a
is
that
a
use
case
like
we
could
someone
set
up
hubble
without
not
without
buying
the
ultimate,
I
believe
so
so
they
could
set
up.
Hubble,
yes,
be
getting
alerts
from
hubble,
but
the
alerts
wouldn't
be
showing
up
here,
they'd
be
showing
up
behind
the
ultimate.
Is
that
correct?
You.
A
F
Would
have
they
would
have
to
create
all
the
syrian
set
up
exactly
as
we
are
expecting
in
order
for
agent
k
to
be
able
to
load
data
from
them.
So
I
think
it's.
There
is
a
very
small
chance
of
someone
being
able
to
do
that.
F
E
A
B
A
So
yeah,
as
long
as
we
can
safely
say,
you
know
it
is
an
ultimate
feature
that
that's
great
and
if
someone
wants
to
go,
do
their
own
development
work
to
have
it
show
up.
You
know
I
mean
that's
true
of
any
of
our
features.
It's
an
open
source
code
base.
Anyone
can
take
our
product
and
extend
it
and
add
in
whatever
they
wanted
to
and
recompile
it
if,
if
they
really
wanted
to
put
in
that
time
and
energy.
A
So
here's
my
last
question
with
all
of
that
clarification
and
discussion.
Where
are
we
sitting
at
you
know?
What's
our
what's
our
confidence
level,
if
we
were
just
to
do
a
quick,
you
know,
you
know
everyone
raise
your
hand
and
put
up
a
number
between
one
and
five
where
five
is
like
yeah
home
run.
It's
definitely
happening
in
thirteen
seven
and
one
is
absolutely
no
way.
B
I
have
a
draft
mr
to
show
the
alerts,
and
I
thought
I'd
probably
need
another
day
on.
So
I
think
showing
alerts
is
good
to
go.
I
think
changing
alert
status
is
good.
To
go,
is
going
to
be
good
to
go,
and
I
forget
other
requirements,
but
at
this
moment,
but
there's
a
few
other
things
that
I
think
we
can
get
in
for
the
front
end
so
that
I'm
feeling
confident.
F
About
from
the
back
end
from
the
back
end,
for
example,
last
week
I
had
a
chat
with
mike
from
configure
and
he
basically
changed
the
structure
of
agent
k
to
have
like
a
plug-in
style
development.
F
So
it's
very
good
for
us,
but
it's
a
type
of
thing
that
if
we
have
issues
going
forward
on
that,
we
might
not
make
to
to
all
the
changes
in
13.7.
So
it's
a
great
change.
It
helps
us
to
move
forward
even
with
the
features
that
we're
going
to
develop
further
on
based
on
agent
k,
but
it
takes
a
toll
right
now
for
for
for
this
release.
In
my
opinion,.
D
On
top
of
that
is
the
does
the
on
the
back
end.
We
still
need
the
api
changes
to
support
the
front
end
right
so
changing
status.
I
don't
know
if
that
already
exists,
does
it
alexander?
It
does
excellent.
I
need
to
put
putting
the
issue
to
make
sure
it's.
It's
not
accepting
alerts
from
psyllium
if,
if
it's
not
an
ultimate
installation,
so
that's
new
and
there's
the
existing.
D
Mr
for
persisting
alerts.
I
think
the
original
mr
review
there
too
there's
the
two
there's
one
in
review,
one
in
draft,
so
I'm
not
going
to
speak
for
for
john
and
that
but
I'll
I'll
check
with
him.