►
From YouTube: Container Security group discussion 2022-01-11
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
Good
day
evening
morning,
everyone
this
is
the
weekly
group
discussion
for
container
security.
Today
is
the
11th
of
january
or
12th,
depending
where
you
are,
and
we
have
a
short
agenda
today.
A
If
my
machine
behaves,
I'm
pretty
sure
my
my
computer
problems
are
the
thermal
throttling
for
mac
for
the
mac
os,
because
today's
nice
and
cool
and
I've
haven't
had
any
problems
yet
anyway.
The
the
discussion
here
is
about
what
do
we
do?
Well,
I'm
gonna
state
the
problem,
as
I
see
it,
and
then
brian
please
chime
in
whether
or
not
to
keep
the
integration
with
the
start
starboard
operation.
So
a
summary
of
the
situation
is
that
the
start
board
operation
operator
decides
when
to
run
the
scans
and
typically
runs
based
on
events.
A
Pod
events,
so
when
a
part
is
modified
or
created,
it
triggers
a
scan.
Those
reports
are
saved
as
vulnerability
report
objects
in
kubernetes
and
then
what
gitlab
does
is,
go
and
ingest.
Those
reports
pools
them
either
via
the
container
image
scanning
analyzer
or
via
the
agent,
and
then
we
publish
them
in
the
report.
A
The
problem
with
this
is
that
when
somebody
creates
a
policy-
and
we
tell
them
that
it's
running
at
a
certain
cadence-
that's
not
exactly
true
all
you're
doing
is
fetching
the
reports
on
that
cadence
you're,
not
executing
them
the
next
situation.
There
is
that
we
can
trigger
the
the
report
to
run,
but
then
these
reports
don't
get
saved
in
the
same
manner
as
the
reports
that
the
starboard
operator
generates.
They
get
saved
somewhere
else,
and
that
means
we
need
to
go
and
create
an
integration
for
that.
B
We
we
don't
really
need
to
create
a
new
integration
for
the
starboard
vulnerability
report,
because
the.
B
A
A
So
I
wrote
down
the
the
three
options
here
and
from
from
a
product
point
of
view.
Sam
has
commented
the
issue
saying
that
ideally
we'll
keep
the
event-based
nature
of
this,
so
it
runs
when
it
gets
updated
and
created.
But
an
alternative
solution
is
follow
the
cadence,
and
at
least
you
know
you
it's
not
immediately
on
the
event,
but
it's
controlled.
A
I'm
not
really
sure
if
that's
feasible,
but
it
would
be
kind
of
cool
if
to
contribute
to
to
to
that
the
other
one
would
be
just
I'm
calling
them
integrations
brian,
but
keep
those
two
connection
points
and
the
other
one
is
like
hey.
We
not
going
to
use
the
starboard
operator,
let's
just
use
the
one,
the
ones
that
we
trigger
and
I'm
gonna
open
the
forum
for
pros
and
cons.
C
Yeah,
I
would
just
note
that
eventually-
and
I
don't
know
how
long
it's
gonna
be
before
this
happens-
but
eventually
we're
probably
going
to
want
to
go
back
to
using
the
operator
integration
at
some
future
point
in
time
when
we
have
the
time
and
the
bandwidth
to
go
figure
out
how
to
make
these
things
run
when
the
vulnerability
database
is
updated
as
a
trigger,
so
that
would
you
know
we
probably
want
to
just
consider
that
long-term
vision
again,
we
don't
even
have
an
epic
for
that
open.
It's
not
on
our
roadmap.
C
A
I
I
think
in
that
situation
it's
it's
less
the
starboard
operator
and
more
notification
mechanism
on
our
side.
So
when
the
advisory
database
gets
updated,
we
don't
know
about
it.
Unless
you,
you
know
that
there
will
need
to
be
a
maybe
a
pub
said
mechanism
to
to
notify
people,
but
the
starboard
operator
wouldn't
know
about
that
event.
Anyway,
even
if
we
did
have
it
so
we
I
think
we
would
still
be
relying
on
the
on
the
triggered
scan,
even
in
that
situation,
sam.
A
What
I
think
is
kind
of
cool
about
the
operator
is
that
it
gives
user
the
user
more
flexibility
in
defining
you
know.
Maybe
you
want
to
configure
that
somewhere
else.
Maybe
you
want
to
keep
the
configuration
on
the
side
and
you
have
a
policy
in
your
company
to
configure
the
operator
and
that's
okay,
we'll
just
take
the
reports
from
it
and
the
secondary
thing
that
I
think
it's
nice
about
the
starboard
operator
configuration.
Is
that
it's
event
based
you?
You
know
if
you
happen
to
run
scans,
every
24
hours
or
every
two
days.
A
Events
are
always
going
to
win
because
as
soon
as
something
changes
boom,
you've
got
a
new
a
new
finding
coming
in,
and
when.
When
we
get
to
the
point
where
we
have
notifications
for
this,
then
that
becomes
really
powerful.
You
could
be
basically
notifying
users
as
soon
as
something
pops
up,
rather
than
waiting
for
a
chrome
job
to
run.
B
Yeah,
what
makes
this
difficult
is
when,
when
we
delegate
tasks
to
the
starboard
operator,
we
can't
really
be
100
sure
that
scans
are
working
correctly,
so
from
security
policies
from
security
policy
perspective.
B
A
Good
point
so
then,
from
a
policy
point
of
view:
if
if
we
trigger
something,
then
we'll
know
the
last
time
when
we
triggered
and
it
was
successful
and
then
if
the
star
board
operator
runs
it,
you
just
have
a
report.
Is
there
a
date
that
we
could
check
on
the
on
the
vulnerability
report.
B
A
Okay,
where
do
we
I'm
thinking
the
way,
the
way
to
decide
whether
or
not
to
do
this
contribution
is
to
get
in
touch
with
them?
A
B
Yeah,
I
also
want
to
look
into
the
starboard
operator
and
check
to
see
how
it
behaves
when
the
database
is
updated.
B
B
So
I
I
have
no
idea
how
it
behaves
in
that
regard
right
now,
so
I'm
thinking
I'll
look
into
that
and
see
you
know.
Maybe
it's
already
doing
that
for
us.
A
That's
a
that's
a
real
good
point,
brian,
because
in
my
mind
here
I
was
thinking
about
the
I
was
thinking
about
our
own
advisory
in
the
gitlab,
the
gymnasium
one
and-
and
I
was
sort
of
conflating
this
with
the
registry
scan.
So
basically
with
the
regis
registry
scan.
Is
you
update
the
registry
you're
gonna
get
scanned?
A
You
update
the
advisory
db,
you're
gonna
get
scanned,
which
just
means
comparing
the
the
bomb
again,
but
on
the
starboard
operator
side
we
need
to
do
some
work
to
tell
the
treev
installation
that
starboard
is
using
to
use
gitlab's
advisory
db
as
well.
This
work
is
in
progress
for
container
scanning
the
regular
container
scanning,
but
it's
not
in
scope
for
container
image
scanning
sorry,
cluster
image
scanning.
C
A
C
C
One
other
thing
I
had
to
note
earlier
is
just
if
you
are
still
having
trouble
getting
hearing
back
from
aqua.
You
might
talk
with
mike
lebeau
since
he's
our
partner
manager.
A
Cool,
how
do
I
get
in
touch
with
him.
A
C
Also,
they
have
a,
they
have
a.
C
Let
me
double
check
and
see
if
they're
in,
like
the
big
kubernetes
slack
working
group
or
something
like
that
too,
I
know
falco
works
out
of
there
and
I
know
psyllium
has
a
public
slack
group,
so
that
might
be
an
option
to
to
yeah.
You
know
make
your
request
in
a
forum
where
they
are
more
likely
to
give
a
response.
A
B
I
think
I
think
we're
pretty
good
right
now,
so
I'm
gonna,
I'm
gonna,
see
how
I'm
gonna
look
into
how
to
start
what
operator
works
and
see.
If
that
changes
my
opinion
at
all,
but
right
now
I'm
leaning
more
towards
the
scheduled
scans,
because
I
think
that
would
work
better
with
security
policies
and
I'm
also
waiting
a
little
bit
to
see
if
we
hear
back
from
aqua
security.
B
A
Okay,
but
in
terms
of
the
issue,
you
you've
not
blocked.
A
A
And
this
is
not
in
the
agenda,
but
I
want
to
congratulate
sashi
he's
got
a
new
baby
and
he's
gonna
be
off
the
rest
of
this
week.
A
A
A
A
I'm
gonna
yeah,
probably
not
I'm
gonna,
stop
the
recording
anything
else.