►
From YouTube: Protect:Container Security group discussion 2021-08-31
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
weekly
group
meeting
for
container
security
alexander
per
usual,
you
have
a
couple
items
to
demo
for
us.
B
Yeah,
so
the
first
thing
is
the
scan
execution,
sidebar
version.
One
is
up
on
staging
now,
so
now
it
parses
the
rules
and
actions,
and
we
can
see
what
a
scan
is
all
about
without
having
to
dig
into
the
details
of
it
and
there's
been
a
couple
of
really
great
iterations
on
this
already,
and
so
this
probably
won't
stay
around
for
long.
But
it
is
something.
B
And
then
the
second
point
is
there
are
a
couple
of
mrs
that
are
left.
They
actually
just
got
merged
last
night
that
fixed
some
bugs
that
were
found,
but
these
are
the
last
mrs,
as
soon
as
they
get
merged
and
they
get
verified
and
I'll
run
through
all
the
sort
of
manual
testing
of
creating
a
scan
execution
policy,
editing
deleting
and
then
doing
so
with
the
other
policies
to
make
sure
there
are
no
regressions
I'll,
be
putting
up
some
docs
and
then
turning
on
the
feature
flag
for
production.
A
B
Yeah
and
if
anybody
finds
anything,
no
one's
informed
me
of
any
issues
yet
besides
the
ones
I
have
found,
but
you
certainly
if
you
find
something
please
let
me
know
and
I'll
get
that
fixed
asap.
B
C
Okay,
hello,
so
I
know
that
we
talked
about
it
sam
some
time
ago
about
where
to
put
the
configuration
for
the
cluster
and
agents
and
the
policy
itself.
When
I
was
started
working
on
it.
For
me,
it
seems
more
natural
to
to
have
it
in
action
itself
rather
than
in
a
rule.
C
I
added
my
explanation
in
in
the
issue
I'm
working
on,
so
I'm
not
sure
if
we
want
to
go
through
this
right
now
or
you
want
to
read
it
and
and
respond
there.
Asynchronously.
A
Yeah
we've
got
time,
so
we
can
talk
about
it
and
we've
got
amelia
on
as
well
and
alexander
so
yeah.
I
think
this
is
a
great
group
to
to
discuss
it
with.
Let
me
pull
up.
I
just
got
in
so
I've
scanned
this,
but
I
have
not
read
it
thoroughly.
So
maybe
you
can
walk
us
through
your
your
thinking
here.
C
Okay,
maybe
I'll
share
my
screen
and
I'll
okay.
C
C
Okay,
so
I
hope
you
can
see
it
so
this
is
what
we
proposed
initially,
that
we're
gonna
have
cluster
configuration
or
agent
configuration
with
the
rule
itself,
and
my
proposal
is
actually
to
move
that
section
so,
instead
of
having
it
here
whenever
we
have
cluster
image
scanning
here,.
C
We
will
add
the
configuration
for
the
analyzer
itself,
so
what
cluster
should
we
use?
What
kind
of
namespaces
should
we
scan
and
so
on
here
instead
of
having
in
in
roles
so
we're
doing
similar
thing
for
das,
for
example,
when
whenever
we
have
scan
dest,
we're
telling
oh
use
that
test
profile
and
so
on?
So
just
like
the
configuration
that
is
supplied
to
the
scan
itself,
so
I
I
believe,
we've
discussed
that
in
the
past.
I
don't
remember
what
was
the
the
outcomes
of
our
discussion.
C
Why
we
put
it
here
instead
of
putting
them
here
just
during
the
like
development
land
and
during
like
the
whole
building
the
whole
solution,
it
seems
like
we
could
have
it
here,
but
from
the
development
point
of
view,
it
will
be
like
hacking,
because
then
we
need
to
somehow
provide
that
information
to
actions
and
then
use
that
actions
and
especially
on
the
ui.
Imagine
that
you're
configuring,
I
believe
we
have
some
something
here.
C
Imagine
you're
configuring
here:
okay,
if
pipeline
is
run
four
main
branch
and
then
I'm
setting
okay
require
a
cluster
image
scanning
scan
and
then
this
section
will
be
automatically
expanded
with
some
information
that
you
need
to
supply
because
you've
selected
something
here
for
me:
it's
rather
networld.
Okay,
I
selected
something
here
and
then
I
have
additional
options
here
that
I
need
to
add
some
information.
What
kind
of
scan
should
I
need
to
provide
and
which
cluster
and
so
on.
A
Thoughts,
do
you
mind
if
I
share
my
screen
now
to
trick
with
my
thoughts
here
on
this,
so
one
of
the
challenges
is
that
we
are
supporting
so
right
now
the
branch
selection
is
part
of
the
rule,
and
maybe
we
should
move
this
down
to
the
actions.
A
We
don't
even
have
a
you
know.
We
never
really
had
a
notion
of
supporting
that.
It
always
was
only
going
to
be
done
via
a
schedule
rule
and
that's
because
when
you're
scanning
production
it
really
is
independent
of
the
pipeline.
It
doesn't
really
have
anything
to
do
with
the
pipeline
and
so
scanning.
The
production
cluster
really
only
makes
sense
on
a
scheduled
basis,
and
so
right
now
you
can
schedule
a
branch.
You
know
for
dast
again
and
you
can
pick
these
configuration
options.
A
But
you're
picking
which
branch
up
here
in
the
rules
and
that
doesn't
really
apply
for
cluster
image
scanning,
and
so
that's
part
of
the
reason
why
we
were
proposing
to
make
the
cluster
selection
appear
in
the
rules,
because
that
would
take
the
place
of
the
branch
you
would
replace,
selecting
a
branch.
You
know
you
would
pick
either
a
branch
or
a
cluster,
and
if
it
was
a
cluster
then
that
you
know
obviously
gas
couldn't
run
in
this
case.
So
it
needs
some
validation.
A
But
that's
where
you
would
run
your
container
scanning
against
the
club,
the
production
cluster.
So
I
guess
I
was
thinking
about
it
less
as
a
scanner
configuration
because
I
know
like
from
a
backend
perspective.
C
Got
it
okay,
yeah?
Now
I
remember
everything
yeah.
You
know
I
was
five
weeks
off
and
I
I
totally
forgot
about
that.
Yeah,
okay,
yeah,
it's
clear
for
me.
Still
on
the
develop
like
in
the
code.
I
will
need
to
do
some
tricks
to
support
that,
but
but
yeah
as
well.
If
I
I
had
different
vision
for
the
ux,
so
it's
good
that
it
looks
like
that
and
not
like,
like
my
vision.
So,
okay,
that's
great
thanks.
A
Yeah
absolutely-
and
I
know
right
now-
we're
actually
differentiating
it
we're
calling
it
a
live
container
scan,
but
I
think
eventually
we
would
just
want
to
call
it
a
container
scan.
You
know
make
it
the
same.
It's
container
scanning
and
the
only
difference
is.
Are
you
running
it
in
production
or
are
you
running
it?
C
A
Yeah
exactly
I
mean
if
users
tried
to
schedule
a
scan
against
a
cluster
and
they
tried
to
schedule
a
secret
detection
scan,
obviously
that's
not
going
to
work
and
so
in
the
future.
It'd
be
nice
to
just
add
in,
like
some
ui
clarification
in
here
like
if
I
come
in-
and
I
say
you
know,
I
want
to
schedule
the
cluster,
this
name
space
to
run
daily
at
midnight
and
secret
detection.
It
should
say
something
here.
You
know
by
the
way.
A
This
is
not
going
to
run
for
that
schedule,
because
it's
not
supported
in
production
so
ideally
would
have
some
sort
of
linting
or
some
sort
of
validation
that
comes
into
place,
and
you
could
still
create
this
rule.
It
just
wouldn't
do
anything,
and
you
know
that
should
be
obvious
right
now.
This
policy
preview
says
it
does,
but
we
would
actually
need
to
change
that
to
do
some
validation
and
say
you
know,
oh
by
the
way,
you
know
only
container
scanning
works
for
production
rules,
so
you
can
create
other
rules.
They
just
won't.
Do
anything.
D
A
We
could
it
gets
tricky
because
we're
letting
users
we're
giving
users
a
lot
of
flexibility.
You
know
we're
giving
them
the
freedom
to
chain
lots
of
rules
together
with
or
clauses.
A
So
if,
in
some
cases,
yes,
we
could
intelligently
limit
it,
but
also
if
they
said
you
know,
I
want
to
run
this
on
the
schedule
or
I
also
want
to
run
it.
You
know
whenever
the
master
brand
a
pipeline
is
run
against
the
master
branch.
D
A
Exactly
and
some
things
like
container
scanning
because
we
support
it
for
both
it's
going
to
work
for
both
in
the
back
end
it'll,
actually
be
scheduling,
both
the
regular
container
scan
and
the
live
cluster.
You
know
cluster
image
scanner,
but
from
the
customer's
perspective,
it's
one
thing:
it
just
works
for
both
so
yeah.
Exactly
we'll
need
two
conditions,
though,.
B
Yeah
I
want
to
try
out
that
feature.
Did.
Can
you
go
back
to
your
prototype,
actually
yeah
sure,
and
can
you
add,
a
rule
for
a
branch.
B
A
We
can
add
that
one
in
here
as
well,
so
the
main
difference
here
I'll
even
make
this
the
same.
We'll
put
somebody
seven
right
so,
instead
of
and
I
don't
know
what
the
exact
yaml
syntax
is
here,
I
think
I've
got
it
somewhat
close,
but
I'm
not
great
at
yaml
anyway.
It
should
give
you
a
general
idea
right
somewhere
in
here,
you're
specifying
which
clusters
and
then
you're
specifying
the
name
spaces
inside
of
those
clusters.
A
B
Right
and
so
then,
right
now,
based
on
what
you've
configured
for
like
you've
added
a
schedule,
the
schedule
is
going
to
run.
But
then
these
the
other
pipeline
and
schedule
for
the
branches
are
just
like
nothing
for
container
scanning
action.
A
Right
so
container
scanning
is
actually
the
only
one
that
works
for
everything,
so
I
see
container
scanning
would
actually
run
per
all
of
these
rules,
but
suppose
it
was
a
secret
detection.
Scan
secret
detection
could
only
work
for
this
rule
and
this
rule-
and
you
know,
rules
two
and
three
here,
because
we
can't
run
secret
detection
in
production
against
a
cluster.
A
Yet
so
secret
detection
would
work
for
rules.
Two
and
three
container
scanning
would
work
for
everything.
A
So
in
these
cases
you
know
suppose
someone
came
in
here
and
tried
to
run
both
it's
not
in
the
prototype,
but
at
some
point
we'll
just
have
to
have
an
intelligent
message
here
that
says
you
know:
secret
detection
is
going
to
work
and
I
don't
know
how
we're
going
to
word.
It
we'll
have
to
figure
that
out,
but
it's
going
to
work
for
these
two
rules,
but
not
the
first
one.
A
I
think
we
can
handle
that
with
some
smart
ux
when
we
get
closer
to
building
out
the
front
end.
For
this
feature,.
A
Actually,
I
think
we
already
have
some
mocks
with
some
kind
of
error
messaging
or
limiting
things
in
here
somewhere.
I
can
try
to
dig
it
up
and
find
it.
I
think
it's
just
like
some
small
red
text
that
falls
inside
of
this
rule
sort
of
the
idea
to
help
clarify
what
it
does
and
what
it
does
not
do.
B
Yeah
and
then
the
we
can
dehumanize
like
explanation
of.
What's
going
on,
we'll
have
oh
yeah,
look
at
that
yeah
and.
B
A
Right
yeah,
for
sure
I
mean
right
now.
This
thing
is
wrong
because
it
says
that
it
runs
the
secret
detection
against
the
production
cluster
which
it
does
not
but
yeah
we
can
we'll
play
with
that.
More.
I
mean
we're
not
up
to
this
point
yet
so,
once
we
get
closer
to
actually
developing
this,
we'll
sort
out
some
of
these
rough
spots,
but
I
think
we
can
do
that
just
with
some
better
messaging
in
line
and
obviously
making
the
policy
preview
accurate.