►
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
All
right
welcome
to
our
container
security
weekly
group
meeting
alexander.
I
think
you've
got
the
first
one.
Do
you
want
to
give
us
a
quick
demo
of
what
you've
done.
B
B
Very
good,
thank
you.
Okay,
so
in
the
staging
project
the
we
have
alerts,
you
can
change
the
status
and
now
there's
the
hide
dismiss
alerts,
getting
one
step
closer
to
that
mvc.
So
this
hides
don't
ignore
that.
Don't
worry
about
that,
not
only
the
dismissed
but
the
resolved,
and
so
maybe
that
wording's
actually
unclear
now.
But
what
leaving
you
with
unreviewed
and
in
reviewed
alerts
on
the
page.
A
A
Awesome
and
then
I
posted
on
our
team
channel
today,
but
for
the
sake
of
the
recording
and
anyone
who
might
be
watching,
we
now
have
new
documentation.
This
has
been
long
awaited
for
us,
but
we
have
a
new
page
here
in
it.
Actually,
we
repurposed
a
page
that
existed
before
it's
under
infrastructure,
securing
your
deployed
applications,
but
we've
totally
revamped.
This
page
there's
now
an
overview
for
each
of
these,
as
well
as
an
installation
guide.
A
So
if
you
have
a
chance
to
take
a
look
at
that,
it
should
now
be
significantly
easier
to
get
started
using
our
technologies,
and
we
give
you
hints
if
you
run
into
problems
on
how
to
how
to
troubleshoot
a
little
bit
so
great
step
forward.
I
would
love
to
keep
those
up
to
date,
as
we
do
documentation
updates
going
forward.
So
if
we
make
document
update,
documentation
updates
and
it
belongs
in
another
place-
that's
fine.
We
should
just
include
a
link
to
wherever
that
is
on
that
page.
A
That
way,
we
have
one
place
with
all
of
the
links,
because,
right
now
our
documentation
is
scattered
through,
like
five
different
places
in
the
docs
and
for
somebody
to
go
and
happen
to
find.
All
of
those
places
is
really
hard.
B
What
the
with
the
alerts
documentation
does
that
go
under
a
container
network
security
or
container
host
security.
A
So
that's
actually
that's
a
tricky
one,
because
it
actually
overlaps
container
network
security
and
security
orchestration,
because
security
orchestration
is
an
overlay
category.
So
when
we
release,
hopefully
when
we
release
our
mvc,
what
january
22nd?
That's
when
we'll
move
security
orchestration
to
minimal
maturity,
so
it'll
technically
be
under
security
orchestration,
but
because
we're
doing
container
network
policy
alerts
first,
it
there's
a
lot
of
overlap
with
that
category.
So
it's!
The
answer
is
yes,
it's
both.
A
A
So
right,
I
don't
know
we'll
have
to
work
with
nick
on
that,
one
to
see
where
that
documentation
should
be
should
live,
but
it's
an
overlay
category
because
we
might
have
alerts
coming
in
from
all
sorts
of
places
there.
So
it's
not.
A
It
probably
wouldn't
quite
be
right
to
put
all
the
documentation
in
container
network
security.
It
probably
needs
its
own
place,
but
we'll
sort
that
out
when
the
time
comes.
B
And
then
you
mentioned,
if
there's
other
other
parts
of
the
code
or
a
documentation
that
relates
to
one
of
these,
that
we
should
have
link
in
there.
I
take
it.
There
is
a
link
to
security
orchestration
somewhere
on
this
new
documentation
page.
B
Well,
I
see
it,
I
see
so
security
or
security
orchestration
is
a
new
page.
It's
not
an
existing
one,
it's
what
about
I
got
and
what
about
the
policy
page.
You
said
we
already
had
a
that
does
exist
today,
yes,
and
and
there's
a
link
in
one
of
these
yep
yeah.
Okay,
sorry,
I
haven't
looked
at
it
yet
my.
A
Cool
well,
the
meat
of
this
meeting.
I
wanted
to
spend
doing
planning
breakdown
for
our
follow-up
design
improvements
zamir.
I
know
this
is
mostly
the
front
end
so
bear
with
us,
but
this
is
more
than
anything
else,
just
to
make
sure
alexander
that
you're
ready
to
go
here.
I
know
kyle
was
gonna,
wrap
those
up
before
he
headed
out
on
pto.
I'm
not
sure
he
quite
got
done
with
everything,
and
some
of
that
might
have
been
my
fault
as
well.
A
I
noticed
there
were
a
bunch
of
comments
that
somehow
slipped
through
the
cracks
that
I
didn't
notice
ahead
of
time,
so
we'll
go
through
this,
the
best
we
can
and
if
there
are
extra
items
that
we
need
to
follow
up
on
with,
like
afterwards,
after
the
break,
we'll
just
make
note
of
those
as
needed.
A
So
I'm
trying
to
keep
this
front
end
work
only
just
to
let
the
back
end
team
once
they
wrap
up
what
they're
doing
now.
I
want
to
switch
them
over
to
the
dashed
project
level,
scan
policies,
so
anything
that
is
back-end
unless
it's
absolutely
critical,
we're
probably
just
gonna
de-scope
it,
but
at
a
high
level
the
requirements
would
be
to
show
policy
name,
which
I
think
we're
already
doing,
is
just
the
name
of
the
alert,
the
environment
and
the
status.
A
So
I
think
this
requirement
is
mostly
met
already,
the
only
new
one
would
be
in
the
environment
and
if
we're
not
able
to
do
that,
if
it's
not
coming
through
from
the
back
end
data,
then
we'll
just
d
scope
that,
but
it
does
say
to
filter
as
well.
I
guess
I
should
probably
technically
remove
this.
We
probably
don't
want
to
have
them
filtered
by
name,
but
we
do
want
to
have
them
filtered
by
environment
and
by
status.
A
A
B
B
We
might
have
to
start
with
just
a
search
box
that
someone
can
just
type
in
the
policy
name.
That
might
be
a
good
starting
point.
I'm
not
sure
if
we
have
a
list
of
all
the
policy
names,
but
we
might.
I
have
to
look
into
it,
got.
A
It
yeah,
if
you
wanted
to
do
something
like
that
as
a
first
pass.
I
would
consider
that
as
still
meeting
the
requirement,
so
the
next
one
is
viewing
details
of
an
alert
priority
wise.
This
is,
I
didn't
intentionally
put
this
in
priority
list,
but
that's
probably
pretty
accurate.
This
is
a
really
high
priority
because,
as
the
list
exists
right
now,
it's
not
practical
for
anyone
to
use,
because
you
can't
get
any
details
about
these
things
at
all.
You
just
see
it
happen
and
that's
it.
So.
A
The
very
next
thing
that
anybody
is
going
to
want
to
do
is
to
actually
get
all
of
the
log
details
so
to
click
on
it,
and
I
think
the
design
kyle
leaned
on
was
more
like
this,
rather
than
what
we
have
in
our
prototype,
but
to
be
able
to
get
all
of
those
details
from
the
log
there
in
that
sidebar.
A
So
again,
priority
wise,
like
as
we're
thinking
about
this
epic,
that's
going
to
be
a
super
high
priority.
If
they
can't
get
the
log
details,
then
you
know
they
they
can't
action
on
it
at
all
and
so
being
able
to
surface.
Those
up
is
is
pretty
critical.
A
A
You
know
details
pane
and
format,
it
a
little
bit
more
cleanly
where
you
know
we're
putting
in
more
like
a
table
format
with
you
know
your
key
value
pairs
here
and
maybe
you
know
formatting
like
our
time
stamps
as
actual
date
times,
instead
of
just
a
big
long
number
string,
you
know
like
it
comes
across
in
the
logs,
but
I
would
view
all
of
those
as
stretch
goals
if
we
can
even
just
dump
out
the
raw
log.
That's
gonna
be
a
huge,
incremental
iterative
improvement
over
where
we're
at
today.
A
It
just
stopped
me
if
you've
got
any
questions
on
these.
Please
stop
me.
Let's
talk
about
him,
so
the
next
one
assign
an
unassigned
individuals
to
an
alert.
I
have
not
seen
designs
from
kyle
on
this
one
yet,
but
the
good
news
is
that
we've
got
a
pretty
strong
paradigm
for
this
elsewhere
in
gitlab
already,
you
know
where
we've
got
this
assignee
thing
in
the
sidebar.
I
don't
think
there's
any
need
to
reinvent
the
wheel
here.
A
I
would
expect
us
to
just
take
this
same
widget
and
you
know
drop
it
in
in
between
the
title
up
here
section
and
the
details
section
down
there.
So
we
would
just
reuse
that
component
if
it
is
a
reusable
component
and
not
reinvent
the
wheel,
for
that
one,
I
think
longer
term.
B
Yeah,
the
operation,
the
monitor
teams
alert
dashboard
already
has
that
paradigm
in
the
in
the
board
or
in
the
list.
So
we
could
probably
just
mirror
that.
A
Yeah-
and
that
would
be
great
as
well
if
we
are
able
to
just
bring
this
column
over
and
show
the
same
thing
that
they've
got
here.
A
Number
four
being
able
to
create
an
incident
from
an
alert
and
this
one
as
well
like
if
we
can
provide
this
column
with
a
link
to
the
incident.
You
know
that's
a
bonus,
I
would
say
not
part
of
the
core
requirement,
but
if
you
do
it,
that
would
be
great.
A
This
just
adds
a
create
incident
button
up
top
here
and
it
should
follow
the
same
workflow
that
you
get
all
of
these
ones
in
their
environment
already
have
an
incident
but
like
if
I
click
on
one
and
it
doesn't
have
an
incident,
I
can
create
a
new
incident,
so
we
should
follow
basically
that
same
workflow.
A
So
an
incident
is
just
an
issue.
It's
just
a
type
of
issue.
So,
instead
of
having
issues
selected,
you
have
incidents
selected
and
then
once
they
create
it,
it
should
be
associated
back
with
that
alert
so
that
they're
linked.
A
A
My
takeaway
was
if
we
can
have
a
link
to
both
the
dedicated
page
and
the
drawer
like
two
different
links,
one
for
the
drawer
one
for
the
page,
that's
great,
but
for
the
sake
of
mvc,
if
we
just
have
a
link
to
this
dedicated
page
that
you
referenced
here
in
your
comment,
I
mean
that's
great,
because
then
they
can
share
that
link
out.
They
can
point
to
it.
They
can
at
least
reference
it.
A
Number
six
and
just
stop
me:
if
I'm
going
too
fast
here,
users
will
be
able
to
choose
to
view
alerts
in
either
a
list
view
or
a
kanban
board
view.
So
again,
like
priority
wise.
I
think
I
would
actually
move
this
down
below
changing
the
status
alert.
A
So
this
is
probably
our
last
priority
is
having
a
second
view,
but
that
would
just
be
that
ability
to
toggle
between
these
two
and
then
lastly,
they'll
be
able
to
change
the
status
of
an
alert
so
right
now
all
we
have
is:
did
we
get
all
the
statuses
in
or
are
we
all
four
of
them.
B
B
Yeah
it
store
just
came
for
free
when
I
was
doing
when
I
was
doing
the
status
column.
So
I
just
that's
what
that
my
that
drop
down
was
in
that
column.
A
Okay,
great,
so
I
will
to
avoid
confusion
I'll
remove
this
from
this,
because
we
already
have
it
so
you'll
just
have
these
six
and
I
think
they
are
more
or
less
in
priority
order
there
amongst
themselves.
So
technically,
I
think
we
could
release
any
one
of
these
independently.
I
don't
think
there's
any
reason.
We
have
to
wait
for
all
six
they're,
all
very
iterative,
incremental
improvements,
so
I
would
say:
let's
just
go
down
the
list
and
see
how
many
we
can
get
done
here
and
in
13
8
or
13
yeah
13
8.
B
Yeah
I
once
we
release
this
mvc
and
I
remove
the
feature
flag
that
is
currently
hiding
it.
I
won't
have
a
feature
flag
for
any
of
these.
Well,
that's
not
true.
I'll
have
a
feature
flag
for
the
kanban
board,
because
that
is
quite
a
bit
of
work,
but
the
other
ones
seem
like
they
can
be
done
incrementally
without
a
feature
flag.
A
Awesome
yeah.
That
sounds
great
again.
I
I
know
we
don't
have
perfect
mocks
for
all
of
these.
You
know,
including,
like
we,
don't,
have
a
mock
with
everything
in
it
at
the
moment,
but
I'm
hoping
that
you
know
like
assigning
individuals.
We've
already
got
a
really
strong
paradigm,
so
I'm
hoping
we
don't
necessarily
need
a
mock
for
that
and
if
you
have
more
questions
along
the
way,
let's
just
stay
in
sync
between
you
and
myself
and
kyle.
B
Yeah,
I
think
we've
been
doing
a
great
job
at
that
so
far,
so
let's
yeah,
let's
just
continue
on
with
it,.
C
And
alexander
for
the
details
in
the
alert,
if
you
feel
that
the
format
it's
not
good
or
if
there's
something
that
I
can
do
some
parsing
on
the
back
end
to
help
you
out,
I
I'm
I'm
happy
to
do
that.
I
I
I'm
I'm
anxious
to
have
the
first
version
of
alerts
working,
I'm
gonna
pair
up
with
the
mic
from
the
configuration
today
on
the
working
progress.
C
B
Yeah,
thank
you.
I
you
know
part
of
the
reason
I
asked
for
your
your
feedback
on
that
alerts.
B
Ad
alerts
in
the
policy
ui
is,
I
don't
have
you
know
I,
the
the
back
end
isn't
complete,
yet
I
don't
have
it
working
locally
and
so
and
sam
this
goes
to
serve
my
com.
My
mix
up
with
policy
name
as
well
is
like
I've
created
alerts
manually
just
by
exceeding
the
database,
and
so
I'm
assuming,
where
I'm
grabbing
the
information
from
is
where
the
policy
name
is
going
to
be
in
the
back
end.
B
A
Sounds
great-
and
I
know
we've
stated
it
before
but
again
just
to
be
super
clear.
The
name
of
the
alert
should
be
identical
to
the
policy
name,
there's
nowhere
else
that
they
would
be
able
to
configure
the
like
a
different
name
for
the
alert.
So
the
policy
name
is
the
alert
name.
Everyone
interchangeable
terms.
A
Just
occurred
to
me
again
kind
of
like
last
week
was
like:
oh,
I
wonder
if
we
caught
this,
there
is
a
very
real
danger
and
we
discussed
this
earlier
on.
I
think
before
you
came
on
board
alexander
and
I'm
just
realizing
now
I
don't
know
if
it
made
its
way
into
the
requirements,
so
it's
kind
of
one
that
just
slipped
through
the
cracks.
A
It's
really
easy
for
users
to
just
set
everything
to
generate
an
alert
and
when
you're
talking
about
network
flows
like
that's
a
high
high
volume
activity,
and
so
you
users
should
not
be
having
everything
generate,
an
alert.
They
should
be
extremely
selective
about
which
policies
generate
an
alert.
It
really
should
only
be
policies
that
they
legitimately
plan
to
have
a
user
manually
review
that
so,
if
they're,
just
like
logging,
all
traffic
to
port
80,
for
example-
and
it's
a
web
server
like
they're,
just
gonna
get
hit
by
this
flood
of
alerts.
A
A
When
they
set
up
their
policies
to
only
have
alerts
triggered
for
things
that
are
likely
to
be
relatively
low
volume-
and
you
know
things
that
they
actually
plan
to
review
manually,
so
we
do
need
a
warning
on
that
policy
page
when
they
say
I
want
to
add
an
alert
or
have
this
policy
generate
an
alert
that
you
know
helps
give
them
some
guidance.
A
You
know
around
what
when
and
where
that
should
be
used.
Like
you
know
warning
you
know
this
can
cause
psyllium
to
have
performance
issues.
If
you
suddenly
do
this
for
all
network
traffic,
I
mean
I'm
happy
to
wordsmith
something
with
you
on
what
that
alert
text
should
say,
but
the
bottom
line
is.
We
need
some
way
to
like
just
caution:
users
whenever
they
add
that
alert
onto
the
policy
page,
and
I
think
that's
something
that
slipped
through
the
cracks.
A
B
I
am
okay.
That
should
definitely
go
in
the
mr
that
I
have
up
currently
with
the
ad
alerts
and
the
policy
ui,
because
that
seems
like
the
right
place
to
put
it.
So
if
you
could
instead
of
adding
a
follow-up
issue,
just
comment
on
the
ad
alerts,
policy,
ui
issue
and
maybe
yeah
like
you
said,
words
meant
something,
and
then
I
will
add
it
to
that.
Mr
that's
up
also.
B
I
don't
know
if
an
alert
is
like
enough
here.
I
don't
yeah
trust
you.
I
wouldn't
trust
users
to
not
just
be
or
not
be
like
yeah
this.
Okay,
I
see
this,
but
this
is
going
to
be
fine
and
it
blows
up
or
like
unexpectedly,
something
goes
wrong
and
blows
up.
You
know
like
they
could
be
judicious
about
this,
but
then
still
have
like
a
major,
catastrophic
failure
which
still
causes
this
issue.
B
Is
there
any
precautions?
We
could
put
any
checks
any
limiters
in
the
back
end
that
we
could
put
for,
like
oh
over
x,
amount
of
alerts
we
stop
or
and
do
something
I
don't
know.
B
C
No
there's
no
risk.
We
were
going
to
use
something
that
would
be
a
little
bit
heavier
on
the
load
to
create
the
mapping,
but
I
was
able
to
manage
around
that.
So
we
are
not
touching
the
the
scalability
of
ceiling
with
our
change.
The
only
thing
that
we
need
to
be
aware
is
that
the
agent
has
some
limitations
to
keep
stuff
in
the
memory.
So
as
soon
as
we
reach
a
limit,
then
we
are
going
to
step
to
drop
and
maybe
to
log
some
error
message
somewhere.
A
Okay,
so
that
should
probably
be
part
of
our
warning
message
that
says
you
know
if
you
have
too
much
volume,
we're
just
going
to
start
dropping
alerts
like
this
is
not
intended
to
be
your.
You
know
our
alerts.
Dashboard
is
not
your
sim,
it's
not
your
logging
tool.
You
know
if
you
want
to
log
all
of
the
psyllium
traffic,
that's
why
you
have
a
sim
go
route
it
that
way.
C
Yeah,
but
there
is
a
limitation
that,
if
you,
if
you
want
all
the
information
in
terms
of
relationship
between
the
policy
and
endpoints
natively,
then
you
need
to
add
an
option
on
when
you
install
celium,
and
I
think
that
was
the
code
path
that
art
was
working
on.
It
would
be
good
because
the
solution
would
come
from
the
student
side,
but
on
the
other
hand
we
would
we
would
hit
this
scalability
issue.
A
Got
it
yeah?
That's
great
news,
I'm
I'm
happy
to
hear
that
so
because
yeah,
there
is
a
risk
that
you
know
you
turn
on
alerts
and
then
you've
exposed
a
potential
way
for
an
attacker
to
denial
of
service
your
system.
So
it's
it
gets
a
little
bit
tricky
there.
Okay,
no,
that's
fantastic!
It
sounds
like
we're
already
thinking
through
those
rate
limiting
things
we
just
need
to
make
that
clear
in
the
ui
we
are
running
on.
B
C
Yeah,
for
sure,
maybe
what
we
can
do
is
that
we
can
add
a
flag
on
the
last
error,
less
alert
saying
that
that's
the
last
one
you're
not
going
to
hear
back
anything
from
that,
but
how
to
implement
the
limit
and
where
I
need
to
figure
out
with
the
guy.
I
can,
I
can
add
my
limits,
but
probably
he's
going
to
add
limit
for
the
whole
api
calls.
So
that's
something
that
might
be
like
global
for
the
architecture
of
the
agent
k
and
not
only
specific
to
our
module
cool.
Thank
you.
B
All
right,
what's
what's
what's
next,.
A
A
A
So
I'll
work
that
asynchronously
with
tiago
we've
gotta.
You
know
either
schedule
it
in
every
release.
To
make
sure
we
update
that
volume
database
or
ideally
automate
it
in
some
way,
but
yeah.
If
we're
not
already
publishing,
updates
every
single
milestone,
we've
got
to
start
doing
that.
That's
going
to
be
problematic
for
our
customers,
yeah.
C
A
Yeah
seems
bad
yeah
all
right
if
we
are
at
time
if
you
need
to
drop,
go
ahead
and
feel
free
alexander.
If
you
have
time
to
stay
on,
we
can
go
through
your
last
item
here.
B
Oh,
it
was
handle
asynchronously,
it's
fine,
I'm
content
with
it.
A
Awesome
well,
thanks
for
all
your
your
good
work
on
alerts,
I'm
looking
forward
to
it,
I'm
starting
to
put
together
a
release
post
for
draft
release
post
for
thirteen
nine.
So
you
know
alexander
on
your
end,
when
you
have
a
good,
solid
screen,
shot,
send
it
over
to
me
or,
let
me
know
and
I'll
grab
it
from
the
staging
project.
You
know
when
we
have
it
at
a
point
that
we're
ready
to
show
it
off,
and
I'm
really
excited
for
this
one.
B
Yeah
yeah
definitely
I'll
be
out,
I'm
on
I'm
on
pto
all
next
week,
so
it
won't
be
next
week.
A
That's
okay,
yeah,
no
rush
on
that.
We
have
usually
until
maybe
a
week
or
so
before
the
release
date.
So
yeah.