►
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
well
welcome
to
our
weekly
meeting
for
our
container
security
group.
There's
no
other
way
to
start
this
meeting.
Other
than
saying
congratulations
to
the
team
for
getting
the
alert,
dashboard
out
the
door
and
shipped
I'm
super
excited
to
see
that
happen.
It's
just
a
huge
story.
It
was
top
of
the
release
post.
A
It
was
you
know,
got
mentioned
all
over
the
place,
it's
going
to
add
value
to
our
container
networking
story
and
it's
going
to
provide
a
good
foundation
for
us
moving
forward
as
we
move
other
kinds
of
alerts
into
that
dashboard.
So
yeah,
congratulations!
It's
great
to
have
that
out.
We
can
start
getting
customer
feedback.
I
am
fully
expecting
usage
to
be
fairly
low
of
it
right
now
and
into
the
near
future.
A
Just
you
know,
because
there's
a
lot
to
set
up-
and
you
know
we
don't
have
a
ton
of
customers
using
network
policies
as
of
yet
but
that's,
okay,
it's
okay
to
start
small
and
you
know
we'll
have
that
come
in
and
we're
only
going
to
expand
that
in
the
future.
So
I'm
I'm
excited
to
see
to
see
the
growth
of
that
one.
B
It
was
the
very
first
feature
mentioned
in
the
release
post.
It
was
like
fifth
paragraph.
A
Yeah,
so
just
so,
the
team
knows
next
steps,
I'm
working
to
update
our
marketing
collateral.
These
are
things
that
the
engineering
team
usually
doesn't
see,
but
like
we
have
a
slide
deck
that
that
I'm
updating.
A
I
want
to
update
the
demo
video
that
I
did
for
the
ebpf
summit
and
edit
it
a
little
bit
and
add
this
onto
the
end,
because
it's
nice
to
see
those
in
gitlab
instead
of
you
know
off
in
kubernetes
and
then.
Lastly,
I'm
going
to
work
with
wayne
to
figure
out
what
usage,
metrics
and
lindsey's
going
to
help
me
on
this
one
figure
out
what
usage
metrics
we
can
get
today
and
if
we
need
to
have
a
separate
issue
for
engineering
to
implement
those
we
will.
A
C
C
D
Certainly
not,
I
just
want
to
say
that
I
got
the
event
counter
column
into
the
alert
details
so
with
the
alert
details
page.
If
you
remember,
we
sort
of
got
the
counts
by
for
free
with
all
the
work
there,
but
now
is
added
to
our
list.
So
you
can
see
how
many
there
are.
A
Awesome
thanks
for
getting
that
through.
That's
that's
helpful
for
sure.
It's
easy
to
see
the
clients
that
we're
aggregating
them
now.
So
that's
that's
great!
That
was
going
to
be
a
big
pain
point.
As
we
observed
it's
amir's
demo
right
to
have
all
of
those
alerts
streaming
in
so
huge
huge
usability
improvement
by
the
way.
I'm
excited
side
note
the
linux
zoom
app.
Finally
added
the
reactions
button
for
me,
so
I
have
not
been
able
to
see
any
of
your
reactions
until
now
and
it's
great.
A
I
can
now
do
reactions
and
see
all
of
yours
alongside
you.
So.
A
Awesome
off
topic,
but
coming
back
to
to
the
main
thing
there
I
believe
we've
got
an
epic
ready
for
planning
breakdown.
Last
week
we
did
the
first
epic
in
our
desk
policy
work.
I
believe
the
second
epic
is
ready
as
well,
let's
deep
dive
into
that
one
and
then
we'll
come
back
to
the
walkthrough
of
everything
we're
doing
with
the
desk
policy
work.
So
it's
recorded.
A
A
A
E
Just
a
question
about
about
the
we
are
now
going
to
be
based
on
the
base
and
is
this
already?
Is
this
configuration
already
available
on
the
security
policy,
because
you
mentioned
that
there
is
no
ui
requirement
for
this.
A
Yeah,
so
this
is
not
in
the
database.
This
is
going
to
be
stored
in
a
separate
security
policy
project
repository
as
a
yaml
file.
So
we
would
just
be
extending
our
support
for
the
type
of
ammo
that
you
could
put
in
there
to
define
a
job
that
runs
on
a
daily
or
weekly
basis.
So
that's
why
there's!
No
ui
is
because
it's
all
in
that
yaml
project.
Okay,
thanks
for
dancing,
yeah,
no
problem
all
right!
Well,
I
saw
a
yes
from
tiago.
C
We
need
to
create
implementation
issues
off
of
this
that
will
be
refined.
I
know
that
this
process
is
working
a
little
bit
different
within
container
security
than
thread
insights
and
I'm
not
sure
quite
if
we've
solved
how
to
represent
that
and
thread
insights.
We've
had
design
issues
that
we're
assigning
to
dris
to
create
those
implementation
issues.
In
this
case,
how
do
we
want
to
have
front-end
and
back-end
implementation
issues
created
that
can
then
be
refined.
B
Yeah
so,
and
and
with
the
design
issue,
then
we
we
won't
have
or
also
don't
need
one
yeah.
I
I
was
just
going
to
slap
jan
as
a
dri
on
this
one
and
have.
E
A
C
Whichever,
as
long
as
we
know
the
process
that
works
for
you
guys
and
it
sounds
like
tiago
just
described
it
so
he's
gonna
mention
someone
on
here
to
get
the
back-end
that
she's
created.
A
Okay,
all
right,
so
this
last
one
that
that
lindsay
volunteered
me
for
it's
a
great
great
idea,
thanks
for
thanks
for
suggesting
this
for
monday,
I
I
went
there.
C
Yeah
before
you
jump
in
sam,
you
know,
given
that
the
front
end
has
been
focused
on
alerts
and
it's
hard
to
follow
this
many
conversations
at
once.
I
got
a
ton
out
of
that
description
that
you
gave
to
us
yesterday.
I
apologize
that
we
didn't
just
record
it
yesterday
so
that
we
could
have
shared
it.
Then.
A
Yeah,
absolutely,
and
to
be
fair,
we've
had
a
lot
change
here
on
this
epic.
I
I
I
can't
even
begin
to
you
know,
speak
to
the
magnitude
of
back
and
forth
and
change
that
we've
had
so
where
we've
landed
is
a
seven
step
process
and
I'm
going
to
share
my
screen
and
walk
through
this.
A
So
the
very
first
step
is
going
to
be
creating
a
separate
project
very
much
like
how
gitlab
managed
apps
version
2
works
today,
where
you
have
a
separate
project,
that's
linked
to
your
main
project.
For
the
sake
of
this
narrative,
I'm
going
to
call
it
the
production
project,
so
you
have
the
production
project
in
your
security
policy
project.
A
Just
to
show
what
this
will
look
like
in
the
ui,
we
will
be
adding
a
new
navigation
item,
on
the
left
hand,
side
for
policies
and
we'll
let
you
pick
a
project.
This
will
be
any
project
at
all,
there's
no
restrictions
there.
It
can
be
the
same
project.
You
can
have
multiple
policies
point
to
the
same
project.
It
doesn't
really
matter
if
that
that
project
then
has
a
yaml
file
in
the
right
location
that
yaml
file
is
going
to
control
what
policies
get
applied.
A
So
it's
a
very
minimal
step,
a
minimal
iteration
to
get
things
out
the
door
with
this
first
pass.
We're
only
going
to
be
supporting
das
policies
running
in
the
pipeline
and
only
at
the
project
level,
so
we're
not
doing
group
or
workspace
level.
Yet
all
of
the
permissions
for
this
will
be
managed
in
that
security
policy
project.
A
They
want
to
set
these
up
and
be
confident
that
they're
in
place
and
know
that
you
know
no
developer
can
come
along
and
intentionally
or
likely
accidentally
change
it
and
right
now,
that's
the
case
with
the
gitlab
ci
dot
yaml
file
developers
have
access
to
edit
that
even
using
code
owners,
you
can't
fully
lock
that
down,
and
so
it's
just
too
easy
for
someone
to
come
in,
and
you
know
change
das
to
enabled
to
true
or
sorry
that's
disabled
to
true,
which
would
disable
the
dash
job
having
a
separate
policy
or
separate
project
lets
them
separate
out
those
concerns.
A
Now.
One
of
the
challenges
here
is
that
these
dashed
policies
are
going
to
be
referencing.
Profiles
that
are
stored
in
the
database
and
those
profiles
are
set
up
in
the
security
and
compliance
on-demand
scan
area.
So
again,
in
order
to
enforce
that
complete
separation
of
duties
where
developers
are
not
able
to
just
to
get
rid
of
those
scans
anytime,
a
profile
is
in
use
by
a
policy
we're
going
to
just
take
the
easy
mvc
route
and
make
it
not
editable
at
all.
A
So
the
only
way
to
edit
or
delete
that
policy
would
be
to
remove
that
profile
from
all
of
the
policies
in
your
organization,
and
at
that
point
you
would
then
be
able
to
edit
or
delete
the
profile.
So
it's
probably
not
the
the
best
solution,
but
it's
a
fast
and
easy
one
that
lets
us
make
sure
that
we
have
a
separation
of
duties
and
we
can
always
iterate
on
that
in
the
future.
Tiago.
B
A
So
I'm
I'm
fine
with
that.
I
don't
know
if
annabelle
got
back
to
you
on
that
one
or
not,
but
I
think
she
would
be
the
bri
for
that
naming.
B
That
can
come
out
in.
We
can
continue
with
the
planning
breakdown
right
on
asynchronously.
A
A
Yeah
so
right
now
it's
just
das
scan
execution
policies.
So
if
we
want
to
get
that
specific,
we
certainly
could
but
yeah
whatever
annabelle
decides
to
name
that
yeah.
A
Yep
and
and
good
call
out
right,
like
with
this
first
mvc,
we
are
going
to
have
two
separate
policy
areas
in
the
product.
It's
not
ideal,
but
it's
a
it's
good
for
the
mvc
and
we're
going
to
clean
it
up
later.
So
you
will
have
policies
here
and
then
you'll
also
have
your
policies
on
the
threat
monitoring
page
under
the
policies
tab.
So
it
temporarily
will
be
in
two
places.
A
A
So
the
third
iteration
we
want
to
start
implementing
some
of
the
functionality
that
users
have
in
their
repository
in
the
ui,
with
the
ultimate
goal
of
hiding
away
that
security
policy
project
in
the
end,
users
should
not
need
to
think
about
where
their
policies
are
stored
or
how
all
of
that
is
managed,
like
it
shouldn't
matter
to
them,
if
it's
in
the
database,
if
it's
an
elastic
search,
if
it's
in
a
repository,
if
it's
just
files
on
our
file
system,
like
you
know,
all
of
that
really
needs
to
be
transparent
to
the
end
user
and
not
something
that
they
have
to
think
about
and
worry
about.
A
As
they're
setting
up
these
projects
now
getting,
there
is
going
to
take
some
time
so
iteration
three
we're
going
to
start
implementing
our
ui
editor.
For
this
we're
going
to
still
let
users
view
the
security
policy
project.
Repository
they'll
still
manage
their
permissions
there,
but
we
do
want
to
start
implementing
a
ui
way
for
them
to
edit
that
yaml
file.
A
So
that's
where
this
prototype
comes
into
place
at
this
point
in
time,
we
would
be
getting
rid
of
the
policies
tab
under
the
threat
management
page,
and
we
would
be
merging
that
with
the
policy
you
know,
merging
those
two
together,
so
that
it's
all
in
one
place,
you'll
have
your
container
runtime
policies
for
your
container
network
policies
and
scan
execution
policies
for
this.
This
approach
for
this
first
for
this
third
iteration,
I
guess
I
should
say
we're
only
giving
them
yaml
modes
so
there's
no.
A
A
A
That
you
get
on
that
page,
we
want
to
also
show
policies
that
are
in
a
pending
approval
state,
so,
instead
of
enabled
disabled
for
status,
you'll
have
a
third
option
here
of
pending
approval
and
what
that
will
do
is
it'll
pull
any,
mrs,
that
are
in
that
project
and
it'll
display
them
as
pending
approval
policies
here
and
if
you
click
on
any
of
those
it'll.
Take
you
to
that.
Mr
so
again,
it's
sort
of
an
intermediate
step
to
start
providing
some
ui
around
that
approval.
A
The
fifth
iteration
will
be
to
show
the
policy
history,
so
you
know
another
benefit
of
having
it
in
this
repository
in
gitlab
means
that
we
get
for
free
today
the
ability
to
go
back
and
see
all
of
the
edits
to
those
policies
over
time.
So
if
we're
going
to
hide
this
project
away
before
we
do
that,
we
need
to
preserve
that
functionality
in
our
own
ui,
so
this
piece
has
yet
to
it
is
not
designed.
Yet.
A
This
is
one
of
the
things
that
annabelle's
working
on
right
now,
but
identifying
how
and
where
in
this
ui
do
we
let
them
see
the
history
of
changes
that
were
made,
who
made
it
who
approved
it?
What
was
the
yaml
at
that
point
in
time
and
then
in
our
sixth
iteration?
I
think
at
that
point
in
time,
we'll
have
enough
functionality
in
the
ui
that
we
can
start.
A
A
B
Just
to
interject
quickly,
sam,
because
migration
can
be
loaded
terms
for
backend
engineers,
we're
always
thinking
of
when
you
say
migrations.
We
think
of
db
migrations.
What
what's
happening
there
is.
The
contents
of
repository
needs
to
be
migrated
to
a
repository
on
on
a
new
hidden
project,
so
yeah
that
migration
wow.
That
migration
may
include
some
database
migrations,
but
it's
mostly
about
getting.
You
know
things
from
one
repo
to
another,
repo
that
yes.
A
Exactly
yeah
you're
right,
it
may
involve
some
database
changes,
but
we're
not
really
talking
about
a
database
migration
here,
because
we're
using
this
repository
as
our
database
essentially
right
we're
using
this
to
store
the
policies
so
in
pre-migration
just
to
get
into
the
details,
because
we
have
time
you
know
we
were
allowing
users
to
have
extreme
freedom
with
this
security
policy
project,
they
could
have
multiple
production
projects
appointed
at
the
same
security
policy
project.
A
In
fact,
this
production
project
a
could
even
point
it
itself
as
its
own
security
policy
project,
and
so,
if
we're
going
to
hide
this
away,
we
can't
just
go
hiding
this.
We
don't
know
what
else
is
in
that
project.
We
don't
know
what
you
know.
We
have
to
be
really
careful
with
that.
So,
instead
of
hiding
this
project,
what
we're
going
to
do
is
we're
going
to
create
a
new
project
with
the
yaml
file
from
your
original
project
and
hide
the
new
project
away.
So
it's
new.
A
We
know
that
the
only
thing
in
there
is
the
yaml
file
that
we
copied
over.
We
can
safely
hide
that
and
start
actually
managing
that
you
know
for
them.
Rather
than
giving
them
full
freedom,
although
this
does
take
away
some
capabilities
for
them,
it
gives
us
the
ability
to
provide
a
better
user
experience,
because
we
have
control
over
that
project
now,
so
we
can
actually
govern
how
things
work
in
that
project.
A
Part
of
that
governance
is
going
to
be
changing.
The
way
that
permissions
work
previously
users
will
have
had
to
manually
add
everyone
that
they
wanted
to
have
access
to
this
project
and
now
we're
going
to
start
automating
that
which,
especially
for
organizations
that
have
thousands
or
tens
of
thousands
of
projects,
that's
a
really
important
step,
because
it's
not
going
to
be
scalable
for
the
security
application
security
team
to
go
in
and
add
the
proper
developers
and
maintainers
on
all
of
their
different
security
policy
projects.
A
So
we'll
have
to
implement
some
sort
of
synchronization
mechanism
there,
where
if
a
maintainer
is
added
or
removed
here,
it
automatically
adds
or
removes
them
as
a
developer.
On
this
new
hidden
project,
these
developers
and
reporters
will
have
the
ability
to
propose
changes
to
the
project,
but
they
will
not
have
the
ability
to
merge
them
in
so
we'll
set
up
this
hidden
project
as
a
project
that
has
a
protected
master
branch
by
default,
so
that
only
maintainers
can
merge
in
and
then
these
maintainers
will
be
decided
by
an
organization-wide
list
of
security
approvers.
B
B
It's
not
a
good
choice
to
go
embedding
that
as
a
as
an
actual
role
in
the
model
in
the
existing
models.
That's
far
too
complicated
to
go
in
there.
We
don't
know
where
it's
gonna
go,
so
the
the
best
choice
there
is
to
do
something
on
the
side
that
acts
like
a
new
role,
but
it's
it's
not.
A
Yeah
we
could
easily
burn
the
entire
team
working
for
a
year
to
add
a
new
role
into
gitlab,
I'm
afraid
so
yeah.
That's
a
good
call
out
thanks
for
that
tiago
from
a
developer
perspective,
it's
not
a
new
role,
just
think
of
it
as
a
new
capability
to
define
a
list
of
security
approvers
that
become
maintainers
on
these
projects.
A
A
You
know,
after
that,
we're
not
going
to
stop
we're
going
to
be
doing
things
like
adding
support
for
sast
and
the
other
scanners,
we're
going
to
want
to
up
level
this
and
allow
users
to
define
these
policies
of
the
group
and
workspace
level
and
we're
going
to
want
to
add
more
types
of
rules.
So
we
want
to
add
scan
results,
policies
and
other
things,
but
all
of
that
is
down
the
road.
We're
not
worrying
about
that.
A
Right
now,
for
the
immediate
time
period,
we
we've
got
this
seven
seven
iteration
breakdown
that
we're
going
to
work
through
and
once
we
get
through
that
we'll
kind
of
pick
up
our
head
and
go
from
there.
A
Any
other
questions
on
that.
I.
E
Have
a
question:
I
was
thinking
that
initially,
let's
say
that
the
user
creates
a
new
policy
and
then
we
are
going
to
trigger
a
new
repository
right
and
let's
imagine
that
the
user
is
able
to
see
that
there
is
a
repository
created
over
there.
So
then
he
can
either
choose
to
maintain
on
their
own
or
automate.
E
Let's
say
that
the
user
might
have
a
couple
of
apis
that
they
they
do
a
couple
of
things
here
and
there
and
then
over
time
we
are
going
to
remove
it
and
and
more
than
remove
it,
we
are
going
to
kind
of
remove
the
access
to
the
project
itself.
We
are
going
to
create
a
new
way.
E
I
was
wondering
if,
in
between
these
stages,
would
be
possible
for
us
to
get
some
feedback
from
the
users,
because
I
noticed
that
from
from
a
couple
of
projects
that
I'm
I'm
I'm
I'm
working
with
people
sometimes
just
reviewing
mars
and
things
like
this
people
always
try
to
do
ci
first
and
looks
like
that's
kind
of
a
culture
that
users
are
kind
of
excited
about
it.
So
I
just
I'm
just
concerned
that
we
are
going
to
add
a
lot
of
complexity
by
hiding
something
that
maybe
the
user
actually
wants
to.
Have
it.
B
I'd
like
to
add
a
disclaimer
sam
that
I
did
not
speak
to
them
here
about
this.
No,
I
I
I
think.
Let
me
sorry,
let
me
tell
somebody
what
nintendo
the
private
joke
is.
I
was
talking
to
sam
about
this
yesterday
and-
and
I
was
talking
about
this
more
or
less
the
same
thing
say:
hey
we're
giving
users
a
text
area
in
the
ui,
but
that
is
not
the
same
as
having
a
git
repo
that
you
can
push
to,
and
script
and
and
do
other
functionalities.
A
Almost
all
of
the
developers
have
raised
that
question
in
one
way
or
another,
at
least
all
of
the
back-end
ones
right.
So
the
trade-off
with
all
of
that
freedom
is
that
we're
losing
some
of
the
control,
and
so
it's
harder
to
provide
a
clean
user
experience.
A
We're
also
looking
at
maybe
offering
a
way
to
optionally
show
the
project,
but
as
soon
as
you
show
the
project,
then
the
permissions
become
really
complicated
because
if
they
add
a
developer
here,
does
that
mean
it
goes
and
adds
a
maintainer
on
this
other
project
too,
and
so
now,
you're
talking
about
a
two-way
synchronization
and
so
showing
the
project
has
a
lot
of
complexities
with
it
that
I
don't
know
that
we'll
want
to
take
on.
E
A
B
If
we
can,
if
we
can
stay
open
to
that
possibility,
it
would
be
good
because
there
are
other
things
that
you
can
do
showing
the
project,
but
but
taking
away
some
of
the
permissions
and
the
project.
For
example,
you
hide
the
members
and
disabled,
so
there
are
ways
to
play
there.
It
will
all
depend
when
we
get
to
the
nitty-gritty
of
refining
and
figure
out
how
we're
going
to
do
these.
A
Right
thanks
everyone,
if
you
have
more,
please
send
them
async.