►
From YouTube: PodSecurityPolicy Replacement: Past, Present, and Future - Tabitha Sable & Tim Allclair
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
PodSecurityPolicy Replacement: Past, Present, and Future - Tabitha Sable, Datadog & Tim Allclair, Apple
Join two of the maintainers leading the PSP replacement effort for a welcoming, accessible discussion of PodSecurityPolicy and its built-in replacement, Pod Security Admission Control. They’ll cover how to tell whether PSP deprecation affects you, the meaning of deprecation in Kubernetes, and steps you can take today to ease your eventual transition off of PSP. You’ll hear guidelines for considering the new Pod Security Admission Control, learn how to try it out yourself, and even enjoy a little bit of Kubernetes storytelling.
A
Hi
I'm
tabitha
sable.
Unfortunately,
tim
was
not
able
to
make
it,
but
his
his
contribution
will
be
here.
He'll
be
he'll,
be
here
with
us
by
video
in
a
moment,
so
I
want
to
start
by
showing
you
one
of
my
favorite
tweets,
which
is
this
tweet,
and
the
thing
that
I
love
so
much
about
this
tweet
is
on
one
hand
it's
like
a
big
pile
of
line
noise.
A
A
B
A
A
And
the
answer
to
that
is
that
I
can
put
this
label
over
here
onto
this
onto
this
thing
and
I
am
changing
things.
This
is
also
bad
all
right,
we
are
just
going
to
get
away
from
that
completely.
The
point
is
that
without
admission
control,
bad
things
are
going
to
happen,
and
so
therefore
we
want
to
have
admission
control.
A
And
so
I'll
clean
up
my
windows
here
for
you
so
yeah
we
want
to
have
admission
control,
we
don't
have
admission
control,
bad
things
are
going
to
happen,
and
so
now
we
actually
have
admission
control.
I
can
label
a
namespace
and
it
will
block
me
from
being
able
to
create
that
pod,
so
yeah.
Thank
you
so
much
for
for
joining
me
here,
virtually
or
in
person
for
pod
security
policy
replacement,
past
present
and
future.
A
Like
I
said,
yeah
tim
wasn't
able
to
join
us
physically,
but
he'll
be
here
with
us
virtually
in
a
couple
of
minutes.
He
and
I
have
prepared
the
session
to
show
how
we
came
together
as
a
community
to
make
the
demo
that
you
couldn't
see
because
it
was
hidden
from
may
happen.
So
we'll
start
with
the
problem
that
we're
trying
to
solve
like
what?
What
does
this
even
mean?
A
Why
do
we
need
an
emission
controller
and
the
easiest
way
to
describe
that
is
because
without
an
admission
controller
kubernetes
is
a
system
administration
tool,
everybody
who
can
use
it
as
a
system
administrator,
which
means
everybody
who
can
create
a
pub,
is
rude
on
every
note.
In
the
cluster,
and
if
that's
what
you
want-
you're
perfect
out
of
the
box,
everything
is
golden,
but
that's
not
really
the
way
that
we
think
about
kubernetes.
A
If
we
think
about
kubernetes
as
being
for
scaling,
workloads
and
and
things
we,
we
tend
to
think
in
terms
of
the
pods
and
like
we
want
to
imagine
that
the
nodes
are
just
a
fungible
resource
and
having
everybody
be
able
to
do
whatever
they
want
to
them,
really
breaks
down
that
understanding.
So
if
you
don't
want
root
on
every
node
to
be
the
same
thing
as
creating
a
pub,
then
you
need
to
create.
A
You
know
we
want
to
be
able
to
encourage
deployment
best
practices
and
to
say
encourage
in
this
context,
is,
is
a
little
is
a
little
heavy-handed,
because
what
we
really
mean
is
block
non-conformant
things
from
being
deployed.
But
if
you're
doing
this
in
a
way
that
is
caring
to
the
users,
you
make
some
accessible
way
for
them
to
ask
for
the
exceptions
that
they
need,
and
so
in
that
sense
it
is
encouraging
best
practices,
because
if
you
don't
file
an
exception,
you
have
to
follow
the
rules.
A
A
So
if
we
trust
everybody
nobody's
ever
going
to
do
anything
bad,
then
we
just
make
everybody
cluster
admin
and
it'll
be
fine,
because
nobody
does
anything
mean.
We
just
presume
that
everybody
is
going
to
be
trustworthy
and,
like
maybe
actually
I
trust
all
of
my
teammates
that
much,
but
I
don't
trust
the
person
who
just
fished
one
of
my
teammates,
that
much
and
so
like
as
a
system
administrator
like
I've,
been
a
system
administrator
since
the
earth
cooled.
A
It's
always
a
good
feeling
to
actually
get
some
keys
off
of
the
keyring
and
and
make
it
so
that
I'm
not
as
worried
that
I
can
do
things
that
I
shouldn't
be
able
to
or
someone
who
has
adopted.
My
account
can
do
things
that
they
shouldn't
be
able
to
and
that's
another
that's
another
thing
that
you
can
get
out
of
admission
control
and
then
you
know
another
really.
A
So
this
is
these
are
the
sorts
of
things
and
there's
a
lot
of
good
options
for
admission
controllers.
Now,
like
you
can
write
your
own.
If
you
really
want
to
there
is
you
know,
the
gatekeeper
is
well
known.
Caverno
is
well
known.
There
are
some
other
open
source
ones
that
are
a
little
bit
less
well
known
and
pot
security
policy
was
sort
of
the
earliest
one
that
really
had
a
lot
of
of
weight
behind
it.
You
know
it's
built
in,
but
psp
is
deprecated
now
and
it's
not
going
to
be
around
forever.
A
It
had
plenty
of
challenges,
but
like
now
it
will
eventually
just
go
away
and
that's
a
real
challenge.
So
if
you
didn't
adopt
psp
but
you're
here
because
you're
thinking
about
it,
because
it
was
quite
a
newsworthy
event,
let
the
fact
that
everybody
is
thinking
about
psp
be
an
opportunity
to
think
about.
Well,
maybe
I
can
deploy
admission
control
and
if
you
did
adopt
psp,
you
need
to
be
planning
your
move
off
in
either
case.
B
And
the
way
we
do,
that
is
through
a
minimal
configuration
where
the
user
chooses
one
of
three
profiles
per
namespace.
Those
profiles
are
privileged,
meaning
that
anything
goes
anything
is
allowed.
It's
the
equivalent
of
not
enabling
the
admission
controller
on
that
namespace
baseline,
which
allows
the
default
pod
settings
but
doesn't
allow
you
to
escalate
privileges
beyond
that
and
restricted,
which
enforces
various
security.
Best
practices
such
as
running
as
non-root.
B
B
B
B
A
B
B
B
B
B
B
This
is
actually
the
sort
of
implied
version.
If
there's
no
version
pin
label,
but
I'm
just
making
that
explicit
here
now,
if
we
create
our
restricted
pod,
the
pod
is
created,
but
we
still
get
that
warning
saying
that
this
would
violate
the
latest
version
of
the
restricted
profile
would,
since
it's
not
actually
being
enforced
right
now,.
B
B
Now
this
time
I've
left
the
pod
running
and
let's
take
a
look
at
what
happens
if
I
update
that
enforce
version
to
latest
now,
except
this
time,
I'm
going
to
set
the
dry
run
command
to
the
server
side,
dry
run,
and
if
I
go
ahead
and
do
that,
we
see
we
get
a
warning
that
the
restricted
pod,
this
would
be
all
pods
running
in
the
name.
Space
actually
violates
the
the
new
version
of
enforce.
B
B
A
A
So
let's
talk
a
little
bit
about
the
history
and
the
story
of
psp,
so
it
kind
of
evolved
out
of
the
security
constraints
that
were
in
openshift
from
very
early
days
and
pod
security
policy
was
added
as
an
admission
controller
in
beta
in
kubernetes
1.3.
This
was
like
this
was
before
our
back
was
a
default.
The
default
service
account
was
cluster.
Admin
like
this
was
wild
west
days
and
it
evolved
really
rapidly
over
time.
So
by
1.6
the
resources
to
create
pot
security
policies
were
available
in
the
api
server.
A
Those
feature
editions
couldn't
really
make
up
for
the
fundamental
struggles
that
adopting
pod
security
policy
had
I'll
briefly
wave
my
hands
at
them,
like
the
fact
that
you
must
create
this
policies
before
turning
on
the
admission
controller
because
it
hard
fails
closed,
and
so,
if
you
simply
turn
on
the
admission
controller,
your
cluster
is
immediately.
Broken
has
been
difficult
to
to
deal
with,
and
you
know,
there's
there's
a
lot
of
other
sharp
edges
for
more
details
about
this.
A
There
is
a
there
is
a
sig
off
talk
from
several
kubecons
ago:
that's
linked
from
the
psp
deprecation,
blog
post
and
in
a
little
while
I
don't
know
if
it's
the
next
session
or
a
couple
of
sessions
down
sig
off,
has
a
maintainer
track
session,
where
they
will
get
into
a
lot
more
detail
about
like
what
those
psp
challenges
were.
But
the
challenges
were
there
and
so
discussions
about
how
to
replace
psp
started
around
116
and
those
discussions
were
not
able
to
progress
rapidly.
A
So
we
got
to
the
point
eventually
where
other
kubernetes
administrative
changes
made
it
extremely
likely
that
psp
was
going
to
be
deprecated
so
like
what
even
is
kubernetes
deprecation,
it's
the
first
step
towards
having
a
feature
go
away,
and
it's
just
a
notice
like
it's
a
promise.
We
are
going
to
continue
to
support
the
feature
for
a
certain
amount
of
time,
but
you
need
to
be
aware
that
it
will
not
be
around
forever,
and
that
is
what
is
currently
happening
with
psp.
A
A
One
way,
if
you
can
inspect
the
command
line,
arguments
that
are
being
passed
to
your
cube
api
server,
you
can
look
for
pod
security
policy
in
the
enable
admission,
plugins
command
line
option.
If
you
only
have
kubernetes
cluster
access
k,
get
ps
kubernete,
you
know,
kub
ctl
get
psp
will
probably
tell
you
if
you're
using
psps,
because
certainly
there
must
be
some
psps
defined
in
your
cluster
or
it
would
be
broken.
A
A
So
if
you
are
using
psp,
it's
going
away,
you're
going
to
need
to
replace
it
with
something
and
because
psp
was
such
a
flexible
feature
that
could
really
be
used
in
a
lot
of
different
ways,
some
of
which
were
quite
straightforward,
some
of
which
were
quite
clever,
some
of
which
were
too
clever
you.
You
can't
simply
replace
it.
Nothing
could
just
replace
psp
except
psp,
but
you
can
think
about
what
are
we
trying
to
get
out
of
psp
like
it
has
mutation
features?
A
It
can
default
certain
pod
settings
to
newer
more
hardened
settings
than
what
the
kubernetes
defaults
are.
Is
that
what
you're
using
psp
for?
Are
you
using
it
to
exert
really
fine-grained
control
over
pods
in
different
name
spaces
like,
for
example,
if
you
are
running
a
cni
plug-in
that
requires
capnet
admin
and
hostnet
on
its
daemon
set?
Have
you
made
a
namespace
for
that
made
a
psp
that
allows
only
those
features
and
enabled
that
psp
to
be
used
in
that
namespace?
A
A
So
once
you
once
you
know
what
you
want
to
get
out
of
psp,
then
you
can
start
to
examine
the
alternatives
that
you
could
use
to
replace
it.
If
pod
security
admission
covers
your
needs,
you
can
walk
through
the
documentation
and
have
some
guidance
on
how
to
migrate
to
it.
If
you
are
using
advanced
use,
cases
that
are
beyond
what
pod
security
admission
can
do,
then
the
various
cncf
open
source
alternatives
like
gatekeeper
or
caverno.
A
I
haven't
actually
read
all
of
those
docs,
but
I
have
glanced
through
them
and
I'm
pretty
confident
that
all
of
them
have
some
documentation
about
how
to
switch
from
psp
to
them.
But
whatever
whatever
you
choose,
the
key
is
to
make
sure
that
you
are
choosing
something
with
intention
that
will
serve
the
needs
that
you
have.
A
A
C
A
And
now
it's
implemented
so
the
details,
the
details
about
that
they
look
like.
First,
the
sigoth
leaders
started
asking
about
the
future
of
psp.
They
tried
a
few
times
to
get
a
design
process
going,
but
it
just
wasn't
happening
and
then
in
late
2020
there
was
a
new
policy
to
get
rid
of.
Perma-Beta
features
can
only
remain
in
beta
for
a
certain
amount
of
time,
and
then
they
have
to
graduate
or
be
deprecated
and
tim
rallied
sigoth
again
to
find
a
solution.
A
He
wrote
an
outline
doc
with
background
and
options,
put
a
discussion
topic
on
the
sig
off
meeting
and
a
show
people
showed
up.
We
had
like
a
couple
dozen
people
in
that
meeting.
We
had
a
great
discussion
and
the
discussion
didn't
really
get
us
any
closer
to
an
answer.
It
was
very
similar
to
the
previous
discussions,
and
so
my
security
co-chair
and
I
ian
we
we
said
well,
we
will
write
a
proposal
that
will
stop
this
churn,
like
that's
gonna,
be
easy
right.
A
No,
no,
of
course
that
wasn't
easy,
but
like
we
we
said
that
we
would
do
it
and
and
then
we
were
then
we
were.
Then
we
we
have
to
keep
our
promises,
and
so
the
the
idea
was
that
if
the
proposal
was
specific
enough
that
we
could
start
asking
what,
if
we
adopted
this
or
like,
why
can't
we
adopt
this
kinds
of
questions
and
when
we
bootstrapped
that
it
was
based
on
our
experiences
as
end
users,
you
know.
C
A
Both
run
kubernetes
in
production
in
several
places
and
really
have
felt
the
pain,
and
so
we
we
put
our
end
user
feelings
into
this,
and
we
had
advantages.
The
situation
had
gotten
a
lot
better
since
the
earlier
meetings.
You
know
now
there's
a
bunch
of
third-party
admission
controller
choices
that
are
really
good,
so
we
don't
have
to
solve
everybody's
possible
use
case
in
the
way
that
psp
had
to
be
everything
to
everybody.
A
And
now
we
have
the
pod
security
standards
document,
which
gives
some
good
guidance
on
places
that
you
can
think
of
stopping
along
your
pod
setting
hardening
journey.
So
there's
some
there's
some
guidance
there
from
that,
and
everybody
agreed
that
kubernetes
needed
to
have
some
kind
of
built-in
option.
We.
A
So
as
ian
and
I
were
working
on
this
proposal
for
a
psp-like
feature
that
was
fairly
complex
had
a
lot
of
flexibility
in
it,
but
had
rounded
off
the
the
really
sharp
edges
that
would
cut
you
on
psp,
tim
and
others
were
also
writing
a
very
specific
proposal
for
an
extremely
simplified
feature.
It
was
almost
binary.
A
particular
namespace
could
allow
everything
or
allow
something
that
was
quite
restrictive
and
we
coordinated
the
release
of
these
two
competing
basic
proposals
so
that
neither
one
of
them
would
get
an
unfair
advantage.
Due
to
timing.
A
I
brought
back
to
the
sig
security
meeting
how
it
was
progressing.
I
think
tim
brought
back
to
the
sig
off
meeting
how
it
was
progressing
and,
over
the
course
of
a
few
meetings.
This
ad
hoc
group
really
sharpened
both
proposals.
We
just
focused
in
more
and
more
on.
What
could
we
agree
with
we
built
group
consensus
and,
as
our
goals
and
values
became
more
clear
from
the
kinds
of
discussions
we
were
having
about
both
proposals.
A
A
You
know
it
had
it
had
this
very
holistic
design
where
user
needs
came
first,
that
means
how
to
maintain
it
is
considered,
and
the
fact
that
there
are
other
options
was
considered.
Like
we
were
able
to
simplify,
because
we
knew
that
if
somebody's
needs
were
beyond
what
we
could
do,
that
they
had
other
choices,
and
so
these
are
really
the
lessons
that
we
learned
from
that
that
big
decisions
have
a
life
cycle,
and
you
need
to
respect
that
life
cycle
that
when
you
see
a
problem,
it
may
seem
obvious
to
you
what
the
problem
is.
A
But
there
are
plenty
of
other
smart
and
caring
people
in
the
kubernetes
community
who
also
think
the
problem
seems
obvious
to
them,
and
you
don't
all
agree
on
what
that
is,
and
you
need
to
come
to
a
shared
understanding
of
what
that
of
what
that
problem
is
and
how
to
solve
it.
And
a
cap
review
is
a
really
hard
place
to
talk
about
your
feelings.
A
So,
like
I
like
to
joke,
when
I'm
trying
to
solve
an
engineering
deadlock
problem,
we're
going
to
get
all
of
the
people
who
know
what
they
want,
but
don't
know
what
they
want
into
a
room
and
we'll
talk
about
our
feelings
and
we'll
figure
it
out.
But
like
the
reason
that
I
love
that
joke
is
like
it
kind
of
disarms
people,
they
laugh
a
little
bit,
but
the
real
truth
is.
We
actually
are
talking
about
our
feelings.
A
If
the
technical
decisions
were
obvious,
we
wouldn't
have
to
have
a
meeting
about
them.
We
wouldn't
have
to
have
a
discussion
about
them,
and
so
big
technical
decisions
do
involve
our
feelings
and
so
therefore
exploring
big
questions
together
in
a
more
form,
more
informal
setting
like
meetings,
slacks,
google,
docs,
building
consensus
that
way
around
an
understanding
of
the
problem
and
understanding
of
a
good
potential
solution.
A
A
A
You
can
come
to
the
sigoth
kubernetes
slack
channel
or
come
to
the
sig
off
meeting
to
tell
us
how
that's
going
there
is
a
web
hook.
Implementation!
That's
in
progress,
you
can
look
in
the
issues,
I'm
sorry,
I
don't
have
a
link
for
it
and
there's
a
lot
of
room
to
improve
the
documentation,
especially
around
migration
from
psp
and
advanced
configuration
and
we'd
really
love
your
help
with
that.
So
thank
you.