►
From YouTube: Kubernetes SIG Auth 20190710
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20190710
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/preview
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
A
Alright,
hey
everyone:
this
is
the
July
10th
2019
sagat's
meeting.
We
have
actually
a
very
empty
agenda.
I
know:
Tim
has
an
important
topic
to
discuss
with
us,
but
I
wanted
to
get
anyone
else.
You
hadn't
had
a
chance.
If
there
any
topics
anyone
would
like
to
bring
up
before
we
move
to
Tim's
topic.
I
have
a
feeling
that
this
will
take
some
time.
A
B
B
B
Yeah
so
I
just
threw
together
this
deck,
to
kind
of
help
frame
the
frame
the
discussion
and
give
give
folks
some
background
on
some
of
the
things
we're
talking
about
and
and
then
we
can
kind
of
discuss
from
there.
So
I'll
just
take
a
few
minutes
to
kind
of
run
through
these,
so
I'm
I'm,
assuming
that
everyone
here,
you
can
go
to
the
next
slide.
Assuming
everyone
knows
what
pot
security
policy
is,
but
just
to
make
sure
we're
all.
On
the
same
page,
it's
a
built
in
policy
API
from
an
end
user
perspective.
B
C
B
Just
at
the
the
resource
level,
but
what
you're
capable
of
doing,
if
you
can
run
a
pod,
is
really
dependent
on
some
of
the
settings
on
that
pod,
and
so
you
can
go
to
the
next
slide,
and
so
the
that
kind
of
gets
into
the
goals
of
what
pod
security
policy
is
doing
for
us
sort
of
the
the
primary
goal.
Is
that
being
able
to
create
a
pod
or
any
sort
of
thing
that
creates
pods?
On
your
on
your
behalf?
B
We
don't
want
that
permission
to
be
equivalent
to
root
on
cluster
and
without
any
sort
of
policy
limitation
being
able
to
create
a
pod
means
you
can
create
a
privileged
route.
Pod
escalate
to
the
node
run
that
on
all
modes
take
over
the
cluster
so
running
without
this
is
equivalent
to
having
root
on
the
cluster.
B
B
So
pod
security
policy
has
been
stuck
in
beta
for
a
long
time.
I
think
it
might
have
first
gone
into
beta,
like
1/3
or
1/2
or
something,
but
there
were
a
lot
of
bugs
in
it
and
we
sort
of
brought
it
up
to
our
beta
quality
standard.
Around
1/8
fixed
a
lot
of
issues.
Then
it
hasn't
seen
a
whole
lot
of
development.
Aside
from
having
a
few
new
features
since
then,
and
it's
opt-in
and
so
I
would
say
this
current
status-
is
it's
pretty
confusing
to
enable
I?
B
This
is
my
impression
from
talking
to
a
lot
of
customers
and
users
and
kind
of
explaining
to
them
how
it
works.
It
is
opt-in,
we'll
go
into
this
more
later,
so
I,
actually
maybe,
let's
just
move
on
to
the
next
slide.
So
this
is
kind
of
where
the
confusion
comes
from
and
sort
of
the
first
would
I
consider.
Maybe
the
biggest
problem
with
cloud
security
policy
is
the
way
that
its
authorization
model
on
policies
works
by
the
way.
B
If
anyone
has
questions
or
comments
on,
these
slides
feel
free
to
interrupt
me
so
yeah,
so
that
just
a
bit
of
background
the
way
authorization
on
cloud
security
policy
works.
Is
you
create
a
cloud
security
policy
resource?
That's
a
cluster
scoped
resource,
but
on
its
own
it
doesn't
do
anything,
and
so
what
I
need
is
a
barback
or
some
other
authorization
to
say
that
I
have
the
use.
I
have
permission
to
for
the
use
verb
on
that
cloud.
B
Security
policy,
resource
that
I've
created
or
the
pod
service
account,
but
the
thing
that
you're
creating
the
identity
that
it's
running
with
that
has
the
use
permission
on
the
PSP
resource,
and
so
it's
kind
of
these
two
different
ways
to
be
using
it,
and
the
first
is
really
the
intuitive
one
like
I'm.
Creating
the
pod
do
I
have
permission
to
use
this
thing,
and
so
that's
kind
of
where
people
default
to
and
where
they
start
with,
and
that's
wrong,
I'm
just
gonna
kind
of
say
that
confidently.
B
If
you
do
it
that
way,
then
it's
gonna
break
any
future
controllers.
Anyone
else
who
needs
to
go
in
and
edit
that
pod
that
thought
after
the
fact,
and
so
the
better
way
of
doing
it
is
through
granting
the
service
account
permission.
Also,
generally
users
shouldn't
be
creating
clods
directly.
They
should
be
going
through
some
sort
of
control
or
a
deployment
replica
set,
etc,
and
in
order
for
that
model
to
actually
work.
Since
the
controller
doesn't
have
permission
to
use
the
pod
security
policy,
you
have
to
grant
it
to
the
plot
itself.
B
The
pod
service
account,
and
so,
but
just
that
just
the
presence
of
that
first
model
creates
a
lot
of
confusion
and
actually
weakens
security.
For
instance,
you
can't
have
a
privileged
controller
that
creates
pods
and
have
those
pods
being
forced
through
the
pod
security
policy
mechanism,
because
that
privilege
controller
needs
permission
to
use
the
privileged
pod
security
policy.
Therefore,
anything
it
creates
also
has
permission
to
use
that
so
next
slide
or
any
questions
on
that
before
I
move
on
so.
D
D
B
E
F
G
D
G
And
we
we
talked
about
you
know
the
act
of
impersonation
of
service.
Account
was
actually
originally
intended
as
the
thing
that
would
allow
a
controller,
but
it
didn't
scale
and
we
never
put
any
more
time
into
it
like
like
no
Tim's
right,
like
the
very
first
design
said
well,
we
can't
go
solve
the
controller
delegation
problem
without
spending
two
years
and
a
bunch
of
theory,
because
we've
never
seen
a
good
model
and
we
don't
know
whether
the
controller
model
is
even
going
to
work.
So
we'll
just
pick,
the
delegation
will
pick
V.
D
D
Having
an
operator
and
and
having
that
operator
understand
what
components
are
accrete
are
handling
the
creation
of
pods
and
associating
the
right
permission
set
with
them
rather
than
with
particular
users,
because
the
user
I
mean
the
user
could
be
a
group,
but
the
user
could
be
ephemeral
right
like,
but
but
managing
that
pot
over
time
is
actually
is
important
to
keep
separated
so
I'm
I'm
not
opposed
to
the
service
account
I,
think
it
makes
sense.
Yeah.
G
I
think
Tim
I
would
say,
like
the
dual
model
weakens
security
on
this,
like
it's
it's
hard
for
people
to
outside
to
understand
what
that
means
and
I
don't
know
they're
busy.
It's
like
the
the
thing
we
really
want
to
say
here.
Is
you
grant
anybody
who
can
create
pot?
You've,
you've
done
something
better,
which
is
great.
Anybody
can
create.
Cons
is
rude
on
the
whole
cluster.
To
anybody
who
can
create
pods
can
do
the
maximum
of
permissions
that
that
namespace
can
do,
which
is
better,
but
it's
not
really
far
enough.
G
Yeah
I
mean
we
saw
issues
where
people
were
running,
a
controller
manager
against
the
unsecured
port,
and
so
it
was
implicitly
a
super
user
and
so
I
I
think,
it's
actually
worse
to
say,
here's
a
policy
tool.
You
can
lock
things
down
and
people
think
they've
locked
it
down,
but
because
their
controller
manager
is
a
super
user,
they
actually
haven't
locked
anything
down.
G
D
Also
confusing
when
you
can
actually
find
it's
that
type
of
permission
to
a
specific
namespace,
so
I've
seen
models
and
actually
even
heard
promoted
models
where
people
are
saying
just
you
know,
find
it
to
all.
The
servers
accounts
that
the
controller
manager
has
to
a
specific
namespace
to
a
specific
policy,
and
in
this
way
you
can
limit,
but
that's
very
confusing
I
mean
like
this.
In
this
way,
you
can
limit
what
pod
security
policies
are
relevant
to
a
given.
Namespace
I
mean
security.
G
Policy
was
always
intended
to
protect
the
nodes,
basically
like
what
what
can
you
tell
a
pod
to
do
that
would
prevent
it
from
doing
privileged
things
or
root
level
things
or
privilege,
escalation
things
or
host
volume,
things
on
node
and
so
like
being
able
to
scope
it
to
a
namespace
is
interesting,
but
we
don't
actually
have
controls
of
the
namespace
level
that
force
specific
namespaces
to
be
associated
with
specific
notice.
There
are
like
alpha
level
admission
plugins,
but
we
don't
have
policy
in
place
that
says
alright.
G
You
can
only
create
privileged
things
in
this
namespace,
but
you
can
then
turn
around
and
say
alright,
well
create
a
purplish
thing
in
the
same
space
and
send
it
to
any
node.
So
it's
like
there's
this
chain
of
policies
that
are
required
and
pod
security
policy
is
one
link
in
that
chain,
but
it's
not
sufficient.
It's.
D
Interesting,
though
I
mean
you
raise
a
good
point,
and
this
is
actually
my
main
concern
in
this
conversation.
Is
that,
like
you
know,
with
the
changes
to
things
you
know
pulling
and
pulling
out
things
that
work,
you
know
heavily
used
in
cubelet
and
mechanisms
like
that
suffer
the
limits
of
things
for
like
privilege,
containers
and
those
sorts
of
things
locally.
Now
literally,
this
is
the
only
this
is
the
only
line
of
defense
flawed,
so
it
may
be
this.
D
D
F
A
F
Don't
think
the
problem
is
that
we're
removing
this
line
of
defense,
but
I
think
the
problem
is
that
there
are
some
checks
that
are
independent
of
the
subject
of
making
the
request,
and
then
there
are
some
checks
that
are
dependent
on
the
subject
making
the
request.
So
if
the
pod
has
a
specific
service
account,
that's
independent
of
the
person
making
the
request
and
then,
if
the
person
making
the
request
is
a
service
gap,
then
it
is
a
dependent
check.
F
B
B
B
This
is
you
know,
sort
of
generally
considered
a
desirable
property
for
security.
This
means
that
you
know
by
default,
once
you're
enabled
plot
security
policy.
You
are
secure
unless
you've
explicitly
granted
access
to
something,
but
it
means
that
it's
very
difficult
to
roll
out
pod
security
policy,
since
you
need
to
have
it
if
you're
tight
at
an
existing
cluster
that
you
want
to
enable
it
on,
you
have
to
have
policies
lined
up
for
every
single
thing
running
before
you
can
enable
and
there's
no
dry
run
mode.
D
B
D
The
point
there
are
a
number
of
organizations
that
are
actively
working
toward
making
this
an
easier
prospect.
I
mean
even
ETS
now
has
a
reasonable.
You
know
permissive
and
restrictive
policy
when
you
enable
pod
security
policies
within
that
cluster,
so
I,
although
I,
do
agree,
it's
difficult
to
roll
out
I,
don't
think
it's
very
difficult
and
I
feel
like
it's
getting
easier
as
we
gain
more
adoption
and
more
people
are
playing
with
it.
G
E
D
It's
an
important
tool
but
I
think
that
I
mean
it's
a
powerful
tool.
I
should
say
you
know,
having
being
able
to
define
policy
that
like
restricts,
you
know,
specific
things
at
a
cluster
level
means
that
you're
going
to
affect
the
ability,
for
particular
things
to
run,
and
this
is
definitely
a
pain
point
that
I
see
every
day
and
in
working
with
people
with
this
stuff.
D
Right
in
that
in,
in
that
you
know,
a
controller
has
created
a
pod,
but
it
doesn't
understand
that
particular
punch
created
policy
would
apply
and
it
doesn't
know
how
to
adjust
for
that.
So
it's
it
is
painful
thing,
but
at
the
same
time
the
ability
to
to
atomically
associate
pod
security
policies
and
work
around
these
things
is
another.
Is
another
powerful
tool
at
our
disposal
right
that
you
can
tie
it
to
a
service
account.
So
I
can
say
this
operator.
D
G
Of
it,
no
disagreement
about
like
that
property
being
important,
I,
think
it's
more.
A
question
of
PSP
only
has
the
all-or-nothing
approach.
As
far
as
enablement
like
like
Tim
said,
you
have
to
fully
account
for
every
workload
running
on
your
cluster.
You
can't,
you
know
dry
run
it
against.
One
newspaper
can
area
against
one
namespace
easily
yeah.
D
Normally
I
see
the
dry
run,
things
happening
in
different
environments,
so,
like
I,
don't
I
don't
enforce
admission
in
depth
by
doing
force
admission
in
in
staging
a
mint
and
from
staging
I.
Do
it
enforce
it
into
production?
And
so
that's
why
I
find
some
successful
customers
are
trying
to
figure
out
a
path
toward
it
is
that
that
promotion
model
you've
seen
that
with
PSP,
where
you
run
ESP
and.
D
That
is
that
I
mean
PSP
doesn't
have
a
non
enforcing
load.
Is
that
well
you
different?
You
would
define
the
pod
security
policy
within
the
construct
of
the
development
environment
in
which
it
doesn't
do
anything
right,
but
at
least
at
that
point
we
could
do
things
like
use
like
Cisco's
PSP
advisor,
harsh
writing,
assistance,
PSP
adviser
to
se.
C
D
See
if
the
pod
is
actually
get
enough
relevant
information
to
define
a
reasonable
pod
security
policy-
or
you
know,
give
it
a
place
to
spin
a
starting
point.
So
the
people
could
actually
define
these
policies
and
then,
when
this
work
is
promoted,
when
this
particular
path,
security
policy
is
then
promoted
to
staging.
We
can
see
what
falls
off
the
bus
right
and
fix
it
in
staging
that.
F
B
B
What
features
are
on
and
off,
and
it's
also
impossible
to
make
it
part
of
conformance
suite,
because
it's
a
has
to
be
optional,
behavior,
so
moving
onto
problem
three,
this
one
is
I
would
say
the
least
import
and
least
significant
of
the
problems
it's
more
like
just
PSP
has
evolved
over
a
period
of
time,
and
this
has
led
to
some
kind
of
confusing
messy
api's.
This
is
all
easy
to
solve,
with
a
v2
API
or
where
maybe
we
don't
even
need
to
solve
it.
B
But
a
few
things
just
call
out
here
is
that
we've
gotten
a
lot
of
requests
over
the
years
for
adding
in
more
controls
to
pod
security
policy.
Some
of
those
have
been
added,
and
it's
kind
of
grown
in
complexity
and
some
of
those
we've
kind
of
put
our
foot
down
and
said.
No,
but
there
is
this
desire
to
sort
of
build
this
more
powerful
policy
mechanism
and
have
it
work
for
all
sorts
of
nice
use
cases
and
also
PUD
security
policy
doesn't
really
compose
with
other
policies.
B
Since
it's
sort
of
an
allow
kind
of
you
have
to
have
a
single
policy
that
allows
everything
in
the
pod
in
order
for
it
to
be
accepted.
So
you
can't
have
say
like
one
policy
that
deals
with
the
the
privileged
aspects
and
one
policy
that
deals
with
the
the
volume
aspects
you
can
sort
of
make
that
work
across
different
admission
controllers,
because
that
mission
controllers
are
sort
of
constraining
by
default.
B
B
I'd
argue
that
pod
security
policy
doesn't
do
a
great
job
of
that,
because
you
still
have
to
understand
things
like
well.
If
you're
running
is
non-root
and
you
should
also
really
enable
or
disable
allow
privilege
escalation.
If
you
disable
allow
privilege
escalation,
that's
going
to
break
utilities
like
and
all
sorts
of
fun
gotchas
like
that.
B
B
So
I
think
the
three
options
that
I
know
that
are
on
the
table
for
how
to
move
forward
here
is
to
to
fix
some
of
these
problems
that
I
called
out
in
cloud
security
policy.
That's
kind
of
what
we
started
to
get
to
of
like
well.
Could
we
bind
the
policies
to
namespaces
or
figure
out
some
sort
of
delegation
model
figure
out
some
way
of
cleaning
up
the
denied
by
default
behavior
so
that
we
can
enable
it
more
widely?
And
then
we
would
need
some
sort
of
migration
path
to
the
speech.
B
Ooh
and
I
don't
want
to
go
in
too
much
into
the
details
there,
but
kind
of
that's
an
option
on
the
tables
to
fix
pod
security
policy
and
bring
it
to
GA.
We
could
also
say
we're
going
to
start
over
from
scratch
with
a
new
entry
policy
mechanism.
This
could
kind
of
go
and
I
could
see
this
going
in
two
different
directions.
B
One
would
be
to
say,
let's
distill,
pod
security
policy
down,
to
be
like
the
bare
essentials
like
what
are
the
sort
of
the
fundamental
minimum
things
that
people
need
to
be
able
to
constrain,
to
run
this
cluster
safely
and
for
all
of
the
other
nice
use
cases.
There's
plugins.
The
other
direction
would
be
to
go
for
a
really
flexible
policy
mechanism,
maybe
sort
of
like
an
opal
light.
B
That
would
let
you
cover
all
of
those
new
shoes
cases
in
this
kind
of
fancy
policy
mechanism,
and
maybe
we
could
try
and
make
it
ways
of
simplifying
it
as
well.
That
starts
to
look
a
lot
like
gatekeeper,
built-in
tree,
so
yeah,
and
then
the
third
option
is
say
well
this
the
like
space
here
is
too
large,
and
we
have
this
nice
web
bug
mechanism
for
arbitrary
admission
controllers.
B
So,
let's
just
let's
leverage
that
ecosystem
and
move
this
behavior
out
of
core,
and
so
we
could
actually
take
the
existing
cloud
security
policy
controller
and
move
it
to
a
web
hook
for
people
who
have
are
already
depending
on
that
functionality
and
then
work
towards
standardizing
the
community
around
some
sort
of
policy
framework
and
I.
Think
gatekeeper
looks
particularly
promising
here.
It's
still
in
early
development,
so
and
then
I
don't
know.
D
One
of
my
concerns
with
me:
you
highlighted
it
like
perhaps
bad
security
policies,
don't
do
an
incredible
job
of
finding
a
lot
of
detail
around
what
was
happened.
Evil
particular
five
from
that
sort
of
stuff,
but
at
the
same
time
I
feel
like
it's
it
is.
It
does
a
reasonable
job
of
exposing
those
enough
that
define
the
constraints
that
should
be
necessary
for
operators
to
secure
cabrini.
D
It
is
even
even
in
some
reasonable
way,
so
I
feel
like
having
some
eight
core
API
that
even
if
it's
just
the
Distilled
PSP
essentials
I
feel
like
having
some
creepy
eyes
it
does.
It
does
give
you
a
mechanism
that
a
way
by
which
to
learn
what
those
knobs
are
is
is
pretty
critical
to
the
product.
My
opinion,
it.
F
F
H
Know
personally,
I
don't
I
I,
don't
really
a
strong
opinion
as
to
how
PSP
should
built,
but
I'll
say
that
number
three
sounds
like
bad
things
waiting
to
happen.
It
kind
of
reminds
me
of
roll-your-own
authentication,
roll-your-own
crypto.
A
lot
of
people
really
don't
know
how
to
do
this
stuff
correctly.
You're
gonna
think
they've
done
it
beautifully
and
goes
back
to
the
what
we
think
we
have
it
locked
down
and
really
it's
wide
open.
B
But
what
I'm
suggesting
is
more
that
you
know
we
lean
on
the
ecosystem
and
you
know
even
contribute,
as
you
know,
sig
auth
contributors
towards
developing
some
of
these
options
and
and
building
building
best
practices
around.
You
know:
here's
a
here's,
something
that
we
endorse
and
we
think
it
solves
the
problems
the
differences
plaintiff.
Does
the
code
live
in
github,
comm,
/,
kubernetes,
/,
kubernetes
or
somewhere
else.
H
So
I
certainly
I
certainly
agree
with
the
idea
of
making
it
extensible,
I
I,
guess
the
the
caution
I
would
put.
There
is
once
you
move
it
outside
of
the
tree.
You
have
to
do
more
than
just
lock
down
your
cluster,
so
I'll
give
you
an
example:
OPA
with
OPA
you're,
usually
importing
a
lot
of
information
from
the
cluster
into
that
internal
database.
To
make
decisions.
Well,
don't
actually
walk
down
that
import
process.
H
Those
people
don't
walk
down,
making
sure
that
they're
validating
the
tokens
that
come
in
they're
trusting
criminais
is
as
it
goes
so,
while
it
would
require
a
really
specific
attack
to
be
able
to
compromise
those
things.
That
is
that,
if
you're
blindly
trusting
the
data
inside
of
that
database
without
having
a
way
to
know,
that's
protect
and
audited
you
leaving
yourself
open
so
Matar
gyu.
That
number
three
shouldn't
be
the
first
place.
H
If
you
have
a
specific
use
case
that
needs
something
outside
of
whatever
PSP
becomes,
then
yeah
three
should
be
a
good
option,
because
if
you're
going
there,
then
you
know
there's
an
expectation.
You're
gonna
have
at
least
some
expectation
as
to
what
you're
doing
but
I
think
as
a
starting
point
would
be
a
really
bad
idea.
I.
F
F
The
second
one,
I,
don't
think,
is
really
has
really
happened
with
PSP,
considering
that,
basically,
all
helm
charts
failed
with
PSP
enabled
it
might
get
better
if
it
was
on
by
default
or
people.
There
was
more
broadly
used
and
I.
Don't
know
that
how
it
will
be
affected
with
something
that
is
outside
of
core.
E
D
D
So
I
feel
like
it
needs
to
be
in
core,
because
it
gives
us
a
place
to
start
with
that
right.
We
need
to
have
some
some
some
way
of
understanding
what
those
knobs
and
dials
are
that
are
that
are
like,
as
you
said
earlier,
you
know,
put
forth
by
say,
goth
as
a
reasonable
set
of
controls
with
which
to
define
what
a
secure
pod
implementation
might
look
like
in
an
inside
of
a
cluster.
If
it's
outside
of
the
cluster
I
feel
like
this
would
be
defined
too.
D
You
know
in
ways
that
are
incompatible
with
each
other
and
I
feel
like
it
would
go
sideways
very
quickly
and
be
very
difficult
to
to
level
the
level
people
up
on
it.
I
do
agree
that
it
should
be
extensible
and
that
there
it
and
then
it's
entirely
possible
to
do
this
with
a
webhook
model
and
I,
don't
see
any
reason
why
people
by
people
wouldn't
be
able
to
do
that
in
the
future.
Regardless,
you
know
by
understanding
what
the
resulting
pod
security
policy
might
do
to
affect
the
pods
configuration
and
define
mutating
or
validating.
D
G
Think
part
of
the
issue
is
that
there
it's
not
clear
what
the
proper
surface
is
so
the
the
ramp
from
like
the
the
simplest
version,
which
is
don't.
Let
me
root
the
cluster,
because
I
can
create
a
pod.
Well,
that's
that's,
actually
pretty
easy.
Just
disallow
tons
and
tons
of
stuffing
pods
right,
like
drop
all
capabilities
and
don't
run
his
route
and
don't
allow
any
volume
mounts,
except
like
the
config
map
and
secretin
PVC
ones
and
like
just
disable
a
bunch
of
stuff
in
pods.
But
then
the
next
issue
is
like,
oh
well.
G
We
were
using
some
of
that.
So
now
we
need
like
all
this
fine-grained
stuff
and
then
that's
just
kind
of
in
the
allow
disallow
category.
Then
the
next
level
is
oh
well.
I
want
to
change
incoming
pods,
so
I
want
to,
like
Tim
mentioned
separate
the
author
in
the
pod,
from
the
person
managing
storage,
and
so
now
you
have
like,
oh
well,
when
a
pod
comes
in
stomp
in
like
an
FS
group,
so
that
they
can
access
the
storage
and
some
of
those
things
layer
in
pretty
easily
and
some
of
those
things.
G
D
Think
the
challenge
there,
though,
is,
is
that's.
That's
gonna,
be
true
regardless,
in
my
opinion,
right
like
whether
you
do
this
with
an
external
mechanism
of
you,
defining
your
policy
through
gatekeeper
or
thumb,
or
some
other
policy
framework
or
whether
you're
doing
that
through
security
policies
doesn't
really
change.
Anything
except
your
the
surface
is
the
same
right.
You're
still,
gonna
have
to
figure
out,
you
know
where
you
have
brittleness
and
how
to
adjust
for
it
one
way
or
the
other
yeah.
G
Is
when
you
start
mixing
policies
from
different
layers
so
like
if
you
had
a
pod
security
policy,
that
was
doing
one
thing
and
then
to
do
like
a
scheduling
policy,
you
had
to
do
a
web
hook.
That
did
something
else.
Those
are
now
like,
controlled
and
audited
and
applied
in
completely
independent
ways.
I
think.
E
Based
on
the
experience
we
have
from
the
past
several
years,
working
on
this
off
and
on
and
how
things
have
progressed,
that
we
are
more
likely
to
succeed
by
turning
something
over
to
out
of
tree
external
implementations,
so
that
people
feel
empowered
to
go
out
and
try
to
solve
this
problem,
and
maybe
they
come
up
with
something
new
we
haven't
even
thought
of.
Maybe
maybe
it
works
better,
but
we
built
these
extensibility
books,
fair
reason
and
we
haven't
done
a
great
job
entry.
So
it
seems
like
the
best
option.
We
have
yeah.
F
F
F
C
Thanks
Mike
walking
here
just
speaking
as
a
representative
gay
Kiba,
the
gate,
keeper
project
I,
think
one
of
the
exercises
were
taking
a
look
at
up
in
the
gatekeeper
community
is
trying
to
build
out
PSP
to
see
what
it
would
look
like.
So
taking
all
the
policies
that
it
currently
supports
in
the
way
that
it
works
and
modeling
that
in
gatekeeper
and
having
a
look
at
how
that
operates,
would
be
probably
something
that's
fairly
beneficial
for
both
sides,
just
to
get
a
crock
of
that,
and
then
you
know
shipping.
C
You
know
a
blessed
set
of
api's
that
constitute
what
Web
PSP
is
today
may
may
be
helpful.
The
community
and
there's
probably
no
reason
gatekeeper,
couldn't
even
ingest
the
current
set
of
api's
and
model
them
in
you
know
the
language
that's
there
as
well.
That
could
also
be
a
possibility,
but
the
gatekeeper
project.
You
know
the
several
representatives
reader
and
max
on
this
call.
You
know
interested
in
you
know
we're
kind
of
got
a
lot,
much
larger
scope
and
what
we're
seeing
is
customers
saying?
C
How
do
we
generically
solve
policy
on
kubernetes
and
what
you've
got?
Is
this
disconnected?
We
go
and
do
this
PSP
thing
to
get
this
stuff,
and
then
we
go
and
do
this
other
stuff
to
get
this
other
stuff.
Why
don't
we
do
it
the
same
way
everywhere
and
is
that
possible?
So
people
are
saying
today
if
we
have
gatekeeper
rather
than
turning
on
PSP,
because
features
like
dry
run
are
being
built
into
gatekeeper
and
audit
and
things
that
address
a
lot
of
the
usability
options.
C
D
D
You
know
a
more
consistent,
API
and
policy
framework
set
with
which
you
apply,
which
with
which
you
scratch
all
those
witches,
whether
they
are,
whether
they
are
about
security
policies
or
network
policies
or
any
number
of
things,
a
way
that
you
can
define
those
probably
not
never
cause.
It's
big
is
the
idea.
D
You
know
define
those
things
consistently
for
your
organization
would
be
great
to
answer
your
most
question,
I
think
the
things
that
we
get
out
of
it
and
I
don't
wanna
I,
don't
have
belabor
this
too
much,
but
I
think
that
we
get
the
thing
that
we
get
out
of
pod
security
policies.
Existing
in
core
is
the
ability
to
teach
people.
D
What
are
what
what
things
are
important
around
securing
pods
right,
whether
they
are
manifested
by
some
external
policy
controllers,
whether
we
advanced
the
way
with
which
we
enforce
these
things,
I
think
is
almost
is
almost
beside
the
point
I
feel
like
we
have
to
continue
to
define
what
what
bounds
and
dials
are
important
to
think
about
consistently
in
some
way
that
is
accessible
to
kübra,
need
to
operators
of
kubernetes
clusters
and
having
different
common
definition.
Action
is
critical,
I.
E
B
Yeah
I
mean
that
that's
kind
of
we
are
today's,
so
you
already
need
to
teach
someone
that
hey
there's
this
thing
called
cloud
security
policy.
You
need
to
go
and
turn
it
on,
and
then
you
need
to
also
teach
them
how
to
use
it,
which
is
kind
of
complicated.
There's,
no
reason
we
could
have.
You
know
that
same
documentation.
F
B
H
Right
but
I
think
I'm,
you
know,
authentication
is
from
a
couple
times
on
the
chat
side
of
things
and
I.
Think
there's
an
analogy
there
in
that
most
folks
are
having
a
hard
enough
time
with
authentication,
which
is
orders
of
magnitude
easier
than
this
problem
to
solve
and
yeah
having
to
externalize
the
authorization,
at
least
at
the
most
basic
level.
I
think
it's
gonna
create
a
much
higher
barrier
to
entry.
Even
saying
you
know.
Let's
say
there
is
a
opa
llamo
file
that
gives
you
OPA.
H
It
gives
you
the
the
baseline
policy
that
it's
all
set
up.
You
know,
maybe
it's
even
an
operator
so
that
everything
stays
updated,
but
you
know
the
second
anything
you
should
change
or
you
know
somebody
needs
to
understand
what
that
is,
or
even
is
Arnie.
Okay,
Todd
built
on
the
version
of
yeah
or
the
containers
built
with
something
that
my
organization
has
certified.
I
think
once
you
start
requiring
external
pieces
for
something
as
complex
as
authorization
gets
very
complicated,
very,
very
quickly.
B
B
C
F
Entry
and
out
of
tree
I
wasn't
using
that
fork
or
I,
don't
think
they
necessarily
mean
to
live
in
the
github
repo,
with
everything
else.
I
think
that
may
be
what
I
was
thinking
of
is
better
considered,
I
want
to
say
conformance
or
standard
across
kubernetes
deployment.
So
I
think
that's
what
what
is
important.
I.
F
That
back
to
the
reason
for
Standardization,
not
necessarily
entry,
is
that
they
can.
We
can
use
functionality
to
protect
core
kubernetes
infrastructure
and
second,
we
can
allow
security
for
portable
application
definitions
like
helm.
We
can
improve
the
security
posture
of
those
applications
for
all
users.
I
think
those
are
the
reasons
for
a
standard
offering
across
kubernetes.
That
is
conforming,
regardless
of
whether
it's
a
negative
repo
I'll.
G
Note
then
I
don't
think
PSPs
like
the
problem.
Psp
is
they're
a
little
bit
like
what
happens
when
you
give
when
you
hard-code
rolls
and
roll
bindings
to
service
accounts
into
a
home
chart
which
is
there's
no
actual
review
there,
and
so
it's
possible,
but
it's
just
creating
another
problem
in
terms
of
distribution
like
it's.
What
permissions
are
you
actually
granting
this,
and
did
you
understand
what
those
permissions
are?
I,
its
the
portability
is
very
possible,
but
without
solving
that
larger
problem,
I'm
not
sure
it's
even
worth
it
from
a
portability
perspective.
G
I
wouldn't
want
to
solve
the
portability
problem
without
actually
not
creating
a
new
security
problem.
There
yeah
I
installed
the
component
through
helm
and
it
gave
it
self
privilege
root
access
on
the
entire
cluster,
which
violates
the
intent
of
PSD
in
the
first
place,
which
is
to
let
admins
control.
Who
can
do
what
yeah
I
see
I
mean
operators
are,
operators
are
almost
completely
broken
unless
you
have
a
trusted
party
reviewing
and
approving
what
permissions
an
operator
can
ask
for.
G
F
To
namespace
scoping
might
be
a
little
bit
better
yeah,
but
potentially
what
Tim
was
talking
about
with
composability
of
add-ons
and
just
granting
that
orchim
possibility
of
PSPs
and
granting
those
two
namespaces,
so
they
can
do.
The
basic
stuff
might
also
solve
that
problem
without
having
to
create
a
specific
role
binding
for
a
service
account
that
helm
decides
to
use
right.
G
In
some
ways
it
seems
like
there
are
conflicting
goals
like
what
one
of
the
goals
for
portability
is
that
the
same
deployment
works
on
like
I
can
reasonably
expect
you
to
work
in
different
clusters,
and
there
are
a
couple
ways
to
accomplish
that.
If
you
run
a
cluster
that
is,
has
titers
security
settings
than
most
deployment.
G
Authors
consider
and
one
is
to
force
settings
into
the
deployment
or
into
the
pods
that
make
it
conform
to
your
stricter
requirements,
and
that,
like
works
great
for
creating
the
API
objects,
but
in
our
experience,
typically
breaks
pods
when
they
actually
try
to
run.
So
it's
great
that
you
told
me
to
run
as
a
random
youíd,
but
now
I,
don't
work,
and
so
I
I'm,
not
sure.
If,
like
we're,
gonna
get
to
a
point
where
deployment
authors
who
don't
think
about
any
of
these
security
aspects
are
going
to
be
successful.
G
So
pause
security
bolts
they
tried
to
air
like
on
the
side
of
I,
guess,
ease
of
use
by
like
helpfully
saying.
Oh,
your
deployment
didn't
specify
these
settings.
I
will
now
go
set
them
for
you,
where
it
probably
would
have
been
simpler
and
maybe
like
in
the
end
just
as
useful
to
just
reject
things
out
of
hands
like
nope.
You
didn't
you
are
out
of
out
of
compliance
like
you
can't
run
these
things.
You
need
to
go
change
your
deployment
that
would
give
like
back
pressure
to
the
deployment
authors
to
say.
G
G
Some
of
the
things
that
we
had
in
there
were
oriented
around
like
force
in
specific
you
heads
so
that
you
can
get
file
permissions.
Some
of
that
is
easier
to
do
now
with
Web
books.
So
it's
somewhat
over
Thugga
know
like
if
someone
has
a
mapping
of
like
LDAP
users
to
namespaces,
and
they
say
everything
in
this
namespace
is
gonna
use
this
storage
so
random.
G
C
G
Anyway,
I,
like
I,
think
we
need
to
untangle
kind
of
the
goals
like
are
we
trying
to
protect
the
cluster?
We
can
do
that.
More
simply,
are
we
trying
to
give
people
knobs
for,
like
all
these
security
settings,
to
fine-tune
things
like
a
define
tuning
level
that
probably
belongs
in
web
hooks
and
extensibility
mechanisms,
but
then
there's
this
big
middle
ground
and
there's
always
disagreement
about
where
that
middle
ground
ends.
B
Yeah
I
agree
with
that:
I
think
what
you're
getting
at
is
sort
of
that
2a
option
and
I
welcome
anyone
who's
interested
in
this
to
to
put
out
a
proposal
for
this,
but
I
think
like
in
practice.
It's
it's
pretty
difficult
to
actually
define
like
what
that
minimum
bar
actually
ends
up.
Looking
like
in
a
way,
that's
not
just
gonna
like
end
up
looking
like
cloud
security
policy
in
three
years
from
now,
when
we
add
Windows,
pod
settings
and
all
sorts
of
other
things
in
there.
A
And
are
we
expecting
something
like
PSP
to
enable
running
soar
like
random
things
you
find
in
home?
Charts
like
it?
Is
that
an
actual
like
goal
I
cop
to
me
like
it,
makes
sense
like
on
a
deaf
cluster
to
say,
okay
I'm,
going
to
try
out
this
cool
thing
that
you
can
run
on
cue
or
or
your
cue
variant,
but
like
I,
wouldn't
expect
that
to
be
a
thing
you
can
just
lift
in
to
prod
and
say:
yeah.
A
That's
gonna
work,
because
I
generally
assume
that
the
environment
that
you
have
in
dev
versus
prods,
probably
just
going
to
be
tighter
in
all
sorts
of
ways.
So
you,
as
the
person
who
wants
to
run
this
component,
has
to
do
some
extra
work
right,
but
I
don't
think
like.
We
have
some
generic
way
to
sort
of
guarantee
that
oh
we'll
tighten
your
pod
just
right
and
as
Jordan
mentioned,
it
might
default
it
and
force
it
down.
But
then
they
might
stop
working
altogether,
like
the
actual
app
might
stop
working
I.
F
G
Policy
at
the
API
level
like
doesn't
have
the
information
it
needs
to
make
a
lot
of
those
decisions,
and
so
whether
it's
odd
security
policy
or
external
admission
or
some
entry
replacement,
like
a
lot
of
the
decisions,
just
lack
the
information
required
and
so
I
think
if
pods
were
required
to
specify
fully
like
the
information
about
what
they
were,
who
they
were
going
to
run
as
and
think
we
can
make
a
lot
better
decisions.
We
could
catch
things
a
lot
earlier,
whether
it
was
entry
or.
G
D
Completely
agree
that
mutating
we
mean
for
the
most
part,
is
definitely
hard
to
reason
about,
especially
because,
because
of
the
ordering
thing
right
like
validating
will
hit
first,
so
anything
that
you
have
that
might
validate
any
pond
security
policy
that
you
might
have
that
validates.
It
no
longer
looks,
there's
no
mutation
that
happens
after
that.
I'm
s,
that's
confusing
for
sure.
Yeah.
G
So
how
forward
like
Tim
said
if
people
have
ideas
about
like
a
minimal
set,
but
it
probably
wouldn't
be
pond
security
policy
like
for
compatibility
like
the
existing
API
and
the
existing
admission
plug-in,
can't
really
make
a
fundamental
change
like
that.
If
we
wanted
to
do
major
changes,
it
would
have
to
be
like
a
separate
submission,
plugin
or
a
separate
API.
G
B
We're
just
about
out
of
time
here,
but
I
wanted
to
kind
of
finish
with
saying
that
anyone
who's
worried
that,
like
we're
gonna,
take
pot
security
policy
away,
we
will
not
deprecated
it
or
remove
anything
until
there's
good,
viable
replacements,
with
smooth
migration
paths
and
everything
like
that.
So
yeah,
don't
don't
worry
about
that
going
away.
This
is
essential.
G
That's
also
why,
when
people
say
it
was
just
gonna
go
to
be
one
like
the
problems
with
the
current
set
up
are
pretty
severe
in
some
cases,
and
so
it's
not
clear
that
we
want
to
promote
this
and
say
oh
yeah.
This
is
this
is
the
thing
that
everyone
should
be
using
look
weak.
Nobody
should
explore
a
bit
through
things.
Nobody
should
explore
alternative,
simpler,
more
comprehensive
or
comprehendible
solutions,
because
this
is
GA,
and
this
is
the
way.
So
that's
that's
the
hesitation
and
why
it
hasn't.
D
This
seems
somewhat
analogous
to
the
ingress
to
the
ingress
argument
in
some
ways,
but
but
I
hear
what
you're
saying
it's
been
it's
great
to
hear
that
it's
not
going
anywhere
and
then
in
the
near
term,
I
think
it'll
be
interesting
to
see
like
a
race
between
the
adoption
of
it,
and
you
know
things
like
I
keep
picking
up
picking
up
where
it
left
off.
That's
right.