►
From YouTube: Cloud Native Live: Examining Pod Security Admission
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).
B
Yeah,
perfect,
hey
everyone
welcome.
We
had
some
connect
connection
issues,
but
we
are
live
now,
quite
okay
on
schedule,
even
though
a
bit
late,
but
as
always
welcome
to
cloud
native
live
where
we
dive
into
the
code
behind
cloud
native,
I'm
annie
and
I'm
a
cncf
ambassador
as
well
as
a
senior
product
marketing
manager
at
camunda,
and
I
will
be
your
host
tonight.
B
C
Hi
there
sure
can
you
hear
us,
are
you?
Are
you
with
us?
Would
you
like
to
to
kick
things
off
or
should
I
go
ahead
and
kick
us
off
here.
C
All
right
I'll
take
that
as
a
as
a
yes
go
ahead
and
do
that
so
hi
folks.
My
name
is
chip
zoller,
I'm
joined
by
my
colleague,
zhao
we're
from
nirmata,
but
we're
also
caverno
maintainers
and
we're
here
to
talk
to
you
today
about
pod
security
admission,
a
really
cool
feature
that
ships
in
kubernetes
123
and
forward
how
that
works.
C
Some
things
to
be
aware
of
how
it
can
work
for
you
and
how
it
can
play
with
some
other
things
like
caverno
and
maybe
some
other
tools
that
are
out
there
so
join
us
as
we
kind
of
explore
this
really
interesting
topic
and
see
how
it
can
work
for
you.
So
the
first
thing
is
to
really
talk
about
like
what
is
pod
security
admission.
So
pod
security
admission.
C
How
are
currently
deprecated
and
they're
also
being
removed,
and
that's
a
very
important
point
removed
in
the
next
version,
and
so
pod
security
admission
is
a
way
for
you
to
provide
security
for
your
pods
by
enforcing
actions
against
them
warning
and
auditing
as
we'll
see
and
without
having
to
add
anything
else,
and
it
improves
in
a
lot
of
ways
on
the
pod
security
policies
that
were
in
use
prior
and
the.
C
But
the
the
super
nice
thing
about
pod
security
admission
is
it's
built
in,
and
there's
not
really
anything
that
you
have
to
do
to
get
started
as
long
as
you're,
using
one
of
the
compatible
versions
of
kubernetes
other
than
to
label
a
namespace
and
to
go,
and
so
some
of
the
things
that
we're
going
to
go
through
are
looking
at
what
psa
is
showing
psa
in
action.
C
Some
things
to
be
aware
of
that
that
are
some
of
which
are
in
the
docks,
some
of
which
are
are,
are
not
quite
that
visible,
but
things
to
be
aware
of
and
we're
gonna
do
you
know
demos
of
these
things
and
also
how
psa
can
work
with
something
like
caverno?
C
What
values
that
you
can
get
from
those
and
some
closing
points,
and
then
some
some
q,
a
and
so
so
shifting,
if
you're,
if
you're
back
with
us
and
and
you're
able
to
hear
us,
feel
free
to
feel
free
to
kick
us
off
and
and
just
launch
into
what
is
psa
and
then
showing
it
in
action.
B
See
what
we
see
the
stream
deck
now?
Okay,
awesome.
A
B
No,
the
floor
is
your
shooting.
You
can
go
ahead.
A
Right
so
before
we
dive
deep
into
into
the
demo,
I
just
want
to
set
up
some
contacts
for
this
session.
So
sorry,
I
just
lost
the
connection
for
a
minute.
You
know
a
little
bit.
C
Okay
seems
like
we're
having
some
connectivity
difficulties
here
with
shutting,
so
why
don't
I?
Why
don't
I
take
over
here
until
we
can
get
those
resolved
so
so
as
as
was
saying
so
pod
security
admission
is
built
in
and
is
the
replacement
for
psa.
C
C
Looks
like
we
are
so
in
in
psa.
What
happens?
Is
you
have
name
spaces
that
can
be
labeled
with
a
label
which
is
able
to
instruct
the
api
server?
What
type
of
behavior
we
want
to
have
happen,
and
so
in
psa
there
are
three
behaviors
that
we
can
get.
We
can
audit
a
result
or
a
resource,
which
means
the
resource
will
be
allowed,
but
it'll
show
up
in
an
audit
log.
We
can
warn
which
means
the
resource
will
be
allowed
to
be
created.
C
But
if
it's
in
violation
of
a
policy
and
I'll
speak
about
those
in
a
second,
then
it'll
just
show
a
response
back
to
the
user.
That
there's
a
problem,
but
it's
been
allowed
and
then
there's
an
enforce
enforced
means
that
a
violation
of
a
resource
that's
being
submitted
will
be
blocked.
Now
psa
is
a
technical
mechanism,
but
it
implements
what's
known
as
the
pod
security
standards
and
the
pod
security
standards
are
a
codified
way
or
a
mech,
a
a
set
of
guidelines
or
controls
that
tell
you
basically
what
pods
shouldn't
shouldn't
do.
C
So,
as
the
name
implies,
it's
four
pods
and
it
really
has
an
a
bearing
on
the
security
of
the
the
various
fields
in
it.
So,
for
example,
things
like
making
sure
that
you
do
not
run
as
root
making
sure
that
you
have
a
set
comp
profile.
That's
within
you
know
specified
parameters.
Pod
security
standards
are
just
a
way
to
describe
the
behavior
that
should
occur,
but
psa
is
a
mechanism.
C
It's
a
technology,
that's
built
in
now
to
the
api
server,
starting
with
kubernetes
140
123,
and
allows
the
pod
security
standards
to
be
enforced
and
without
anything
added
to
them.
So
if
we
take
a
look
at
some
of
the
name
spaces,
I've
got
here.
B
C
So
we'll
actually
get
to
that
in
just
a
little
bit
and
I'll
explain
kind
of
what
what
they
are
and
why
they're
or
why
they're
labeled
as
that
and
then
you
can
decide
whether
that
that
kind
of
makes
sense
or
not.
But
first
I
just
want
to
show
what
the
what
the
actual
pod
security
mechanism
looks
like
in
here.
C
So
a
good
pod
in
this
case
there's
no
other
fields
that
are
specified
and
then
the
baseline
of
the
pod
security
standards.
This
is
going
to
allow
to
be
passed
because
there
aren't
any
fields
in
this
that
violate
the
controls
of
that
baseline.
However,
the
next
level
up
is
the
restricted
profile
which
places
many
more
restrictions
on
the
the
fields
and
what
their
values
have
to
be,
and
in
which
case
this
may
not
necessarily
pass
the
restricted
one.
C
So
what
we're
showing
with
this
is:
we've
created
a
new
namespace
and
we
want
pod
security
admission
to
be
enabled
and
by
the
way,
it's
already
technically
enabled
in
the
api
server.
But
when
we
label
a
namespace,
we're
effectively
saying
hey,
go
into
action
and
do
something,
and
so
now
we've
declared
that
we
want
to
do
two
things.
One
we
want
to
enforce,
which
means
that
anything,
that's
in
violation
of
a
level
should
be
blocked
and
two
we
specify
the
level
as
the
baseline,
and
so
that's
what
we've
done
here.
C
C
So
now,
if
I
have
no,
it's
called
good
pod.
It
should
not
be
a
good
pod
anymore,
and
so
now
we
see
the
message
that
came
back
from
the
api
server
and
this
is
blocked
by
the
psa
controller
itself,
directly
error
when
creating
this
pod,
it's
forbidden
because
it
violates
the
pod
security
baseline
latest,
and
then
we
have
a
privileged
container.
That's
that's
being
requested
here,
so
privileged
equals.
True
and
privileged
is
required
to
be
false
in
the
baseline
profile.
C
C
So
one
of
the
other
nice
things
about
psa,
in
addition
to
just
simply
applying
a
label
and
go
is
you
can
apply
multiple
labels
to
and
namespace
and
get
a
union
behavior.
So
it's
not
just
an
either
or
type
thing,
but
we're
we're
only
enforcing
here.
But
let's
say
that
we
wanted
to
warrant
as
well,
and
so
I
could
simply
just
add
another
label
to
this
same
name,
space
and
rather
than
enforce.
C
Let's
do
warn
and-
and
I'm
actually
going
to
change
it
up
to
do
I'm
going
to
remove,
enforce
and
just
do
a
warrant
instead.
But
let
me
also
add
audit,
so
what
I'm
gonna
I'm
gonna
be
able
to
show
here
is
that
the
label,
the
namespace,
now
has
two
labels.
C
One
of
those
labels,
if
I
show
them
one
of
those
labels-
is
to
audit
at
the
baseline
and
the
other
label,
is
to
warn
at
the
baseline
and
so
rather
than
blocking
a
resource.
It's
doing
two
things
because
we're
getting
a
union
behavior
we're
saying,
allow
the
resource
to
be
created
if
it's
in
violation,
but
warn
the
user,
which
is
a
nice
capability
and
also
two.
C
We
want
that
to
be
shown
up
in
an
audit
log,
which
is
a
separate
entity
that
has
to
be
configured
in
advance
under
the
api
server,
which
unfortunately,
don't
have
time
really
to
show
that,
but
we
should
be
able
to
now
try
and
apply
the
same
resource
again.
This
is
still
in
violation,
and
we
saw
this
resource
blocked
just
a
minute
ago,
but
we
should
at
least
this
time
allow
this
resource
to
be
created,
and
we
are
not
able
to
do
that.
And
let's
see,
why
did
I
mess
up
here?
C
Okay,
well
take
my
word
that
the
the
warning
actually
works,
and
it
does
show
something
back.
So
so
that's
the
behavior
that
we
would
get,
and
so
that's
a
nice
thing
to
be
able
to
combine
in-force
behavior
with
other
behaviors,
including
warren
and
audit,
and
so
really
that's
as
simple
as
pod
security
admission.
Is
you
label
a
name
space
with
a
combination
of
the
profile
that
you
want,
the
behavior
that
you
want
and
optionally?
C
If
you
want
to
pin
things
to
a
specific
version
of
those
pod
security
standards,
because
remember
that
psa
implements
pss
and
nothing
more,
then
you'll
be
able
to
do
that
and
you
can
pin
it
to
a
specific
version.
C
So,
for
example,
let's
say
that
we're
on
1.24,
which
my
test
cluster
running
under
k3d
is,
but
when
you
upgrade,
you
want
to
be
able
to
pin
the
version
of
the
pod
security
standards
at
124
so
that
when
you
do
upgrade,
you
have
the
chance
to
to
gently
move
developers
and
other
users
to
what
the
new
standards
are.
C
By
continuing
with
to
do
things
like
enforce
the
version,
that's
pinned
at
124
and
giving
the
ability
to
do
things
like
warren
at
a
later
version,
so
it's
nice
in
that
you
know
you
can
you
can
prepare
developers
and
you
prepare
your
users
by
having
certain
behavior
enforced
on
a
name
space,
but
also
giving
them
the
opportunity
to
look
at
or
let
them
be
warned
about.
C
C
This
will
be
blocked
when
we
either
enable
this
on
this
namespace
for
the
restricted
profile
or
in
other
namespaces.
That
restricted
may
already
be
enforced.
It's
not
going
to
be
allowed,
so
that's
the
that's
the
capability
of
operating
at
the
namespace,
but
one
of
the
common
things
that
comes
up
is
well
hey.
You
know
that's
great,
but
I
really
want
this
to
apply
to
my
cluster
in
wholesale
fashion,
and
so
how
do
we
do
that?
C
So
let's
just
see
what
other
namespaces
I
have
and
I'll
just
create
a
new
demo,
namespace
and
so
I'll
go
back
to
my
I'll
go
back
to
my
bad
pod
here,
which
I
guess
I
already
had
one
so
I
didn't
need
to
buy
my
good
pod
and
I'll
go
to
my
namespace
and
apply
bad
pod
baseline,
and
so
we
see
here
that
the
pod
is
being
rejected.
Because
of
that
admission
configuration
file,
I
have
a
cluster-wide
configuration,
that's
applying.
I
did
not
label
this
namespace,
as
you
saw
I
just
created.
C
I
didn't,
assign
a
label
to
it
and
there's
the
proof
for
that
other
than
the
metadata.name,
which
is
a
default
and
immutable
label,
so
we're
getting
that
behavior
cluster-wide,
and
that
is
that
goes
for
any
namespace
that
I
just
created
as
well
as
future
namespace
as
existing
namespaces.
So
that's
a
really
nice
thing,
and
so,
with
that
config
that
admission
control
file,
you
know
it's
really
easy
and
useful
to
be
able
to
enforce
psa
across
the
entire
cluster.
C
You
can
put
different
levels
here,
so
I'm
enforcing
it
baseline
and
under
the
enforced
version
I'm
pinning
to
latest,
and
so
I
talked
about
version
pinning
so
rather
than
saying
an
explicit
version
like
123
or
124,
just
saying
latest,
which
means
whatever
the
version
of
pod
security
standards
that
you
have
with
you
know
the
version
of
your
the
api
server
itself.
That's
the
version
that
we
want
to
enforce.
But
again
you
can
mix
and
match.
So
I'm
doing
auditing
and
warning
for
baseline.
C
So
you
can
basically
extend
this
and
see
how
you
can
take
it,
and
you
know
get
the
behavior
that
you
want
from
a
global
perspective.
So
that's
a
little
bit
about
psa
in
action
and
showing
how
that
works.
Again.
It's
pretty
simple,
which
is
a
good
thing,
because
you
can
either
just
label
a
namespace
and
go,
and
if
you
need
cluster
application,
you
can
do
that
with
a
submission
configuration
file.
So
let
me
pause
here
and
see
if
there
are
any
questions
that
came
up
and
just
scanning
real,
quick.
B
C
Okay,
okay,
good
deal.
So
with
that
you
got
a
little
bit
of
taste
of
psa
and
you
know
you
might
be
saying
well,
this
is
great.
You
know
I
want
to
use
this
and
indeed
it
is
great
and
we
think
that
you
probably
should,
but
we
do
also
call
out
some
of
the
things
both
comparing
the
pros
and
cons
so
that
you
can
you
make
a
decision
for
yourselves
keeping
in
mind.
You
know
real
world
operation
of
clusters,
so
you
know
the
first
thing
as
I've
shown
it's
super
easy
to
get
set
set
up.
C
In
fact,
you
know
if
you're
on
123
or
124
there's
nothing
that
you
have
to
do
it's
already
there.
You
just
label
the
name
space
and
go
it's
integrated.
You
know
it's
built
into
the
api
server,
and
this
is
one
of
the
biggest
pros
is
that
you
don't
have
to
worry
about
submitting
resources
to
another
admission
controller
and
that's
better
from
a
security
standpoint,
but
it's
also
super
fast
and
that's
a
really
good
thing.
C
It
embeds
the
pod
security
standards.
So
you
know
I
talked
about
at
the
beginning
the
idea
of
pod
security
standards
being
a
collection
of
concepts
organized
as
controls,
where
each
control
specifies
the
type
of
behavior
that
you
should
have
and
so
psa
embeds
that
it's
a
technology
that
that
enforces
that
behavior,
but
but
there's
no
bolt
on
there's
there's
nothing
else
that
you
have
to
go
and
do
it's
already
intrinsically
there
and
that's
super
convenient.
It
can
audit
resources
so-
and
I
didn't
really
show
this
from
an
audit
perspective.
C
But
if
a
resource
was
in
violation
and
you
had
the
audit
label
applied
if
you
had
created
an
audit
log
and
that's
a
little
bit
out
of
scope
for
this
discussion,
but
kubernetes
api
server
has
an
audit
log
capability
that
you
also
have
to
create
an
advance
with
a
configuration
file,
and
you
can
do
things
like
send
the
audit
results
to
a
file
or
you
can
send
it
out
to
another
location.
But
but
anyhow,
if
you've
done
that,
then
those
audit
results
will
show
up
in
that
audit
log.
C
Now
that's
good
and
bad,
as
you
know
kind
of
talk
about,
but
but
you
can
do
that
and
that's
super
helpful.
It's
also
super
helpful
that
psa
allows
you
to
warn
users.
That
is
let
something
pass,
but
just
let
them
know
hey
fyi.
You
know
we're
warning
you,
but
this
resource
didn't
actually
pass
the
profile
that
we
assigned,
so
that
could
just
be
like
a
preemptive
mechanism
or
that
could
be
hey
fyi.
You
know
a
month
down
the
line.
C
It's
not
going
to
warrant
it's
going
to
fail,
so
that
gives
users
some
feedback
to
know
whether
you
know
the
resource
that
they're
submitting
needs
to
be
tweaked
and
how
that
gets
tweaked.
You
know
that's
that's
kind
of
a
separate
thing,
but
version
pending.
C
I
talked
about
this,
but
the
ability
for
you
to
basically
lock
in
the
version
of
pod
security
standards
that
you
want
now
to
ensure
that
even
if
you
upgrade
you
still
get
consistent,
behavior
until
you're,
ready
to
move
and
you
moving
is
just
simply
a
matter
of
you
labeling
that
namespace
that's
really
helpful,
because
predictability
is
a
good
thing.
It
helps
us
reason
about.
Behaviors
helps
us
troubleshoot
behaviors.
It
helps
communicate
with
users
better.
So
those
are
good
things.
B
Calling
out
some
of
the
things
question
as
well,
we
have
time
for
it.
So
how
can
I
live
with
php.
C
C
So
so
going
into
some
of
the
cons
here
and
really
these
are
just
fy
things
to
be
aware
of,
because
you
know
you
want
to
operationalize
this,
probably
in
a
production
environment
for
your
users
and
not,
you
know,
tinker
around
in
it
with
a
lab
like
that's
always
a
good
first
start,
but
it's
just
pods.
You
know,
as
the
name
implies-
and
this
is
you
know,
coming
from
pod
security
standards
or
pod
security
policies.
C
So
pods
are
a
great
place
to
start
from
workload
perspective
because
you
know
pods
are
the
atomic
unit
of
scheduling
they
run.
Containers
containers
represent
the
workloads,
like
that's
great,
but
there
are
more
than
pods
and
you
you
do
need
to
be
more
cognizant
of
more
than
just
pods,
but
but
four
pods,
you
know
psa
is
a
great
thing
to
get
started
with
it's
just
the
pod
security
standards.
C
This
may
not
be
as
apparent,
but
you
know,
as
I
mentioned,
pod
security
standards
are
a
codified
set
of
controls
that
the
kubernetes
upstream
organization
puts
together.
That
means
that
you
can't
create
your
own
custom
control
and
have
that
enforced.
You
get
the
pod
security
standards
and
also
it
may
not
be
apparent,
but
this
is
one
of
the
things
to
call
out
you
either
enforce
or
you
either
take
action
on
the
entire
control
or
the
entire
level
or
you
don't.
In
other
words,
you
can't
have
let's
say
that
there
are
eight
controls
within
baseline.
C
C
Oh
question:
how
does
pod
security
and
mission
controller
interact
with
other
solutions,
like
you
jump
in
the
gun,
I'm
about
to
get
there
in
just
a
minute,
I'm
going
to
show
some
some
useful
things.
So
so
let
me,
let
me
finish
through
these
and
then
and
then
we'll
actually
get
there,
no
mutation.
So
if
you're
familiar
with
pod
security
policies,
you
know
one
of
the
abilities
that
psps
had,
which
was
really
cool,
was
that
you
could
mutate
pods
and
get
the
behavior
that
you
want
in
psa.
C
Not
so
it's
just
validation,
so
your
validation
is
either
is
falling
into
one
of
those
three
categories:
you're
enforcing
your
warning
or
you're
auditing,
but
you're,
not
materially
changing
a
pod,
so
be
be
mindful
of
that.
This
one
is
fairly
fairly
important
to
know,
and
that
is
enforcement
of
pod
controllers.
So
your
deployments,
your
stateful
sets
those
aren't
getting
enforced.
If
you
have
a
a
policy
or
a
a
label
that
is
enforcing
that,
and
so
let
me
just
show
real
quickly.
C
So
I've
got
a
restricted
namespace,
that's
here,
and
this
is
labeled
enforce
restricted,
and
so
let
me
try
and
create
a
deployment.
That's
bad
that
I
know
is
bad
just
to
demonstrate
this
and
I've
got
a
bad
deploy
restricted
here
and
it's
bad
for
the
restricted
profile
because
it
doesn't
have
anything
in
it.
That
does
things
like
say
run
is
non-rude,
etc,
etc.
So,
if
I
try
and
create
that
in
the
restricted
profile.
C
C
So
we'll
do
it
get
events,
and
so
now
we
can
see
here
that
it's
actually
blocking
the
pods
that
are
coming
out
of
the
replica
set.
So,
as
you
can
see
from
the
subject
on
which
the
event
was
created,
the
event
isn't
created
on
the
deployment,
which
means,
if
you
do
a
cube,
control,
explain
on
the
deployment.
It's
not
going
to
show
anything.
C
So
anyhow,
just
wanted
to
point
that
out
that,
although
warning
does
work,
although
audit
does
work
for
your
enforce,
which
was
what
you,
what
you
really
want
for
a
lot
of
the
behavior,
then
there's
not
you
know,
you're
gonna
have
to
figure
out
what
you
do
and
typically
the
answer
is
well.
C
You
want
to
additionally
label
it
with
warning
that
way
that
somebody
sees
something
and
that's
good,
but
what,
if
you're,
creating
this
as
part
of
an
automation
process
as
far
as
a
pipeline,
or
something
no
one's
going
to
be
there
to
see
that
so
anyhow,
that's
one
thing
to
be
a
warrant
to
be
aware
of.
Is
that
there's
no
enforcement
for
pod
controllers,
I
use
a
deployment
same
type
of
thing,
with
stateful
set
job,
etc.
Those
are
all
pod
controllers
it
doesn't
enforce.
C
This
is
fairly
minor,
but
messages
aren't
configurable.
So
the
message
that
you
get
back
and
that
users
see,
regardless
of
whether
that's
a
warrant
or
an
enforce,
it's
not
configurable.
However,
the
warning
message
is
pretty
descriptive
and
it
is
helpful,
but
that's
something
to
be
cognizant
of
you
can't
really
change
the
message.
C
Seeing
audits
honestly
is
a
little
bit
painful.
I
know
I
didn't
show
it
here,
but
going
through
the
audit
process
in
order
to
see
resources
that
you
want
to
allow
but
show
up
involves
a
multi-step
process.
You
have
to
create
an
audit
log.
You
have
to
have
a
configuration
for
it.
You
have
to
determine
where
those
audits
are
going.
You
have
to
do
this
across
all
your
control,
plane
members.
You
have
to
pass
a
flag,
and
you
know
if
you're,
using
a
paths,
whether
that's
on
premises
or
out
in
the
cloud
oftentimes.
C
C
On,
if
you
can
great,
then
you
know
you
can
do
that
if
you're
running
you
know
like
a
bare
metal
cluster,
that's
provisioned
with
cube
adm
or
you
know
whatever
you
want
to
do,
but
but
it
is
a
multi-step
process
to
go
through
to
see
those
audits,
and
that
goes
without
saying,
or
maybe
it
doesn't,
but
I'll
say
it
that
you
can't
really
see
them
in
the
cluster.
C
So
you
can't
have,
for
example,
your
developer
team,
that's
creating
resources
and
their
resources
that
are
in
violation,
but
your
operations
team
or
your
sre
team
who's
responsible
for
looking
at
those
and
maybe
coordinating
or
communicating
with
them
from
inside
the
cluster.
Going.
Oh,
hey,
you
know,
samantha
created
this
deployment
and
it
failed,
and
you
know
we
want
to
let
her
know
and
whatever
the
case
is
you
actually
have
to
go
and
find
the
audit
log
in
the
control
plane
or
wherever
that's
exported.
C
The
cluster-wide
policy
requires
a
special
configuration
that
is,
that
admission
control
file
that
I
mentioned
here,
and
so
I
kind
of
talked
about
that
a
little
bit
earlier
same
similar
thing
with
the
audit
logs
and
that
you
have
to
pre-create
the
file
has
to
be
available
on
the
on
the
the
control
plane.
You
have
to
pass
a
flag
all
that
type
of
stuff
exemptions,
they're
kind
of
limited.
C
You
know
you,
you
have
three
possibilities:
you
have
usernames
runtime
classes
and
namespaces,
but
one
of
the
things
that
we
see
in
the
caverno
project
is
that
very
very
often
people
need
more
fine-grained
exemptions
than
that
they
need
things
like
pod
name.
They
need
other
stuff,
so
anyhow,
be
mindful
of
that.
Can't
use
this
in
a
pipeline
from
the
perspective
of
like
a
separate
tool,
that's
decoupled
for
it.
So
a
lot
of
us
do
use
pipelines
when
we're
offering
resources
in
order
to
go
from.
C
C
It's
not
really
a
thing,
and
you
know
it
just
goes
without
saying,
but
this
is
fairly
new
and
it
does
take
a
little
while
for
this
technology
to
mature,
and
that
comes
with
people
that
are
using
it
so
not
reasons
to
not
use
it.
Just
reasons
to
you
know
be
cognizant
of
these
things
and
see
if
see
if
this
is
gonna
work
for
you,
and
so,
let's
from
there
take
a
little
bit
of
comparison.
Let's
look
at
a
little
bit
of
comparison
against
caverno
and
how
you
know
this
works.
C
You
know
in
comparison
to
psa
and
so
that
you
can
kind
of
decide.
You
know
which
one
is
attractive
and
it's
it's
not
necessarily
an
either
or
it
could
be
of
both
and
I'll
show
that
in
just
a
second
but
but
caverno
works
on
anything,
it's
not
just
pods
any
resource
that
you
can
create.
C
You
can
create
any
custom
policy
that
you
want
to
it's
not
just
limited
to
pod
security
standards.
Caverno
does
have
mutation
support,
so
if
you
want
to
change
pods,
if
you
want
to
change
any
other
resource
for
that
matter,
you
can
do
that.
Based
on
your
own
custom
policy,
caverno
does
offer
the
the
pre-built
pod
security,
standard
policies
and
I'll
install
those
in
just
a
second
here
so
that
you
can
see,
but
they
are
the
exact
same
controls
that
are
that
are
enforced
in
psa.
C
There's,
not
any
it's
just
the
caverno
implementation,
there's
not
any
difference.
As
far
as
you
get.
You
know
this
behavior
with
things
that
are
in
caverno
or
other
things,
and
you
get
different
behavior
with
it's.
The
same
behavior,
it's
just
how
it
comes
caverno,
has
a
resource
called
a
cluster
policy
and
I'll
show
that
here
in
just
a
second
cluster
policy
applies,
as
it
kind
of
sounds
to
the
entire
cluster,
without
having
to
create
a
file
that
is
specifically
known
only
to
the
api
server.
C
The
exemptions,
which
I
think
I'll
also
show,
can
be
super
easy
and
very
granular.
In
fact,
you
can
get
down
as
far
as
container
name
and
a
union
of
bunch
of
different
things,
so
container
name,
environment
labels
and
annotation
values.
Basically,
whatever
mechanisms
are
already
there
in
kubernetes,
you
can
define
an
exception
for
that.
Somehow,
in
caverno,
caverno
automatically
applies
pod
policies
to
pod
controllers
through
a
nifty
capability
called
auto
generation
rules.
That
means
that
there's
no
allowing
silently
of
a
deployment,
that's
in
violation
but
blocking
of
its
pods.
C
C
C
Audit
results
are
easy
in
that
audit
results
show
up
in
an
open
standard,
called
a
policy
report
and
that
is
available
as
an
in-cluster
resource.
So
if
you
have
a
resource,
that's
in
violation
of
a
policy,
you
can
see
that
violation
as
an
in
cluster
resource
and
that's
cool,
because
you
can
now
decouple
who
writes
policy
and
who
sees
policy
results.
So
you
can
have
that
separation
between
your
policy
authoring
team
and
your
sre
team
that
can
go
and
see
those
violations.
C
It
does
have
a
cli
that
is
standalone.
So
you
can
know
in
your
pipelines.
Is
this
resource
going
to
pass
that
pod
security
policy
or
that
pod
security
standard
profile?
It'll
tell
you
immediately
before
it
even
hits
a
cluster,
and
it's
got
some
broad
version
support
so
psa,
it's
on
by
default
and
123
forward.
C
There
is
a
separate
admission
controller
that
you
can
deploy
from
earlier
versions,
but
kaverno
works
back,
there's
versions
that
work
all
the
way
back
to
114
or
something
like
that
and
that's
good,
because
not
everyone
can
upgrade
it
even
the
reduced
velocity
of
three
releases
per
year.
So
I
see
a
question.
That's
come
up
here
is
this
native
kubernetes,
which
version
is
it
in
so
pod
security
admission
is
in
123
forward
enabled
by
default.
So
if
you're
on
kubernetes,
123
and
forward
it
is
there,
it
is
enabled
by
default.
C
All
you
do
is
assign
a
namespace
label
and
go
or
other
things
if
you
want
to
so
quickly
hitting
on
the
cons,
because
you
know
want
to
be
open
and
transparent,
because
really
this
is
about
you
know
showing
what
the
capabilities
are
and
then
you
determining
for
yourselves
like
how
this
capability
can
be
used,
and
you
know
we
do
think
that
psa
should
be
used
and
that
it's
a
it's
a
it's
a
positive
step.
So
you
know
caverno,
just
like
every
other
tool
has
its
own
cons,
and
that
is
it's
an
add-on.
C
It's
an
it's
an
admission
controller
that
you
install
additionally
now,
no
matter
how
easy
that
is,
nothing
is
as
easy
as
being
built
in
like
psa
is
so
that's
something
to
call
out
you
know.
Psa
is
a
set.
Pss
is
a
separate
group
of
policies
that
you
install.
You
know,
that's
that's
just
that
comes
with
the
nature
of
of
the
beast,
but
the
pss
policies
are
fully
built
and
can
be
installed
with
a
helm
command
which
I'll
show
in
just
a
minute
here.
C
Unfortunately,
carverna
right
now
does
not
have
warnings,
it
has
an
enforce
and
an
audit
capability
we're
going
to
try
and
address
that
in
the
future.
So
that's
something
to
be
aware
of
block
resources
aren't
in
audits,
but
they
are,
however,
written
to
events
on
the
policies
themselves.
So
you
that
you
can
get
visibility
on
that
and
if
you
do
need
to
do
version
pinning
you
just
have
to
have
more
policies
and
rules.
So
you
know
that's,
probably
not
the
biggest
deal,
because
the
caverno
community
would
typically
provide
those.
C
So
anyhow,
let's
take
a
look
at
some
use
cases
that
we
can
use
psa
plus
caverno
and
get
some
useful
behavior.
So
the
first
thing
I
want
to
show
is
so
we
want
to
use
psa,
but
maybe
we
also
want
to
use
caverno
or
something
else
that
has
mutation
capabilities,
but
in
this
case
I
want
to
automatically
like
I
don't
want
to
use
a
cluster-wide
admission
configuration
file.
C
I
do
want
to
do
this
on
a
per
namespace
level
by
you
know,
ad
hoc
labeling
a
namespace,
but
I
really
don't
want
to
label
every
single
namespace
by
hand.
Well,
that's
perfectly
fine.
How
about?
Let's,
let
caverno
add
those
labels
for
us.
Let's
let
caverno
add
the
labels
that
we
want
for
the
given
pod
security
admission
based
on
the
policy.
So
I
have
a
policy
here.
C
That's
going
to
anytime
a
name
space
is
created
and
I
can
gate
this
in
a
lot
of
different
ways
by
you
know,
making
it
specific
to
names,
but
I'm
going
to
assign
the
baseline
to
be
enforced
and
I'm
going
to
warn
at
the
restricted
level.
So
let
me
just
apply
this
cluster
policy.
C
So
that's
super
nice
and
that
whenever
you're
provisioning,
new
name
spaces-
and
you
can
create
multiple
rules
that
do
this
based
on
like
a
pattern,
for
example
like
if
you
have
like
prod
dash
star
or
something
then
caverno
can
respond
accordingly.
So
that's
the
first
thing
and
yeah
I
can
apply
a
resource
to
that,
but
but
and
prove
that
it
works.
C
But
I
think
that
that
you'll
take
me
at
my
word
that
it
does
so
that's
the
first
thing
you
know
use
caverno
to
apply
labels
to
a
namespace
that
you
want,
but
let's
say
that
you're
already,
using
that
admission,
control
file
and-
and
I'm
I'm
already
using
this
in
my
case
now-
one
of
the
things
I
didn't
talk
about
is
that
you
can
set
a
label
called
privileged
and
privileged
is
basically
allowing
users
to
do
whatever
they
want
in
that
that
name
space.
C
So
we
think
of
pod
security
admission
as
a
as
a
mechanism
that
you
increase
enforcement
of
by
having
nothing
and
then
making
it
more
restrictive.
But
you
can
also
go
the
opposite
direction,
which
is
you're
more
restrictive
from
a
cluster
perspective,
but
you
want
to
go
privileged
on
a
certain
name.
Space.
Well,
caverno
can
help
us
in
in
that
regard
as
well,
because
let's
say
that
we
do
need
you
know.
As
part
of
our
exceptions,
we
do
want
the
the
cluster
to
have
an
admission
configuration
file.
C
That
applies
to
the
entire
cluster,
but
we
also
need
to
create
some
namespaces
that
have
that
privileged
label,
because
we're
doing
some
things
in
there
that
you
know
we
need
maybe
temporarily
or
not
some
privileged
access.
So
that's
what
we're
doing,
but
we're
saying
here
with
the
exclude
that
everybody
who
is
not
a
cluster
admin,
is
immediately
prohibited
from
doing
that.
So
let's
create
this
cluster
policy.
C
And
so
I've
created
a
user
in
this
cluster
called
foo
user
and
foo
user
has
the
permission
to
create
namespaces,
but
in
kubernetes
are
back,
there's
no
way
to
distinguish
between
one
who's
able
to
create
namespaces
and
one
who's
able
to
create
name
spaces
with
certain
labels.
So
this
is
where
caverno
can
come
in
and
sort
of
augment
the
ability
of
psa
in
providing
more
of
that
fine-grained
exclusionary
control.
C
And
it's
allowed
me
to
do
that,
and
so
I
just
created
a
privilege
namespace
that
has
the
privilege
label,
which
is
basically
going
to
allow
anything
that
I
want
to
do
to
to
happen.
Inside
of
that.
So
let
me
rename
this
cookies
because
I
like
cookies
and
let's
try
and
create
the
cookies
name
space
which
remember,
has
that
label
set,
and
we
don't
really
want
that
if
your
cluster
admin
as
foo
user,
so
I'm
going
to
apply
the
same
thing:
foo
user.
Actually
before
I
do
that.
Let
me
just
prove.
C
C
Okay,
I'm
not
sure
what
is
going
on
internally
with
that,
but
but
anyhow
it
it
should
block
it
and
it
did
block
it
and
prior
to
this,
this
is
always
the
fun
thing
with
live
demos.
Is
you
never
know?
What's
gonna
happen
so
anyhow,
that's
that's
one
policy
that
can
be
used.
You
can
scope
down
and
and
prohibit
certain
activities
from
happening
based
on.
You
know,
whatever
type
of
exclusions
that
you
want
and
also
see
from
the
last
last
example.
C
Here
you
can
use
psa
to
enforce
baseline
and
you
can
use
caverno
to
enforce
the
the
restricted
profile
in
your
cluster.
So
if
I
go
and
install
the
restricted
policies,
the
restricted
pod
security
standards-
and
so
I
talked
about
you-
know
installing
the
pod
security
standards
from
a
caverno
perspective-
and
this
is
this-
is
how
I'm
I'm
doing
it.
It's
a
simple
helm,
chart
helm,
install
caverno
policies,
I'm
setting
the
profile
to
restricted,
and
I'm
also
setting
it
immediately
to
enforce.
C
So
that's
basically
I'm
still
using
basic
baseline
in
my
cluster,
but
I'm
using
caverno
to
enforce
the
restricted
profile,
and
so
I
can
now
do
things
like
create
or
prevent
the
creation
of
a
bad
deployment
and
restricted
in
a
namespace
that
does
not
have
the
does
not
have
the
label
assigned.
So
if
I
do,
for
example,
can
foo
apply,
f
bad
deploy,
restricted.
C
We've
seen
here
that
caverno
is
providing
all
of
these
messages
back
and
we
are
not
setting
any
of
these
things.
So
these
are
all
messages
from
caverno
here,
as
you
can
see
from
caverno.
The
validate
web
hook
has
denied
all
of
this.
So
you
can,
you
know,
combine
a
lot
of
these
things
together
and
get
the
exclusions
that
you
want
enforce
things
where
you
need
them
and,
as
things
become
you
know
more
known,
you
can
remove
those
exclusions,
you
can
gate
them
down,
etc,
etc.
C
So,
hopefully
this
has
provided
some
info
on
that
and
on
how
you
can
use
the
two
together
and
so
just
to
go
over
some.
Some
closing
points
here
for
opening
up
for
questions.
So
first
thing
is
to
acknowledge
that
you
will
have
exceptions.
Everybody
has
exceptions,
no
exception,
so
almost
no
matter
what
you're
doing
in
any
environment.
The
first
thing
you're
going
to
have
is
exceptions.
So
what
type
of
flexibility
do
you
need
with
psa?
C
You
get
three
options:
username
runtime
class
and
namespace,
and
if
that
is
all
that,
you
need
from
an
exception
standpoint
great.
You
should
definitely
look
into
that
because
it's
yeah.
It's
super
useful.
However,
you
will
have
to
create
that
admission.
Configuration
file,
securing
pods,
isn't
enough
so
right
out
of
the
bat
right
out
of
the
gate,
you're
signed
up
for
more
than
just
psa.
C
So
do
you
want
to
use
one
or
do
you
want
to
use
two
tools,
just
keeping
in
mind
that
you
solve
for
pods
and
that's
a
great
and
necessary
first
step
and
everybody
should
do
things
like
enforce
the
baseline,
but
you
got
to
think
longer
about
like
what
other
things
are
are
are
happening
in
my
environment.
Where
are
we?
How
do
we
operate
who's
using
it?
What
are
they
permitted
to?
Do?
C
What's
going
to
happen
when
that
lands?
In
my
you
know,
pci
cluster:
what's
what's
going
to
happen
when
that
goes
out
to
my
cluster?
That's
in
london
and
I'm
in
the
us-
and
you
know
we're
just
rolling
a
new
application
out,
like
you
probably
want
to
test
those
things,
and
so
maybe
in
your
existing
pipeline,
it's
easier
to
use
a
standalone
tool
because
you
can
just
drop
that
in
rather
than
build
a
full-fledged
kubernetes
cluster.
No
matter,
you
know
how
that
may
come.
C
So
do
you
need
to
think
about
that?
But
also
you
know,
as
I
mentioned
at
the
outset,
there's
a
difference
between
deprecated
and
removed.
Psps
are
removed
in
the
next
version,
and
so,
if
you're
still
on
psp's,
definitely
look
at
psa,
but
keep
in
mind
that
as
of
125,
they
are
going
to
be
gone,
and
so
with
that
I'm
going
to
stop
sharing,
and
I
will
be
glad
to
take
any
questions
and
let
me
just
scan
here
and
see
what
we
have.
B
I
think
people
might
be
typing
their
questions
now.
So
yes,
it's
q,
a
time
everyone
so
time
to
ask
all
those
burning
questions.
Now
we
have
a
four
minute
timeline.
C
B
For
them
so
good
time
for
those,
while
we
wait
everyone
to
type
away
their
questions,
I
have
a.
I
have
a
question
as
well.
So
what
are
the
most
common
security
failures?
You
see
in
kubernetes
workloads.
C
A
lot
of
the
a
lot
of
the
common
security
failures
that
that
come
in
with
kubernetes
workloads
are
just
not
doing
not
doing
things
according
to
those
pod
security
standards.
So
having
problems
with
you
know
letting
your
containers
run
as
root
and
that
that
goes
for
building
them
and
also
running
them.
Things
like
ensuring
that
you're
not
using
privileged
mode
like
most
things,
don't
need
privilege
mode.
C
You
know
a
lot
of
the
failures
that
happen
are
due
to
some
of
these
misconfigurations.
That
tools
like
psa
can
catch
really
quickly,
and
so
you
know
I
mentioned
it
multiple
times,
but
regardless
of
you
know,
you
use
multiple
tools
or
not
at
the
very
least.
You
should
enforce
baseline.
Just
do
it
just
enforce
baseline
get
started
with
a
good
base.
You
know
you
will
avoid
a
lot
of
those
misconfiguration
and
security
issues.
If
you
just
enforce
baseline
today
and
then
select,
excuse
me
selectively,
as
you
begin
to
go
forward,
start
look.
C
Excuse
me
again,
start
looking
at
restricted
and
seeing
if
that
see,
if
that
works
for
you,
but
you
know
keep
in
mind.
Like
I
mentioned
on
the
closing
points.
You're
gonna
have
exceptions,
so
it's
probably
not
gonna
be
a
case
where
you
can
just
carte
blanche
flip
something
on
even
in
a
whole
name
space,
because
you're
going
to
have
things
like
you
know,
side
cars
that
need
to
be
injected
from
your
service
mesh
or
your
your
secret
storage
system
or
some
bespoke
stuff
that
you're
doing
so
anyhow
long
answer
to
the
question.
C
Most
security
failures
just
come
in
in
not
doing
some
of
these
simple
things
from
the
very
beginning.
B
Great,
the
jingdong
had
a
comment
rather
than
a
question,
but
thanks
so
much
for
the
presentation
super
cool.
So
that's
really
great
to
hear.
Thank
you
so
much
for
that
comment.
We
have
two
minutes
left,
so
this
is
final
call
for
questions.
If
anyone
is
typing
away
right
now,
but
while
we
see
if
anyone
hits
that
enter
button
now
is
there
any
final
words
that
you
want
to
tell
everyone
to
like
resources
that
they
should
check
out
after
this
or
so.
C
Yes,
thanks
for
that,
so,
as
I
mentioned,
you
know,
with
psa,
go
look
at
the
documentation.
C
There
are
some
really
nice
tutorials
that
are
out
there
and
then
try
it
out
in
your
environment
and
see
how
everything
works
play
around
with
the
admission
configuration
file,
you
know
from
a
cluster-wide
perspective,
get
a
feel
for
that
and
then
kind
of
make
the
determination
for
you.
Based
on
how
you
operate.
You
know
your
organization
operates
what
your,
what
your
requirements
are,
what
your
constraints
are.
Is
that
going
to
work
for
you
and
but
at
a
very
least
start
by
enforcing
you
know
getting
some
quick
wins
by
enforcing
baseline
to
enforce.
C
You
know
some
some
basic
hygiene
in
your
clusters
and
then,
if
you
want
to
look
at
additional
tools
like
caverno
or
something
else,
that's
out
there,
you
know
a
great
way
to
get
started
with.
That
is
the
pod
security
standards
that,
as
I
showed
caverno,
will
have
the
ability
to
deploy
in
a
in
a
fully
blunder,
bundled
manner
and
also,
if
you
take
a
look
at
the
policies
library
that
caverno
has,
I
think,
there's
over
180
sample
policies
that
are
out
there.
So
it's
a
great
way
for
you
to
learn.
C
You
know
how
caverno
constructs
policies,
but
it's
also
a
super
easy
way
for
you
to
go
and
just
grab
something
that
works
for
you
and
either
just
turn
it
on
immediately
or
perform
some
minor
modifications
and
you
know
start
getting
value
from
it.
So
thank
you
all
for
allowing
us
to
talk
and
hope
everyone
enjoyed
it.
B
Perfect,
thank
you
so
much,
then,
it's
time
to
wrap
up.
So
thank
you.
Everyone
for
joining
the
latest
episode
of
cloud
native
live.
It
was
great
to
have
a
session
about
examining
spot
security
admission,
so
we
really
also
love
the
interaction.
Thank
you
for
the
great
comments
as
well
as
questions
today
from
the
audience.
Thank
you
so
much
and
as
always,
we
bring
you
the
latest
cloud
native
code
every
wednesday.
So
next
week
we
have
a.
We
will
have
a
session
on
enhancing
your
get
ops
experience
with
flux
tools
and
extensions.