►
From YouTube: Kubernetes SIG Security Docs 20210204
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
Recording
hello,
everyone
today
is
february
4..
Welcome
to
these
security
documentations
of
project
meeting.
We
abide
by
community
code
of
contact,
which
means
be
nice
and
kind
to
everyone
and
to
yourself
all
right.
So,
first
off
we
could
start
with
new
contributors.
A
So
if,
if
there
are
any
new
contributors,
please
give
us
a
brief
intro
one
liner
or
what
is
that
that
you
want
to
see
in
this
project?
Or
what
do
you
want
to
learn?
How
what
do
you
want
to
contribute
if
there
is
anything
at
all,
if,
if
you're,
just
locked
and
looking
around-
and
you
want,
you
want
to
learn
something
new?
That's
that's
good
too.
Just.
B
Sure
I
can
introduce
myself,
so
my
name
is
john
osborne.
I
work
at
red
hat,
I'm
on
the
the
field
team
for
public
sector,
so
I'm
a
chief
architect.
I
do
a
lot
of
the
lead,
a
lot
of
the
engagements
on
the
pre-sales
side.
I've
been
really
interested
in
security.
B
For
a
long
time,
I
had
been
tracking
a
lot
of
the
security
things
with
kubernetes
for
a
while
and
and
I'll
talk
about
that
at
some
point
during
this
this
call,
but
as
far
as
contributing
just
want
to
contribute
any
way
I
can
with
putting
things
in
perspective
around
you
know,
maybe
federal
standards
with
nist
853
or
I
know,
there's
some
questions
in
the
chat
around
pii
and
other
things
like
that.
B
So
I
know
any
way
I
can
I'm
not
really
looking
to
steer
the
project
anyway
or
just
overall
looking
to
contribute
and
just
adding
my
two
cents
for
my
view
of
the
world
over
here
in
the
public
sector,.
A
B
A
And
is
there
anyone
who
wants
to
go
next.
D
I
can
give
a
brief
introduction
to
myself.
My
name
is
joseph.
I
work
at
apple
and
I'm
putting
together
some
documentation
for
sort
of
a
inner
source,
open
source
project
and
helping
teams
move
to
kubernetes
and
cloud
native
tools,
and
I'm
the
guy
on
the
team
trying
to
make
sure
that
secure
it
stays
on
the
track
from
a
security
perspective.
A
Thank
you
joseph
welcome,
so
how?
How
do
folks
prefer
do
you
want
me
to
share
my
screen
with
the
agenda
or
would
that
work.
A
Okay,
let
me
just
go
and
cheers.
A
A
All
right,
can
everyone
see
my
screen.
A
Right
so
the
first
one
up
is
by
rory.
Do
you
want
to
give
a
brief.
E
Yeah,
so
yes,
the
the
document,
that's
in
the
agenda,
there
is
just
a
first
stab
one
of
the
things
that
was
discussed
back
when
municipal
security
was
kind
of
kicking
off
was
the
idea
of
of
having
a
like
a
kubernetes
official
hardening
guide
as
being
something
that
could
help
people
in
sort
of
saying
you
know,
here's
your
default
settings,
but
here's
some
of
the
things
you
might
want
to
consider
that
you
could
do
to
harden
that
and
to
have
something
that
was
a
bit
different
from
some
of
the
existing
content.
E
What
I've
in
the
actual
document
is
linked.
One
of
the
things
I
did
was
kind
of
say.
Here's
I
mean
the
first
one
identified
was
cis
benchmark.
I
said:
there's
the
cis
benchmarks,
which
are
already
there.
How
would
this
contrast
essentially
so
that
the
cis
benchmarks,
if
you've
seen
them,
are
quite
prescriptive?
They're
quite
kind
of
like
pass
fail
oriented,
and
so
the
idea
of
this
would
be
to
be
something
that
wasn't
like
that
that
that
didn't
cover
the
necessity.
E
We
might
cover
some
of
the
same
ground,
but
but
took
a
different
approach,
because
I
think
the
cis
format
can
be
a
bit
limited,
and
I
see
that
as
someone
who
kind
of
helped
out
in
developing
those
absolutely
yeah,
and
so
what
I
started
to
do
and
that's
what
this
document
was
just
like.
E
A
very
initial
kind
of
like
look
at
was
what
would
you
put
in
a
hardening
guide
right
because,
obviously,
there's
like
a
lot
of
stuff
that
could
go
in
there,
but
we
probably
want
to
try
and
add
at
least
initially
limit
the
scope
and
say
look
what's
the
core,
and
then
you
know
once
we're
happy
with
that.
If
this
is
this
seems
to
be
working
as
an
approach,
we
can
look
to
say:
okay.
Well,
that's
great!
E
Let's
now
see
you
know
if
there's
other
areas
that
people
feel
would
be
useful
and
would
be
helpful
and
that's
essentially,
what
I've
got
in
the
dock
is
just
what
I
what
I
came
up
with,
like
top
of
my
head
things
that
that
you
know
either
I've
seen
in
the
past
or
or
kind
of
areas.
I
think
would
probably
be
good
to
kind
of
cover.
E
Yeah,
I
guess
that
was
where
I
thought
it
might
be.
I'm
just
like
going
out
a
little
bit
into
some
of
the
other
areas
around.
You
know,
there's
obviously
the
straightforward
stuff
or
the
kind
of
the
initial
stuff
around.
You
know
configuring
control,
plane
worker
nodes,
but
then
also
talking
about
stuff
like
pki
and
kind
of
branching
off
a
little
bit
into
that
and
linking
into
things
like
authorization
guide.
E
I
think
a
lot
of
it
to
an
extent.
I
think
a
lot
of
it
probably
exists.
You
know
there's
a
lot
of
good
docs
already
there,
but
maybe
even
if
it's
a
lot
of
it
is
bringing
that
together.
E
You
know
so
people
have
say
here
is
the
hardening
guide
and
I
kind
of
go
through
that
and
a
lot
of
time.
It
might
just
be
saying:
well,
this
information
exists.
Maybe
there's
some
discussion,
there's
some
discussion
discussion
to
add,
but
fundamentally
here's
where
you
go
and
you
know
kind
of
build
that
out.
E
I'll,
just
like
you
know,
I
think
that
was
kind
of
the
idea.
I
don't
people
think
that's.
That
sounds
like
something
that
makes
sense
to
develop.
E
I
I
I'm
kind
of
coming
out
from
the
basis
of
I've
done
stuff
with
the
cis
benchmarks
and
I've
found
and
people
seem
to,
like
those
you
know,
there's
quite
a
lot
of
companies
that
seem
to
want
to
use
cis,
but
I
personally
find
the
cis
format
quite
restrictive,
and
it's
very
hard
to
have
a
more
you
know.
There's
difference,
there's
different
approaches
that
might
make
sense
in
different
clusters
where
sea
ice
is
very
much
either
you
pass
this
setting
or
you
fail.
It.
B
B
It's
basically,
they
went
through
every
documentation
for
the
kublet
for
the
api
server
et
cetera,
et
cetera
yeah,
and
they
picked
every
flag
and
then
they
said
this
is
the
more
secure
one
that
might
be
me
and
okay.
There
might
be
this
view
and
then
so,
yeah
yeah,
and
so
I
was
like
you're.
It's
your
decision
to
make
a
risk-based
assessment
around
that.
Whether
you
want
to
do
that
or
not.
B
E
Got
this
idea
of
profiles
which,
but
it's
what
I
was
hoping
with
with
this-
was
to
be
able
to
say
more
look.
You
know,
let's,
we
can
discuss
strategies
so
like
authentication,
right,
there's
different
strategies
that
are
going
to
make
sense
for
different
clusters
for
a
lot
of
people,
it
might
make
sense
to
say,
don't
give
people
direct
access
to
the
kubernetes
api.
That's
not
something.
E
B
Actually,
the
doc,
so
I
just
made
a
spreadsheet
and
it
basically
because
I
this
didn't
exist
and
essentially
what
it
was
is
like
you
know,
there
was
a
lot
of
things
to
secure
a
cluster
in
addition
to
the
kubernetes,
the
ci's
kubernetes
benchmarks,
and
I
feel
like
from
what
I've
seen
in
the
field
like
a
lot
of
the
people
that
want
to
use
those
that
it's
just
because
there's
really
nothing
else.
They
don't
really
know
any
better.
They're
like
what's
out
there
and
it's
like
well,
the
cds
has
kubernetes
but
benchmarks.
I'm
like.
B
Let's
do
that?
Not
that
not
that's
necessarily
bad.
I
mean
the
nist
and
all
those
other
things
are
basically
the
same
kind
of
similar
thing
where
it's
like.
Here's,
like
you
know,
people
like
lists
right,
it's
very
subjective,
objective
and
consumable.
So,
like
here's,
the
50
things
you
should
do
to
be
secure,
you
know
they
like
that.
It's
easy
for
them
to
consume,
but
you
know
what
I
what
I
was
trying
to
do
with
the
spreadsheet
I
put
together
is
basically
like
you
know.
B
Every
time
I
turn
around
there'd,
be
somebody
like
you
know
doing
another.
Kubernetes
security
talk
and
be
like
hey,
we
have
used,
you
know
like
ian
colbert
did
like
the
abusing
kubernetes
defaults
as
just
one
example
or
you
know,
there'd
be
talks
like
liz
rice
did
the
thing
at
kubecon,
where
she
like
abused
the
dns
that
was
built
in
on
layer
two
and
then
and
then
it'd
be
like
all
right.
Well,
openshift,
you
know
sorry
red
hat
like
does
all
these
things
by
default,
that,
like
upstream
kubernetes,
isn't
doing
so.
It's
like.
B
Let's
wrote
these
things
down,
and
that
was
really
the
spreadsheet
was
like
here's,
like
the
other
things
that
you
could
possibly
do
to
secure
kubernetes,
not
that
you
should
do
them,
but
here's
like
the
everything
else
that
I've
ever
seen-
and
I
just
spent
like
a
year
like
every
time,
I'd
see
something
that
was
not
already
existing
somewhere.
I
just
kind
of
put
into
the
spreadsheet.
So
it's
not
anything
consumable
yet
I
mean
it's
totally
risk-based
and
you
need
to
figure
out
what
makes
sense.
B
But
it's
like
it's
supposed
to
be
an
aggregate
of
everything
I
had
seen
from
you
know
all
the
kubernetes
hacker
talks,
or
you
know
somebody
put
out
like
if
stack,
rocks
or
google
put
out
like
a
blog
and
they're
like
hey.
We
just
solved
this
cbe
and
you
know
you
change
this
default
and
here's
another
security
practice
and,
and
things
like
you
know,
blocking
apis
access
or
things.
That
would
be
human
checks
that
you
can't
necessarily
script
against
those
types
of
things.
B
General
best
practices
and
other
things
that
we
do
at
red
hat
are
seen
other
places
other
security
guard
guides.
I
mean
I
basically
went
through
every
single
vendor's
security,
hardening
guide
and
just
put
an
aggregate
in
the
spreadsheet,
and
so
I
mean.
B
Sorry,
a
huge
piece
of
snow
dispel
behind
me,
so
it's
not
really
meant
to
be
a
it's
similar
to
the
kubernetes
cis
kubernetes
benchmarks,
in
the
sense
that
it's
not
necessarily
meant
to
be
like
you
have
to
do
this,
but
it's
like
a
an
aggregate
list
of
everything
else.
You
could
possibly
do
so
at
least
like
if
you
write
something
it's
a
good
starting
point
for
things
to
consider
and
but
not
necessarily,
you
would
need
to
put
all
those
into
a
document
form.
E
If
that
makes
sense
yeah,
I
know
that
sounds
cool
well,
there'll,
be
a
lot
of
a
lot
of
kind
of
good
material
that
can
be,
like
kind
of
you
know,
looked
at
and
say:
where
does
this
fit
or
does
it
fit
into
different
places?
So
that
really
awesome
to
have
as
a
reference
you've
got
more
smoother?
We
have.
We've
only
got
a
little
bit
snow.
B
B
E
So
I
I
guess
in
terms
of
the
hardware
guide,
the
question
I
had
is:
does
that
sound
like
something
that
that
makes
sense,
and
I
mean
I'm
happy
to
like
start
working
on
it-
I'm
kind
of
hopeful
I'm
going
to
have
more
time,
starting
in
march,
I'm
kind
of
pretty
hopeful.
I
should
have
some
more
time
to
like
focus
on
it
more
seriously.
E
I'd
also
if
anyone
had
any
ideas
of
other
other
approaches,
maybe
or
other
things
they'd
like
to
see
covered.
That
would
be
cool
as
well.
A
A
I
will
go
through
it
and
if
I
have
any
comments
I
will
add
and-
and
I
think
this
is
gonna
help
so
many
folks-
and
this
is
one
of
the
goals
that
why
we
have
this
project-
to
combine
and
consolidate
all
the
security
related
things
in
one
place
so
that
it
can
be
easily
updated
and
it
can
be
also
referenced
easily.
It's
not
all
over
the
place,
and
we
can
also
add
more
in-depth
examples.
A
If
we
want
in
the
main
documentation,
we
can
have
like
small
examples,
but
if
you
want
much
more
in-depth
various
other
examples-
and
this
is
a
place
that
we
could
have
them
and
link
them
and
that's
how
I
feel
so.
This
is
great
and
things
rory.
A
That's
wonderful.
Does
anyone
have
anything
to
add
to
the
hardening
guide?
Please
feel
free
to
take
a
look
whenever
you
have
time
and
if
you
have
any
comments
post
make
a
note.
I
think
it's
open
right.
It's
yeah
yeah.
C
Rory
yeah,
would
you
be
willing
to
open
this,
maybe
after
a
little
revision
of
the
google
doc
as
an
issue
and
against
case
website.
E
E
C
Okay,
have
a
look
at
the
issues
in
in,
in
that
repo
and
you'll
get
an
idea.
I
can
give
you
an
example
of
a
couple.
Actually,
in
fact,
did
I
put.
Did
I
put
one
in
the
dock?
Let
me
no,
I
didn't,
but
I
will.
I
will
put
some
example
issues
in
the
chat
that
I
think
are
relevant
awesome.
A
Hey
sounds
good
not
to
party
folks.
I
know
john
wanted
to
present
a
spreadsheet.
So
if,
if,
if
we
don't
have
anything
more
than
just
on
the
hardening
guide,
we
can
move
on
to
the
next
one.
B
As
well-
and
I
kind
of
just
given
my
blurb
on
it-
I'm
not
going
to
go
through
every
single
check.
This
spreadsheet
needs
to
be
cleaned
up
a
lot.
It
definitely
needs
to
be
normalized.
B
But
my
goal
of
this
was
to
find
everything
that
you
could
potentially
care
about
or
want
to
do
with
regards
to
security
outside
of
what
already
exists
in
the
cis,
kubernetes
benchmarks
and
other
common
things
that
you've
seen.
So
some
of
them
might
look
duplicated
duplicative.
B
But
if
that's
the
case,
then
in
most
cases
I
wanted
to
kind
of
extend
or
kind
of
double
down
on
something
that
was
already
in
the
kubernetes
benchmarks.
But
I
started
this
for
for
some
of
the
air
force
effort
when
they
were
creating
the
upstream
for
what
they
were
doing
with.
If
you
saw
like
the
the
new
kubernetes
stig
that
just
came
out
so
the
upstream
of
that
it's
called
an
srg
security
readiness
guide,
and
so
I'd
started
for
that.
Putting
this
together
for
the
air
force
for
that.
B
But
it
kind
of
just
like
this
was
over
a
year
ago
and
then
I
kind
of
just
extended
it
to
basically
finding
everything
about
security
for
kubernetes
you
possibly
care
about
through
reading
hardening
guides,
going
through
all
of
the
things
that
red
hat
does
to
open
shift
to
see
what
we
could
do
to
apply
that
to
upstream
kubernetes
anybody
that
did
a
hacker
talk
or
anything
like
that
where
something
was
abused
by
default,
or
you
know
some
other
thing
outside
the
system,
like
you
know,
blocking
direct
access
to
the
nodes
or
anything
else.
B
That
would
just
be
a
good
idea,
like
anything.
That
would
be
a
good
idea
for
security.
I
kind
of
put
it
in
this
document,
so
it
right
now,
there's
94
rows
in
here.
I'm
not
arguing
that
anybody
should
do
all
these
things,
but
these
are
things
that
you
should
consider
outside
of
what
I've
seen
documented
already.
So
it
almost
it's
almost
like
an
extension.
B
You
can
almost
think
about
like
an
extension
of
the
cis
cabernet's
benchmarks
and
the
reason
why
I
joined
six
security
and
to
was
just
kind
of
share
the
work.
I
don't
even
know.
I
didn't
really
have
a
concept
of
how
everyone
would
use
this.
I
just
figured.
I
know
that
would
had
been
asked
before
and
I'd
seen.
B
Other
people
from
the
kubernetes
security
team
last
year
publicly
say
that
there
was
nothing
like
this
that
existed
so,
since
I
put
it
together,
I
just
wanted
to
share
it
and
see
if
it's
helpful,
but
I
honestly
didn't
have
a
great
idea
of
how
it
would
be
used
or
what
it
would
look
like.
I
just
since
I
put
so
much
effort
into
aggregating
all
these
things
together.
B
I
just
wanted
to
share
it
and
maybe
get
your
thoughts
if,
if
it's
helpful
and
and
maybe
how
I
could
help
put
this
clean
this
up
and
do
something
with
it,
but
maybe
if
it
is
something
that
goes
into
like
the
kubernetes
hardening
guide,
you
know
that
would
be
good
but
and
I'm
still
I'm
still
adding
stuff
to
it.
B
So
I
think,
like
the
the
bottom
one
like
I
just
saw
on
twitter,
like,
for
instance,
like
a
month
ago,
someone
was
saying
that
if
you
run
a
static
pod
and
you
give
it
a
made
up
service
account
name
that
it
will
still
run,
but
it
won't
show
up
as
a
mirrored
pod
in
the
api
server,
and
so
I
wrote
that
down.
So
that
was
just
it's.
You
know
things
like
that
where
it's
like.
I
see
something
really
interesting,
that
someone
might
care
about,
I'm
still
adding
to
it.
B
So
it's
definitely
not
a
static
document
by
any
means,
but
I
don't
know
if,
if
would
love
to
get
your
feedback,
if
you
think
this
is
helpful,
you
can
ignore
some
of
the
columns
like
if
I
put
red
hat
there,
it's
just
because
this
that
was
the
format
that
the
air
force
originally
wanted,
but
yeah.
So.
E
I
think,
from
my
perspective,
this
sort
of
thing
is
really
useful,
because
this
is
the
kind
of
thing
when
you're
doing
another
document
or
you're
writing
a
hardening
out
or
something
like
that.
You
can
go
through
here
and
go.
What
am
I
forgetting,
because
it's
really
impossible
to
remember
all
the
areas
and
something
like
this
is
great,
because
you
can
say:
hey
I've
forgotten
to
talk
about
this
and
it's
kind
of
like
our
things,
to
think
about
this
sort
of
stuff's
really
useful
or
are
I
find
it
useful
anyway?.
D
Yeah,
if
I
could
put
my
two
cents
in
I
I
think
just
looking
at
it
there's
the
mandatory
and
there
was
a
different
category
yeah
and
for
opens
or
for
like
sharing
it
out
to
other
organizations.
D
B
B
B
I
mean
everything
is
about
your
own
risk
assessment
that
you
do
rates,
that's
true
yeah,
so,
but
the
ones
that
I
put
mandatory
was
like.
Okay,
somebody
could
totally
you
know
who
borrow
your
cluster?
If
you
don't
do
this.
B
So
yeah,
that's
it
I
mean
for
for
you
all
in
kubernetes
security
is
there.
I
know
you
have
like
a
seat,
we're
doing
that.
Karting
guide
now
and
there's
secure
cluster
guide
is.
Is
there
any
place
like?
B
Should
I
put
this
in
a
git
repo
in
like
markdown
format,
or
something
like
that
or
is
there
any?
Is
there
any
way
this
be
cleaned
up
that
you
would?
I
guess
want
this
as
somewhere.
C
So,
from
a
documentation
point
of
view,
that's
not
the
right.
The
the
kubernetes
documentation
is
not
the
right
place
for
that
document,
but
something
like
an
awesome
kubernetes
page.
You
know
what
I
mean
like
an
awesome
x,
page
cleaning
that
up
and
probably
making
it
into
like
a
simple
github
page,
or
you
know
your
your
your
cdn
of
choice,
basically
and
then
putting
an
awesome
kubernetes
list
great
we're
a
bit
more
we're
quite
strict
on
on
the
kubernetes
documentation.
C
B
Yeah-
and
that
was
just
honestly
laziness
on
my
part
where
it
was
like,
and
I
would
totally
wouldn't
expect
to
look
to
like
open
shift.
You
were
putting
kubernetes
docs,
but
it
was
just
like
hey.
B
You
know
red
hat
to
this,
and
you
should
consider
doing
it
too
and
like
here's,
where
we
already
documented
a
type
of
thing
and
then
like
in
the
and
that'd,
be
part
of
a
clean
up,
and
you
know
this
makes
more
sense-
external,
it
totally
makes
sense
too
but
like
and
then
the
last
column
is
like,
where
I
found
it
so
like
if
I
found
it
on
you
know
whatever
vendor,
I
found
it
on
or
whoever
blogged
about
this.
B
Like
I
just
put
there,
you
know
I
try
to
reference
that
in
there,
so
there's
yeah,
there's
all
sorts
of
external,
not
just
red
hat
but
external
stuff,
and
that
that
last
column,
j,
external
resources
type
of
thing.
But
you
know
there's
nothing
that
in
the
like,
at
least
as
far
as
red
hat,
like
linking
back
to
any
red
hat,
docs
was
more
just
laziness.
When
I
put
together
this
spreadsheet
of
like
hey,
I
don't
want
to
copy
and
paste
this.
I'm
just
gonna
put
in
the
link
type
of
thing.
B
A
So,
are
you
applying
to
actively
maintain
this
so
that
that
is
my
one
question
like
it
could
be
outdated
or
it
could
be
like
there
could
be
more
and
more
new
things
coming
up.
So
are
you
looking
from
the
community
that
everyone
participates
or
it's
it's
gonna,
be
like
so
you're
gonna,
take
this
whole
ownership
and
maintain
this
like.
B
I
mean
my
intention
now
is
to
keep
it
up
to
date.
I'm
definitely
still
adding
to
it.
When
I
see
new
things
and
you
know
really.
However,
it's
helpful
if
it's
helpful
to
more
than
one
person,
then
yeah,
then
you
know
if
they
wanted,
people
want
to
contribute,
or
you
know
whatever.
I
honestly
didn't,
really
have
any
plans
for
it
other
than
just
to
see
how
I
could
could
help.
If
that
makes
sense,
I
don't
really
have
like
an
agenda
to
promote
red
hat
or
anything
like
that.
I
just
wanted
to.
A
B
I
mean
I'm
definitely
maintaining
it,
but
obviously
like
it
like
I'm
adding
to
it,
but
yeah,
I'm
not
always
like
cleaning
it
up
or
you
know
it's
it's
it's
like
a
best
effort
maintenance.
I
guess,
but
I
am
definitely
still
you
know,
keeping
it
active
so.
B
Yeah
yeah
no,
but
I
didn't
know
if
there'd
be
any
take
away
or
or
anything,
and
if
that's
fine,
that
works
too,
but
yeah
I
just
wanted
to
to
share
it
because
I
have
it
and
that's
really
all
there
is
so.
A
Thank
you.
Does
anyone
have
anything
to
add
to
it.
A
Thank
you
yeah
I've
already
bookmarked
that,
because
I
thought
the
list
is
so
good
and
I
bookmarked
for
my
personal
reading
so.
A
And
we
have
one
more
item
and
it's
from
tim,
so
I'm
just
gonna
do
a
mind.
Giving
couple
like
briefly
sure.
C
We're
the
sick,
contrabax
is
leading
on
or
contributor.com
is
leading
on
a
blog
article
to
announce
the
official
deprecation
of
pod
security
policy,
which
will
be
part
of
the
next
release.
V
1.21,
it's
obviously
related
to
security,
and
so
I'm
putting
I've
put
it
on.
The
agenda
should
have
done
that
earlier.
C
To
give
this
group
a
chance
to
essentially,
you
know,
have
a
look
over
that
people
from
security
have
already
commented.
People
sig
author
already
commented,
but
I
think
with
this
sort
of
thing,
you
cannot
have
in
a
sense
too
much
checking
before
stuff
goes
out.
C
For
a
little
bit
of
context,
one
of
the
things
that
has
made
this
get
so
much
attention
within
the
kubernetes
contributors
is
that
we
didn't
handle
the
deprecation
of
a
different
thing
very
well
so
docker
shim,
which
is
a
bit
of
code
to
glue
kubernetes
kubelet
to
docker.
We
deprecated
that
and
a
lot
of
people
thought
we
were
saying
you
can't
use
docker
or
you
can't
use
docker
as
a
container
runtime,
neither
of
which
is
true,
but
we
want
to
make
sure
we
don't
do
the
same
thing
again.
C
So
I
mean
that's
a
pull
request,
so
you
can
follow
the
preview
link
and
see
the
preview
of
the
code
as
it
stands.
And
if
you
know
the
feedback
can
be
you've
misspelled.
The
you
know
to
anything
up
to
like
this
is
completely
wrong
and
we
sh
and
we
know
what
whatever.
C
C
F
There's
a
few
things,
I
guess
of
course,
I
totally
agree
with
you
how
pod
security
policy
is.
We
should
be
on
top
of
comms
on
this.
One
yeah
just
had
some
chats
with
someone
with
one
of
the
six.
F
F
E
I
think
it
is
challenging
timing,
because
we
we,
I
decided
to
consult
your
own
kubernetes
and
what's
happening
with
pod
security
policy,
and
should
we
all
run
to
oppa
or
anything
else,
is
a
conversation
that
I've
had
more
than
once
so
you're
right,
yeah
that
the
challenges
when
this
blog
post
goes
out.
It
will
because,
unsurprisingly,
the
people
who
make
oppa
and
kyberno
will
obviously
you
know
kind
of
time
into
that,
because
that's
something
this
is
where
they
kept
their
coming
in
so
yeah.
E
C
Yeah,
it
is
tricky
to
clarify.
You
know,
I
think
ready
means
that
you
know
kubernetes
could
say
we
commit
to
having
this
api
ready
in,
say
the
1.24
release
and
it
will
be.
You
know
we
we
commit
to
having
it
beta,
because
what
security
bullet
is
beta,
so
it
doesn't
have
to
graduate
to
stable.
C
But
if
we
say
look
for
example
in
1.24,
new
api
goes
beta
and
we
commit
to
that.
We've
got
a
design
and
we're
going
to
make
it
happen,
which
that
is
a
big
statement
for
community
kubernetes
to
make
that
that'll
happen,
but
that
could
be
a
commitment
that
that
we
find
that
you
know
that
the
community
makes,
I
think,
that's
the
kind
of
thing
that
could
happen,
but
otherwise
it
will
be.
C
Yes,
there
is
also
an
ecosystem
and
take
it
out
of
kubernetes
itself
and
say
you
need
to
use
third-party
software
to
secure
a
cluster.
That's
the
message:
I'm
a
bit
wary
about
saying.
To
be
honest,
you
know
yeah.
E
It's
a
tricky
one
because
essentially
it's
mandating
you're
gonna
have
to
have
third-party
software,
which
I
suppose
look.
It
can
already
happen.
You've
got
cni,
obviously
in
cri,
so
to
extend
that
happens,
but
it's
not
quite
the
same.
B
Have
you
thought
about
this
might
be
an
awful
idea,
so
just
laugh
at
me,
but
has
it
been
talked
about?
B
Like
you
know,
pod
security
policies
obviously
does
the
very
small
subset
of
like
what
a
notebook
could
do,
which
is
theoretically
boundless
right
and
so
have
you
thought
about
like
saying,
hey
you
can
use
third
party
software
like
opa
or
kyberno
or
whatever
or
like
here,
is
some
javascript
based
admission
controllers
that
basically
do
what
pod
security
policies
do
and
they'll
check
your
pod
spec
to
make
sure
that
you
don't
run
privileged
or
something
like
that,
and
if
you
want
to
use
these
here,
they
are
in
the
git
repo
or
something
else
that
people
could
do
kind
of
simple
that
they
could
do
by
themselves.
C
I'm
I
know
that
people
on
the
sig
security
side
and
also
sigourth
are
looking
hard
at
a
few
different
options
for
in-project
in-cluster
things
that
that
solve
the
problem
that
that
pod
security
policy
does,
and
I
guess
what
that
comes
down
to
is
like
defining
what
problem
you
think
that
is,
and
then
okay
also
presenting
a
solution.
C
It's
a
challenge,
because,
according
to
sort
of
the
rules,
pod
security
policy
does
need
to
be
deprecated.
We
we've
brought
in
some
rules
to
to
end
perma-beta.
C
B
Yeah,
and
I
think
the
challenge
is
like
you
know,
there's
a
lot
of
teams
that
need
something
like
those
third-party
tools
but
they're,
also
like
the
cognitive
overhead
of
adopting
something
like
oppo,
is
a
lot
higher
than
just
like
implementing
a
pod
security
policy.
So
it'd
be
nice
to
have
something
simple.
That's
like
hey!
You
just
have
this
simple
use
case
here
you
go
and
if
you
have
you're
trying
to
run
like
a
big
multi-tenant
cluster
with
a
bunch
of
enterprise
policies,
then
do
oppa
or
something
else,
but.
C
I
have
an
idea:
is
there
anyone
on
this
call
who
feels
I
actually
do
security
cloud
native
security
for
a
living
or
you
know,
have
a
big
interest
in
it
and
I
could
write
a
follow-up
blog
article.
I
know
enough
about
this:
to
communicate
with
authority
to
the
world
and,
like
the
blog
article,
that
you
see
there
in
that,
pull
request
can
go
out
and
I
will
make
a
follow-up
that
dovetails
into
it.
C
E
C
It's
a
blog
article,
so
yeah
if
you've,
if
you've
got
a
perspective
on
that
that
you
want
to
to
put
forward
and
there's
a
few
options
like
essentially
speak
up,
and
I
can
probably
rally
people
to
help
you
possibly
me.
You
know
even
if
you've
never
blogged
before,
but
you've
got
a
perspective
to
say
and
I'm
not
going
to
say
what
that
perspective
should
be
it's.
It
can
be
crappy
fit
to
be
your
personal
perspective
or
your
corporate
perspective.
E
I
blog
about
container
security
for
quite
a
lot.
I'd
be
happy
to
at
least
talk
about
it
because
I've
been,
I
talked
to
quite
a
lot
of
customers
about
security
policies
and
other
things
similar
and
I've
seen
some
of
the
challenges
they
have
even
with
pod
security
policies.
E
So
I'm
happy
to
to
work
on
that
with
you
rory.
If
you
want
yeah
yeah.
B
E
I
I
definitely
oh
yeah.
Absolutely
I
don't
want
to
because
yeah
more
eyes
on
this
one
would
be
better
rather
than
at
the
gala
yeah.
B
I
think
that's
the
thing
it's
like
you
know.
We
live
in
this
space,
this
kubernetes
space
and
stuff,
and
I
think
that's
probably
what
happened
with
the
docker
stuff
is
like
yeah.
If
you
were,
if
you
work
in
kubernetes
all
the
time,
you've
known
that,
like
docker
itself,
refactored
like
three
years
ago,
right
with
container
d
and
all
that
stuff,
but
you
know,
then
you
go
in
the
enterprise
and
somebody,
you
know
still
has
a
misunderstanding.
B
What
a
container
image
is
versus
a
host
os
right,
like
there's
a
huge
gap
between
the
end
user
a
lot
of
times
and
and
you
know,
people
that
attend
six
and
so,
but
since
I'm
in
the
field,
I
see
that
so
I'm
happy
to
participate.
A
Sorry
did
I
miss
anyone
other
than
john
rory
and
tim
wanted.
A
A
A
All
right,
we
are
well
over
time.
We
had
a
great
discussion
today,
please
feel
free
to
follow
up
on
the
slack
thread.
A
We
can
open
a
slack
thread
for
it
or
we
can
pick
it
up
next
week
and
I
have
captured
the
notes,
the
best
that
I
could
do
so
if
there
is
anything
missing
or
you
want
to
add
anything,
please
feel
free
to
add
it
edit
it
and
that's
all
from
me,
thank
you,
everyone
and
it's
good
to
see
you
all
take
care,
stay
safe
and
until
you
meet
in
two
weeks
and
and
seek
security
in
one
week.
So
yes,
until
we
meet
again.