►
From YouTube: Protect:Container Security group discussion 2021-09-21
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
B
B
Yes,
scan
execution
policies,
they're
live
yay,
the
future
flag
has
been
turned
off
and
we're
just
excited
to
have
people
using
it
now
and
keep
an
eye
out.
We
we
didn't,
we
didn't
let
our
support
counterpart
knows.
I
suppose
we
should
right.
A
C
E
B
A
C
On
the
related
topic,
how
long
we
want
to
leave
this
feature
flag
in
until
we
have
the
confidence
to
remove
it?
We've
typically
that's
been
dependent
on
the
size
of
the
feature
and
really
on
a
case-by-case
basis,
but
we
wanted
to
bring
it
here
and
thought
that
14-4
was
our
suggestion.
E
So
there
is
an
issue
that
alexander
made
to
remove
the
old
pages
yeah.
We.
C
E
I
was
just
thinking
once
you
remove
the
feature
flag,
we're
past
the
point
of
when
we
turn
and
recap
exactly.
B
Does
anybody
know,
does
anybody
know
if
we
remove
the
if
we
switch
the
flag
on
by
default
or
if
we
change
it
on
the
bot
justfuck.com.
B
The
the
feature
flag
can
be
turned
on
on
the
bot
or
it
can
be
switched
on
by
default
via
code.
I
don't
know
which
one
we
did.
B
C
E
Yeah
just
wondering
do
we
have
like
any
metrics
for
how
many
people
have
used
a
new
page,
how
many
visits
have
been.
C
A
But
you
can
see
the
results
of
turning
that
on
you
know.
They're
definitely
has
been
some
interest
there.
If
you
look
at
our
page
in
periscope
versailles,
I
think
it's
called
now.
B
B
Hi
alexander,
okay,.
E
Okay,
I'll
go
ahead
and
move
on
to
my
item
I
wanted
to
talk
about.
There
was
a
rather
lengthy
discussion
on
some
documentation
that
I
wrote
for
the
cluster
image
scanning
analyzer.
I
will
put
up
in
just
a
second
I'm
trying
to
figure
out
the
screen
share.
E
First
time
with
two
monitors
and
I'm
saying
about
okay,
so
for
the.
E
Cluster
image
scanning
the
cluster
image
scanning
analyzer,
sorry,
cluster
image
scanning
runs
in
two
places.
It
can
either
run
in
clcd
or
it
can
run
in
the
gitlab
agent
and
for
the
gitmap
agent
to
get
the
configuration
right
now.
E
The
only
way
to
do
that
is
to
use
a
configuration
repository
which
is
awfully
similar
to
the
security
orchestration
policies,
but
there
this
is
the
configuration
that
we
have
and
in
order
to
configure
the
agent,
the
user
has
to
commit
this
into
the
configuration
file
in
their
agent
repository
and
it's
basically
mirroring
what
we
have
for
the
scan
execution
policy.
E
B
E
Yes,
that's
correct
the
starboard
operator
automatically
scans
resources
when
they
change.
B
Which
is
what
agent
k
is
doing
as
well
right
only
on
on
its
own
schedule,
rather
than
when
the
pipeline
runs.
A
E
Make
it
a
configuration
option,
so
that's
totally
feasible
as
well.
E
Let
me
write
that
down.
Could
someone
take
notes
from
me.
E
So
back
to
the
discussion
thread,
sam's
concern
is
basically
we
have
this
separate
configuration
that
does
the
same
thing
as
the
scan
execution
policy
and
we
don't
want
to
have
the
users
have
to
maintain
two
separate
configurations
right.
E
Like
expressing
what
I
mean,
but
I
think
I
think
people
shouldn't
be
configuring
step
via
other
policies.
The
policy
should
be
used
to
enforce
configuration.
B
I
usually
in
terms
of
security,
what
happens?
There's
a
policy
that
mandates
something
creates
a
requirement
and
then
there's
a
procedure
to
execute
it,
which
will
then
create
that
configuration
of
that
I
think
you're
writing
that
we
conflate
both
a
little
bit.
Even
if
you,
if
you
look
at
the
existing
scan
execution
policies,
you
could
think
of
them
as
configurations,
because
you,
you
you're
still
setting
schedules
and
you're
setting.
So
I
don't
think
we're
deviating
too
much
from
the
pattern
there.
B
What
I
what
I
wanted
to
get
out
of
that
thread
and
I'm
happy
that
you
brought
it
here.
Thank
you
is
do
we
do
we
refactor
dmr
to
to
take
the
results
of
this
discussion,
or
are
we
okay
to
continue
dmr
and
then
we
iterate,
because
we
we're
releasing
this
in
alpha,
so
changing
the
schema
is
not
a
huge
deal
breaker.
Ideally
we
wouldn't,
but
that's
what
I'm
putting
out
there.
It's
mostly
a
question
for
sam.
I
think.
A
Yeah
I
mean
I
don't
if
we
want
to
refactor
the
existing.
Mr,
we
could,
if
we
want
to
make
a
new
mr
to
change
it,
I'm
fine
with
that
as
well.
That's
more
of
like
a
order
of
operations
question
and
I'm
not
too
particular
there
so
say
whatever
you
think
best,
if
it's
better
to
just
merge
in
what
you
have
now
and
then
change
it
later,
either
way,
I'm
fine
with
either.
Thank
you,
sir.
E
A
What
you're
saying,
though,
about
the
configuration
versus
policy-
and
it
certainly
does
feel
like
we're,
conflating
the
two
on
the
back
end.
You
know
especially
to
you,
because
you're
an
engineer
you've
worked
on
this.
You
understand
all
the
inner
workings
of
the
whole
process
start
to
finish,
but
you
know
if
you
were
to
take
a
step
back
and
think
of
it
from
the
perspective
of
someone
whose
job
it
is
to
make
sure
that
this
cluster
gets
scanned.
I
don't
know
that
they
see
so
much
of
a
difference.
A
A
There
are
some
cases
where
we
may
not
be
able
to
actually
enforce
this
policy
right
because
it
technically
is
configuration,
and
so
if
the
network
goes
down
or
name
spaces
change
or
you
know,
there's
a
lot
of
things
that
can
go
wrong,
and
if
that
happens,
you
know
now
your
policy
that
you
wrote
is
no
longer
being
enforced,
and
so
I
think
the
follow-on
to
that
is.
I
opened
an
epic
to
capture.
A
You
know
something
that
can
be
done
in
a
future
improvement,
but
you
know,
I
think
the
solution
to
that
is
just
to
display
an
error
state
and
make
it
really
apparent
to
users.
This
policy
that
you
created
it's
enabled,
but
it's
not
working
and
here's.
Why
and
actually,
as
thiago
pointed
out,
that
state
could
be
true
of
most
or
maybe
even
all,
of
our
policies
in
one
way
or
another,
you
know
just
a
regular
desk
scan
could
fail
to
run
because
the
url
that
was
supplied
doesn't
match
up
with.
A
E
Okay
and
yeah
about
the
configuration
michael
from
configure
group
is
kind
of
pushing
back
a
little
bit
on
the
configuration
that
I
have
so
I
may
need
to
change
it
anyway,
but
it's
something
that
you
need
to
think
about
a
little
bit.
B
Yeah
for
completeness
and
for
people
who
prefer
to
watch
this
rather
than
read
the
the
huge
thread,
what
sam
suggested
was
to
have
the
front
end,
somehow
read
the
objects
in
the
cluster
and
display
that
to
the
user,
when
they
creating
the
the
policy,
say:
hey.
These
are
the
name
spaces,
just
tick,
some
boxes
and
we'll
scan
them.
For
you.
B
So
I
don't
know
if
you
thought
about
that
brian,
but
I
know
you
can't
make
synchronous
requests
from
the
front
end
through
the
back
end
to
through
the
agent,
because
you
got
to
wait
for
the
agent
to
talk
to
gitlab,
not
vice
versa,
but
yeah.
If
we
were
down
that
track
would
probably
need
to
would
be
another
synchronization
item
for
us
to
keep
on.
On
the
back
end.
A
A
E
Yeah,
I
think
I
think
it's
a
little
bit
there.
I
have
not
looked
at
the
epic
yet
so
I
will
take
a
look
at
that
after
and
if
I,
if
I
have
any
follow-up
questions,
then
I
will
ask
those.
A
B
E
B
I
don't
know
which
one
we're
talking
about,
but
the
one
they
want
to
communicate
policy
errors
to
the
users
who
need
front-end
right,
that
that
must
be
not
the
one.
We're
talking
about.
A
A
All
right
anything
else
to
cover
today,
as
thiago
said
clear:
as
mud
yeah
don't
hesitate
to
reach
out
again.
If
you
know,
if
you
get
confused
again
or
if
we
need
to
talk
through
it
more
with
this
one.
I
know
it's
there's
a
lot
here
and
there's
a
lot
of
details
to
keep
track
of.
E
When
I
was
doing
this,
I
was
kind
of
thinking
well
the
policies.
The
policies
can't
work
with
this,
so
we're
not
gonna.
I
didn't
really
realize
that
we're
still
gonna
have
cluster
image
standing
policies.
A
Got
it
okay?
Well,
yeah,
hey
thanks!
Everyone
for
the
discussion
today.
Are
there
any
other
items
or
should
we
call
it.