►
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
the
container
security
group
meeting
looks
like
big
one,
for
today
is
just
I
wanted
to
follow
up
on.
Is
there
anything
we
need
to
discuss
related
to
alerts?
I
know
we've
had
a
lot
of
asynchronous
communication
back
and
forth.
So
that's
the
number
one
topic
for
today.
I
just
want
to
make
sure.
Are
we
good
to
go
on
our
approach
there
or
are
there
still
questions
or
things
we
need
to
discuss.
B
C
C
A
D
Yeah,
exactly,
I
think
we
might.
We
might
need
to
take
a
little
bit
more
time,
figuring
out
more
details
before
like
trying
to
go
anyways
and
maybe
hitting
like
a
roadblock
or
something.
A
Okay,
yeah,
that's
okay,
I
mean
I
understand
this
is
going
to
take
more
than
one
iteration
and
you
know
we
want
to
do
it
right,
so
I
think
we're
headed
in
the
right
direction.
Let's
just
be,
you
know,
let's
try
to
solve
the
hard
problems.
First,
I
I
know
it's
tempting
to
sometimes
to
go
solve
the
easy
problems
that
are
known,
but
let's
focus
on
those
hard
problems,
especially
arthur,
while
you're
here
in
case
we
do
need
to
make
any
upstream
contributions
to
philia.
A
You
have
previous
previous
experience
with
that.
So
I
want
to
make
the
most
of
your
time
while
you're
here,
if
we
do
end
up
needing
to
do
something
upstream,.
A
D
Yeah,
I
had
a
question
on
that.
Actually,
it's
not!
I
don't
want
to
start
a
discussion.
It's
just
more
like
a
question.
I
was
thinking
that
was
the
main
design
of
having
the
policy
editor
for
ceiling
network
policies
and
then,
on
the
same
time,
we
provide
out-of-the-box
policies
that
are
more
generic.
D
A
We've
already
decided
to
support
psyllium
specifically,
so
this
is
in
line
with
the
rest
of
that
you
know.
The
challenge
with
supporting
the
generic
supporting
generic
network
policies
is
nice,
because
then
users
can
potentially
pick
their
own
network
policy
provider.
They
could
go
with
calico,
they
could
go
with
something
else,
but
whenever
you
try
to
genericize
things,
what
you
lose
is
the
ability
to
do
those
deep
integrations
and
get
really
specific.
A
So
you
know,
for
example,
like
our
network
policy
editor,
it
would
be
really
hard
to
do
something
like
that
and
support
everything
like
in
order
to
provide
a
really
good
user
experience.
At
some
point
we
have
to
say
this:
is
it
you
know
we're
going
to
go
with
psyllium
and
we're
not
going
to
support
the
others.
So
that's
kind
of
the
trade-off
is
usability
versus
supporting
everything,
and
I
would
rather
go
with
usability.
A
C
Yeah,
the
only
there
are
actually
a
couple
concerns,
but
in
in
this
specific
topic-
and
I
already
mentioned
that
we
are
technically
reducing
functionality.
By
doing
that,
I
was
trying
to
find
the
handbook
page
for
how
to
handle
that,
but
I
think
we
agreed
right
now
to
just
handle
it
in
the
docs
right.
I
think
it
should
be.
E
C
But
because
it's
still
a
new
feature,
but
technically
previously
we
were
supporting
any
generic
network
policy
supporting
provider,
but
after
this
change
it
will
be
only
serum
specific,
which
is
a
bit
unfortunate,
but
yeah
not
much.
We
can
do
as
an
expand
the
editor
to
support
other
policies,
but
it's
a
bit
tricky
to
do
yeah
and
the
second
topic
is
alright.
Yesterday
I
actually
had
a
good
progress
on
the
change,
but
playing
with
it.
How
could
I
think
it?
C
I
don't
really
like
the
direction,
and
I
honestly
I
would
recommend
to
wait
for
kyle
to
return
to
get
ux
approval
on
that.
So
the
idea
is
when
you
click
edit
on
a
predefined
policy,
it
will
be
deployed
and
then
you
will
transition
to
the
editing
screen.
C
I
think
it's
super
unconventional
for
github
to
do
that
and
I'm
a
bit
hesitant
to
commit
into
the
solution
and
since
I'm
not
the
ux
person-
and
we
don't
have
it
right
now
from
my
understanding
like
I
was
on
pto,
so
I
would
maybe
recommend
to
wait
a
bit
and
see
what
he
will
say,
because
he
is
just
more
knowledgeable
in
this
area
and
I
don't
know
where
to
look
for
the
advice.
If
it's
a
good
solution
or
not,
but
my
gut
feeling
it's
not
from
the
ux
perspective,
so
yeah
implementation
wise.
C
It's
really
close.
I
can
just
push
my
branch
but
ux
wise,
I'm
not
sure.
A
C
Because
semantically,
like
when
you
click
right
now
on
any
edit
button
in
github,
it
will
transition
you
to
the
editing
interface
right.
There
is
no
side
action
in
this
process.
You
are
not
expecting
that
something
will
happen
with
your
cluster,
but
we
are
changing
the
semantic
to
you.
Clicking
get
it.
There
is
no
confirmation
of
hint,
but
there
will
be
a
change
here.
C
I
realize
that
it's
not
a
destructive
action
in
a
way
that
policy
is
disabled,
but
it
will
change
the
state
of
your
cluster,
and
on
top
of
that,
it's
conditional,
it's
not
happens
all
the
time.
It
only
happens
with
the
predefined
policies,
so
I
think
changes
the
semantic
semantic
just
makes
like
use
it
and
like
process
more.
What
is
happening
behind
the
click
and
it's
not
clear
and
then
I'm
pretty
sure
some
someone
will
return
to
us
say:
hi,
hey.
C
Why
did
you
deploy
a
policy
when
I
did
not
want
to
deploy
policy
in
the
first
place?
Just
so
I
could
edit
it.
I
think
it's
overall
a
bit
intrusive
for
and
like.
I
would
personally
not
expect
this
to
happen
when
I
click
on
the
edit.
So
again,
is
this
just
my
gut
feeling.
E
C
D
F
D
E
C
Yeah,
I
actually
changed
the
policies
to
salem
to
and
and
it's
not
one
to
one
because
it's
a
bit
awkward
to
to
make
drop
policies
with
cillum
right
now.
So
yeah,
that's
another
question
my
topic
to
discuss,
but
it's
not
super
important
from
my
understanding,
but
yeah
id
is
not
that
clicking
the
resultant
conversion.
It's
more
that
once
we
have
this
version
deployed,
all
the
predefined
policies
will
have
psyllium
specification,
and
so
essentially,
if
it
were
going
13.5,
so
in
13.5,
the
predefined
policies
will
be
serium.
C
E
A
I
I
have
a
different
question.
I
mean
from
the
user's
perspective.
I
would
actually
expect
these
to
be
deployed
into
the
cluster
when
I
first
installed
psyllium
because
they
are
default.
Policies
default
out
of
the
box
policies
to
me
that
says
that
they
should
be
installed
out
of
the
box
like
at
the
time
that
psyllium
is
deployed
and,
of
course
they
would
be
deployed
in
a
disabled
state.
But
I
would
actually
expect
that
to
happen,
not
when
I
click
the
edit
button.
A
C
I
can
understand
that,
but
at
the
same
time
it
will
be
really
hard
for
us
to
handle
it
generically
like
we
provide
the
scripts,
but
we
don't
force
users
to
use
those
scripts
right.
For
example,
if
someone
from
digital
ocean
cloud
would
decide
to
use
our
products,
they
already
have
a
silhouette
start
and
we
don't
have
ability
to
push
anything
up
there
on
the
installation
state.
C
It
seems
it's
going
to
be
similar
as
google
cloud
eventually,
because
netapp
and
v2
is
psyllum,
hassle
and
bundled
in
it
right
and
then
in
other
cards,
users
before
committing
to
github
can
have
cilium
or
any
other
product
deployed
to
their
classes.
So
I
think
our
current
logic
is
a
bit
better
and
generically
and
at
the
same
time,
it's
more
hard
I'd.
Imagine
kubernetes
supposed
to
work,
because,
while
there
is
a
data
storage
in
forms
of
usually
utcd
on
kubernetes,
it's
not
meant
to
store
disabled
resources
right.
C
Disabling
kubernetes
is
removing
action,
so
in
our
case,
since
we're
kinda
using
disable
state
by
using
a
trick.
So
I
felt
like,
in
our
case,
the
logic
we
have
right
now
is
that
enabling
policy
will
trigger
the
first.
Deploy
was
a
bit
better
solution,
so
why?
Our
original
event
was
that,
but
we
could
change
it,
but
I
don't
think
it
will
be
possible
to
generically
support
all
the
situations.
So
I
think
maybe
current
id
still
will
be
a
bit
better.
B
A
F
All
right
so
tim
on
the
one
that
you
commented
that
we
probably
shouldn't
talk
about
it
on
a
public
recording.
Let's
I
agree.
Let's
not,
let's
jump
to
the
second
one
and
you
already
answered
in
the.
A
F
Yeah,
so
I
know
we
found
one
good
solution
for
container
scanning
after
the
container
is
already
running
trivia.
I
think
it
is
yep
trivia.
There
are
many
or
container
native
scanning
solutions,
but
those
have
pros
and
cons
and
some
vidcons,
and
also
probably
some
big
pros,
but
we've
shied
away
from
those-
and
I
think
the
non-container
native
ones,
which
I
think
has
been
the
right
call.
So
we
know
one
I
like
having
more
than
one
to
choose
from
or
it
feels
like.
F
You
know
if,
if
one
exit,
if
more
than
one
exists,
so
I
guess
I
know
we're
not
we're
nowhere
near
a
decision
point,
but
we
definitely.
I
think
we
definitely
want
to
look
at
more
than
one
before
making
a
decision
open,
source
solutions.
We
can
use
for
container
scanning
post
the
container
being
instantiated.
F
Yeah,
we
absolutely
should
do
that
and
let's
some
lessons
learned
from
this:
let's
look
at
what
the
requirements
are,
that
we
want
to
meet
and
then
look
at
how
trivia
meets
them.
Not
sir
trivia.
Does
this,
let's
find
a
trivia
alternative
so
which
is
easy
to
do.
We
should
take
advantage.
We
should
definitely
list
everything
in
trivia
we
like
but
not
say.
Can
we
find
a
trivia
alternative,
so
I
know
we're
not
there
yet,
but
I'm
really
happy
with.
C
That
I'm
just
wanted
to
mention
again.
I
checked
it
after
the
previous
week
discussion.
There
is
a
comparison
in
trivia
docs
at
the
bottom,
with
other
solutions
in
including
proprietary
like
what
the
docker
does
so
maybe
just
check
that
things
first,
because
if
it
satisfies
the
topic
of
research,
there
is
no
problem
point
of
doing
additional
research
beyond
that.
F
Yeah,
I
remember
seeing
that
arthur.
That's
a
good
point
to
bring
that
up
again.
I
did
read
through
that.
I
know
my
first
question:
is
it
didn't
come
up?
It
didn't
have
any
good
alternatives
to
trivia
that
would
work
for
us,
but
it's
still
a
good
article
to
read
and
I
may
have
gotten
it
wrong
too.
F
I
just
I
just
skimmed
through
it
when
you
posted
that
it's
good
good,
it's
a
good
good
first
step
to
look
at
alternatives
and
trivia
might
be
awesome
and
it
might
be
the
direction
we
want
to
go
or
it
might
not
be
it
just
it's
one.
It's
one
potentially
good
option.
F
A
Yeah,
I
just
want
to
say
I
don't
want
to
override
the
priorities
that
we've
got
to
do
this
bike
like
I,
I
wanted
to
start
the
discussion
now
because
it's
the
next
thing
coming,
you
know
down
the
road,
but
for
now
let's
stay
focused
on
alerts.
I
don't
want
to
you
know
prematurely
chase
the
next
thing
when
we
haven't
finished
the
thing
that
we're
already
on
right.
So,
let's
let's
stay
focused.
A
I
I
do
want
to
have
some
of
these
discussions,
though
just
so
that
we
can
talk
through
some
of
the
challenges
of
the
group
and
start
looking
at
solutions.
You
know
not
again
not
to
distract
from
the
main
priority,
but
to
help
me
give
you
good
requirements
going
into
it,
just
to
make
sure
that
we're
thinking
through
the
problem
in
a
complete
way.
So
that's
that's
really
the
purpose
of
bringing
up
the
discussion
at
this
point,
even
though
we're
not
quite
ready
to
start
work
on
it.
A
So
I
do
have
a
few
questions
that
I
posted
to
the
design
issue
the
requirements,
design
issues
since
this
all
really
is
still
back
in
that
requirements
and
design
phase.
Maybe
we
can
pick
one
of
them
and
talk
about
it
now.
I
you
know
one
of
the
things
that
we're
going
to
need
to
handle
in
this
scanning
of
production
environments
is
the
ability
to
schedule
regular
scans.
You
know
where
people
might
say.
I
want
to
scan
this
container.
A
You
know
once
a
week
at
2
am
on
sunday,
for
example,
and
so
do
we
have
any
thoughts
on
where
that
configuration
might
live?
Is
that
something
that
would
end
up
being
stored
in
git
lab
like
in
our
database?
Would
that
go
in
the
repository
in
a
yaml
file
and
would
auto
devops
somehow
push
that
into
kubernetes
cluster?
A
Obviously
you
know
there's
you
haven't
had
any
time
to
research
this,
but
I
think
it
might
be
interesting
to
talk
about
where
we
store
those
configuration
parameters.
B
Don't
we
have
now
a
security
center
that
that's
where
a
lot
of
these
other
settings
will
go
something
that
matt
worked
on
from
a
vulnerability
management
perspective,
but
I
had
the
impression
that
we
wanted
to
configure
some
of
the
because
dust
has
the
same
problem
right
you
you
want
to
have
and
the
other
analyzer
you
want
to
have
chad
do
things
and
and
the
way
we
do
we
do
these
that
we
run
these
scanners
outside
the
ci
pipeline
is
a
little
bit
of
a
hack.
B
It
relies
on
the
schedule
pipeline,
but
it's
not
a
first-class
citizen.
It's
you're
just
using
that
as
a
trigger
for
your
for
your
scan.
A
C
I
think
probably
the
only
thing
comes
to
mind
is
actually
the
agent
kubernetes
agent
that
registration
is
working.
I
know
it's
a
bit
controversial,
but
they
have
a
place
to
start
those
configs,
and
if
you
want
a
time-based
scheduling,
you
can
just
deploy
cron
jobs,
kubernetes
crown
jobs
for
that
that
will
do
the
scanning.
So
I
think
I
see
a
lot
of
things
fit
really
well
in
what
you
say
so
to
describe
it
a
bit
more.
C
C
We
could
potentially
set
up
a
chrome
job
up
there
that
will
trigger
and
because
agent
is
already
sits
in
production
cluster,
it
can
trigger
job
from
inside.
So
it's
it's
a
really
clean
solution
for
running
production
what's
triggered
by
github,
so
that
might
be
worth
investigating
in
connection
to
the.
D
To
me
it's
just
I,
I
haven't
considered
implementation
yet,
but
I
was
thinking
if
it
depends
on
how
we
are
going
to
prioritize
the
integration
with
v1
or
v2.
We
might
have
to
consider
how
this
configuration
is
going
to
reach.
I
imagine
that
maybe
the
application
has
a
configuration
internally
to
do
that
to
do
this
scans.
Otherwise
I
think
the
background
job
that
arthur
is
mentioning
it's
it's
an
interesting
way
of
us
handling
this
from
our
side
and.
B
And
it
aligns
with
v3
right,
which
is
not
it's
called
what
kit
ops,
but
it
seems
to
be
what
what
they
planning
at
the
moment.
So
we
back
to
that
thing
where
we
don't
quite
know
where
it's
going.
A
Great
well,
thanks
for
sharing
your
thoughts
on
that.
I
just
wanted
to
add
the
comment
there
of
note
that
the
ui
for
scheduling
these
you
mentioned
daft
tiago.
A
I
think
the
ui
is
going
to
overlap
between
us
and
das
and
really
all
of
the
other
scanners
as
well,
since
they
all
have
the
need
to
schedule
their
scans.
So
the
policy
editor
that
we
released
right
now
in
the
navigation
hierarchy,
it's
under
security
and
compliance
and
then
under
threat
management
and
it's
a
tab
in
there.
A
The
long-term
plan
always
has
been
to
uplevel
that
one.
So
it's
security
and
compliance
policies
and
have
that
policy
editor
be
cross-functional
for
all
of
secure
and
defend.
So
I've
actually
been
talking
with
derek
quite
a
bit
on
this
topic
over
the
last
couple
weeks.
A
But
yeah
kind
of
the
big
question
is:
where
does
that
live
on
the
back
end?
So
I
I
think,
arthur
and
jimmy
have
given
us
some
good
ideas,
good
starting
place
on
how
we
might
think
about
that.
B
What
you
said
sam
reminded
me
of
something
that
that
authors
of
me
might
not
have
heard
about
yet,
but
there's
a
the
the
there's
requests
from
customers
to
manage
policies
at
an
organization
level.
So
a
lot
of
the
our
security
products
work
at
a
at
a
project
level
and
when
you've
got
hundreds
or
thousands
of
projects,
it
becomes
very
hard
to
manage
that
consistently
across
the
board.
B
A
A
Yeah
we'll
need
it
at
all
three
levels,
eventually,
we'll
have
to
figure
out
where
we
start
likely
we'll
start
at
the
project
level.
Just
because
that's
going
to
be
the
easiest
to
get
started,
but
yeah
you're
right
tiago,
for
when
it
comes
to
the
the
secure
scans.
The
biggest
need
is
actually
up
at
the
instance
and
group
level.
B
One
quick
comment:
what
we've
been
calling
the
instance
level,
so
a
gitlab
instance
is
the
server
it's
the
whole
thing.
When
we
talk
at
an
instance
level
from
a
product
point
of
view,
we
probably
mean
the
the
root,
the
the
root
group,
so
like
the
top
level
group
for
for
an
organization.
So
when
you
go
to
that
top
level
menu
and
you
hit
more
that's
sort
of
the
instance
level,
but
it
doesn't
affect
every
group
in
the
instance,
it
just
affects
your
base
group.
Doesn't
it.