►
From YouTube: Protect:Container Security group discussion 2021-10-19
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
the
group
discussion
for
the
container
security
group
today,
we've
got
just
one
agenda
item,
but
it's
a
big
one
and
that's
planning
breakdown
for
the
group
level
policy
management
feature
we've
been
doing
policies
at
the
project
level
for
quite
a
while
now
we're
at
least
working
towards
it
for
quite
a
while.
I
think
we
officially
turned
the
feature
flag
on
by
default
in
14.3
and
naturally
the
next
step
is
to
move
that
to
the
group
level
and
eventually
up
to
the
workspace
level
where
users
can
set
policies
once
for
their
entire
organization.
A
A
But
we'll
be
adding
a
new
source
column,
and
here
it
says
where
it
came
from
whether
it
came
from
this
group,
so
this
would
be
a
group
level
view
or
whether
it
was
inherited
from
something
above
it,
and
now
we
won't
have
workspace
policies
yet
as
of
this
feature,
but
this
is
to
give
you
an
idea
of
how
something
would
show
if
it
was
inherited
and
for
now
it's
just
going
to
apply
to
all
the
projects
inside
of
that
group.
We'll
worry
about
filtering
those
later,
but
it
gives
you
an
indication.
A
It
makes
that
super
clear
right
here.
It
says
the
policy
applies
to
all
56
projects
and
if
you
try
to
click
on
something,
that's
inherited,
you
get
this
read-only
message,
so
you
can't
change
it
here
and
same
thing.
This
would
show
like
a
project
level
view
you're,
seeing
things
that
are
coming
down
being
inherited
from
the
group
same
thing
on
the
side.
This
isn't
sam.
A
A
A
But
the
big
thing
here
is
the
source,
the
addition
of
the
source
section.
So
that
would
be
the
piece
that
concerns
this
epic,
we're
going
to
work
on
aligning
the
ux
for
this
in
a
separate
effort,
but
just
for
this
piece
it's
going
to
be
sourced.
It
says
this
is
a
group
level
policy
and
again
it
applies
to
all
39
projects
in
this
group
and
same
thing
like
the
group
level
or
if
it's
coming
down
from
a
workspace.
C
So
could
you
go
back
one
more?
Yes,
that
one
right
there,
so
one
thing
that
I
just
noticed
is
the
change
history.
I
noticed
it
only
refers
to
major
quests,
but
a
policy
may
not
necessarily
have
a
merge
request
to
be
changed.
Can
it.
C
A
A
B
C
Feature
so
I'll
make
I'll
make
a
note
to
go,
find
the
design
or
the
issue
related
to
that
and
get
feedback
on
that.
But
I
don't
want
to
do
real
examination,
so
go
ahead.
A
Thank
you
no
worries
and
that's
a
great
point
of
feedback
yep.
So
for
now
we're
just
adding
in
the
source
section
would
be
this
epic
and
then
the
other
change
on
the
front
end.
So
for
a
group
level
policy,
you
won't
get
this
banner
if
it's
a
project
level
policy,
but
if
it,
if
you
create
a
new
group
level
policy
or
edit
one,
it
just
makes
it
super
clear
by
including
this
banner
up
top
saying
you
know
after
you
enable
this
it's
going
to
apply
to
all
36
projects
in
the
group.
B
This
would
be
the
group,
it
should
be
the
okay.
Just
the
breadcrumbs
says:
giflaborgitlab
that
implies
project.
B
Thank
you.
You
mentioned
something
at
the
start,
and
you
said
it
didn't
provide
much
details.
How
do
we
actually
do
the
the
linking
because
for
projects
when
you
go
to
threat
management
it
offers
you
the
chance
to
link?
What's
the
idea
for
groups
do.
B
C
Yeah,
so
I
believe
the
way
it
works
right
now
it
doesn't
actually
tell
you:
hey,
go
link
a
policy
project
to
this.
What
happens
is
when
you
try
to
create
a
new
policy.
It
automatically
creates
the
product
for
you
right.
A
B
Sorry,
brian,
I
was
telling
sam
that
he
can
use
the
demo
project
demo
group
in
production.
E
A
Yeah,
so
we've
got
actually
priority
number
two
here:
this
follow-on
improvement
for
the
security
policy
editor
and
I
think
most
of
these
things
there's
a
big
long
list
of
issues
in
here,
but
I
think
we've
got
issues
covering
that
better
handling
when
users
do
not
have
permissions
to
create
a
policy.
A
Oh
right,
I'm
sorry,
I
interrupted
you,
but
this
sounds
related
yeah,
so
we
do
have
an
issue
out
to
fix
that
it
is
confusing
ux.
So,
instead
of
this
point,
if
you're
not
an
owner
and
there's
not
one
that
already
exists,
the
proposal
I've
got
here
is
to
display
an
empty
state
and
you
know
direct
them
now
the
project
owner
create
the
security
policy
project
because
actually,
in
that
workflow,
where
I
started
to
go
down
because
I'm
not
an
owner,
it
actually
would
not.
A
Let
me
create
the
new
policy,
because
I
can't
because
I'm
not
a
project
owner,
so
it
is
really
confusing
ux,
I'm
hoping
we
can
clean
that
up
here
soon.
E
Yeah
I'll,
let
I'll
let
all
the
front-end
people
know
to
start
working
on
that.
A
And
brian,
the
issue
that
you
were
mentioning
earlier:
cleaning
up
the
drawer,
that's
in
this
epic
as
well.
A
E
I
have
a
question
about
this.
I
was
just
typing
up
a.
I
was
actually
looking
at
the
epic
preparing
for
this
meeting
and
that's
why
I
was
late.
So
it's
typing
up
a
question
on
the
epic
there
and
you
may
have
addressed
this
already,
but
there's
a
lot
of
styling
updates
to
the
list
and,
like
you
mentioned
a
lot,
some
of
it's
covered
in
the
follow-on
epic
that
you
just
showed.
Some
of
it
is
new.
E
A
A
So,
like
you
know
the
other
styles
that
you
see
over
here,
you
know
you
can
disregard
those.
I
think
we've
got
other
epics
and
other
issues
to
cover
them.
You
know
like
this
pending
and
open.
Merge
requests,
that's
covered,
you
know
just
given
the
nature
of
how
we
break
up
our
work.
It
becomes
a
little
bit
complicated
for
ux
to
give
it
iteratively
in
the
exact
sequence
that
it's
going
to
be
developed,
and
so
what
ends
up
happening
is
ux
just
ends
up.
A
A
A
The
biggest
thing
to
worry
about
is
adding
in
the
source
column
here
for
the
list
view
adding
in
the
source
section
for
this
side
drawer,
creating
the
policy
page
for
a
group
at
the
group
level,
yeah
policy,
page
of
the
group
level,
giving
this
read
only
pop
out
for
if
it's
an
inherited
policy
that
can't
be
edited
here.
A
A
And
the
last
thing
would
be
this
info
box,
so
yeah
there's
there
are
more
things
in
these
mocks
than
are
included
in
the
scope,
but
if
you
kind
of
pair
you
know
the
requirements
with
the
mox
really.
The
effort
for
this
is
focused
on
adding
policies
of
the
group
level.
We
don't
need
to
match
everything.
That's
in
the
box
cool.
Thank
you.
E
I
saw
if
you
can
you
go
to
the
mock
for
the
group
level
policy
list.
Is
this:
it
yeah.
This
just
might
be
a
mistake,
but
the
fourth
policy
down
is
a
network
policy
which
is
not
inherited
from
a
policy
project.
Is
that
network
policies
should
not
be
supported.
A
Or
mock
yeah,
that's
just
another
result
of
the
mock
for
this
effort.
We're
only
doing
scan
execution
policies
at
the
grace
level,
we're
not
doing
network
policies
at
group
level,
yet
cool
yeah.
In
fact,
you
see
here
there
are
scan,
result
policies
in
this
box.
There's
a
lot
in
this
mock
that
we
have
not
built
out
yet,
but
don't
worry
about
anything.
That's
not
specifically
tied
to
group
level,
scan
execution
policies.
C
So
I
think
we
probably
want
to
have
all.
B
I'm
talking
I'm
talking
that
there's
a
there's
a
group
here,
there's
a
project
here
you
go
to
this
group
and
you
link
it
to
a
link
to
a
project
to
a
policy
project.
So
this
guy
is
now
obeying
those
policies
there.
Then
you
come
to
this
project.
Can
I
link
it
to
another
policy
project
and
if
yes,
then,
there's
follow-up
questions,
but
let's
start
with
that,
one.
A
Obviously
we
start
running
into
some
design
things
if
you,
if
the
answer
to
that
question
is
no,
then
we
need
some
error
states
and
some
warnings,
or
you
know
we
have
to
tell
the
user
that
from
a
functional
perspective,
I
can't
really
see
a
problem
with
that
on
the
project
page.
You
would
see
every
policy
duplicated
twice.
A
You
know
be
there
once
flowing
down
from
the
group
level
and
it'll,
be
there
again,
because
it's
there
on
the
project
level,
but
if
there's
some
other
backend
limitation
or
reason
that
we
can't
do
that,
then
you
know,
like
I
said,
there's
no,
like
user
requirement
to
have
it
mapped
to
both.
So
if
we
need
to
design
up
some
mocks
for
some
error
states
to
prevent
that,
we
can.
B
Okay,
so
we're
inclined
to
say
yes,
you
can
you
can
link
at
the
project
level
and
also
at
the
group
level
and
I'm
hearing
that
the
resulting
policy
at
the
project
level
is
additive,
meaning
whatever
you
had
at
the
group
level.
You
add
to
the
project
level,
there's
no
attempt
to
merge
them
by
name
or
by
whatever.
A
A
C
The
one
thing
I
can
think
of
is:
if
there's
two
policies,
it's
the
same
name,
you
might
be
able
to
override
a
group
of
a
policy
with
a
project
level
policy,
because
we
use
the
name
as
the
identifier
right
now,
unfortunately,
and
so
if
you
have
two
policies
with
the
same
name,
it
will
use
whichever
one
it
finds
first.
C
A
That
actually
may
not
be
a
bad
thing,
because
there
actually
may
be
cases
where,
in
fact,
I
know
there
are
cases
where
customers
do
want
to
override
things
for
specific
projects.
In
that
case,
I
you
know,
rather
than
just
having
it
be
random.
We
should
probably
hard
code
that
to
say
that
the
project
level
policy
overrides
the
group
level
policy
is
the
feedback
that
we
have
from
customers.
C
Yeah,
I
think
I
think
we
should
be
intentional
about
it,
rather
than
just
making
it
a
way
of
working
around
an
edge
case.
So
currently
we
would
pre.
We
should
probably
just
make
sure
that
you
can't
create
two
positives,
the
same
name
across
groups
or
workspaces
or
projects.
B
Across
groups,
meaning
subgroups
right,
we've
got
parent
group
a
then
subgroup
b
and
then
project
c.
So,
between
a
b
and
c,
you
can't
repeat
names
of
policies.
C
Yeah,
I
still,
I
still
haven't
wrapped
my
head
around
how
this
is
going
to
work
with
subgroups,
so
so
you're
automatic
you're
talking
out
of
my
depth
right
now.
B
I
I
I
don't
understand
the
mechanics
either
of
the
back
end,
but
at
from
from
an
object
level,
I
think
I
think
a
group
is
a
group.
Is
a
group
it
like
you,
get
a
menu
where
there's
a
group
or
subgroup,
and
then
it
just
changes
what's
in
the
contents.
Contents
of
that
group.
A
There
is
a
difference
between
groups
and
subgroups
in
the
back
end.
So
that's
another
note.
I
guess,
while
we're
on
that
topic,
which
is
why
you
know
from
the
back
end,
it
would
be
ideal
if
we
can
implement
this
associated
to
the
new.
I
think
they're
actually
calling
it
name.
Space
yeah
object
on
the
back
end
and
that
way
we
can
build
it
once
and
have
it
apply
to
everything.
A
A
B
I
think
I
think
this
is
going
to
come
up
again
when
we're
refining
this,
and
we
have
a
better
idea.
We
actually
look
at
the
back
end
and
see
how
things
tie
together.
We
might
say:
hey,
can
we
do
it
like
this?
Or
can
we
do
it
like
that?
But
for
now
I
think
the
answer
is
the
product
requirements
are
flexible
and
we
can.
We
can
work
with
you.
C
So
when,
when
you
said
about
so
when
you
brought
up
having
the
name
being
random,
I
had
a
thought
that
there's
there's
this
thing:
kubernetes
does
where
it
takes
whatever
name
you
use
and
it
adds
a
little
random
suffix
on
the
end,
so
that
the
names
don't
collide
with
each
other.
C
C
Yep
yeah,
I
think
I
think
the
the
way,
the
stuff
that
we're
allowing
names
is
pretty
right
now
is
pretty
confusing
too,
because
you
can
have
spaces
in
the
name
and
the
name
ends
up
going
in
the
url,
and
so
you
get
these.
You
get
these
really
weird
urls
when
you
pull
up
a
policy
in
a
posse
editor,
because
it
could
be
something
like
like
slash,
run
dust
in
every
pipeline
with
spaces
in
it,
and
nobody
like
that.
B
Right
it
doesn't
nobody
likes
percent
percent
symbols
percent
symbols
in
the
urls,
nobody
likes
it.
I
I
think
I
think
we're
okay
to
to
put
that
as
as
part
of
refinement
but
sam.
I,
I
think
we're
okay
too.
B
From
my
view,
I
I
don't
want
to
answer
for,
for
brian
and
and
alexander,
but
I'm
happy
to
to
move
to
the
like
planning
breakdown
of
the
high
level.
However,
high-level
issues
that
we
would
need
for
this.
A
C
Think
I
think
it
sounds
good.
You
know
the
most
stuff
you
have
questions
about.
Are
just
implementation
details
right,
so
we
can
figure
those
out
yep.
B
E
Yeah,
the
the
front
at
the
container
security
front
end
meeting
I'll
yeah
it'll
just
be
like
four
I'll
wear
different
hats.
So
you.
A
We
do
have
a
lot
of
work
here.
I
mean
this
is
priority
number
four,
so
I'm
hoping
we're
not
getting
too
far
ahead
of
ourselves
in
refinement
here.
This
is
probably
about
as
far
out
as
I
wanted
to
go,
so
we'll
probably
take
a
pause
on
putting
things
through
planning
breakdown
for
a
little
while
until
we
can
catch
up.
But
you
know,
even
though
we're
talking
about
this
today.
A
It
is
further
down
on
the
priority
list
compared
to
some
of
the
other
things
we've
got,
and
you
know
that
also
is
just
important
now
to
keep
in
mind.