►
From YouTube: Protect:Container Security group discussion 2021-09-07
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
I
don't
because
I
haven't
seen
the
demo,
but
I
do
know
the
feature.
Did
anybody
actually
watch
it.
A
I
watched
part
of
it.
I
did
not
finish
the
video
yet,
though,.
C
Yeah
I
watched
it,
it
looked
pretty
good.
One
thing
in
particular
is
that
the
analyzer
right
now
can
only
take
one
filter.
You
know,
so
if
you
want
to
filter
by
a
specific
container
or
a
specific
namespace
right
now,
the
only
the
analyzer
only
takes
one
at
a
time,
but
the
policy
can
have
multiple,
so
we
will
need
to
figure
out
how
to
handle
that
on
an
analyzer.
I'm
not
sure
if
we
have
an
issue
for
that,
we
should
make
sure
that
we
have
one.
B
Can
I
can
follow
that
up
thanks
brian
I'll
I'll?
Do
that
once
I
once
I
watch
the
video
okay
sounds
good.
Thank
you.
A
Yeah,
all
in
it
looks
like
I'm
really
excited
for
the
progress
here
container
scanning
and
production
is
something
I've
heard
customers
requesting
pretty
much
since
I've
joined.
So
it's
great
to
see
us
move
along
and
be
able
to
offer
that
to
them.
D
Yeah
I
before
I
go
into
those
I
did
watch
some
of
allen's
videos,
though
I
was
skipping
around
looking
for
his
use
of
the
new
policies
page
and
he
didn't
use
it,
and
I
was
very
disappointed,
but
that's
fine.
D
I
just
was
working
on
some
small
styling
issues,
the
to
wrap
up
the
scan
execution
policy
project.
The
add
rule
button
looks
normal
and
not
just
like
some
blue
text
randomly
on
the
page.
Now
the
panning
around
the
yaml
mode
changes
color
with
preferences,
which
is
excellent
and
then,
as
we've
seen
in
slack,
the
security
orchestration
feature
flag
is
on
an
olive
prod
and
there
are
a
couple
of
issues
that
need
to
be
fixed
and
I
will
start
working
on
those.
A
E
Oh
in
addition
to
my
yay
celebration,
the
item
that
was
added
for
planning
breakdown-
this
just
came
up
in
conversation
with
sam
and
I
and
our
one
on
one
earlier,
looking
forward
to
the
upcoming
work,
to
add
the
vulnerability
tab
for
cluster
image
scanning
and
alexander's
already
answered
here
async.
So
we
may
not
need
to
talk
about
it
too
much,
there's
no
additional
work.
That
needs
to
be
tracked
in
issues
that
has
not
been
discussed
yet.
D
The
ones
that
don't
have
links
next
to
them,
I
am
not
sure
where
those
issues
are,
but
I
would
love
to
see
them
but
yeah.
This
seems
like
everything.
A
So
I
just
wanted
to
make
sure
that
we
were
correctly
mapping
the
backend
front-end
dependencies
for
this
one.
Obviously,
I
think
we're
well
aware
of
the
back
independencies
before
we
can
add
in
the
cluster
and
image
filtering
on
that
page,
but
there
are
a
couple
others
as
well
like
the
empty
state.
A
So
if
you
don't
have
any,
what
does
that
empty
state
show?
I
think
the
designs
had
it
pointing
directing
the
user
to
go,
create
a
new
policy,
but
if
the
backend
doesn't
support
creating
a
new
policy
for
cluster
image
scanning
yet
then
obviously
we're
directing
them
to
the
wrong
place.
So
you
know
we
need
to
make
sure
that
we
do
that
before
we
have
that
empty
state
or
that
the
empty
state
points
them
somewhere
else
as
an
intermediate
step
and
then
number
three
is
you
know
right
now
we
can
connect.
A
So
there
are
two
ways
to
connect
a
cluster
to
gitlab.
You
can
do
it
with
the
certificate
connection
method
and
the
agent
connection
method.
Correct
me
if
I'm
wrong
here,
brian
or
thiago,
but
I
think
right
now
we
only
work
with
the
cluster
connection
method.
We
haven't
added
support
for
the
agent
yet,
and
so
there
may
be.
That
may
be
a
dependency
for
some
front-end
work
as
well.
C
For
you
can
actually
work
with
just
the
agent,
but
it
will
not
be
able
to
show
the
network
security
policies
in
the
list
view,
because
the
back
end
uses
the
certificate
integration
to
get
those,
I
believe,
but
the
scan
execution
policies
should
work
without
an
agent.
Those
don't
require
an
environment
at
all.
B
I
I
think
I
think
you're
right
sam.
I
think
you
do
need
the
certificate.
So,
if
even
if,
even
if
you
don't
of
the
the
situation
that
brown
is
is
describing,
is
a
bit
to
be
wonky,
isn't
it
so
we
shouldn't
call
it.
C
C
The
analyzer
the
analyzer
works
with
our
a
certificate
integration
it
it.
You
can
configure
either,
but
really
it
just
needs
a
crib
config
and
a
connection
to
the
cluster
either
through
the
clcd
tunnel,
or
you
know
directly.
B
That
you
can
pass
the
basically
you
pass
the
authentication
in
a
variable
right.
You
pass
the
certificate
and
then,
instead
of
using
the
integration
you're
just
overwriting,
but
if
you
don't
provide
that
it'll
try
to
use
the
what
you've
provided
the
integra
integration,
but
I
I
think
the
short
answer
is
the
agent
itself
isn't
used
for
that.
C
Yet
the
agent
just
provides
the
tunnel
for
cicd
to
be
able
to
connect.
B
And
for
for
those
who
who
don't
know
why
the
tunnel's
there
is
that,
if
the?
If,
if
you
imagine
the
kubernetes
api,
it's
not
exposed
to
the
internet,
if
gitlab
tries
to
talk
to
it,
it
won't
find
it.
But
what
happens?
Is
the
agent
is
running
in
that
environment
so
that
connects
out
to
to
gitlab
and
now
gitlab
has
a
has
a
path?
Has
a
channel
open
to
talk
there
and
parenthesis
right.
A
Okay,
so
yeah,
that
makes
sense,
and
I
know
in
the
future
we're
planning.
I
think
it's
like
iteration
three
we're
planning
to
fully
support
the
agent
where
we're
having
the
agent
send
those
vulnerabilities
directly
back
to
gitlab,
but
anyway,
that
may
impact
the
front
end
a
little
bit
as
well.
A
I
that's
probably
less
impactful
than
items
one
and
two,
but
it's
something
to
think
about
when
we
start
developing
the
security
cap
on
the
on
the
view
of
the
agent
cluster
itself
anyway,
that
may
or
may
not
be
relevant,
but
it's
just
something
to
keep
an
eye
on
that.
You
know
just
want
to
make
sure
we've
got
our
back-end
front-end
dependencies
that
we're
fully
aware
of
all
of
them,
so
that
you
know
we're
not
turning
something
on
on
the
front
end.
That's
not
supported
in
the
back
end,
yet.
D
Yeah
we,
the
front
end,
has
not
started
even
playing
breakdown
on
the
vulnerability
details,
the
security
tab,
because
we
know
that
there's
a
lot
of
back-end
dependencies
there
we're
solely
focused
on
the
vulnerability
report,
which
is
much
easier,
okay,
so
yeah.
That
would
just
be.
A
D
E
Alexander,
could
you
create
that
front
end
issue
and
then
whatever
back-end
work
that
needs
to
come
off
of
that
we
can
ask
someone
from
the
back-end
team.
Thank
you
and
another
call-out
is
that
we're
going
to
be
working
with
folks
from
the
front
end
team
for
threat
insights
on
this
at
least
daniel,
but
maybe
there'll,
be
more
capacity
available
to
help
with
that
in
the
14,
3
and
14
four
milestones.
A
All
right
and
then
for
our
last
topic
here,
I
just
wanted
to
talk
a
little
bit
more
about
the
authentication
token
that's
being
used
for
cluster
image
scanning.
I
know
I
talked
about
that
previously
and
brian.
A
It
looks
like
you
answered
some
of
my
questions
async,
but
it
would
be
nice
if
we
can
get
it
to
a
point
where
we're
not
relying
on
a
token
being
passed
through
the
ci
pipeline,
and
I
know
we
can't
get
away
from
that
for
clusters
that
are
connected
with
the
certificate
method,
but
for
clusters
connected
with
the
agent
method.
If
we
can
avoid
sharing
that
with
the
pipeline
at
all,
that
would
be
ideal,
but
I'm
not
sure
I
understand
where
we're
at
today.
A
What
I
don't
understand
is:
where
are
we
headed
and
what
security
precautions
are
we
going
to
have
in
place
by
the
time
we're
done
with
this
and
ready
to
move
it
out
of
the
alpha.
C
Yep,
so
I
can
answer
that
you
know
right
now.
Today
we
have
them
configure
a
coupe
config
file
in
our
ci
cd
variables,
which
contains
the
credentials
if
they
do
not.
If
the
user
does
not
protect
the
cicd
variable,
then
there
is
a
security
risk
associated
with
that
unauthorized
people
may
be
able
to
access
that
variable
and
get
the
credentials.
C
When
we
have
the
gitlab
agent
version,
we
will
no
longer
require
credentials,
because
the
ab
agent
has
a
service
account
in
kubernetes,
and
so
it
has
its
own
identity,
which
the
cluster
image
scanning
can
run
as,
and
so
the
agent
is
already
running
inside
the
cluster.
It
already
has
its
own
credentials.
C
A
Got
it
yeah?
That
seems
like
a
much
better
setup.
I
think
we'll
have
to
document
that
when
you
install
an
agent,
then
that
you're
going
to
want
to
have
it
be
some
sort
of
gitlab
admin
or
like
a
bot
user
or
someone
that
has
permission
to
all
of
the
projects.
So
you
don't
have
to
install
multiple
agents
into
a
cluster
potentially
to
get
the
right
permissions,
but
yeah.
That
sounds
like
a
much
better
solution.
B
The
the
the
security
implications
of
of
putting
secrets
in
cicd
variables
are
well
understood
and
well
documented
the
the
attack
vector
there
is,
if
the
two
flags,
one
you
you
hide
it.
So
if
it
prints
on
the
console
it
it
gets
redacted
and
the
second
one
is,
you
can
only
run
it
in
protect
protected
branches,
so
you
need
both
to
make
it
more
secure,
but
it's
not
impossible.
B
B
The
the
the
general
idea
is
that
if
you,
if
you're,
using
the
certificate
integration,
you're
pooling
the
vulnerabilities,
so
it's
git
lab
connecting
there
via
a
worker
and
pulling
the
vulnerabilities
out.
If
you
have
an
agent,
that's
already
running
in
in
the
cluster
and
that's
pushing
it
into
gitlab.
A
Okay,
yeah,
that
all
makes
great
sense.
So
thanks
for
clarifying
that,
I
think
that's
going
to
be
the
big
thing
that's
going
to.
Let
us
move
this
out
of
alpha
is
when
we
have
support
for
the
agent
so
that
there's
no
longer
that
risk
of
exposing
the
secret
in
the
ci
pipeline,
and
I
get
that
protecting
it
and
making
it
hidden
provides
an
added
layer
of
protection,
but
at
least
the
few
customers
that
I've
talked
to
about
this.