►
From YouTube: Kubernetes SIG Security Tooling 20210615
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
All
right,
I
think
we
have
about
eight
people,
maybe
while,
while
others
are
trickling
in,
we
can
start
with
the
brief
introduction
from
everyone.
What
what
you
do,
what
you
are
interested
in,
what
brings
you
to
the
meeting
and
anything
else
that
we
should
know
about
you,
maybe
I'll
start
very
quickly.
A
This
is
really
our
second
meeting
ever
for
this
subgroup.
This
subgroup
is
part
of
our
larger
security
under
kubernetes
project,
and
the
main
goal
of
the
group
is
trying
to
find
what
are
possible
gaps
and
improvements.
We
can
make
in
tooling
related
to
kubernetes
security
and
then
contribute
back
in
the
community
by
collaborating
with
different
sigs
that
are
part
of
kubernetes,
and
sometimes
we
also
will
end
up
collaborating
with
cncf
tags,
especially
the
security
tag.
A
B
Hi,
I
can
go
hi.
My
name
is
adolfo.
I
am
one
of
the
technical
leads
with
sig
release
and
I
was
invited
by
pushkar
to
join,
to
discuss
some
of
the
an
outstanding
issue
which
we're
going
on
in
a
little
bit,
and
so
my
pronouns
are
him,
and
I
work
in
a
small
company
in
mexico
city
which
will
which
is
called
youth
servers,
and
I've
been
in
these
meetings
before
mostly
as
a
listener.
C
Hi
everyone
I'm
vinayak.
This
is
my
first
time
coming
to
this
meeting.
Although
I've
been
frequenting
the
six
security
meetings,
I
work
at
google,
I
work
in
gke
focusing
on
security
and
I'm
excited
to
see
what
the
charter
of
this
meeting
is
nice
to
meet.
Everyone
welcome.
C
E
Go
for
sorry,
yeah,
I'm
sam,
I'm
an
engineer
at
bloomberg,
working
on
a
managed
platform
based
on
kubernetes.
I
actually
switched
teams
to
join
this
effort.
Recently,
I've
been
to
a
couple
kubernetes
meetings
and
virtual
coupons
and
basically
just
want
to
get
more
involved,
and
this
is
an
area
that
I'm
really
interested
in
so
happy
to
meet.
All
of
you
and
looking
forward
to
you
know
actually
contributing
so
excited.
D
Yeah-
and
I
can
try
now
so-
I'm
based
in
israel
working
for
the
past
year
and
a
half
or
so
for
reddit
as
part
of
a
larger
development
group
that
tries
to
bring
openshift
for
telco,
5g
customers
and
I'm
leading
the
security
effort
inside
of
that,
and
we
are
now
deeply
looking
into
wider
security
issues
in
kubernetes
and
want
to
help
wherever
we
can
so
glad
to
be
here.
It's
my
first
attendance
in
this
meeting
and
mostly
wanted
to
hear
what
what
is
about.
F
I
can
go
next,
hey
everybody.
My
name
is
rachel
sweeney.
I
work
at
the
pew
research
center.
I've
stood
up
for
kubernetes
cluster
there
and
I've
managed
it
for
the
past
couple
years,
starting
as
a
I
think,
customer
reliability
engineer
for
fairwinds
in
a
couple
weeks
where
we
work
with
a
lot
of
clients
working
with
their
clusters
and
started
to
take
a
deep
dive
into
security.
A
G
I'm
eric
smalling,
I'm
a
developer
advocate
at
sneak
on
the
cloud
native
and
containers
side.
I
work
a
lot
with
the
docker
folks
and
aws
some
of
the
other
partners
we
have.
Prior
to
that.
I
was
a
consultant
doing
kubernetes
and
docker
work
at
vmware
on
the
tonzo
team
and
before
that
at
docker
as
a
practice,
manager
and
nps
consultant
and
going
back
just
been
doing
docker
since
the
early
days.
H
I
All
right,
my
name
is
ray
lahano,
I'm
the
one
of
the
chairs
for
the
stick-
security,
external
audits
subgroup-
so
I
came
over
from
the
sixth
security
side,
also
dab
on
some
of
their
sig
release
as
well.
I
work
first,
I'm
I'm
an
engineer
for
susa.
I
weigh
a
branch
of
labs
and
I
pretty
much
work
in
all
things:
kubernetes
for
many
different
customers,
so.
J
Hello,
everyone,
I'm
yashika,
I
work
for
juniper
networks
and
I
the
product
that
I'm
working
on
is
contrail
and
my
team
is
is-
is
mostly
working
on
the
sdn
data,
part
of
it
and
it's
my
first
time
that
I've
I
am
attending
this
meeting
and,
like
I
recently
came
across
kubernetes
and
I'm
exploring
it
so
yeah
happy.
K
A
No
looks
like
we
got
everything,
everyone,
okay,
cool,
just
just
one
thing
I
wanted
to
mention-
I
I
don't
claim
to
know
everything
about
kubernetes
security
or
what
this
group
should
be
doing
so
as
much
as
me
or
anyone
else
sharing
what
we
should
be
working
on
as
a
group.
I
also
want
to
encourage
any
thoughts
from
all
of
your
experiences
that
you
have
that
you
found
as
a
gap
in
kubernetes
security,
where
we
can,
as
a
community,
come
together
and
help
out
and
contribute
on
anything
that
you've
been.
A
Maybe
working
on
that,
you
would
like
to
use
us
as
a
sounding
board
and
get
feedback
which
is
relevant
to
kubernetes
and
security,
any
issues
you
have
seen
in
github
that
are
relevant.
So
as
much
as
it's
my
meeting,
it's
all
of
our
meeting
more
than
that,
so
anything
that
you
want
to
share
even
now
and
if
it's
not
concrete
or
you
don't
have
anything
real
to
show,
that's
also
fine,
even
an
idea,
even
a
thought
is
equally
important.
A
Typically,
we
would
add
the
discussion
points
in
our
mini
beating
men's
talk
under
a
discussion
before
the
meeting,
but
because
we're
sort
of
new,
if
you
have
something
of
a
extempore
topic
that
we
haven't
put
in
the
agenda,
that's
also
totally
fine
and
then,
if
there
is
nothing
else,
we'll
have
other
things
to
discuss
but
want
to
give
all
of
you
the
first
opportunity
to
share
what
you're
thinking
or,
what's
on
your
mind,.
G
One
thing
that
occurs
to
me
that
we
have
several
people
have
joined.
That
say
you
said
you're
new
to
kubernetes
and
this
is
not
self-promotion
by
any
means,
but
there's
a
book
that
several
of
the
tons
of
guys
put
out
recently
we're
doing
a
book
club,
carlos
santana
and
a
few
and
william
and
a
few
of
us
are
going
through
this
book
right
now,
every
I
think
we're
doing
fridays
now
I
was
on
vacation
last
week,
so
everything's
focused
for
me
we're
on
chapter.
G
We
just
finished
cni
we're
moving
on
we're
going
to
start
getting
into
some
security
aspects
too.
So,
if
you're
interested
private
message
me
on
slack,
I'm
smalls
pretty
much
everywhere,
so
I
can
show
you
where
to
get
into
it.
A
G
A
Wow,
that's
great
to
hear
I'll
just
start
sharing
screen.
So
we
have
a
single
point
of
view
to
look
at
in
the
basically
we'll
share
the
meeting
minutes
link.
So
in
case
you
don't
have
the
link
or
access.
Please.
Let
me
know
we'll
try
to
get
you
access
in
real
time
and
yeah.
If
let's
try
to
get
some
thoughts
from
all
of
you,
what
you've
been
thinking
about
working
on,
we
have
a
topic
that
we
can
discuss
but
want
to
get
some
initial
thoughts
from
everyone.
C
I
have
one
so
I've.
I
was
talking
to
dims
from
vmware
a
while
back,
and
he
mentioned
that,
like
sig
security,
kind
of
focuses
on
like
security,
vulnerabilities
and
research
there
right,
and
so
the
implementation
of
security
kind
of
holes
falls
largely
on
like
sig
node.
I
think
because
they,
because,
like
anything,
you
do
related
to
security
configurations,
would
probably
have
to
be
done
through
the
cubelet
right.
C
You
have
to
plug
it
in
there,
and
so
I
was
thinking
if
we
need
like
a
sig
working
group,
which
kind
of
sits
between
these
two
things
where
like.
If,
like
new
issues,
come
and
they
have
the
bandwidth
they
go
like
and
implement
it,
because
it's
kind
of
hard
to
expect
like
people
who
kind
of
just
work
on
signal
to
know
like
the
deeper
aspects
of
security,
yeah.
B
C
Then
it's
hard
for
sig
security,
folks
who
are
doing
like
research
to
kind
of
know
the
nitty
gritties
of
cubelet
right,
and
so
I
was.
I
don't
know
what
how
others
feel
about
like
having
a
security
work
group
who
kind
of
like
I,
I
don't
know
the
past
companies,
but
I've
done
security,
there's
always
like
security
researchers
and
then
there's
security
engineers
who
kind
of
go
build
security
features
right.
So
I
was
thinking.
C
Maybe
we've
kind
of
need
something
like
that
in
kubernetes,
because
there's
a
lot
of
like
cool
issues
that
I
see
which
are
open
and
I'm
like.
Why
don't
we
build
this
because
it'll
make
like
running
components
as
root
as
non-root
much
easier,
but
it's
like
nobody
get
nobody's
driving
that
because,
like
I
feel
like
sometimes
it's
like.
Who
really
goes
and
does
it
right
right
right.
A
A
This
is
probably
a
good
audience
to
bring
issues
where
we
need
development,
help
or
engineering
help
and
the,
and
also
to
bring
ideas
where
we
can
build
on
on
top
of
it.
So
if
you
see
issues
where
there
isn't
enough
security
people
around
or
giving
feedback
or
working
on
engineering
activity,
then
please
bring
those
issues
here
as
a
gender
topics
or
even
if
we
meet
once
a
month,
you
can
bring
it
on
the
slack
channel
or
share
it
on
the
mailing
list
and
whoever
is
interested.
A
But
for
now
I
would
say
anything
you
have
seen
like
needs
help
or
there
aren't
enough
people.
People's
eyes
on
it,
please
bring
it
here,
and
I
think
we
will
try
to
find
out
who
can
help
and
how
they
can
help.
A
All
right
cool
any
anything,
any
other
thoughts
from
your
experiences
or
things
that,
when
you
are
working
on
kubernetes,
have
thought
like.
Oh,
I
wish
this
was
there
in
the
community
and
I
could
have
just
used
it.
Those
kind
of
topics
or
ideas
are
also.
A
A
Okay,
all
right
so
no
worries
if
you
do
can't
come
up
with
anything
now,
it's
it's
new
and
we
are
all
learning
as
we
do
more
of
this,
we'll
start
coming
up
with
more
ideas.
We
have
one
topic
that
I
do
want
to
discuss
and
we
have
someone
from
sid
release
adolfo
who
worked
on
this
and
he
is
assigned
right
now
technically
to
this,
but
he
definitely
needs
some
help
from
all
of
us,
so
I'll
open
this
I've
opened
this
on
github.
A
B
Sure
so,
first,
I
think
we
should
have
some
a
little
bit
of
background
of
how
we
how
we
release
the
base
images.
So
whenever
we
got
a
new
kubernetes
release,
we
produced
a
couple
of
artifacts
with
it,
and
this
is
from
documentation,
which
is
the
the
release
notes.
So
all
the
way
up
to
the
container
images,
then
that
run
on
that
run
the
on
on
the
on
the
people's
actual
clusters
right,
we
also
have
binaries.
We
have
also
tar
files
and
there's
there's
lots
of
things
going
on
there,
one
of
those.
B
So
when
we
produce
the
container
images
we
base
them
on.
If
memory
serves
correctly,
we
have
two
base
images.
We
have
a
debian
image
where,
where
which
is
the
base
for
things,
things
that
need,
for
example,
iq
tables
and
and
also
we
have
the
digital,
is
the
trellis
image
for
things
that
do
not
require
that
thing.
There
is
an
effort
currently
going
on
to
move
the
to
get
rid
of
the
base
image
of
the
debian
based
image
and
have
everything
this
true
less,
it's
not
there.
B
Yet
some
people,
I
think,
are
working
on
it
and
I'm
not
sure
how
how
dense
the
effort
is
right
now
and
yeah
the
the
topic
of
actually
patching
the
the
images
in
a
more
automated
fashion
has
come
several
times
in
the
past.
We
do
it
whenever
we,
but
this
is
a
human
that
detects
a
flow.
That's
considered
serious
enough
to
touch
the
images.
Then
we
start
doing
the
work
of
generating
new
base
images.
B
This
is
not
ideal
as
the
as
someone
has
to
be
actively
monitoring
that
and-
and
this
is
in
this-
this
has
this
is
currently
in
the
state.
It
is
because
of
two
main
reasons.
The
first
one
is:
we
need
to
build
more
automation
on
the
side
of
building
things,
and
also
we
need
to
have
like
a
machine,
readable
sort
of
truth,
for
whenever
the
the
vulnerabilities
are
published
right.
B
So
we
as
as
promoting
so
the
image
building
in
in
for
the
kubernetes
releases,
involves
a
lot
of
steps
right
now,
so
we
have
to
go
and
manually
update
a
series
of
jmo
files
to
come
to
the
new
versions,
and
then
we
have
to
promote
those
images
and
then
we
have
to
make
sure
that
they're
available
in
their
registry.
So
whenever
we
get
a
new
release
or
a
batch
release
or
a
batch
release,
it
actually
can
pull
those
images.
And
so
it's
it's
a.
B
I
mean
it's,
it's
a
complex
problem
and
it's
a
complex
operation
in
the
sense
that
it
has
many
moving
parts
and
there's
many
steps
to
do
that.
So
for
the
same
reason,
we
cannot,
for
example,
build
the
images
for
every.
B
I
don't
know
for
every
trivial
patch
that
deviant
issues,
so
we
we
need
to
make
sure
that
we
are
reacting
to
vulnerabilities
which,
in
my
view,
should
be
serious
enough.
I
don't
know
if
we
could,
based
on
those
on
on
cv
sports,
for
example,
or
or
some
measure
like
that
and
yeah.
So
if
someone
wants
to
get
involved
in
that
effort,
there's
like
two
tracks
that
I
can
see
that
we
could
prepare
and
start
discussing
it.
So
the
first
one
is
the
actual
improvement
of
the
building
of
images.
B
B
How
could
we
read
the
the
security
information
from
somewhere
react
to
them
and
actually
trigger
the
build
jobs
for
the
images?
So
those
are
the
two
main
components.
Once
we
have
those
in
place,
we
can
start
thinking
on
on
building
things
more
automatically.
So
I
don't.
I
don't
see
that
we,
we
can
do
the
actual
image
feeling
in
an
automatic
in
fully
automated
in
the
in
a
short
term,
but
we
can
definitely
start
improving
the
tooling
that
we
need
first
to
build
new
images
and
second,
to
create
the
information.
A
Can
you
hear
me
yeah,
okay,
all
right
yeah?
I
think
that
helps
a
lot
one
of
the
things
that
you
mentioned.
Would
I
I
think,
especially
for
me,
and
maybe
others
will
help-
is
a
quick,
maybe
a
workshop
or
a
work
hands-on
session,
where
we
get
to
know
how
the
images
are
built
today
for
that
are
relevant
to
kubernetes,
because
for
me,
maybe
a
few
months
back,
I
did
not
know
how
many
images
were
part
of
kubernetes
kubernetes
and
then
the
deeper
I
went
the
more
I
found
and
then
I
was
like
wow.
A
B
If
you
are
curious
enough,
you
can
go
into
the
release
bucket
and
it's
there
and
you
can
take
a
look
at
it
and
it
lists
the
actual
images
as,
but
we
also
have
somewhere
I'll
share
it
with
you
in
a
minute,
a
list
of
the
absolute
facts
will
produce
and
there
should
be
all
the
images
listed,
and
I
can
I
can
share
that
with
you
and
yeah.
Definitely
I
can.
B
I
can
talk
with
with
the
other
release
managers
who
are
and
see
if
we
can
bring
on
someone
who
has.
Actually,
I
I
haven't
to
be
honest.
I
haven't
programmed
in
and
touched
the
golden,
the
actual,
build
jobs
and
so
on
then
I've
I've
built
the
images,
but
I've
never
gone
into
the
code
and
actually
the
actual
build
jobs
that
run
the
yeah
the
image
building
side
of
things.
B
I
can
probably
have
someone
on
board
with
a
little
bit
more
experience
and
how
things
work
internally,
and
we
can
organize
a
talk
to
that
and
yeah.
I
think
it
would
be
if
we
can
get
people
with
more
experience,
reading
the
vulnerability
stuff
and
assessing
them
and
having
them
hook
up
with
the
reason
during
things
would
be
a
very
fruitful
effort.
I
think.
A
C
I
have
a
question
so
about
this,
so
you
said
that
you
want
to
build
the
you
want
to
automatically
build
the
base
image
right
exactly,
but
will
that
trigger?
C
Will
that
new
base
image
will
trigger
a
new
patch
version
build
for
kubernetes
a
new
batch
version,
a
new
patch
version
for
for
kubernetes
like
so
so
the
once
the
base
image
gets
updated
right
unless,
like
you,
update
the
cube
api
server,
cube
control
manager,
images
to
kind
of
use
this
new
image
version
like
unless
we
do
that
we
are
not
really
pushing
a
safe
version
of
kubernetes
out
there
right,
which
doesn't
have
that
vulnerability.
C
B
Yeah
those
voice
images
get
built,
and
then
right
we
would
we
would.
We
would
actually
use
them
until
the
next
actual
release
that
we
got
so
yeah
if
you're,
using,
for
example,
one
20.1
and
that
120.1
will
always
be
in
the
base
on
the
same
base.
Image
currently
as
as
right.
C
Gotcha,
so
so
it's
still
manual
in
terms
of
how
we
update
the
kk
repository
to
kind
of
use.
This
new
base
image,
that's
created
that
will
still
be
manual.
B
C
And
what
about
what
about
like,
once
the
image
gets
updated?
Let's
say
a
new
debian
based
image
is
created
right.
What
about
patching
it
to
like
previous
release
versions,
or
are
we
only
scoping
it
to
the
latest
version,
so,
let's
say
1.20
and
we
create
a
new
patch
version
for
1.20,
because
we
found
a
vulnerability.
B
H
A
I
think
this
is
a
good
segue
for
the
other
topic
I
wanted
to
discuss
related
to
this
is
we
we've
been
trying
to
work
with
the
per
security
response
committee,
which
was
product
security
committee
before
to
figure
out?
What
is
the
policy?
We
would
want
to
apply
for
vulnerabilities
that
we
find
in
either
kubernetes
dependencies
or
in
kubernetes
images
in
this
case
and
decide.
When
do
we
want
to
do
n
minus
2
updates
for
releases,
which
means
if
121
we
find
something?
A
Do
we
go
back
120
and
119
and
update
it
and
then,
and
when
is
the
time
to
just
update
the
upcoming
version,
and
when
is
the
time
to
maybe
not
worry,
because
vulnerability
doesn't
impact
us,
even
if
some
scanner
is
saying
kubernetes
is
vulnerable,
so
this
is
something
I
wanted.
Some
feedback
from
all
of
you
as
well
I'll
share
this
link
as
quickly
on
google.
Sorry
in
zoom
chat.
A
So
there
are
five
categories
we
identified
so
far,
but
happy
to
discuss
more.
One
is
obviously
obvious
false
positive,
whereas
scanner
says
hey,
you
are
vulnerable,
but
we
find
out
that
either
the
code
doesn't
exist
or
the
image
that
exists
already
has
the
fix.
So
then,
in
that
case
we
just
open
a
github
issue
and
log
that
this
is
a
false
positive.
So
it
becomes
sort
of
like
a
tracker
for
anyone
who
runs
the
same
scanner
on
the
same
kubernetes
release
and
gets
the
same
result.
A
A
Then
the
second
category
we
found
was
true
positive,
but
no
impact,
so
this
would
typically
be
in
a
situation
where
we
we
have
the
the
vulnerable
package
or
a
vulnerable
os
dependency
in
the
base
image,
but
the
code
actually
is
maybe
not
used
by
kubernetes.
A
So
as
a
result
of
that,
even
if
the
package
has
the
vulnerable
code
because
it's
not
used
by
kubernetes,
it
really
has
no
impact,
then
the
other
one
we
found
was.
There
could
be
a
true
positive
and
in
this
case
the
kubernetes
kubernetes
repo
is
vulnerable,
but
because
of
the
way
we
have
threat
model
kubernetes.
We
think
that
that
vulnerability
does
not
apply.
A
So
in
that
case
we
know
there
is
an
impact,
but
there
is
negligible
impact
because
of
the
way
we
have
assumed
the
threat
model
to
be
so.
In
that
case,
the
resolution
could
be
different.
Where
we
say
you
please,
if
you
apply
this
compensating
controls,
then
the
threat
is
redundant
for
you
and
you
don't
have
to
worry
about,
but
we
will
fix
it
anyway
in
the
upcoming
kubernetes
kubernetes
release.
A
So
that
was
third
and
then
fourth,
fourth
is
really
the
last
one
that
matters
to
us.
Any
embargoed
vulnerabilities
will
still
be
taken
care
by
product
security
committee,
which
is
a
group
of
individuals
essentially
who
keep
track
of
public
hacker
rank
submissions
for
things
they
have
found
vulnerable
in
kubernetes
and
then
they
resolve
it
and
then
fixes
are
applied
if
needed
and
because
it's
under
embargo
most
of
that
discussion
is
confidential,
but
what
we
may
end
up
doing
will
could
be
probably
public.
A
So
last
last
one
in
this
case
number
four
is
true.
Positive
with
impact
where
we
know
kubernetes
is
vulnerable.
Kubernetes
is
using
vulnerable
code,
and
in
that
case
we
will
actually
go
to
n
minus
2
and
also
patch
the
latest
release
or
the
upcoming
release.
So
those
are
the
few
things
we
came
up
with,
but
probably
we
haven't
covered
all
the
scenarios,
or
maybe
the
resolution
doesn't
make
sense,
so
want
to
get
some
feedback
from
all
of
you
now
or
even
offline
later.
It
would
work
as
well.
B
Yeah,
I
can.
I
can
say
that
this
is
precisely
what
we
need
to
do:
the
base
images.
So
if
you,
if
you
can
take
all
the
streams
of
of
updates
of
patches
of
all
the
information
that
goes
and
releases
and
then
then
make
a
subset
of
that
insecurity
and
then
make
these
assessments,
I
mean,
run
all
the
information
through
this
criteria
and
then
produce
a
machine,
readable
output
from
this,
then
we
are
there.
This
is
precisely
what
we
were
missing.
A
G
Yeah
I
was
gonna
throw
my
hat
in
the
ring
for
adolfo
include
me
in
anything.
You
want
to
talk
about
as
far
as
image
scanning
I'd
be
happy
to
help
and
and
in
any
way
I
can,
and
I
know
we
need
to
be
vendor
agnostic
here,
obviously
of
whatever
tool
we
choose
to
use.
G
G
That
are
available
to
the
kubernetes
account
that
might
help
with
some
of
the
questions
you
had
about
what
how
to
trigger
when
new
cves
come
up,
how
to
trigger
builds,
and
things
like
that.
But
I'd
be
happy
to
you
know:
brainstorm.
A
Yeah
and
what
eric
said
completely
agree
like
we
have
to
start
somewhere
so
we'll
start
with
the
tool,
get
the
process
working,
end-to-end
test,
drive
it
and
then
we'll
try
to
ensure
that
the
process
can
is
flexible
enough
or
loosely
coupled
enough
to
the
tool
such
that,
if
needed,
we
can
switch
the
tool
in
future
to
something
that's,
maybe
completely
open
source,
so
that
will
always
be
the
goal,
but
we
have
to
start
somewhere.
So
we'll
start
with
any
tool.
That's
available.
A
All
right
any
any
other
thoughts.
I
know
samuel.
You
were
interested
in
this.
What
what
do
you
think
about
the
discussion
so
far.
E
I
mean
I
think
this
document
definitely
makes
a
lot
of
sense.
I
you
know
personally
have
like
these
terms,
like
embargoed,
vulnerabilities
and
stuff.
I
think
I
have
a
little
reading
to
do
or
catching
up,
but
yeah.
It's
definitely
seems
like
an
important
thing
that
could
be
automated
in
a
pretty
effective
way,
so
definitely
interested
in
helping
out.
However,
I
can.
A
All
right,
all
right
cool
as
a
next
step-
at
least
I
am
taking,
is
I'll.
Try
to
convert
this
and
some
of
the
other
discussions
into
a
markdown
in
under
a
community
security
folder,
so
we'll
be
able
to
have
it
somewhere
where
everyone
can
view
and
edit
and
submit
prs,
and
once
we
have
some
details,
I'll
share
the
links
feel
free
to
jump
in
contribute.
Collaborate
with
me
review
anything
I've
written
and
in
any
other
thoughts
that
come
up
even
later
or
now
in
the
meeting.
A
A
We
have
about
nine
minutes
more
anything
else
that
anyone
wants
to
talk
about
people
who
have
been
quiet
in
the
meeting
want
to
give
you
a
chance
to
share
your
thoughts
as.
F
Well,
another
question:
I
was
curious
about
thinking
of
tooling
and
security.
F
Is
there
any
kind
of
list
of
like
a
lot
of
the
commonly
used
tooling
like
I
know,
I've
certainly
seen
a
lot
of
things
from
like
aqua
security
and
other
great
places
online,
but
I
was
just
wondering
you
know
maybe
kind
of
hard
to
maintain,
but
I
was
just
wondering
if
there
was
any
kind
of
list
trying
to
think
of
like
where
gaps
might
be
in
tooling.
It's
hard
to
know
what
are
the
representative
tools
that
we
use
in
security
to
begin
with,
to
even
think
about
where
the
gaps
might
be.
A
Yeah,
a
few
things
come
to
mind
on
my
side
is
some
of
the
work
that
tax
security
is
doing
so
for
folks
who
are
new,
we
basically
have
two
security
groups.
One
is
focused
on
cncf,
which
is
called
tag:
security,
technical
advisory
group,
hyphen
security,
so
they
are
advisory
group
under
the
cncf
umbrella
who
work
on
not
just
kubernetes
but
for
all
the
projects
and
essentially
defines
some
level
of
policy
and
guidance
of
how
to
secure
your
cncf
projects.
A
Our
group
is
tied
in
the
kubernetes
project
umbrella,
but
we
do
have
a
fairly
pretty
much
of
an
overlap
in
terms
of
some
members
who
are
part
of
both,
including
me
and
some
who
also
end
up
doing
similar
like
activities.
A
So
in
that
group
there
is
an
activity
going
called,
seek
security
map
or
sorry,
not
security
map.
It's
because
the
name
has
changed
there.
Now,
tax
security
map,
which
is
essentially
an
idea
where
the
tax
security
last
year
created
a
cloud
native
security
white
paper
and
that
cloud
native
security
white
paper
was
high
level,
explaining
the
different
threats
in
the
entire
cloud
native
landscape
and
what
they
didn't
do
purposely
was
to
scope
it
to
share
that
hey.
These
are
the
tools
or
things
you
should
do
to
take
care
of
it.
A
So
as
part
of
our
next
step
to
the
white
paper,
they've
started
creating
some
level
of
an
interactive
map
which
takes
one
section
from
the
white
paper
and
then
shares
that
hey
for,
if
you
want
to
be
hands-on
or
if
you
want
to
play
around
with
things
that
you
should
worry
about,
worry
about
or
things
that
you
want
to
know.
If
there's,
if
they,
if
there
is
a
tool
that
exists,
then
these
this
is
what
you
should
do.
So
that's
something
that
comes
to
my
mind.
It's
still
again
in
progress.
A
I
don't
think
there
is
anything
public,
but
that
doesn't
stop
us
from
creating
something
similar
for
kubernetes,
which
we
could
then
push
back
to
their
initiative,
so
anything
related
to
kubernetes
and
security.
Where
we
know
there
are
tools
that
exist,
but
things
that
are
not
clear,
probably
a
good
opportunity
as
a
community
for
all
of
us
to
start
creating
a
google
doc
with
a
draft
and
then
all
of
us
jumping
in
and
coming
up
with
some
details.
A
You
all
want
to
make
sure
if
you
have
any
thoughts.
Just
just
don't
be
afraid,
don't
be
shy.
I'm
a
very
shy
person
myself.
A
A
Okay,
no
worries.
I
started
like
that
as
well,
so
cool
a
last
call,
if
nothing
else,
we
can
probably
give
back
couple
of
minutes
time
back
to
everyone.
So
no,
no,
no,
okay,
all
right!
So
thank
you!
Everyone!
It
was
great
meeting.
A
I
hope
to
see
you
again
next
month,
third,
tuesday
of
every
month
we
meet
at
the
same
time
and
we'll
continue
to
have
more
offline
discussions
as
much
as
possible
to
avoid
meeting
fatigue
for
all
of
us,
but
yeah
don't
be
afraid
to
hit
me
up
or
anyone
else
in
the
group
on
slack.
If
you
have
questions
or
things
that
you
will
come
up
with
as
an
idea,
we
will
try
to
figure
out
a
way
to
get
it
into
the
community.