►
From YouTube: sig-auth bi-weekly meeting 20201111
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
hello,
everyone
welcome
to
sig
off
for
november
11th
2020..
The
I
think
the
big
discussion
topic
that
we
have
on
the
agenda
today
is
the
future
of
pod
security
policy.
A
I
know
we've
discussed
this
a
few
times
in
the
past,
but
we
haven't
actually
come
to
any
sort
of
definitive
conclusions.
Yeah
and
pod
security
policy
is
on
a
on
a
timeline
at
this
point
because
of
the
no
perma
beta
policy
that
went
into
effect.
I
think
it
was
last
release,
if
I
remember
correctly
or
sure
david
can
correct
me,
so
I
believe
pod
security
policy
is
currently
on
track
to
be
deprecated
in
1.22
by
default.
That
is
sort
of
the
the.
A
If
we
do
not
take
any
action,
pod
security
policy
will
go
away.
That
does
that's
not
a
decision
for
it
to
go
away,
although
that
is
a
decision
that
we've
discussed
in
the
past
so
yeah.
So
we
do
need
to
actually
make
a
decision
here,
otherwise
one
will
be
made
for
us
by
default.
A
B
A
Me
make
that
a
little
bigger
too
yeah,
so
I
tried
to
capture
some
of
the
things
that
we've
discussed
in
the
past
for
people
who
are
kind
of
newer
to
this
conversation.
A
A
Pod
security
policy
has
this
sort
of
dual
overloaded
authorization
model
where
you
can
either
authorize
the
requester
to
use
a
pod
security
policy
or
you
can
authorize
the
object
being
created
in
this
case,
the
pod,
based
on
its
service,
account
to
use
the
policy,
and
so
this
is
confusing,
and
also
if
that
pod
happens,
to
have
create
pod
permissions,
then
you
run
into
some
problems.
There.
A
A
So
this
makes
it
essentially
impossible
to
turn
on
by
default
and
which
means
that
we're
always
lacking
some
test
coverage
and
users,
don't
typically
start
with
pod
security
policy
enabled
and
then,
because
of
the
global
nature
of
it.
It's
very
difficult
to
roll
out
a
pod
security
policy
on
an
existing
production
cluster.
A
I
think
I
see
the
kind
of
unclear
scoping
as
a
larger
problem
as
we
get
requests
for
limiting
various
things
for,
for
example,
finer
grain
controls
on
volumes.
A
A
Such
as
the
istio
sidecar,
which
requires,
I
think
at
one
point,
it
required
a
cap
net
admin.
A
That
I
see
some
chat,
so
I
want
to
pause
to
leave
room
for
if
anyone
has
comments
on
what
we've
talked
about
so.
A
C
A
Guidance,
I
think
I
agree
with
you
that
would
be
good
to
provide
some
guidance,
but
maybe
to
david's
point.
I'm
not
sure
that
we
need
to
decide
that
right
here
now
to
block
the
psp
decision
on
that.
B
B
So
as
long
as
we
have
a
general
thing
for
deciding
whether
pods
run
in
the
cluster
or
not,
it
kind
of
feels
like
it
should
handle
what
people
decide
to
do
with
side
cars,
except
for
the
surprise
factor
where
somebody
injects
a
side
car
that
causes
your
pot
to
get
rejected
when
it
otherwise
wouldn't
have.
But
mutating
admission
controllers
are
confusing.
E
The
container
model
was
not
truly
designed
for
anonymous
injection
of
arbitrary
content
and
people
are
trying
to
use
that
that
way
inside
cars,
I
kind
of
like
derek's
been
trying
to
track
that
down
to
solve
side
cars
as
part
of
the
api
without
addressing
the
security
considerations
would
be
a
mistake,
but
that's
part
of
sidecar
as
a
general
concept
like
people
are
abusing
init
containers
and
other
containers
hoping
to
get.
You
know
magic
and
it's
not
going
to
provide
a
magic,
no
matter
how
much
they
try.
A
A
A
I
could
also
see
wanting
to
explicitly
allow
list
certain
signed
containers
where
you
know
exactly
what's
running
in
there
and
have
additional
constraints,
maybe
in
the
supply
chain,
up
up
the
supply
chain
until
you've
made
the
decision
to
allow
elevated
permissions
on
that
sidecar
yeah.
E
E
One
of
the
original
sidecar-
or
you
know,
multi-container
examples
that
we
haven't
gone
back
and
addressed
in
four
years,
because
it's
not
going
to
work
was
you
know,
I
want
to
run
a
a
daemon
that
does
like
a
fuse
driver
in
a
side
car
right.
It's
completely
unrealistic
with
the
security
model
of
cube
to
get
any
kind
of
security,
while
you're
doing
that
requires
far
too
much
and
in
the
meantime
we
have
created
csi
and
cni,
which,
for
all
their
faults,
mostly
address
those
kinds
of
integrations
in
a
different
way.
E
So
it
could
just
be
that,
like
sidecar,
secure
sidecars
are
just
not
the
right
approach.
Pod
security
policy
shouldn't
be
blamed
for
that,
but
it
is
a
key.
It's
it's
important
to
note
that
it's
happening
that
people
don't
understand
about.
What's
going
on,
I
like
the
point
that
web
hook
admission
is
hard
because
injection
of
anything
that
changes
a
pot
without
you
understanding
it
if
it
doesn't
have
a
clean
interface,
is
increasingly
hard
to
understand
how
it
will
impact
the
workload.
A
I
feel
like
this
is
getting
more
into
implementation,
details
of
the
kind
of
path
forward
that
we
choose.
I
think
it's
an
important
discussion
to
have
before
we
like
actually
execute
on
one
of
these,
but
I
would
like
to
move
forward
with
talking
about
the
really
high
level
options
for
moving
pod
security
policy
forward.
A
So
there's
kind
of
three,
or
maybe
three
and
a
half
options
that
we've
discussed
in
the
past,
for
what
to
do
with
pod
security
policy
and
just
kind
of
really
quickly.
That's
basically
fixed
pod
security
policy
say
call
it
psp
v2
if
you
want,
or
v1
or
whatever,
but
try
and
address
some
of
these
challenges
that
we
just
called
out
in
the
sort
of
existing
more
or
less
something
that
looks
like
what
we
have
as
psp
today.
A
Actually,
let's
go
skip
ahead
to
the
third
option.
The
third
option
is
say:
we're
not
going
to
own
this
as
a
kind
of
a
core
feature
of
kubernetes.
A
Instead,
we
provide
we
provide
admission
web
hooks
and
there's
a
good
rich
ecosystem
of
third-party
policy
controllers
that
are
solving
this
problem
in
various
ways,
and
you
could
even
write
your
own
pod
security
policy
web
hook.
A
If
you,
if
you
desire
and
the
second
option,
I
see
as
kind
of
a
intermediate
between
those
two
it's
the
idea
is
that
having
some
control
over
pod
security
settings
is
essential
to
baseline
security
in
kubernetes,
and
so
let's
provide
the
the
bare
minimum
to
not
have
a
creator
update
pod
be
equivalent
to
root
in
the
cluster
and
for
everything.
A
Beyond
that,
then
we
say
we
offer
third
party
controllers
and
then
there's
this
sort
of
half
option,
which
is
the
go
with
the
third
party
controllers,
but
sort
of
pick
a
winner
as
sig
off
and
say.
This
is
the
option
that
we
think
the
should
be
the
default
for
for
most
customers
needing
a
policy
solution.
A
E
So
it
is
worth
noting
that
three
is
going
to
happen,
no
matter
what
and
we
have
to
support
it
anyway,
because
we
already
have
web
hooks,
so
the
that
that's
a
good
like
there
are
third-party
controllers
out
there.
That
can
do
some
aspects
of
this
web
hooks
are
hard.
Some
of
the
cons
here
have
already
happened
or
are
a
general
problem
with
web
hooks.
E
That's
at
least
one
thing
to
recognize
is
we
have
three
is
gonna
happen,
no
matter
what
and
I
think
we're
successful
if
three
is
easier,
but
it
may
not
be
this
group's
responsibility.
E
One
of
the
cons
on
two
that's
not
called
out
is:
we
will
continually
have
to
negotiate
the
boundary
for
the
baseline
and
as
security,
vulnerabilities
and
capabilities
are
introduced
into
the
ecosystem.
Right,
like
ebpf,
is
pretty
darn
unsecure
right
now,
unless
you
do
a
whole
bunch
of
really
limited
things
right,
someone's
going
to
come
to
us
and
say,
oh,
I
think
I
should
have
epbf
rights
to
load
these
modules.
You
know
so
I'm
making
up
things
here
right
but
like
we're
gonna
have
to
negotiate
that
boundary.
E
So
definitely
with
two
one
of
the
cons:
is
this
going
to
be
a
long
term
cost
that
we'll
have
to
negotiate
as
a
group
with
users
and
security
policies
doesn't
mean
it's
the
wrong
thing
to
do?
It
might
actually
be
similar
to
what
we
already
do
in
this
project
of
we're,
trying
to
have
a
reasonable
security
posture
out
of
the
box
and
leave
open
the
door
for
the
right
thing,
but
it
is
a.
It
is
a
cost
that
we
should
keep
in
mind.
C
B
Default,
I
I
like
that
concern
about
number
two
and
the
the
different
levels
changing
over
time,
because
I
like
that,
that
kind
of
points
the
way
towards
a
implementing
option,
two
by
using
the
tools
of
option,
one
add
the
like
pod
security
policy,
binding
and
then
ship,
three
or
potentially
more
default,
pod
security
policies
that
correspond
to
those
security
baselines
and
you
could
even
go
to
the
extent
of
shipping
a
default
pod
security
policy
binding
in
the
default
namespace
to
the
one
that
corresponds
to
restricted
whatever
the
middle.
B
Whatever
the
middle
layer,
one
is,
but
then
in
the
future,
as
the
definitions
of
what
makes
sense
as
baseline
policies
change
that
entails
updating
the
default
pod
security
policies
that
are
shipped
and
it
lets.
You
turn
it
on
by
default
in
new
installs,
but
also
you
know,
lets
people
choose
whatever
they
want.
Just
by
modifying
those
bindings.
C
G
Do
we
think
we
can
select
policies
for
option
two
that
we
wouldn't
want
to
change
or
tweak
in
the
future?
I
kind
of
look
at
the
additional
controls
that
got
added
to
pods
and
then
pod
security
policy
around
like
no
new
capabilities
and
like
over
time.
We
kind
of
added
more
things
when
we
realized
that
there
were
gaps,
and
it
would
really
be
unfortunate
if
our
baseline
or
restricted
policies
turned
out
to
not
actually
be
baseline
or
restricted
in
the
future,
because
we
couldn't
compatibly
take
advantage
of
new
new
controls.
We
had.
A
Yeah,
so
this
is
something
I
thought
about
when
putting
together
the
pod
security
standards
that
I
was
kind
of
imagining
this
being
based
on
privileged
the
privilege
policy,
never
changes,
because
that's
always
everything
is
allowed.
A
The
baseline
policy
tracks
what
is
default
in
the
pod,
restricted
tracks,
best
practices
restricted,
is
definitely
going
to
change
over
time
and
would
need
to
be
versioned.
I'd,
say
we
just.
E
Because,
today
you
can
reasonably
get
away
like
they've,
been
like
just
going
through
the
numbers
here
like
if
you've
set
everything
up
right
and
done
everything
right.
There
have
been
like
two
vulnerabilities
that
would
have
slipped
through
in
a
reasonably
well
configured
system
on
the
baseline
and
almost
all
of
them,
you
know
involves
getting
access
to
some
level
of
volume.
E
E
Let
me
let
me
tweak
it
in
one
slight
dimension:
what
is
baseline,
that
works
within
the
defaults,
to
do
something,
and
could
you
imagine
a
default
imposed
by
a
lower
level
that
correctly
bounds
that
I
can
there's
a
bunch
of
negotiation
in
it?
We'd
have
you
know
the
goal
would
be:
is
the
goal
that
baseline
runs?
All
of
the
workloads
like
baseline
will
not
run
100
of
workloads
on
cube
today,
so
there's
no
magic
here
right,
privileged
is
100
of
workloads.
E
Baseline
is
something
less
than
100
if
it's
a
difference
between
92
93
and
94,
we're
going
to
take
heat,
no
matter
where
that
lines
up.
If
we
move
that
as
one
percent
one
way
and
we're
able
to
get
a
recommended
configuration
that
was
significantly
more
secure
within
those
bounds,
I
think
that's
probably
achievable,
regardless
of
like
whether
you
know
you
should
follow
things
but
we'd
be
setting
a
a
guideline
for
the
community.
That
would
improve
security
across
the
board
for
all
kubernetes
admins
and
we
would
effectively
say:
look
if
you
have
the
escape
patch.
E
B
I
mean,
I
think
we
have
that
already
with
the
pod
security
standards
document.
We
just
don't
give
people
an
easy
way
of
picking
one
conforming
their
workload
to
it
and
adopting
it,
and
so,
if
we
shipped
all
three
of
those
as
options,
then
shipping,
the
most
restrictive
one,
gives
people
something
to
aspire
to
and
adds
like
200
bytes
of
yaml
to
your
install.
B
If
you
don't
use
it
and
then
making
the
one
that's
making
the
the
like
baseline
one
be
a
default
still
when
people
can't
live
within
those
bounds,
they'll
remove
that
and
make
their
own
policy
and
bind
to
it
but
like
having
it.
There
is
something
that
they
can
agree
or
disagree
with,
but
within
kubernetes,
as
opposed
to,
depending
on
some
particular
kubernetes
distributions
choice
of
what
are
the
lower
layers
under
it.
F
Ask
for
that,
like
that's
a
thing
that
people
want
and
a
thing
that
we
aren't
currently
giving
them,
and
I
think
it
would
make
it
easier
for
users
to
do
the
right
thing,
because
a
lot
of
the
time
people
are
like
we
want
this,
and
we
don't
actually
know
what
to
do.
Please
tell
us
what
to
do
and
historically
it's
the
answer
has
been
well,
you
know,
do
things
granularly
according
to
your
needs
and
use
case
and
they're
like
we
don't
know
how
to
do
that.
Please
tell
us
what
to
do
so.
E
Do
try
this
right,
maybe
maybe
I
didn't
you
know
present
this
clearly,
but
I'm
pretty
convinced
that
there's
something
very
close
to
baseline
that
just
is
secure
by
default.
That's
a
little
bit
less
restricted
than
restricted
like.
I
know
there
is
because
it's
possible
to
run
like
that,
so
I
guess
the
question
was
like.
E
E
F
B
B
That's
why
I
like
this,
this
idea
of
like
a
hybrid
option,
two
by
shipping,
pod
security
policies
and
a
default
binding,
because
it
a
lets
users,
agree
or
disagree
with
the
say
three
default
policies
we
ship,
but
also
b.
If
they
disagree,
they
can
save
the
policy
that
we've
shipped
make
the
one
tweak
that
they
disagree
with
and
load
it
back
in
with
a
different
name
and
roll
with
it.
So
it
still
reduces
their
cost,
whether
they
agree
with
us
and
use
it
or
if
they
disagree
with
us,
but
use
us
as
a
starting
point.
A
One
thing
I
like
about
that
approach
is
that
it
sort
of
naturally
bounds
the
api
so
addressing
that
whatever
it
was
third
problem
that
I
called
out
in
that
we
say
you
know:
okay,
you
want
to
add
a
new
option
to
pod
security
policy.
A
E
Policy
one
one
challenge
for
that
is
one
challenge
with
leaving
the
api
there
other
than
as
a
read-only
kind
of
thing
is
that
if
you
change
like
we're,
gonna
have
to
test
this
in
conformance,
no
matter
what
like,
if
we,
if
we
go
to
two,
this
will
be
in
conformance.
It's
not
there's
no
way
that
this
could
work
without
it,
and
that
means
you
really
can't
change
those.
E
I
think
that
that
still
comes
like
that
still
has
all
of
the
problems
of
the
current
mechanism
without
any
of
the
advantages,
because
you're
kind
of
heavily
constraining
what
you
can
do
with
the
defaults,
and
you
have
a
less
flexible
mechanism
than
something
like
gatekeeper
or
more
custom
built
like,
for
instance,
in
the
restricted
set
like
most
of
those
volume
types
really
should
like
you.
Just
can't
let
people
touch
volumes.
E
Would
I
rather
tell
people
to
use
baseline
and
then
come
up
with
rules
about
how
they
could
access
those,
but
then
we
have
cni
and
csi,
which
are
both
completely
unbounded
and
cni.
Local
is
going
to
need
some
better
mechanism.
We
would
have
to
go.
Add
that
to
pod
security
policy
that
like
right
now,
that's
a
gavin
pod
securities
policy
with
the
new
csi
like
local
stuff,
and
you
should
be
able
to
use
it
in
some
cases,
but
the
control
of
that
is
going
to
depend
on
each
csi
plug-in
and
you
got
to
go.
E
Do
custom
policy
that
just
doesn't
scale
with
pod
security
policy
today.
So
like
the
scalability
of
pod
security
policy,
as
we
add
more
concepts
around,
like
extension,
points
I
think,
is
pretty
weak,
so
we
would
have
to
maintain
that
and
then
still
have
to
go
to
option
three,
so
we'd
be
doing
option
one
option
two
option
three
and
maybe
option
three
b.
I.
B
Disagree
because
I
feel
like
having
security
policy
constraints
around
options
that
are
added
by
a
plug-in
is
really
on
the
plugin,
and
so
as
long
as
pod
security
policy
covers
everything
that
you
can
do
in
vanilla
kate's.
Without
any
additional
like
strange
plugins,
then
I
feel
like
that's
the
only
scope
that
it
needs
to
track
and
it
does
still
need
to
grow
over
time
as
the
options
within
kubernetes
change.
But
you
know
if
I
start
a
storage
startup
tomorrow
and
I
make
a
csi
plugin
for
it.
E
F
Okay,
can
I
say
a
thing:
I
think
that
there
is
a
fundamental
disagreement
underlying
the
crosstalking
that
we're
doing
right
now,
that
involves
when
people
say
the
existing
problems
with
combat
security
policies
that
is
in
scare
quotes.
Although
you
cannot
see
me,
people
are
referring
to
different
things.
E
Yeah
I
mean
I
would
agree
with
all
those
they
psp
and
scc
have
all
those
today
they
have
all
of
those
problems.
People
don't
understand
how
to
use
psp.
Well,
people
don't
understand
how
to
use
scc.
Well,
people
change
them
expecting
that
to
fix
their
problem
and
break
their
clusters.
So
I
the
flexibility,
comes
with
a
cost.
I
thought
that
we
were
talking
about
reducing
our
cost
as
well,
with
a
better
option.
I
I
have
a
slightly
more
fundamental
question.
I
think,
does
pod
security
policy
because
of
its
privileged
status?
Is
it
able
to
do
anything
that
a
third
party
policy
controller
can't
do.
J
B
And
one
of
the
most
political
things
you
ever
do
in
software
is
deciding
what
the
upstream
defaults
are
going
to
be
because
people,
if
even
if
they
don't
take
them,
look
to
them
as
the
examples
that
they
should
agree
or
disagree
with,
which
is
why
I
don't
like
the
kubernetes
has
no
opinion
on
this
use.
A
third
party
strong.
J
J
J
The
sooner
someone
else
can
say
they
are
the
thing
that
is
better
right,
like
we,
as
the
maintainers
of
kubernetes
have
made
it
so
that
psp
is
king
because
it
exists
in
court
right.
I
am
willing
to
bet
gatekeeper,
scc
and
various
other
things
are
better
because
they're
actually
significantly
more
complete,
and
I
would
rather
walk
away
from
this
problem
and
give
it
to
someone
else
who
actually
has
the
time
to
solve
it
in
a
more
robust
and
complete
way
than
continuing
to
go
in
circles.
A
I
agree
with
the
second
point:
definitely
that
you
know
by
building
something
into
kubernetes,
we're
sort
of
implicitly
king
making
here
and
hamstringing
the
third-party
plugins.
I'm
not
sure.
I
agree
that
sigoth
doesn't
have
the
bandwidth
to
fix
this
problem.
I
think
the
problem
is
that
we
haven't
been
able
to
agree
on
what
the
right
path
forward
is
for
pod
security
policy.
A
I
think
if
we,
if
we
chose
one
of
these
options
and
scoped
pod
security
policy
in
a
better
way
and
kind
of
addressed
these
more
systematically,
I
do
think
that,
like
you
know,
we
could
make
that
happen.
Well,.
E
And
maybe
my
other-
and
this
is
partially
why
I
was
kind
of
arguing
against
one-
is
pod
security
policy
couples.
A
number
of
discrete
problems
together
and
the
introduction
of
new
things
to
cube
has
made
that
more
complicated
rather
than
less,
and
so
maybe
there's
an
option.
Two
a
or
three
c.
E
E
One
of
them
is
the
ability
to
escalate
which
resources
you
have
access
to
via
arbitrary
device,
plug-in
naming
right
like
you
can
ask
for
a
pv
that
the
that
the
cluster
has
access
to
and
get
access
to
it
and
then
potentially
others
which
you
know
align
with
you
know
potential
like
network
or
capability,
related
problems
that
aren't
well
defined,
breaking
it
up
into
three
or
four
smaller
problems
with
a
good
default
for
one
or
two
of
those
problems
might
be
more
attractive.
E
G
Just
wanted
to
mention
a
couple
things
decomposing
a
policy
problem
into
lots
of
little
policy
sounds
attractive,
but
and
makes
each
individual
problem
smaller,
but
if
the
net
effect
is
for
users
that
they
then
have
to
go,
set
up,
10
things
and
make
sure
10
things
are
in
place.
I
think
the
we.
We
still
want
something
that
sort
of
says
like
stamp
the
recommended
default
in
and
if
it
goes
and
does
10
things
under
the
covers.
Maybe
that's,
okay,
but
from
a
user
perspective
like
turning
one
problem
into
10
problems
is
not
great.
G
G
G
It's
the
ramp
between
the
two
is
really
tough
and
so
for
option
two.
If
we
had
something
to
take
the
csi
plug-in
example,
you
had
clayton
like
say
we
have
a
baseline.
That
says
you
can
have
like
normal
volumes,
no
csi
volumes,
because
those
might
be
scary
and
no
nfs
volumes,
because
it
might
be
scary,
no
privilege
spots,
because
those
might
be
scary.
G
So,
okay,
we've
got
a
baseline
policy.
So
then
someone
contributes
a
csi
volume,
plug-in
they're
like
I
have
specific
policy.
I
want
to
implement
around
that.
Well
now
you
need
to
punch
a
hole
in
your
minimalist
policy
to
let
that
through
in
order.
So
in
order
for
the
custom
policy
to
like
have
opinions
about
it
or
you
have
to
come
up
with
the
baseline,
and
so
it's
that
it's
that
ramp,
that
I
think
we're
struggling
with
for
trying
to
do
something
in
tree.
B
I
I
like
the
way
those
two
different
concerns:
kind
of
mesh
together
because,
like
to
your
point,
clayton
there's
these
plugins
and
when
people
want
to
do
something,
fancy
for
storage
or
networking,
they
they
use
a
plug-in,
but
also
note
that
kubernetes
ships,
basic
versions
of
those
plugins,
so
that
you
can
do
something.
That's
quote,
unquote,
not
fancy
and
have
it
just
work
out
of
the
box,
and
you
know.
B
Similarly,
that's
how
I
would
imagine
in
a
future
the
relationship
between
pod
security
policy
and
gatekeeper
being
like
I'm
arguing
passionately
in
favor
of
pod
security
policy.
I
run
gatekeeper
in
production
and
I
wouldn't
stop
doing
that.
Even
if
we
did
ship
this
pod
security
policy
that
I'm
arguing
for,
because
I
think
that
people
won't
want
to
punch
a
hole
in
their
simple
policy
in
order
to
let
something
else
handle
one
part
of
it.
B
I
think
that,
like
your
storage
plug-in
or
your
networking
plug-in,
people
will
decide
or
ought
to
decide
when
they're
standing
up
a
cluster.
No,
this
one
is
fancy,
we're
gonna
use,
say
gatekeeper
in
it,
but
then
we're
giving
them
an
option
kind
of
similar
to
kube
net
of.
If
you
don't
have
very
fancy
or
specific
needs.
F
The
biggest
demand
that
I
see
and
have
seen
for
years
is
that
there
be
some
kind
of
security
policy
that
has
defaults,
that
ship
out
of
the
box
that
are
not
just
nothing
and
that
have
like
levels
of
specifically
people
have
asked
for
low
medium
high
that
people
can
choose
from
how
restrictive
they
want
it
to
be,
and
then
people
can
set
it
and
forget
it,
and
I
think
that
like
we
have,
I
think,
the
arguably
the
biggest
mistake
that
kubernetes
has
made
with
security
assumptions
over
the
years
is
that
shh
is
that
people
have
assumed
that
users
are,
and
in
the
beginning.
F
We
are
just
throwing
end
users
to
the
wolves
like
they
don't
know
what
to
do.
They
want
to
know
what
to
do.
People
want
to
do
the
right
thing
and
right
now
we
are
just
not
giving
them
easy
tools
to
be
able
to
do
that,
and
I
think
that
if
we
ship
something
out
of
the
box
that
has
like
different
sets
of
suggested
defaults
that
allows
users
to
do
that.
F
I
think
we
are
actually
empowering
users
to
make
it
easier
for
them
to
make
their
stuff
more
secure,
because
right
now
again,
if
we're
talking
about
cost,
maybe
we're
lessening
the
cost
for
us,
but
the
less
that
we
are
giving
users
in
terms
of
tools
for
them
to
do
this
stuff.
The
more
that
we
are
offloading
the
costs
on
to
these
users,
who
are
really
struggling
with
trying
to
figure
out
what
they
need.
A
Jim's
is
next
for
everyone
who
isn't
aware
we're
switching
to
hands
and
chat.
H
Yeah
hi,
so
the
only
thing
I
can
add
to
this
discussion
is
the
model
that
we
have.
Where
cube
proxy
you
know
has
can
be
replaced
by
you
know
psyllium
directly
right.
So,
if
we
have
is
that
we
have,
we
already
talked
about
those
that
kind
of
a
model
where
there
is
a
default
controller.
That
does
something
basic,
but
then
it
can
be
replaced
by
something
that
other
people
are
writing.
A
I
think,
to
some
extent
we
already
have
that
today,
like
I
mean
that's
sort
of
pod
security
policy,
you
can
not
use
it
and
use
an
admission
controller
option.
Two
is
saying:
well,
this
is
gonna
default
on,
but
there's
nothing
preventing
you
from.
A
You
know
considering
every
namespace
privileged
from
the
purpose
of
that
implementation
and
again
falling
back
to
third
party.
So
I
think
that
was
kind
of
the
point
that
david
made-
or
I
can't
remember,
who's
sorry
early
on
that
we
have
third
party
controllers
and
they're
not
going
anywhere.
A
A
This
conversation
has
gone
similar
to
similarly
to
past
pod
security
policy
discussions
and
again,
if
we
don't
make
a
decision,
the
default
is
that
we're
going
to
end
up
with
option
three
at
you
know
1.22
or
24,
or
whenever
it
actually
goes
away.
A
So
I
would
actually
like
to
shift
the
discussion
to
ask
how
how
we
can
move
forward
on
this.
How
do
we?
How
do
we
come
to
some
agreement
here?
What
are
the
next
steps?
Should
we
start
a
working
group?
Should
we
keep
discussing
in
sigoth
security
offers.
C
J
J
Can
we
can
we
make
a
requirement
that
this
api,
when
you
say
like,
if
this
thing
existed,
could
we
say
that
restricted
means
like
restricted
for,
like
this
version
of
this
cluster,
and
if
your
app
stops
working
on
upgrade
sorry,
you
shouldn't
use
restricted
like
that's.
What
restricted
means
same
with
baseline
right
like
if
you
could
have
such
an
api
is
the
biggest
thing,
which
is
the
maintenance
burden
of
this
thing,
go
away
right
because
we
could
just
keep
tightening
it
but
like
we
don't
have
to
like
maintain
indefinitely
long,
never
ending
versions
and.
J
Yeah,
I
don't
know
like
it
doesn't
sound
like
the
rest
of
kubernetes,
because
we
like
never
break
you
basically
or
we
give
you
like
years
for
like
trivial
things,
so
that
would
be
my
general
concern
of
us
making
up
the
buckets,
because
the
buckets
are
like
never
static
in
my
mind
and
we'll
keep
adding
stuff
to
pods
and
they'll
need
more
fancy.
J
Restrictions
and
bass
line
will
change,
and
now
we
have
like
seven
bass
lines
like
which
bass
lines
is
the
bass
line,
all
right,
but
yeah
in
my
head,
like
you,
could
you
could
have
high
medium?
J
You
could
have
hot
sorry,
you
could
have
low
and
medium
and
not
actually
have
a
high,
because
high
is
just
audit
right,
but
that
was
just
my
thoughts.
B
I,
when,
when
I
did
when
I
raised
my
hand,
it
was
because
I
wanted
to
put
forth
the
proposal
from
sig
security
that
we
take
over
this
bike
shed,
but
that
has
now
instead
happened,
because
I
interrupted
due
to
the
fear
that
the
discussion
would
go
off
in
a
direction
where
it
no
longer
made
sense
to
make.
That
proposal.
F
B
Okay,
certainly
yeah
like
if,
if
sigoth
is
not
happy
with
continuing
to
have
this
bike
shed
problem,
then
yeah
sig
security
formally
formally
proposes
that
we
take
this
bike
shed
off
of
your
hands,
perhaps
by
owning
pod
security
policy.
G
Yeah,
I
I
think
the
the
issues
raised
with
pod
security
policy
are
ones
that
we
see
as
preventing
it
in
its
current
form
from
moving
forward.
If
there's
I,
I
would
see
it
more
of
as
a
replacement
like
if
there's
a
replacement
entry
proposal
that
is
like
option
two
or
maybe
option
one
like
what
would
psp
v2
look
like
like
if
we
fix
the
things
that
have
prevented
it
from
getting
adopted.
F
I
believe
that
we
have
verbally
agreed
upon
a
proposal
that
sig
security
has
made,
that
we
have
not
had
the
opportunity
to
write
yet
because
this
came
up
right
this
minute
and
we
are
in
a
meeting
rather
than
writing.
I
think
my
hand
isn't
up,
but
like
I
think
that
that
is
a
thing
that
could
be
done,
that
a
proposal
could
be
made
and
put
out
that
is
written
it
just
it
does
not
currently
exist,
because
we
are
having
this
conversation
in
real
time.
J
I
actually
followed
what
you
just
said.
I'm
sorry.
F
J
A
Oh
yeah,
let
me
jump
in
there.
Of
course
anyone
can
make
a
proposal
or
cap
it
doesn't
there's
no
like
you
know
it
has
come
from
a
sick.
I
I
would
be
very
happy
for
six
security
to
contribute,
or
even
own,
like
definitions
of
what
standard
default
policies
should
be.
A
I
don't
I
don't
want
to
start
like
a
cross
sig
war
here,
but
I
do
want
to
be
careful
about.
C
C
F
C
F
Frankly,
I
see
part
of
the
problem
here
as
sort
of
a
lack
of
imagination,
which
makes
sense
for
people
who
are
sick
of
having
this
conversation
after
dealing
with
a
broken
api
for
a
long
time,
and
I
have
a
lot
of
empathy
for
that.
But
I
also
think
that,
like
there
are,
you
know
there
is
a
certain
extent
to
which
I
think
like
oh
well.
This
will
never
work
not
with
that
attitude.
F
It
won't
that,
like,
I
think
that
you
know
the
hybridized
policies
that
were
not
entirely
within
the
bounds
of
one
or
two
were
suggested,
and
I
think
people
have
ideas
and
excitement
and
energy
around
that
and-
and
I
think
that,
like
if
people
are
open
to
ideas
and
figuring
out
ways
to
make
this
work,
I
don't
think
it's
undoable.
Unless
everybody
poops
on
it
and
says
that
it'll
never.
J
J
No,
so
I
was
gonna
ask
so
you
know
I
get
the
feeling
that
security
folks
have
a
vested
interest
in
this.
Would
it
make
sense,
like
I
generally
agree
with
david,
that
I
don't
see
psp
evolving.
However,
I
it's
not
that
I
don't
see
a
new
thing
showing
up
right.
J
If,
if
there
is
just
this
great
desire
to
have
this
entry,
like,
I
feel
like
that's
the
way
we
go
through
it
right
like
the
kept
process
has
evolved
immensely
since
psp
has
existed.
We
have
a
much
better
understanding
of
how
to
build
maintainable
apis
in
cube,
and
we
know
everything
we
dislike
about
psp
for
sure,
like
I
feel
like.
That
is
much
more
likely
to
get
traction.
J
If
someone
is
willing
to
put
in
the
effort
to
write
the
kept
or
design
or
something
it
doesn't
have
to
be
a
kept,
it
could
just
be
a
google
doc
where
you
necessarily
come
up
with
something
right
and
like
if
it
solves
the
problems
that
psp
has
like.
I
rather
like.
J
I
don't
feel
the
need
to
carry
psp
forward
just
because
it
was
there
right
like
right,
like
you
could
call
it
pspv2
for
all
I
care
but
like,
but
it
doesn't
have
to
like
have
any
of
the
fields
or
anything
like
that
right
to
me.
That
seems
like
a
if
you
have
time
and
effort
and
if
we
were
doing
this
all
over
again,
that's
what
we
would
do
right
like
if
we
went
back
and
we
knew
everything
we
knew
today.
J
A
Okay,
since
we're
almost
at
time
here,
I
wanna
talk
a
little
about
next
steps.
No,
I
absolutely
agree
with
you
about
writing
caps.
Even
if
it's
sort
of
an
informal
draft
cap,
I
think,
having
some
more
concrete
proposals
will
help
us
to
carry
this
conversation
forward,
and
so
I
encourage
anyone
who
has
some
more
concrete
ideas
about
what
next,
what's
next,
to
try
and
write
those
up.
A
I
think
that
we
need
to
continue
this
conversation
and
sig
off,
at
least
to
the
point
where
we
can
agree
on
another
place,
to
continue
the
conversation
so
with
that
the
next
sigoth
in
two
weeks
is
the
day
before
thanksgiving.
A
I
don't
know
how
folks
feel
about
meeting
that
week
or
if
we
should
cancel
and
go
out
four
weeks.
I'm
also
aware
that
there
are
two
agenda
items
we
didn't
get
to
today.
So
I'd
like
to
start
with
those
next.
A
Okay,
so
let's
say
let's
say
next:
I'm
just
gonna
make
an
executive
decision
that
next
cigarette
is
canceled,
we'll
reconvene
in
four
weeks
to
discuss
next
steps
for
the
clientgo
credential,
plugins
and
spiffy
client
certificate
authentication,
and
also
to
pick
up
the
pod
security
policy
discussion.
F
G
I
think
doing
things
side
by
side
would
make
it
much
easier
and
faster
honestly
to
get
a
thing
which
solves
customers
problems
and
would
give
a
really
easy
transition
for
like
if
you're
using
psp,
keep
it
in
place,
start
getting
onto
this
new
thing,
but
rebuilding
the
airplane
in
flight.
I
think
we'll
just
waste
a
lot
of
energy,
given
compatibility
with
the
bad
parts
of
psp.
We
wish
we
could
drop.
G
B
G
B
F
A
I'm
going
to
stop
the
conversation
here.
If
you
do
write
up
a
proposal,
you
absolutely
do
not
need
to
wait
until
the
next
conversation
in
four
weeks.
Please
send
it
out
to
the
mailing
list
and
we
can
and
start
having
some
more
of
the
discussion
on
there
all
right.
Thank
you.
Everyone-
and
I
hope
you
have
a
great
next
four
weeks.