►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
The Hitchhiker's Guide to Pod Security - Lachlan Evenson, Microsoft
With the release of Kubernetes v1.23, Pod Security admission has now entered beta. Pod Security is a built-in admission controller that evaluates Pod specifications against a predefined set of Pod Security Standards and determines whether to admit or deny the pod from running. Pod Security is the successor to PodSecurityPolicy which was deprecated in the v1.21 release, and will be removed in Kubernetes v1.25. In this presentation I cover the key concepts of Pod Security along with how to use it walking through practical examples. Through education of this new security focused API I hope that cluster administrators and developers alike will use this new mechanism to enforce secure defaults for their workloads.
A
Thank
you
very
much.
Thank
you
very
much.
I'm
really
really
excited
for
this
session
and
I
know
it's
the.
I
am
the
only
thing
between
you
and
some
nice
cold
beers
at
the
end
of
the
day,
so
I'm
gonna
try
my
best
to
entertain
you,
but
you,
let
me
know
at
the
end
you
be
the
judge.
So
this
is
the
hitchhiker's
guide
to
pod
security.
A
Take
you
through
oops
we're
going
to
take
you
through
that
guidebook,
and
I
have
a
couple
of
goals
for
you
in
the
next
35
minutes.
We're
going
to
learn
together.
So
my
hope
is
that
everybody
leaves
this
session.
You
go
back
to
your
lives
and
you
turn
on
pod
security
in
your
clusters
and
you
report
back.
If
my
learnings
actually
helped
you
with
your
journey
to
pod
security,
but
I
would
love
to
see
more
secure,
kubernetes
clusters
out
there.
A
So
what
you're
going
to
learn
today
is
how
to
use
some
features
in
kubernetes
to
achieve
that.
So
I
hope
hold
me
to
this
and
let
me
know
at
the
end
that
you'll
feel
comfortable
going
back
and
turning
this
on.
If
you
don't,
please
ask
me
for
more,
I'm
happy
to
give
it
to
you.
So
our
journey
today
has
a
few
pit
stops
and
hopefully
do
we
have
any
hitchhikers
go
to
the
galaxy
fans
in
the
room
I'll
make
a
few
puns
I'll
make
a
few
puns.
A
So
we
will
go
through
all
this
and
more,
but
I
guess
you
want
to
know
who
you're
talking
to
who's
talking
to
you
about
this.
My
name
is
lockheed
evanson,
lachlan
evenson,
I
listen
to
both.
You
can
call
me
hey
mate
or
whatever
I'm
a
product
manager
at
azure
on
the
upstream
team,
where
we
work
in
cloud
native
ecosystem
tooling,
to
help
make
folks
successful
in
the
community.
You'll
see
me
around
in
this
space,
I'm
a
cncf
ambassador,
I'm
on
the
governing
board.
A
I've
served
on
kubernetes
steering
I
built
a
kubernetes
release
that
hopefully
didn't
ruin
your
life
1.16.
If
it
did,
please
give
me
that
feedback.
I
love
travel
language
hiking
and
experiencing
different
cultures.
I'd
like
to
learn
seven
languages,
while
I'm
here
on
earth.
I
know
three
currently,
if
you
don't
count
australian
and
english
as
two
different
languages.
A
Okay,
good
now
you
know
who's
talking
to
you.
We
can
get
on
with
that.
Thank
you
very
much,
okay.
So,
let's
get
into
the
concepts,
let's
get
into
what
we're
here
to
talk
about
before
I
get
into
all
the
details,
I
want
to
go
over
what
is
pod
security
and
you
might
have
heard
pod
security
or
pod
security
administration.
A
Pod
security
is
a
built-in,
so
I
have
everything
bolded
admission
controller
it
is
built
in
you,
don't
need
any
extra
software
to
run
this.
It
is
there
and
you
can
use
it
in
kubernetes
today,
yeah.
What
does
it
do?
It
evaluates
pod
specifications
against
a
predefined
set
of
pod
security
standards.
Don't
worry
about
that
I'll.
Tell
you
exactly
what
they
are,
but
they're
super
important.
A
A
It
is
currently
in
beta
or
beta
for
you,
americans
and
as
of
kubernetes
1.23,
which
is
now
not
the
current
release,
the
one
behind
so
we're
on
release
in
and
it
is
planned,
if
you
all
give
it
a
thumbs
up
after
this
to
go
to
stable
in
1.25,
which
is
the
next
release.
I've
got
some
links
down.
There
just
follow
along
here,
I'll
post
the
deck
later,
so
you
can
grab
the
links
and
whatnot
excellent.
A
Why?
I
think
it's
important
to
say
why
am
I
telling
you
about
this?
Why
would
you
I
want
to
know
this?
So
what
we
want
to
do
again
is
level
up
the
security
of
your
kubernetes
clusters
and
the
workloads
specifically
that
are
running
on
them,
so
the
pod.
This
provides
policy
standards
to
restrict
pod
privileges.
Why
would
we
want
to
restrict
pod
privileges
to
make
our
workloads
more
secure
if
they
are
ever
compromised,
we're
reducing
the
surface
area
of
attacks
and
therefore
making
your
cluster
more
secure
by
doing
so
as
well?
A
A
There
is
a
set
that
already
exists
and
you
simply
can
refer
to
them
by
name.
It
supports
and
encourages
kubernetes
security
best
practices.
So
if
you
use
these,
you
will
be
in
line
with
pod
security,
best
practices
out
of
the
box.
You
don't
have
to
do
much
and
it
performs
validation.
Only
we'll
cover
this
a
little
bit
later,
but
you
might
be
thinking.
Can
I
change
resources?
The
answer
is,
you
cannot
and
we'll
talk
about
some
different
options
for
doing
that.
A
What
about
the
elephant
in
the
room,
or
maybe
the
fish
in
the
room,
the
babble
fish
in
the
room?
What
about
pod
security
policy?
You
may
have
heard
of
this
or
have
used
it
and
been
terribly
disappointed
when
you
heard
it
was
deprecated,
it
is
going
to
be
removed
in
kubernetes
1.25.
So,
if
you're
still
using
it
today,
don't
worry
I'm
going
to
go
over
how
you
can
migrate
to
this
so
that
you
won't
be
broken
in
the
next
release.
A
A
Okay
moving
right
along
here,
I'm
going
to
cover
the
migration
story.
So
if
you're
in
this
path,
I'm
not
going
to
go
into
terrible
detail,
but
there
is
a
migration
plan.
It
is
well
documented
on
the
kubernetes
docs,
so
you
can
go
from
pod
security
policy
today,
which
is
deprecated
and
being
removed
in
three
months
four
months,
two
pod
security
which
we're
talking
about
today.
There
is
a
link
to
do
it.
A
A
Okay,
everybody
following
along
so
fast
so
far
cool
so
far:
okay,
excellent
other
secret
other
similar
ecosystem,
tooling.
So
I'd
be
remiss
to
mention
that
there
is
an
ecosystem
of
tooling
out
there.
You
may
have
heard
of
some
of
these
different
tools,
but
pod
security
is
designed
to
provide
a
built-in
set
of
capabilities
that
include
the
security
of
your
workloads.
It's
not
supposed
to
be
the
only
thing,
so
it's
complementary
and
composable
that
last
point.
A
So
there
are
other
projects
out
there.
If
you
want
to
do
more
complex
things,
I'm
going
to
name
two
they're
on
the
screen
there,
kivono
and
gatekeeper
if
you're
interested
in
more
complex
pod
security
use
cases,
pod
security
use
cases,
and
this
is
designed
to
be
composable.
So
this
is
complementary.
You
can
use
this
and
others
as
well
and
again
again,
these
aren't
all
of
them.
I
just
list
two
there
for
the
interest
of
showing
you
some
others
all
right.
Now
we're
going
to
get
into
the
elements
of
of
pod
security.
A
We
have
a
built-in
admission
controller.
It
may
be
run
as
a
standalone
web
hook.
So
if
you
are
running
earlier
versions,
then
the
version
this
became
beta
in
which
was
1.22-
you
can
actually
deploy
this
in
earlier
versions.
Using
a
web
hook.
Administ
admission
controller
won't
go
into
the
details.
You
just
need
to
know
that
exists.
A
The
policies
are
applied
with
a
specific
mode
per
name,
space
we'll
go
into
these
modes
and
you
can
apply
multiple
modes
to
a
namespace.
That'll,
be
critical,
we'll
go
over
that
as
well
with
different
policy
levels
and
we'll
go
over
why
you
might
want
to
do
that
at
the
same
time.
They're.
The
elements
you
need
to
know
lost
the
monitor
and
we're
back.
A
I
didn't
record
that
this
isn't
recorded
that
I
know
of
okay.
So
let's
take
a
look
at
the
pod
security
standards.
These
are
the
levels
that
you
will
be
using
and
they
are
pre-defined
levels.
Privilege
which
is
open
and
unrestricted,
as
I
mentioned
baseline,
this
covers
the
known
privilege
escalations
while
minimizing
restrictions.
So
this
is
where
you
want
to
get
to
for
a
start.
A
If
you
have
nothing
and
have
never
looked
at
this
before
the
goal
state
you
want
to
get
to
is
baseline
for
starters
and
then
restricted
is
the
highly
restricted
if
you
have
really
high
security
interests.
This
takes
out
the
most
security
prone
pieces
of
pod
specification
and
make
sure
that
you're
in
the
most
restricted
mode
but
be
warned,
it
may
cause
compatibility
issues.
A
So
it's
up
to
you
to
decide.
I
think
a
great
goal
would
be
that
every
kubernetes
cluster
and
every
namespace
has
baseline
pod
security
standards
applied
to
them.
I
think
that
would
be
a
cool
goal
to
have
okay,
but
what
about
these
specific
standards?
What
are
in
these
standards,
so
they
are
well
documented.
The
link
is
down
the
bottom:
I'm
not
going
to
go
over
every
piece
of
the
pod
specification
that
is
indeed
restricted
by
these
different
pod
security
standards.
A
A
There
is
a
wide
range
of
different
pieces
of
the
spot,
pod
specification
that
are
defined
in
that
link
down
the
bottom
so
too
many
to
list,
but
you
can
go
and
have
a
look
at
the
different
pieces
and
I'll
show
you
them
in
action.
So
don't
worry
about
writing
them
down
again
applied
per
name
space
which
allows
you
to
have
granular
or
different
levels,
different
levels
of
security
standards
based
on
your
needs
per
name
space.
A
You
may
not
want
to
apply
restricted
to
cube
system
name
space,
for
example,
but
you
may
want
to
do
it
to
your
default
workload,
namespace,
okay,
elements
of
pod
security,
so
these
things
are
applied
in
a
specific
mode
and
there
are
three
different
modes
and
they
can
be
set
on
a
name
space
and
you
can
have
different
policy
levels
per
name
space
as
well.
The
three
modes
are
enforce,
which
says
I
will
not
allow
this
it'll
strictly
block
it
order.
A
It
will
post
something
in
the
audit
log
and
warn
it
will
actually
fire
a
warning
message
back
to
the
user
stating
that
hey.
This
is
in
violation
of
this
policy
and
you
might
want
to
do
something
about
it,
but
it
will
allow
it
to
be
created,
so
you
can
actually
get
user
feedback
if
you
define
a
non-compliant
resource
within
force.
You'll
actually
get
an
error
message
back
via
cubectl.
That
says
this
policy
has
been
violated.
A
Okay,
so
just
remember
those
three
sorry:
water
break:
okay,
okay,
in
addition
and
I'll
show
you
how
to
do
this
with
labels
on
a
namespace,
you
can
pin
policy
so
for
each
version
of
kubernetes
there
will
be
changes
to
the
pod
security
standards.
Why
is
this
important?
Because
if
it
changes
over
time
and
you're
not
familiar
with
those
changes
and
you
upgrade
kubernetes,
you
might
break
your
workload.
So
this
allows
you
to
pin
much
like
everybody
pins,
all
their
version
dependencies
and
software
right.
A
Oh
bad,
joke!
Sorry
too
soon
too
soon,
but
you
can
pin
the
specific
version
spin.
The
specific
versions
allows
you
to
have
consistent
behavior,
you
can
say
baseline
colon
latest,
you
can
say
baseline
colon
v1.22
and
that
will
apply
because
remember
this
is
built
into
kubernetes,
so
you
can
strictly
version
pin
okay.
So,
let's
get
on
to
enabling
pod
security
and
how
we
might
go
about
doing
that
so
123,
it's
enabled
by
default,
because
beta
features
are
actually
enabled
by
default.
A
If
you
want
to
test
this
out
now,
I
had
to
put
the
disclaimer
here
as
we're
going
through
the
galaxy.
Don't
test
this
in
production?
No,
no!
No!
You
might
get
unexpected
outcomes
so
get
familiar
with
it
in
a
development
setting
a
lab
cluster
spin,
it
up
on
kind
start,
seeing
how
it
works
before
you
turn
it
on.
I
don't
want
anybody
calling
me
saying
lockheed,
you
told
me
to
do
this
and
I
blew
up
prod.
Don't
want
to
hear
it.
Okay,
you've
been
warned,
okay,
configuring.
A
A
Excellent
yeah,
you
got
them
all
enforce,
warn
and
audit.
They
are
the
three
modes,
so
that
is
required
specifically
to
enable
it
the
second
one
there
is
version
pinning
which
is
completely
optional.
There
is
so,
if
you
say,
hey
loki,
I
don't
want
our
users
defining
pod
security
policies
or
labels
on
namespaces.
No,
no.
I
can't
have
that
there
is
an
admission
configuration
way
that
you
can
do
it
by
setting
a
config
file
and
actually
having
the
api
server
pick
it
up,
so
that
users
don't
configure
anything.
A
So
there
is
a
way
to
do
that
and
there's
a
way
to
do
regexing,
excluding
namespaces,
except
so
you
can
do
that.
So,
as
I've
got
the
star
down
there,
the
bottom
so
possible
modes,
there
again
and
force
audit
one.
These
are
important.
Okay,
configuring,
so
the
specific
version
can
be
applied
for
the
enforcement
mode.
Why
would
we
do
this?
We
have
remember,
warn
audit
and
what's
the
other
one
enforce
exactly.
Thank
you.
A
So
you
usually
start
with
one
give
the
users
back
warning
and
then
you
move
on
from
warn
to
enforce.
So
this
is,
you
might
be
able
to
warn
on
one
level
and
enforce
on
another.
For
example,
you
might
want
to
move
from
privileged
to
baseline,
so
privileged
to
baseline,
so
you
might
enforce
on
privileged,
but
warn
on
baseline,
so
that
you
can
actually
help
the
workloads
that
are
currently
deployed
move
up,
so
the
users
will
actually
get
a
warning
message.
A
Their
workloads
will
still
be
deployed,
but
you
can
say:
hey
you're,
not
in
compliance
fix
it.
So
you
don't
get
this
warning
message.
They're
actionable
I'll,
show
you
and
then
you
can
move
from
privileged
up
to
baseline
and
then
even
subsequently
up
to
restricted
we're
good.
So
far,
everyone
up
in
the
rafters
good
see
thumbs
up
excellent,
okay,
we're
going
to
go
into
some
demos
in
a
minute.
So
what
I
wanted
to
show
you
is
what
actually
an
audit
piece
looks
like
without
filtering
through
an
audit
log.
A
So
if
you
have
audit
logging
on
your
cluster,
you
will
see
a
message
that
looks
like
this,
so
this
one
says
allow
privilege
escalation,
does
not
equal
false
for
the
container
busy
box.
It
must
be
set
in
the
security
context.
Allow
privilege
escalation
needs
false,
unrestricted
capabilities,
so
there's
a
bunch
of
errors
there,
you
can
put
them
in
audit
logs
and
people
looking
at
audit
logs
can
actually
see
where
things
have
been
fired.
A
I
will
also
show
you
that
we
publish
a
set
of
metrics
that
you
could
scrape
with
prometheus
to
see
which
policies
are
indeed
being
hit,
how
often
they're
being
hit
so
that
you
can
see
from
your
monitoring
tool
how
it's
operating
as
well.
So
I'll
show
you
that,
okay
from
here
we're
going
to
show
you
it
in
action
and
and
by
the
way
I
got
all
these
images
from
the
free
and
public
nasa
images
site.
They
have
wonderful
images
of
space,
that
is
the
hubble
telescope,
which
is
fantastic.
Okay.
A
A
No,
you
know
I'm
not
pulling
a
rabbit
out
of
a
hat.
It's
all
up
and
running
and
you're,
going
to
see
that
there
are
some
nodes
on
that
cluster
as
well.
In
the
blog,
we
actually
show
you
how
to
run
this
up
with
kind,
so
I'm
actually
using
a
kind
cluster.
If
you
don't
know
kind
check
it
out,
it's
a
great
tool
for
testing
out
these
features
and
running
with
them.
A
Okay.
So
what
I'm
going
to
do
in
this
to
check
that,
if
it's
enabled
I'm
actually
going
to
check
the
api
server
flags,
if
you
do
not
have
access
to
the
api
server
flags,
you
cannot
run
this.
This
will
not
work,
but
you
can
run
this
command
and
specifically
I'll,
go
and
highlight
it
in
that
big
list
of
different
emission
controllers
that
pod
security
is
indeed
present
in
that
list.
That
means
pod
security
is
indeed
enabled
on
this
cluster
and
that
I
can
use
this
feature
now.
A
A
A
So
I'm
running
that
command
now
and
then
I'm
going
to
actually
just
show
you
the
yaml
of
that
specific
name.
Space
called
verify
dash
pod
security,
just
to
prove
that
that
label
is
indeed
there
I'll,
go
and
highlight
it,
and
you
can
see
it
there
in
the
list
that
that
is
applied
to
that
specific
namespace.
So
what
we're
going
to
do
here
is
actually
do
an
interesting
command.
A
So
if
you
don't
know
this
one,
it's
a
fun
one
to
test
we're
going
to
do
a
run,
so
we're
going
to
run
tests
with
the
image
busy
box,
but
we're
actually
going
to
do
a
dry
run
equal
server.
So
I'm
going
to
try
to
apply
this
and
it
violates
the
policy
and
I
actually
get
an
error
back
that
it's
forbidden
because
it
violates
pod
security
policy
restricted
colon
latest.
A
So
because
of
these
reasons,
so
there
are
many
reasons
there
in
that
list
that
this
workload
violates
that
policy.
But
that's
just
a
great
way
for
you
to
test
that
it's
running
you
apply
a
restricted
to
a
test
name
space
and
then
actually
try
to
dry
run,
create
a
workload
on
the
cluster.
So
dry
dry,
run
server
is
something
I
use
all
the
time
to
test
the
capabilities
without
actually
having
to
run
a
workload.
A
A
Yes,
I've
got
a
prize
for
you,
okay,
yeah,
no
excellent!
So
I
know
it's
relatively
modern,
1.23
1.24,
so
you
need
to
check
that
it's
indeed
enabled
now
we're
actually
going
to
go
through
what
it
looks
like
to
apply.
Some
policy
then
create
a
workload
that
violates
that
policy
then
try
to
bring
it
into
compliance.
Okay,
sound
good,
excellent!
Thank
you
all
right
I'll!
Kick
this
one
off,
so
we're
going
to
apply,
create
a
privileged
level
enforce
on
privileged
and
create
a
workload.
A
So
again,
I'm
going
to
create
the
namespace
verify
dash
pod
security.
That's
indeed
created
I'm
going
to
label
the
namespace
with
the
dash
dash
overwrite,
because
I
didn't
clean
up
the
labels
from
last
time
on
this
test
cluster
and
we're
going
to
enforce
on
restricted
and
we're
going
to
audit
on
restricted,
okay,
so
we're
getting
the
hang
of
this
now
right.
Everybody
knows
what
we
need
to
do
to
turn
this
on
and
now
we're
going
to
take
a
privileged
workload
and
deploy
it
to
the
namespace.
A
We
expect
this
to
be
forbidden.
Why
do
we
expect
this
to
be
forbidden?
Because
I
have
in
this
pod
security
context,
allow
privileged
escalation
equals
true
and
that
violates
the
restricted
policy,
so
we're
going
to
go
and
use
this
pod
specification
and
apply
it
to
the
kubernetes
cluster,
and
what
we
should
expect
is
an
error
back,
and
indeed
we
get
an
area
for
the
pod
busy
box.
Privilege
forbidden
violates
allow
privilege
escalation,
does
not
equal
false,
so
again,
a
useful
error
message
for
your
users.
A
Okay,
I'm
going
to
go
ahead
and
actually
update
it
to
say
we're
enforcing
on
privileged
we're
warning
on
baseline,
as
I
said,
and
auditing
on
baseline,
so
we
actually
have
mixed
mode
there
across
enforce,
warn
and
audit,
and,
as
I
said,
this
is
a
great
way
to
enforce
and
make
our
users
move
help
users
move
to
baseline
okay.
So
I'm
going
to
deploy
this
privileged
workload
and
then
we're
gonna
check
if
it's
running
so
do
we
all
think
it'll
run
this
time?
A
Okay,
it
is
indeed
created
because
we
actually
set
the
privileged
policy,
so
we're
allowed
to
have
privileged
escalation
is
privileged
escalation
great
in
pods.
No,
it's
not
okay!
So
I'm
going
to
run
some
cleanup
here
and
now
we're
going
to
walk
through
more
complex
on
restricted
workloads
so
that
you
can
see
exactly
how
you
might
be
able
to
clean
them
up
and
look
at
them.
You
can
see
that
it's
running,
even
though
in
the
brackets
at
the
top.
A
A
Okay,
now
we
apply
the
labels
to
the
namespace.
What
we're
doing
this
time
is
enforcing
on
restricted.
Last
time
we
enforced
on
privilege
that
we're
enforcing
on
restricted
and
auditing
on
restricted,
so
we're
going
to
deploy
a
restricted
workload
in
this
namespace
and
you're,
going
to
see
a
little
different
behavior.
This
time,
which
is,
is
really
interesting.
A
Okay,
so
here's
our
restricted
pod
and
we
actually
have
a
security
context
with
a
loud
privilege,
escalation
false
and
we
add
a
capability
netbind
service
which,
if
you
look
up
in
the
pod
security
standards,
I
should
be
able
to
do
that
under
the
restricted
pod
security
standard.
So
I
expect
that
to
be
okay,
but
let's,
let's
see
what
happens.
A
Okay,
it
is
forbidden,
why
is
it
forbidden,
unrestricted
capabilities?
What
does
unrestricted
capabilities
mean?
You
actually
have
to
explicitly
set
fields
in
the
pod
specification
when
using
the
restricted,
you
cannot
infer
that
default
values
are
compliant,
so
you
have
to
explicitly
set
in
this
case
that
error.
I
need
to
drop
all
the
capabilities.
If
I
don't
explicitly
put
that
in
my
pod
specification,
I
will
not
be
compliant
so
here
I
am,
I'm
dropping
all
the
compa
capabilities
capabilities
all
specifically
and
adding
the
net
bind.
So
again.
A
I
think
I've
addressed
this
as
as
a
user,
but
this
is
interesting
with
restricted
policy.
It
does
not
allow
you
to
use
default
values
that
are
computed
server
side.
It
wants
them
to
be
upfront,
so
that
is
indeed
created
and
we
are
great
there
now.
I
want
to
go
through
one
other
use
case
here,
which
I
think
is
really
interesting
check
out.
The
pod
the
pod
is
stuck
in
container,
create
config
error.
What's
going
on,
it
passed
the
policy,
I
thought
we
were
good.
A
I
don't
know
what's
going
on,
so
what
I'm
going
to
do
is
go
and
describe
the
pod.
In
my
normal
cube
control
debug,
we
have
a
really
interesting
error
message
here
that
we
can
take
a
look.
Error
container
has
non
run
as
non-root
and
image
as
root,
so
only
when
we
execute
the
container
do
we
actually
see
that
it
wants
to
run
as
root,
and
we
can't
have
any
containers
running
as
root
right.
No,
no!
No!
A
So
now
that
we've
seen
that
we
can
actually
go
and
fix
this
up
and
what
we
need
to
do
is
actually
set
in
the
pod
specification
that
the
pod
cannot
run
as
root
again.
This
is
getting
these
pod
security
best
practices
out
there
and
allowing
you
to
have
a
safer
operating
environment
for
your
workload.
So
I'm
specifically
setting
to
the
runners
user
65
534,
so
this
pod
will
now
not
be
executed
as
root
in
the
container
namespace
or
the
pod
namespace.
A
A
Hopefully,
it's
running
this
time
excellent,
so
there
we
can
actually
see
it'll
actually
be
blocked
as
the
pods
trying
to
execute,
because
it
violates
the
policy
by
running
as
root.
Okay,
we're
going
to
clean
up
there,
one
more
demo
quickly.
This
is
how
I'm
going
to
show
you
the
metric
end
point
so
that
you
can
go
grab
them.
I'm
actually
using
cube,
cube
control,
get
dash
dash
raw,
slash
metrics,
but
you
could
have
prometheus
scrape
these
metrics
endpoints
and
we're
going
to
grab
pod
underscore
security.
Underscore
evaluations
underscore
total.
A
Now
why
this
is
important,
is
you
can
light
this
up
in
your
monitoring
dashboard
and
actually
see
hey?
What
have
I
got?
I've
got
a
motive
and
force
set
a
policy
level
set
to
privilege
latest
on
this
specific
name
space,
and
we
can
see
that's
been
hit
17
times,
so
you
can
actually
light
this
up
in
your
prometheus
or
any
of
your
monitoring
dashboards
and
know
where
all
your
violations
are
happening
or
where
all
the
allows
are
happening.
A
A
Okay,
next
steps.
So,
as
I
said,
what
are
you
gonna
walk
away
with
here
as
we
round
up?
Okay
go
experiment.
I
want
everybody
to
start
playing
with
this
understand
it.
It's
not
scary,
it
wasn't
scary
for
me,
and
hopefully
it's
not
scary,
for
you
use,
warn
and
audit
on
existing
name
spaces,
and
there
is
a
really
really
cool
trick.
You
might
say
to
me:
hey
loki.
I
have
clusters
everywhere
there
is
stuff
everywhere.
How
could
I
possibly
turn
this
on
that
sub
point?
A
A
If
you
run
dry
run,
it's
not
going
to
action,
it
you're
not
going
to
apply
the
label,
but
you
have
a
list
that
you
can
burn
down
on
a
specific
namespace
to
bring
all
those
workloads
back
into
compliance.
So
this
isn't
just
something
you
turn
on
in
a
brand
new
cluster
and
figure
it
out.
You
actually
have
some
tools
to
go
and
introspect
and
safely
use
it
on
clusters
that
already
have
a
bunch
of
workloads
to
deploy.
A
Okay,
I
always
say
you
know
general
set
warn
to
the
same
level
as
a
force,
because
that
helps
you
get
some
user
user
feedback
and
make
a
goal.
So
you
want
to
you
want
to
start
a
privileged
and
you
want
to
work
to
baseline.
You
want
to
make
sure
that
all
your
name,
spaces
are
at
least
a
baseline
and
then
selectively
figure
out
which
workloads
could
run
to
it,
restricted,
think
you
got
it
okay,
I
feel
like
I'm
leaving
everybody
in
good
hands
this
time
next
year.
A
I
don't
want
to
see
a
talk
at
kubecon,
saying
how
pod
security
ruined
my
life
and
lockheed
ruined
my
life,
but
if
it
is
I'll,
sit
in
the
front
row
and
listen
okay,
I
just
want
to
say
thank
you
for
coming
on
this
journey
through
pod
security
with
me.
So
now
it's
handed
over
to
you
so
long
and
thanks
for
all
the
fish-
and
I
do
want
to
thank
bridget,
tim
and
jim
for
their
review.
Thank
you
very
much.