►
From YouTube: Get In Containerds, We’re Going Securing: Kubern... I. Coldwater, T. Sable, S. Raghunathan, A. Small
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Get In Containerds, We’re Going Securing: Kubernetes SIG Security is Here! - Ian Coldwater, Twilio; Tabitha Sable, Datadog; Savitha Raghunathan, MathWorks; Aaron Small, Invitae
Kubernetes SIG Security is a newer and evolving SIG, and we’re excited to be here and tell you what we’re all about! Come learn about our work on horizontal security initiatives for the Kubernetes project including regular third-party security audits, cross-cutting security documentation, and building bridges both internally and externally to improve the security of the project as a whole. Most importantly, learn how you can get involved. Bring your thoughts, questions, and ideas! Can’t wait to see you there!
A
B
B
So
where
did
the
stick
come
from?
What's
up
with
this?
Why
now,
what
are
we
doing?
Let's
talk
about
it
so
seek
security
evolved
from
the
third
party
security
audit
working
group,
the
original
founders
of
the
sig,
who
were
the
people
who
ran
the
working
group,
recognized
that
more
could
be
done
to
promote
security
in
kubernetes
across
the
project
and
over
time.
B
So
they
decided
that
expanding
the
working
group
into
a
sig
would
be
one
way
to
help
them.
Do
that,
so
they
wrote.
The
charter
did
all
the
applications
and
paperwork
and
transitioned
the
working
group
into
a
sig.
They
also
recognized
that
it
was
really
important
to
build
community
to
establish
the
successful
crosstig
effort,
as
well
as
reach
out
to
the
external
security
community
and
get
the
external
security
community
involved
in
the
security
of
the
kubernetes
project.
B
B
One
thing
we
do
is
to
try
to
foster
security
knowledge
sharing
in
the
kubernetes
project
across
cigs
and
among
contributors.
We
also
want
to
encourage
people
from
the
external
security
community
to
come,
get
involved
in
the
security
of
the
kubernetes
project.
We
want
to
make
it
a
kind
of
coalition
community
building
effort,
and
in
pursuit
of
that,
we've
built
our
sig
as
a
community
building
effort.
B
This
is
important
both
because
we
think
it's
important
and
for
historical
reasons
too.
Historically
kubernetes
hasn't
really
had
a
place
for
people
who
are
interested
in
helping
with
the
security
of
the
project
to
have
a
home.
Security-Minded
contributors
could
traditionally
go
to
sigoth
or
you
know
other
kinds
of
sig
efforts
that
kind
of
had
security
involvement,
and
I
think
part
of
that
was
the
thought
that
security
affects
all
parts
of
the
project,
and
that
makes
sense,
but
also
that
could
leave
newer
contributors
confused
because
they
were
like
where's.
B
A
So,
of
course,
most
of
the
work
that's
done
day
to
day
by
the
psc
has
to
be
private
by
necessity
because
of
the
nature
of
the
work
as
the
psc,
we
are
really
here
to
serve
kubernetes
as
a
community
and
as
a
software
development
project,
and
so
while
the
work
may
be
private,
the
planning
that
goes
into
how
the
work
should
be
done,
how
the
work
should
be
prioritized.
How
we
should
interact
with
the
rest
of
the
project,
really
should
be
a
community
project
and
before
sig
security.
A
B
We
believe
that
building
community,
rather
than
being
non-technical,
actually
helps
technical
excellence,
because
when
people
work
better
together,
people
can
build
better
systems
together
when
people
are
communicating
with
one
another
things
that
might
be
missed.
If
people
were
in
silos
are
more
likely
to
be
seen.
So
we've
really
built
this
sig
on
purpose
as
a
community
forum
as
a
community
building
thing,
so
that
people
can
come
together
across
cigs
and
outside
of
the
outside
of
the
community
in
the
project
to
be
able
to
work
together
to
help
build
kubernetes
up
better.
B
So
we
want
to
encourage
six
and
contributors
to
work
together
beyond
security
issues
by
security
people,
because
we
don't
actually
think
that
those
silos
are
what
we
need.
We
think
that
increased
collaboration
means
a
better
outcome
for
everybody,
and
that's
a
big
reason
of
why
we're
here-
and
we
have
built
our
group
that
way
on
purpose,
when
there
are
issues
that
people
see
that
they
believe
are
security
relevant
within
the
kubernetes
project.
B
B
A
Yeah
yeah,
absolutely
so
pot
security
policy
has
been
a
feature
in
kubernetes
for
a
very,
very
long
time.
If
I
remember
correctly,
it
first
had
its
alpha
release
in
1.3
and
from
the
beginning,
pod
security
policy
evolved
over
time
as
kubernetes
evolved
as
the
pod
specification
evolved,
and
so
as
that
evolution
happened,
it
became
more
and
more
apparent
to
users
and
to
sigoth
who
were
taking
care
of
it.
A
A
We
brought
ourselves
to
sigoth
and
we
heard
what
their
concerns
were,
and
so
then
we
applied
the
experience
that
we
have
as
kubernetes
end
users
to
writing
a
proposal
for
a
replacement
for
pod
security
policy.
Tim
alclair
from
sigoth
wrote
another
proposal
that
was
that
was
different,
but
working
to
address
the
same
kinds
of
concerns.
A
Then,
together
with
tim,
we
were
able
to
bring
both
of
those
proposals
to
the
community
in
sig
security
to
the
community
in
sigoth
and
really
iterate
on
both
of
those
proposals
together
with
all
of
those
community
groups.
You
know
this
resulted
in
the
creation
of
a
temporary
spin-off
meeting
for
for
iterating
on
these
ideas,
and
people
really
responded
wonderfully.
The
both
proposals
improved
really
dramatically
as
a
result
of
the
input
that
all
of
the
folks
from
sig
security
and
sigoth
and
from
the
broader
kubernetes
community
put
into
them.
B
If
there
are
people
who
are
excited
about
implementing
these
ideas,
two
subgroups
that
we
have
going,
which
are
really
awesome
right
now,
are
the
subgroup
for
security
docs
and
the
subgroup
for
the
security
audit
and
we're
going
to
hear
from
two
of
the
leaders
of
those
subgroups
talking
about
their
work
there.
But
first,
I
think
tabby
wanted
to
talk
a
little
bit
about
what's
going
on
with
security
docs
and
some
of
the
things
that
security
is
involved
with
helping
them
with
too.
C
My
name
is
habita
and
I
am
going
to
talk
about
the
subproject
security
documentation
today.
So
what
do
we
do
there?
We
work
on
improving
the
overall
security
documentation
in
the
kubernetes
website,
and
we
do
it
by
going
through
the
existing
content
and
adding
supplementary
security
guides
and
tutorials.
C
We
look
through
the
examples
and
make
sure
they
have
the
right
security
context
in
them.
If
not,
we
create
a
pr
and
fix
it.
We
also
remove
the
old
and
deprecated
security
content
from
the
website.
One
of
the
major
goals
of
this
project
is
to
create
a
platform
for
new
and
existing
contributors
to
come
together
and
a
talk
about
their
passionate
security
topics
and
share
and
learn
together.
C
The
beauty
of
this
sub
project
in
creating
all
these
guides
examples
is
that
all
the
content
spans
around
various
special
interest
groups
and
thereby
it
brings
people
together.
It
creates
a
medium
for
collaboration
and
it
also
pays
way
for
continuous
improvement
in
the
form
of
good
reviews
and
feedback.
This
is
also
a
good
place
for
someone
who
is
starting
out
who
wants
to
know
and
learn
about
kubernetes.
They
can
do
that
slowly
and
steadily.
For
example,
there
is
this
new
contributor
who
wants
to
improve
an
example
in
a
persistent
volume
page.
C
C
By
doing
this,
they
will
get
some
more
knowledge
around
this
area
and
they
can
grow
from
there.
If
these
things
are
interesting
to
you-
and
you
want
to
contribute
here,
so
you
can
do
it.
We
are
working
on
a
kubernetes
hardening
guide
that
is
targeted
towards
the
cluster
operators
and
it
will
help
them
secure
the
cluster
when
they
are
provisioning
it.
C
C
I
want
to
give
a
special
shout
out
to
rory
mckeon
for
putting
this
guide
and
the
base
structure
together.
Thank
you,
rory.
If
you
are
a
new
contributor,
you
want
to
learn
and
you
want
to
participate
in
the
discussions
you
can
do
that
by
attending
our
meetings.
That
happens
every
first
and
third
thursdays
at
6
pm
utc,
that
is
2
p.m.
East,
eastern
and
if
this
time
is
not
right
for
you
and
you
cannot
make
it
for
some
reason,
we
also
have
a
slack
channel,
say:
security
docs
and
we
encourage
asynchronous
collaboration.
C
So
you
can
stop
by
there
say:
hi
post
your
topic
and
discuss
away.
If
you
have,
there
is
also
another
place
where
you
can
start
contributing
to
seek
security,
stop
by
the
kubernetes
website.
Tremble,
and
you
can
filter
through
the
issues
and
prs
based
on
the
label
security,
and
you
can
pick
an
issue
or
you
can
review
a
pr
whichever
that
interest.
C
We
would
request
you
to
create
a
issue
in
the
communities
website,
tag
it
with
security
and,
if
you're
interested,
you
can
create
a
pr
and
someone
or
the
other
will
be
there
to
review
and
provide
some
feedback.
This
is
how
you
can
help
us
make
the
kubernetes
security
better
and
better.
Thank
you.
Everyone
happy
honking.
B
Thanks
avatar,
I'm
really
excited
about
the
things
that
our
doc
sub
project
is
doing,
and
I'm
really
excited
about
the
way
that
we
are
all
working
together
to
help
level
up
contributors.
People
who
are
newer
people
who
are
learning
and
people
who
want
to
come
be
future
leaders
in
the
project.
I'm
really
excited
that
we're
able
to
do
this
and
with
a
security
lens.
I
think
it's
really
great
work
and
I'm
so
glad
that
it's
happening
really
excited
about
the
hardening
guide
too.
B
So
another
thing
that
is
happening
on
an
ongoing
basis
is
the
third
party
security
audit.
As
we
said
earlier,
sig
security
came
out
of
the
third
party
security
working
group,
and
that
is
a
thing
that
the
cncf
is
having
happen
on
a
cyclical
ongoing
basis.
Right
now,
as
a
recording
time,
we
have
a
request
for
proposals
open
for
vendors
who
want
to
be
involved
in
that
process.
B
D
My
name
is
aaron
small,
ian
and
tabitha
asked
me
to
join
them
and
give
a
brief
update
on
what's
going
on
with
the
third
party
security
audit.
So
our
job,
in
short,
is
to
facilitate
a
third
party
vendor
to
come
in
and
perform
a
security
assessment
of
kubernetes
help
them
find
vulnerabilities
and
get
them
fixed.
D
We're
also
looking
to
find
these
horizontal
architectural
choices
that
exist
across
kubernetes
that
may
be
hindering
our
security
generically
and
get
those
fixed
as
well,
though
those
tend
to
resolve
over
much
longer
timelines
and,
finally,
we're
looking
to
engage
the
broader
security
community.
When
you
can,
when
you
publish
findings
on
an
audit,
that's
this
large
and
this
visible.
What
can
happen
is
what
we're
hoping
happens
is
independent
researchers
from
around
the
world.
Look
at
what
you've
done.
Look
at
your
findings
and
think
to
themselves.
D
I
think
I
could
have
done
better
or
I
don't
think
you
went
far
enough
or
I
think
you
missed
something
really
important,
and
then
we
can
take
all
that
interest
and
all
that
excitement
and
we
can
funnel
it
right
back
into
the
public
bug.
Bunny
program
get
those
researchers
paid
and
make
communities
more
secure,
so
this
year
we're
focusing
all
of
our
research
on
this
list
of
components.
D
The
last
audit
we
ran
in
2019
spent
a
lot
of
energy
on
threat,
modeling
and
understanding
the
relationships
between
components
and
how
threats
might
propagate
through
the
environment.
We've
selected
this
list
because
we
think
they're
really
critical
from
a
security
standpoint,
and
we
didn't
pick
every
component
because
we
need
to
strike
a
balance
between
breadth
and
depth.
If
you
don't
go
broad
enough,
then
you
don't
build
confidence,
that
you've
looked
in
all
the
right
places
and
if
you
don't
go
deep
enough,
then
you're
not
going
to
find
the
really
critical
stuff
you
spend
an
hour.
D
Looking
at
a
component,
you
might
find
a
surface
level
vulnerability.
But
if
you
spend
much
more
time
on
that
component,
you
might
find
the
one
that
is,
is
business
ending
for
someone
who
uses
kubernetes.
So
we
want
to
go
deep
enough
to
find
the
good
stuff
as
we
go
through
the
process
of
evaluating
these
components.
D
Adjacent
stuff
is
going
to
come
up.
We're
just
going
to
use
the
public
bug
bounty
program
scope
to
determine
if
they're
in
or
out
rule
of
thumb
would
be
if
it's
part
of
kubernetes
kubernetes
or
one
of
the
other
repos,
it's
probably
in
scope,
but
if
it's
related
to
a
specific
deployment
technology
or
related
to
a
specific
distribution,
it's
probably
other
scope.
D
So,
as
I
mentioned
before,
the
first
third-party
security
audit
of
kubernetes
finished
in
may
of
2019.
That
audit
generated
a
lot
of
excitement.
We
have
a
talk
here.
People
were
very
interested,
very
engaged
and
we
wanted
to
channel
that
into
making
these
audits
recurrent
making
it
part
of
communities
process,
and
we
also
lobbied
for
the
creation
of
sig
security,
which
is
now
up
and
running
and
doing
really
great
work.
D
One
of
the
reasons
for
this
delay
appears
to
be
high
demand
right
now
in
this
space.
Personally,
I
can
attest,
and
other
people
on
the
sub
project
have
mentioned
that
they're
having
a
hard
time
getting
a
vendor
engagement
on
audits,
even
for
smaller
corporate
projects,
so
we'll
relax
our
dates,
we'll
get
in
the
proposals
we'll
select
one.
Our
selection
criteria
by
the
way
is
all
public,
as
is
the
our
evaluation
of
the
proposals
from
last
audit
and
the
the
final
proposal
that
we
did
eventually
accept.
D
So
the
reason
we
need
your
help
is
really
simple.
Kubernetes
is
really
big
and
moving
really
fast.
We
have
6.2
million
lines
of
code
when
I
ran
that
command
right
before
I
recorded
this,
and
also
about
240
commits
one
week
in
february.
That's
big
and
that's
fast,
and
it's
not
reasonable
for
us
to
expect
a
vendor
to
come
in
and
know
right
where
to
start
and
how
to
dive
in.
D
We
are
selecting
for
vendors
that
have
experience
in
the
space
experience
with
kubernetes
experience
with
open
source
projects,
but
we
need
more
depth
than
that,
so
the
subproject
members
will
be
facilitating
interviews
with
leaders
around
the
communities
project,
sig
owners,
people
who
have
been
here
a
long
time.
Anyone
who
knows
where,
where
the
bad
code
is
we're,
gonna,
be
wanting
to
talk
to
and
and
point
the
researchers
where
their
time
is
most
valuable
after
these
interviews,
potentially
with
some
overlap,
they'll
go
about
the
process
of
building
out
an
environment.
D
They'll
use
this
environment
for
dynamic
analysis
of
a
running
communities
cluster,
as
well
as
the
static
analysis
that
they'll
also
do
as
this
process
is.
Ongoing
vulnerabilities
will
start
to
come
out
and
we're
going
to
take
these
vulnerabilities
and
send
them
straight
to
the
product
security
council.
Following
their
standard
disclosure
process,
we
won't
be
disclosing
them
as
they
come
out
to
the
public,
though,
at
the
end
of
the
audit,
we
are
going
to
take
all
the
findings
all
of
the
research
and
all
of
the
the
writings
that
come
out
of
it
and
share
them
publicly.
D
Just
like
we
did
last
time,
though,
there
may
be
some
delay.
If
there's
a
disclosure
timeline,
we
need
to
follow
for
the
safety
of
kubernetes
we're
looking
for
more
help.
We're
looking
for
more
engagement
on
this,
please
come
join
us
in
the
six
security
slack
channel.
You
can
also
reach
out
to
myself
or
ray
directly
ray.
Is
the
chair
of
this
sub
project
and
he'd
love
to
to
hear
from
you?
I
hope
to
see
you
there
soon.
Thank
you
so
much
for
your
time
and
I'll
see
you
around.
B
Thanks
aaron,
as
aaron
said,
one
way
that
you
can
get
involved
with
sig
security
is
by
helping
point
vendors
to
the
third
party
security
audit.
If
you
have
relationships
with
anyone
in
that
line
of
work-
and
there
are
lots
of
other
ways
to
get
involved
with
sick
security
too,
we
really
want
you
to
come
and
bring
yourselves
your
concerns.
Your
project
ideas,
things
you
want
to
see
happen.
Whatever
thoughts
you've
got
to
our
meetings
and
to
our
stock
channel,
we
would
love
to
hear
from
you.
We
would
love
to
have.
B
Also,
while
we're
on
the
subject
of
sub
projects,
our
sub
projects
are
born
from
ideas
and
people
who
come
to
us
with
these
ideas
and
have
people
respond
to
them.
Come
show
up,
come
bring
yourself,
come
bring
your
ideas
and
come
start
it.
The
sky
is
the
limit.
Really.
Security
is
an
enormously
wide
field.
There's
lots
of
opportunities
for
growth,
lots
of
work
to
do.
We
would
be
so
excited
for
you
to
come
help
us
do
it
another.
A
B
One
thing
to
note,
though,
is
if
you
have
found
a
security
vulnerability
in
kubernetes.
You
should
not
come
and
bring
it
to
a
public
hub
issue
or
necessarily
a
public
meeting.
That
is
what
the
product
security
committee
is
for.
We
do
have
a
security
disclosure
process
and
a
bug
bounty.
So
I
recommend
taking
a
look
at
that,
but
if
you
have
kind
of
security
topics
that
can
be
spoken
about
publicly,
we
would
love
to
have
you
come
and
speak
about
them
and
we
would
love
to
hear
from
you.