►
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
meeting
for
the
container
security
group.
First
thing
I
wanted
to
talk
about.
I
just
wanted
to
check
in
and
see
if
there
are
any
outstanding
items
that
would
be
worth
reviewing
and
clarifying
synchronously
related
to
the
project
level.
Dast
scan
execution
policies,
epic,
I
know
we've
had
a
lot
of
a
lot
of
discussion
in
the
issues
which
has
been
great
to
have
that
asynchronous
and
have
it
documented
just
wanted
to
see
if
anything
would
be
useful
to
clarify
synchronously
alan's.
Not
here.
Does
anyone
want
to
vocalize
his
question.
B
I
can
do
that
he
was
asking,
I
believe
I
didn't
click
on
the
note,
but
based
on
your
answers,
asking
about
the
options
of
storing
the
policy
as
a
yamo
file
versus
database.
C
A
Are
in
the
epic,
so
you
know,
although
I
have
an
opinion
that
I'll
express
here
in
a
moment,
please
you
know,
feel
free
to
take
on
either
one
of
them.
You
know
again,
they
both
satisfy
the
customer
requirements.
I
think
there
are
pros
and
cons
to
both
and
there
could
be
a
solution
there
either
way.
A
A
It's
been
a
bottleneck
for
development
in
the
past,
but
I
do
feel
like
that
will
provide
a
much
cleaner
user
experience
because
they
won't
have
to
go
in
and
select
a
separate
security
orchestration
policy
project,
there's
a
very
similar
workflow
for
get
lab,
managed,
apps
version
2,
where
you
go
and
pick
a
cluster
management
project
for
your
cluster,
and
we
all
know
that
usage
of
that
has
been
really
really
low.
In
fact,
you
know
just
anecdotally
when
I've
talked
with
customers
about
it,
they've
been
surprised
and
to
find
out
that
it
was
even
there.
A
You
know
they
didn't
know.
It
was
there
at
all.
They
didn't
realize
that
it
was
there.
It
was
an
extra
step
that
was
buried
in
the
ui
in
a
way
that
was
really
hard
to
find,
and
so,
if
we
do
go
down
the
route
of
putting
it
in
a
repository,
we'll
probably
end
up
having
some
follow-on,
epics
or
issues
later
to
make
that
easier.
You
know
more
obvious
for
the
user
to
maybe
prompt
them
as
part
of
the
alert
dashboard.
A
You
know,
reporting
tends
to
be
a
little
bit
hard
because
you
then
have
to
go
into
all
of
the
repos.
So
anyway,
I
detailed
all
of
my
thoughts
there
in
the
notes.
I
posted
them
on
the
issue
as
well,
but
I
just
want
to
come
back
to
what
I
said
at
the
beginning.
You
know
I've
got
an
opinion
here,
but
I
don't
want
to
force
it
on
the
team.
You
know,
whichever
direction
you
feel
is
appropriate.
B
This
this
would
be
a
lot
more
similar
sam
to
to
the
cluster
management
project.
So
you
you've
got
that
for
a
group
just
because
you
adding
more
the
more
pods
to
our
applications
doesn't
mean
you
necessarily
need
a
new
project
for
the
cluster
configuration,
so
this
would
be
the
same,
but
there
there's
still
balances
there
to
to
look
for
both
of
them.
B
I
I
haven't
caught
up
to
the
latest
to
the
latest
on
on
on
that
issue,
I
I
did
notice
that
when
machia
first
proposed
the
implementation
steps,
it
wasn't
there
and
now
it
is
so
I
I
need
to
go
there
and
read
and
see
why
I
came
back.
Why
are
we
thinking
about
it?.
A
So
if
we
do
do
it
at
the
group
level,
rather
than
the
project
level,
that
does
handcuff
us
in
terms
of
our
permission
set,
because
we
have
customers
who
want
to
have
the
maintainers
of
the
project
have
access
to
edit
these,
but
not
necessarily
another
project
in
the
same
group
that
they
may
not
be
maintainer
on.
And
so
you
know,
a
big
full
policy
thing
is
getting
the
permission
set
right
and
giving
them
that
granularity,
and
I
do
have
concerns
if
we
do
that
on
the
group
level
related
to
future
requirements.
B
Yeah,
so
I
think
that
that
falls
in
the
future
proofing
question
because.
B
A
So
we
there
is
a
requirement
in
there
just
to
clarify.
We
do
want
to
limit
the
ability
to
edit
an
individual
projects
policy
only
to
the
maintainers
of
that
project,
so
yeah,
if
you,
if
you're
a
maintainer
on
one
project
in
a
group
and
you're,
not
a
maintainer
on
project
b
in
the
same
group,
you
should
not
have
the
ability
to
edit
policies
for
project
b.
B
Yeah,
which,
which
would
have
been
done
by
overriding
at
the
project
level,
because
you're
a
maintainer
you'll,
be
able
to
override
the
project
level
that
that's
where,
where
I
was
going
with
that
you,
you
have
one
more
comment
there
before
the
item
that
I
just
added.
B
Iv,
I
think
I
think
it's
the
same.
I
think
you'll
call
for
in
your
same
answer.
A
So
yeah
I
mean
I,
I
know
both
of
them.
Those
two
options
have
their
pros
and
cons.
I
know
working
with
the
database
has
been
painful.
Ultimately,
I
would
encourage
the
team
to
pick
the
right
technical
solution.
You
know
I'm
hopeful
that
at
some
point
in
the
future,
I
don't
know
how
long
it's
going
to
be,
but
we'll
make
it
a
little
bit
easier
to
get
changes
made
into
the
database.
A
So
you
know
this
is
something
that
we're
going
to
be
dealing
with
for
a
long
time,
and
so,
if
we
can
pick
the
option
with
less
long-term
technical
debt,
I
I
believe
that's
going
to
pay
us
dividends
in
the
future.
You
know,
rather
than
taking
perhaps
an
easier
way,
that's
going
to
be
more
costly
down
the
road.
So
I
you
know,
if
that
helps
your
decision-making
process
at
all,
like,
let's
lean
towards
the
one,
that's
the
better
technical
solution.
B
It
does
help
my
questions
is,
is
still
around
that.
So
one
of
the
I
remember
one
of
the
main
or
one
of
the
reasons
of
having
orchestration
policies,
security,
series
and
policies
is
for
the
use
case
where
a
company
has
you
know
tens
or
hundreds
of
projects
and
they
want.
They
don't
want
to
go
into
each
one
of
them.
Setting
policies
at
a
project
level,
meaning
we'll
do
that
at
the
group
level,
but
an
analyzer
such
as
dast
that
requires
always
requires
a
project.
B
You
know,
there's
a
standard
way
of
defining
the
eur
the
target
url
for
dust
and
that
then
all
projects
implement
they
have
to
implement
it,
and
otherwise
the
policy
will
execute,
but
you
will
fail
because
you
didn't
do
what
you
had
to
do
on
your
side
of
the
thing.
So
I
at
least
I
haven't
thought
about
that
before,
and
I
just
wanted
to
throw
it
out
there
to
to
other
people
in
case
there
was
an
epiphany
for
them
as
well,
and
and
if
you
have
some
thoughts,
sam.
A
A
Do
so
we're
still
figuring
out
the
right
solution
here?
I
will
note
you
know:
let's
not
get
too
hung
up
over
that
right
now,
it's
outside
the
scope
of
the
mvc,
exactly
and
actually
the
problem,
validation
that
I'm
doing
right
now
with
karen
is
poking
at
that
exact
problem
is
one
of
the
things
that
we're
we're
in
the
process
of
actively
researching
so
just
yeah.
This
cool
thoughts,
like
you
know,
especially
with
dast
like
we've,
got
these
desk
site
profiles
and
these
desk
scan
profiles.
A
I
think
one
potential
solution
would
be
to
specify
one
of
those
as
a
default.
You
know,
or
primary
one,
and
so
there,
as
you
mentioned,
there
would
be
a
prerequisite
to
have
that
configured
at
the
project
level
in
order
for
the
group
level
policy
to
work.
Otherwise
it
would
fail-
and
we
would
report
on
that.
B
It
can
be
a
standard
as
well.
Right
could
be
a
an
environment
variable,
that's
always
defined,
or
it
can
be
when,
when
I
think
gitlab
ci
has
cd
has
its
own
predefined
variables
for
the
for
the
application
they
got
deployed,
so
that
could
work
as
well
like
their
solutions,
just
something
that
I
you
know.
I
hadn't
thought
about,
but
you're
right
about
about
the
scope.
We
we're
not
letting
that
stop
us.
A
A
D
Just
doing
doing
what
I
can
over
here
yeah,
the
thing
I
got
in
this
time
is
originally.
If
you
went
to
the
threat
monitoring,
I
guess
I
could
demo
this
myself.
I
don't
have
it
set
up.
I
don't
worry
about
it.
Just
trust
me
when
you,
if
you
went
to
a
project
and
you
went
to
threat
monitoring,
if
you
didn't
have
an
environment
set
up,
there
would
be
an
empty
state,
svg
and
message
being
like
hey,
there's,
no
environment.
D
Look
at
these
docs
go
check
it
out,
but
there's
a
use
case
with
how
we're
releasing
the
alerts
where
a
project
won't
have
an
environment
set
up,
but
we'll
have
alerts
set
up,
and
so
my
change
is
so
that
now
that
when
you
go
to
threat
monitoring
without
an
environment
set
up,
the
alerts
still
displays
the
tab
with
saying
no
alerts
display
or
alerts.
If
you
have
any,
but
then
the
other
tabs
are
still
there,
statistics
and
policies,
and
then
those
have
the
individual
empty
states.
C
I
have
to
find
my
unmute,
so
this
is
less
of
a
planning
breakdown,
topic
and
more
just
a
quick
question.
We
don't
generally
keep
issues
or
create
issues
specific
to
documentation,
but
because
we
were
behind
a
feature
flag
for
the
alert
dashboard,
we
haven't
created
any
documentation.
Yet
this
can
be
very
simple
and
just
go
to
alexander
and
nick
gaskell
as
far
as
front-end
changes,
but
I
I'm
assuming
there's
some
back-end
changes
that
need
to
be
documented
from
the
api
perspective.
B
Was
typing
because
I
think
the
link
the
link
is
incorrect
is
pointing
to
jira?
Oh.
B
Yes,
you
you're
right
and
we
we
spoke
about
this
earlier
today.
I
I
don't
know
the
answer.
I
I
I
know
that
there
are
back
lots
of
backhand
species,
specific
things
and
I
know
there
will
be
some
front-end
information
to
to
share
as
documentation.
So
I'm
I'm
good
with
that.
I'm
good
with
the
starting
with
with
that
sort
of
division
of
labor,
so
to
speak.
C
B
D
B
Maybe
that's
the
exception
right
that
I
didn't
catch
on
yeah.
Maybe
that's.
B
D
I
immediately
went
to
the
docs
handbook
and
started
like
searching
for
things
so
we'll
get
back
we'll
come
back
to
that.
How.
B
I
think
you're
right
I'll
have
to
check
as
well.
I
know
I
know
that
stuff
with
feature
flag
has
been
documented
before
and
it's
called
out
hey.
This
is
behind
a
feature
flag.
C
Got
it
so
we
know
that's
true
of
the
front.
End
changes
back-end
the
documentation
is
usually
very
different.
Around
api
updates.
Are
you
saying
tiago
that
you
believe
that
the
back-end
documentation
updates
were
being
done
as
per
normal
when
we're
not
behind
a
feature
flag
and
should
have
been
released
or
updated
with
mrs
themselves?.
B
B
C
B
Don't
know
if
it's
none
of
it.
I
know
that
some
of
it
for
sure,
but
there's
work
to
be
done.
C
D
D
D
You
need
me
like
the
feature
plugin
can
be
turned
on
for
any
project
in
either
staging
or
production.
So,
if
you
want,
if
you
want
to
turn
it
on
for
other
projects
to
test
it
or
whatever,
I
don't
see
a
reason.
B
D
Say
there's
there
are:
there
are
a
couple
of
front-end
issues
that
are
not
completed
yet
that
might
we
might
want
to
hold
off,
for
one
is
the
issue
that
shows
an
alert
to
the
user
when
they
haven't
installed
cass
or
the
agent.
That's
not
in
yet
it's
in
review,
and
then
I
think
that's
okay,.
A
B
Appreciate
the
concern
and
alexander,
I
appreciate
the
concern
it's
a
good
call
out,
but
the
future
flag
would
be
for
staging
only
if,
when
this
goes
to
production,
you
would
still
be
behind
the
feature
flag.
D
Right
right,
definitely,
okay,
cool
and
then
the
other
one
is
that
we
aren't
both
alerts,
operations,
alerts
and
threat.
Monitoring
alerts
currently
will
get
both
alerts,
though,
and
that
mr
is
in
review
and
was
waiting
for
casks,
get
released
so
I'll
start
pushing
that
forward,
though,
but
that
also
doesn't
seem
like
a
blocker
for
turning
on
for
staging.
So.
B
A
D
Cool
all
right:
let's
do
it
I'll,
create
an
action
item
for
me
to
turn
on
this.
This
feature
flag
for
all
of
staging
them.
B
D
C
I
added
one
last
topic
that
just
came
up
in
my
mind.
While
we
were
talking
about
that
last
thing
was
that,
after
talking
to
sam,
he
made
a
really
good
point.
That
load
testing
would
be
very
useful
in
this
alerts.
Dashboard
scenario,
because
we
do
have
the
potential
to
have
to
make
great
harm
on
our
customers
production
environments.
If
we're
not
aware
of
how
maybe
a
huge
spike
in
alerts
might
affect
their
systems.
C
So
I
don't
have
any
experience
without
a
gitlab
I
have
in
the
past,
but
I
don't
know
how
to
apply
it
here.
So
this
seemed
like
a
really
good
case
where
we
could
pull
in
our
stable
counterpart
and
test
which,
despite
something
that
was
mentioned
in
an
earlier
call,
we
do
have
a
stable
counterpart
and
test.
C
Her
name
is
vinci,
and
I
know
she
hasn't
been
very
involved
yet,
but
we'll
start
to
take
small
steps
to
get
her
more
involved,
so
I've
got
a
one-on-one
with
her
later
this
week,
she's
already
replied
to
the
app
mention
and
the
epic
saying
that
she
has
availability
and
I'll
be
able
to
assist
with
this.
So
it's
not
a
blocker
for
getting
the
mvc
out
in
13.9.
Sam
has
made
that
clear
to
me,
but
it's
something
that
we
want
to
know
how
to
do
and
the
earlier
we
can
get
some
reasonable
load.
Testing
done.