►
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
the
container
security
group.
First,
one
is
a
demo
item
from
alexander
lindsey.
Do
you
want
to
show
us
this,
or
I
can
try
to
share
our
agenda
as
well
and
just
share
what
he
has
here?
A
So
now,
if
you're
drilling
in
to
view
the
details
for
an
alert,
you
can
adjust
the
status
right
here
from
the
details
page
so
yeah.
Thanks
for
that
alexander,
that's,
a
great
great
improvement.
I'm
glad
to
see
glad
to
see
that
that
got
through
tiago
put
the
next
item
on,
but
I'm
happy
to
talk
through
it.
A
A
So
I
guess
the
question
for
this
one
would
be.
Are
there
any
questions
around
the
requirements
here
or
is
everything
clear,
and
are
we
ready
to
move
this
on
to
refinement?
The
short
summary
is:
we
should
be
taking
it
out
of
the
product
entirely,
including
all
documentation.
A
We
should
be
marking
all
of
our
metrics
as
removed,
and
we
don't
want
to
actually
uninstall
waff
like
if
we've
previously
installed
waff
into
a
customer's
cluster.
We
don't
want
to
go
out
and
remove
it,
but
we're
not
going
to
be
maintaining
it
or
do
any
anything
with
it
anymore.
So
that
would
be
a
manual
step
if
they
want
to
remove
it.
They'll
do
that
themselves,
but
we're
no
longer
interacting
with
waff
or
installing
waff
into
the
cluster.
A
The
last
item
in
this
is
just
that
you
know
we
have
done
a
fair
amount
of
work
in
waff,
and
so
it
you
know
just
being
good
open
source
stewards.
It
makes
sense
to
just
post
that
in
a
public
project
somewhere,
I
think
we've
done
that
before
with
other
breaking
changes
on
the
secure
side.
So
our
plan
is
just
to
post
what
we've
done
publicly
in
a
public
project
that
we're
not
going
to
maintain,
but
that
way
it's
there
in
the
public
domain.
B
A
So
this
came
as
a
suggestion
from
lucas,
I
believe
and
in
the
requirements
I
linked
to.
I
think
I
linked
to
what
he
suggested
that
we
include
basically
just
our
default.
The
way
we
set
it
up
by
default
is
what
he
was
recommending
that
way.
It's
there
for
historical
purposes,
so
you
might
want
to.
We
might
want
to
sync
up
with
lucas.
I
think
he
had
some
ideas
of
what
what
would
be
useful
for
you
know
just
preserving
in
the
for
historical
context,
since
I
think
he
worked
on
this
originally
setting
it
up.
A
So
honestly
he's
probably
a
better
person
to
clarify
that
with,
but
he
did
link
to
that
code
snippet
there.
So
I'm
assuming
that,
I'm
assuming
it's
just
the
way
that
we're
setting
up
on
security
that
he
was
suggesting
that
we
preserve.
A
A
Okay,
yeah
great
questions,
amir,
any
other
questions
on
this
one.
Are
we
comfortable
moving
this
to
refinement.
B
Yeah,
I
think,
if
you
are
clear
that
we
are
just
going
to
remove
everything
and
we
are
not
going
to
consider
any
kind
of
backward
compatibility
with
users,
for
example,
if
if
an
user
install
had
installed
waff
using
jmav1.
A
A
A
So
we
just
want
to
take
it
all
out.
You
know
if,
if
we
do
go
down
this
route
again,
it
probably
will
not
be
with
mod
security.
We
would
be
looking
at
options
where
we
do
have
not
only
high
availability
but
also
ddos
protection,
and
you
know
it
probably
would
be
more
of
like
a
front
ended
system
rather
than
something
inside
of
the
cluster.
I
think
we
can
do
most
of
what
we
need
to
with
solium
inside
the
cluster.
B
Okay
and
yeah,
so
basically
we
are
going
to
remove
from
gmav1.
We
are
going
to
remove
from
gmav2.
We
are
going
to
remove
the
integration
with
elasticsearch.
We
are
going
to
remove
the
integration
with
fluency
yep
and
I
think
sh
that
should.
A
Right
now
it
shows
up
on
the
statistics
page
and
it
also
shows
up
on
gma
v1,
but
I
think
there's
a
broader
effort
to
deprecate
and
possibly
even
remove
gme
b1.
So
I
don't
know
if
the
mrs
are
going
to
collide
there
or
not,
but
we
want
to
at
least
make
sure
that
our
part
is
fully
removed,
not
just
deprecated.
A
Sounds
good
great,
since
we've
got
some
extra
time.
I
added
as
a
late
addition
to
the
agenda
item
just
to
discuss
starboard
a
little
bit
more.
I'm
sorry!
I
don't
have
a
link
super
handy
for
that
discussion.
I
can
try
to
pull
it
up
while
we
talk,
but
this
was
recommended
to
me
by
this
by
the
trivia
team,
first
asynchronous
lien
in
issue
and
then
again
when
I
talked
with
them
synchronously
as
a
really
good
way
to
get
trivia
to
run
against
running
containers
in
production.
A
So
I
just
wanted
to
open
that
up
for
synchronous
discussion.
I
know
we've
had
some
good
asynchronous
comments
on
that,
but
it
seems
like
this
could
be
a
really
good
way
to
you
know,
be
able
to
scan
running
production
images
without
a
whole
lot
of
the
other
downsides
of
some
of
the
other
things
we're
considering.
B
I
think
two
points
are
like.
I
have
at
least
one
point
that
I
think
it's
sometimes
it
gets
misunderstood
is
that
for
us
to
have
to
install
starboard
into
the
cluster,
we
need
credentials
right.
So
if
we're
going
to
automate
this
installation,
then
it
means
that
we
need
the
famous
cluster
regime
privilege
unless
we
just
provide
like
we
just
provide
like
a
one
line
command
that
the
user
runs
it.
So
then
we
don't
need
their
access.
They
have
already.
So
it's
the
it's
that's
the
philosophy
of
the
agent.
B
The
agent
is
the
single
line
that
the
user
runs.
It
it's
going
to
deploy
the
agent
in
the
cluster,
because
the
user
has
that
access,
but
then
gitlab
doesn't
need
to
have
that
access,
so
the
access
needs
to
be
there
for
this
kind
of
operations.
There's
no
way
that
you
can
do
something
like
that
without
without
privileges
high
privileges.
B
B
The
other
thing
is
that
I'm
not
able
to
as
much
their
documentation
seems
a
little
bit
blurred
on
if
it's
scanning
containers
or
if
it's
getting
images
for
me
so
far.
What
I
understood
is
that
they
can
scan
the
container
metadata
and
then
they
get
the
image
that
are
there
and
then
they
scan
the
image.
That's
what
I
got,
but
so
they
have
a
very
fancy
way
of
querying
this
and
also
the
results
they
create
a
new
resource
in
kubernetes.
B
I
think
called
vulnerability
report
that
this
just
encapsulates
all
the
results,
so
I
would
have
to
maybe
the
person
that
helps
us
with
trivia,
it's
very
friendly
and
it's
very
responsive.
I
can
ping
him
just
to
confirm
if
it
install
container
if
it
scans
container,
live
containers,
even
if
it
generates
an
intermediary
image.
That's
fine!
But
if
it's
just
a
scanning
image,
I'm
not
sure
how
much
better
that
would
be
from
the
integration
that
we
have
right
now.
Yeah.
A
Yeah,
that
is
an
important
point,
because
you
know
one
of
the
big
goals
of
this
is
if
an
attacker
has
gained
access
to
that
container
and
they've
modified
the
packages.
We
want
to
capture
that
and
the
image
that
spawned
the
container
is
not
going
to
reflect
those
changes
that
happened
after
the
container
started,
and
so
you
know
that
is
an
important
distinction
to
make.
We
don't
just
want
to
look
at
it
and
go
back
to
the
image
that
it
came
from
and
scan
that
image.
A
B
A
Whether
we,
you
know,
snapshot
that
container
and
create
a
new
image
to
reflect
the
current
state
like
that,
doesn't
matter,
that's
you
know
as
long
as
we're
capturing
the
latest
changes
that
have
happened
in
that
container
after
it
started
originally
would
be
the
goal
there.
A
B
So
as
soon
as
you
have
the
cube,
config
setup
on
your
computer,
then
you
have
the
privilege
that
you
have
let's
say
adamine
or
clustered
me.
So
then
you
can
do
everything
and
then
people
are
comfortable
running
one
line
to
install
things
in
the
cluster
right.
People
are
more
comfortable
doing
that
than
actually
giving
this
full
access
to
a
third-party
software.
That's
going
to
have
constant
ability
to
make
those
changes.
That's
that
was
a
tricky.
So
then
the
agent
after
you
install
the
agent.
B
Then
it
has
like
five
or
or
or
six
privileges
just
to
list
pods,
it's
just
very
minimal.
That's
the
difference
and
then
star
board
is
the
same.
They
expect
maybe
the
person
that
has
privilege
to
just
run
starboard
in
it
and
then
it's
going
to
spin
lots
of
services
in
the
cluster
to
do
what's
supposed
to
do
and
then
and
then
after
that,
it's
it's
it's
there
already.
B
So
then,
now
from
the
from
now
on,
you
still
have
lots
of
privilege
comparing
with
agent,
because
it's
accessing
the
point,
the
pods
and
container
and
probably
it's
going
on
the
docker
level.
So
then
you
have
you
need
way
more
access
than
agent
requires
right
now,.
A
Yeah
that
makes
sense.
I
I
think
the
users
would
greatly
prefer
to
just
run
a
one-liner
versus,
like
the
other
proposed
solution
that
we've
been
discussing
of
scanning
images
and
get
labs
registry.
A
That's
quite
a
lot
of
setup
on
that,
their
part,
because
they
have
to
make
sure
that
all
of
the
images
that
are
running
in
production
are
also
pushed
into
gitlab's
registry.
So
that's
a
lot
of
setup.
You
know
if
they're
not
doing
that
already
today,
if
they
can
just
run
a
one
line
command
and
then
be
done.
That
seems
like
a
really
good
solution
to
me.
It's
it's
not
as
easy
as
if
we
install
it
on
our
own,
but
you
know
running
a
one-liner.
A
A
Okay,
so
yeah,
I
I
think
if
we
can
do
this
just
by
requiring
them
to
run
a
one-liner,
that
would
be
a
a
really
good
good
solution.
We
do
need
to
still
clarify
your
second
point.
A
There's
a
samir,
but
I
I'm
just
a
little
bit
hesitant
to
go
down
the
route
of
scanning
images
in
the
gitlab
container
registry,
because
for
many
customers
that's
going
to
be
a
lot
of
setup
that
they
don't
have
in
place
today,
and
so
I'm
I'm
meeting
with
a
number
of
customers,
I'm
trying
to
set
up
a
few
more
customer
meetings.
I've
met
with
one
already.
I
have
another
one
scheduled
for
this
week
and
hopefully
I'll
get
a
couple
more
next
week.
A
So
I'm
trying
to
double
check
and
see
if
you
know
pushing
everything
into
the
gitlab
registry
is
a
solution
that
will
work
for
them.
But
I
know
it's
going
to
be
a
lot
of
setup,
so
the
path
to
adopting
that
for
customers
is
going
to
be
quite
a
bit
longer
than
if
we
can
do
something
that
you
know
like
a
one-liner
would
be
a
great
solution.
A
That
would
be
very
easy
for
customers
to
use
because
they
just
run
it
once
and
they're
done,
whereas
the
lab
registry
solution,
they
have
to
make
sure
that
all
of
their
images
are
always
going
there,
and
you
know
that's
a
whole
like
pipeline
process.
They
have
to
set
up
and
maintain,
and
they
may
not
be.
Most.
Customers
are
not
using
the
gitlab
registry
today.
So
that
would
be
a
new
thing
they
have
to
adopt.
Has
the
benefit
of
pushing
them
to
adopt
gitlab
registry.
A
A
Great
well,
I
don't
have
any
other
topics
to
discuss
lindsay
or
zamir.
Do
you
have
more?
You
want
to
talk
about
on
this
topic
or
anything
else.