►
From YouTube: sig-auth bi-weekly meeting for 20201209
Description
sig-auth bi-weekly meeting for 20201209
A
All
right
welcome
to
sigoth
for
december
9th
2020..
Let
me
try
and
share
my.
A
A
All
right
can
we
everyone
see
that
yep,
okay,
the
first
two
items
on
here
are
carried
over
from
last
week
since
we
didn't
get
to
them
andrew.
Would
you
like
to
ask
your
host
your
question.
B
Hopefully,
this
item
should
be
reasonably
short,
maybe
famous
last
words.
I
just
wanted
to
take
this
opportunity
to
maybe
give
a
quick
status
on
clientgo
credential
plugin
api,
as
well
as
validate
some
assumptions
and
maybe
get
a
quick
answer
to
a
question
I
have
so
my
assumption-
and
someone
can
correct
me
if
I'm
wrong
in
the
next
minute
or
two-
is
that
it's
still
valuable
to
the
community
to
get
this
client
go
credential
plug-in
api
to
ga.
B
Judging
by
the
cap,
it
looks
like
the
next
steps
between
here
and
ga
are
to
write
some
end-to-end
tests
and
write
some
docs.
I
would
be
interested
in
contributing
any
or
all
of
those
things
roughly
for
the
121
timeline
if,
if
time
allows
so,
my
question
is
what
what
is
the
what
like?
B
If
we
want
to
get
this
api
to
ga
like
what
powers
it
be
need
to
be
contacted,
I
I
would
assume
someone
outside
of
the
sig
needs
to
like
give
a
thumbs
up
or
something
of
of
that
of
that
measure
in
order
to
get
an
api
to
ga.
But
what
like,
if,
if
we
want
to
try
to
get
this
api
to
ga
in
121,
like
who
else
in
the
community
needs
to
be
brought
in?
On
that
conversation?.
C
So
the
links
to
the
beta,
the
ga
graduation,
that
you
mentioned
so
making
sure
that
all
the
things
in
that
list
are
like.
We
can
point
to
why
we
think
those
are
satisfied.
C
C
So
we
want
to
do
due
diligence
around
that
make
sure
that
the
things
that
people
are
reporting
to
us
in
the
beta
phase
we
are
actually
resolving.
So
that's
the
point
of
this
time
in
terms
of
people
outside
the
sig,
sig
release
and
api
review.
Those
are
the
two
main
groups
that
are
we
need
to
interface
with,
so
once
sig
release
sets
up
the
timeline
for
121.
C
We
will
know
when
the
feature
freeze
date
is
and
we'll
need
to
make
sure
that
this
enhancement
is
tracked
for
the
release,
if
we're
wanting
to
graduate
it
and
then
as
part
of
the
promotion
to
v1
there'll,
be
an
api
review
step.
C
B
Well,
that
sounds
good
yeah
thanks
for
bringing
up
that
issue,
I'd
forgotten
about
that
one!
Okay,
that
makes
sense.
I
think
it's
my
understanding
and
someone
correct
me
if
I'm
wrong
that,
when
contributing
like
integration
tests
or
end-to-end
tests
that
you
just
see
the
the
sig
that
oversees
the
functionality
that
is
being
tested,
not
sick
testing,
so
I
may
try
to
hack
on
that
a
bit
over
the
next
couple
months
and
post
post
a
contribution
there.
This
is
all
helpful,
I'm
I'm
sensing
that
it's
still
valuable.
A
Yep
definitely
still
valuable
thanks
for
contributing
there
all
right
by
the
way,
I
moved
pod
security
policy
to
the
end,
not
because
I
don't
want
to
talk
about
it,
but
because
it
has
a
way
of
filling
up
whatever
time
there
is
so
I
want
to
make
sure
we
get
to
the
other
items.
First,.
A
E
Does
anyone
know
no,
they
don't
because
they
put
the
spiffy
id
in
sand
and
the
common
name
is
the
uid
got
it.
E
Yeah,
just
so
to
the
credential,
I
think
the
work
would
be
like
deciding
that.
Yes,
this
is
a
thing
first
class
that
we
would
want
to
support
and
then
determining
whether
we
want
it
to
like
match
the
service
account
like
if
you're
issuing
it
for
a
service
account.
Should
it
also
look
like
a
service
account
token's
identity,
or
should
it
just
be
the
string,
that's
in
the
sand
getting
passed
through
that
you
can
then
write
policy
about.
E
This
I
know
we're
poking
around
a
little
bit.
I
think
folks
are
interested.
I
mean
I'm
assuming
that's
why
ahmed
was
posing
this.
I
don't
know
if
we
have
any
other
those
other
folks
on
the
call
yeah
just
to
chime
in.
I
think
I'm
working
with
to
hear
here
on
this
and
the
idea
was
we
just
wanted
to
know
if
someone
else
is
working
on
this
just
to
get
a
better
understanding
and
if
there's
no
duplication
of
work.
C
It
might
be
worth
sending
a
message
to
the
mailing
list,
just
in
case
there
are
people
not
on
the
call
to
get
a
broader
audience
to
ask.
That
sounds
good.
Thank.
A
No
worries
did
you
have
anything
to
add
on
this,
particularly
yeah,
okay,
yeah.
Let's,
let's
follow
up
on
the
mailing
list.
A
All
right
next
up
sure:
how
are
you
on
the
call.
G
Yeah,
so
I'm
wondering
whether
we
can
pick
it
because
we
have
the
the
panasonic
panel
service
scan
token
volume
that
will
be
better
in
the
next
three
days.
I'm
just
wondering
whether
we
can
disable
token
controller.
One
point
that
I'm
pointing
point
out
by
mike
dennis
is
that
some
some
use
cases
that
they
will
like
rely
on
this
functionality
to
be
available
because
they
they
may
want
to
like
assume
that
every
assume
that
token
controller
is
available.
G
But
but
I
don't
think
it's
gonna
be
useful
for
the
new
use
cases
right.
So
I'm
just
running
either
way
a
safe
way
to
say
boy.
C
Yeah,
it's
a
good,
it's
a
good
topic
to
think
about
now
that
we
actually
have
a
like
a
reasonable
path
to
bound
service
account.
Tokens
like
the
next
step
is:
how
can
we
stop
putting
credentials
in
secret
yeah?
I
kind
of
like
the
idea
of
a
per
service
account
way
to
opt
out.
We
already
have
a
per
service
account
way
to
opt
out
of
auto
mounting
tokens
into
pods,
letting
specific
creators
of
specific
server
accounts
say.
C
We
could
do
that
in
cube
system
namespace,
with
the
service
accounts
we
set
up
for
controller
manager,
which
already
use
token
request
to
get
ephemeral
tokens.
C
G
A
Yeah,
I
agree.
I
also
think
it
would
be
valuable
to
have
a
namespace
level
and
probably
eventually
we're
going
to
want
a
cluster
level
knob
as
well,
so
be
able
to
have
all
three
of
those.
C
H
I
definitely
know
people
who
who
are
relying
on
the
fact
that
they
can
get
a
service
account
token.
This
way
sure
I'm
trying
to
think
about.
If
it
was
an
explicit
opt-out,
why
would
anyone
ever
bother
to
use
the
explicit
opt-out
like
like,
I
know
a
few
select
people
will
be
awesome
and
they'll.
Do
it
the
idea
of
turning
it
on
within
a
like
enforcing?
That
would
be
admission.
C
Honestly,
like
cube
system
cube
controller
manager
created
service
accounts
are
probably
the
highest
value
place.
These
could
be
used
like
those
are
service
accounts,
cube,
controller
manager,
sets
up
and
manages
credentials
for,
and
if
it
opted
out
of
populating
credentials
for
those
things
in
secrets,
that
would
make
cube
system
listing
secrets
way
less
valuable
than
it
currently
is,
which
be
kind
of
nice.
C
For
other
people,
I
agree,
I
don't
know
that
other
people
would
like
trouble
themselves
to
opt
out
of
this.
Maybe
they
would,
but
probably
I.
A
A
C
H
C
E
I
think
it
also
like
gives
the
the
pathway
for
that
communication
to
happen,
because
today
it's
like
hey,
you
can
go
turn
this
thing
off
if
you
know
how
to
with
the
cluster
config,
but
there's
no
way
to
say
by
default,
these
things
will
still
be
around.
You
should
go
into
things
you
care
about
making
them
not
available
by
policy.
E
F
I
Europe,
hey
yeah,
so
I
have
been
doing
some
thinking
about
the
kind
of
the
just
threat
modeling
on
kubernetes
and
and
how
notes
can
create
mirror
pods
and
how
that
is
like
a
known
attack
pattern.
I
think
tim,
you
and
greg
talked
about
this
at
cubecom
last
year
for
anyone
who's
not
aware.
Basically,
if
a
node,
if
a
node
is
compromised.
I
There's
a
number
of
different
things
that
can
go
wrong
after
that,
basically,
nodes
can
create,
are
called
mirror
pods,
which
are
local
only
to
that
node.
They
cannot
get
scheduled
somewhere
else,
but
they
and
they
can't
use
things
like
service
accounts,
also
called
like
static.
Pods
can't
use
things
like
service
accounts,
config
map
mounts
into
the
pod,
but
they
can
have
arbitrary
labels,
and
so
a
maliciously
taken
over
node
could
create
a
pod.
I
That
say,
has
the
cube,
dns
or
core
dns
labels
and
start
redirecting
dns
requests
and
then
and
then
the
service
controller
would
update
endpoints
for
the
dns
service
and
start
sending
dns
requests
to
that
to
a
fake
pod
or
a
possibly
fake
pod
on
that
node
same
for
any
other
in-cluster
service.
So
if
you
have
an
in-cluster
web
book
like
say
an
istio
web
hook,
that's
adding
side
cars.
I
H
I
So
so
again,
you're
right.
If
there's
tls
for
a
web
hook,
yes,
they
might
not
be
able
to
get
that
but
say
dns
requests.
They
might
be
able
to
answer
for,
hopefully
they're
using
tls
everywhere
else.
But
that's,
as
you
know,
that's
not
always
the
case.
Isn't
it
required
for
webhooks?
I
It
is
required
for
webhooks
but
yep.
But
if
a
t-
but
if
say
a
dns
request,
gets
answered
and
there's
some
other
service
that
not
using
tls
in
the
in
the
cluster
or
out
external,
the
cluster
that
could
be,
you
know,
pointed
to
some
malicious
source
so
trying
to
think
about
how
do
we
mitigate
those
kind
of
attack
patterns?
One
of
the
thoughts
that's
come
up
is
how
can
we
have
a
knob
that
prevents
the
node
from
creating
these
mirror
pods?
I
Obviously,
that
would
break
certain
setups
people
who
are
using
that,
but
having
just
even
giving
administrators.
You
know
the
ability
to
limit
how
bad
things
can
happen
because
say
you're
doing
you're
doing
everything
right
in
a
hardened
cluster
you're
still
sort
of
susceptible
to
this
attack
pattern,
and
I
guess
I
wanted
to
get
input
here
on
kind
of
if,
if
that,
if
a
knob
for
this
disabling,
this
is
is
worth
adding,
is
deprecating
mirror
pods
altogether
a
more
worthy
thing
to
do?
I
H
H
You
can
actually
direct
service
traffic
to
them,
so
you
can
create
a
service
for
your
static
pods.
I
happen
to
know
at
least
one
distribution
doing
this.
What
so.
C
I
To
my
knowledge,
yeah,
that's
that's!
The
main
thing
here
is
that,
like
you
can
dynamic?
Okay!
Yes,
if
you
take
over
node,
you
can
dynamically
run
anything
you
want.
So
that's
not
the
concern.
It's
more!
The
like
the
the
controllers,
like
the
service
and
endpoint
controllers
that
are
that
are
creating
these
and
actually
routing
traffic
to
those.
A
I
would
say:
that's
the
that
is
the
known
vulnerability
here,
but
I
think
mirror
pods
represent
a
pretty
big
attack
surface
and
the
ability
to,
I
think,
there's
a
value
in
being
able
to
block
those
entirely
for
the
the
unknown
unknowns.
As
I
say,.
D
But
then
also,
similarly,
if
I
wanted
to
drop
a
manifest
into
the
appropriate
directory
to
get
a
pod
running
that
I
don't
want
people
to
see,
I
would
appreciate
it
not
showing
up
as
a
mirror
pod,
because
then
it
would
not
be
visible,
and
I
mean
I
suppose
the
the
counter
argument
to
that
is.
If
you
want
to
do
that,
just
run
it
yourself
directly
with
docker
or
with
you
know,
cri,
ctl
or
whatever,
but
it
does
seem
like
something
that
you
would
want
to
think
about.
According
to
your
threat
model,.
A
A
So
yeah,
I
think,
there's
some
follow-up
work
to
do
there,
but
I'm
also
still
interested
in
discussing
blocking
mirror
pods.
Of
course,
you
can
always
just
do
that
with
an
admission
controller
web
hook
anyway,.
I
Do
you
think
that
there's
just
I
guess
my
question
is:
do
we
think
that
there's
not
enough
fat
like
is
this?
Is
this
just
like
behavior,
that's
too
difficult
to
defecate
or
remove
or
or
to
find
grain
to
add
a
knob
for,
and
the
answer
should
just
be
add
a
web
hook
for
because
adding
a
web
hook
is
kind
of
I
mean
I
guess
it's
not
totally.
The
problem,
like
we
said
earlier,
there's
tls
around
web
hooks
but
like
an
in-cluster
web
hook
is
still
it.
I
C
Static
pods
are
really
widely
used.
If
you
have
static
pods,
I
guess
technically,
you
could
have
static
pods
that
don't
get
mirrored.
That
would
make
them
really
hard
to
manage.
C
H
H
I
wouldn't
be
against
adding
a
label
restriction
like
only
these
nodes
can
set
these
labels
on
their
mirror,
pods,
and
that
would
still
satisfy
the
use
cases
that
I
know
of,
because
usually
when
people
deploy
these
things,
they'll
say
like
okay,
I'm
gonna
have
a
static
pod.
It's
gonna
run
on
nodes
that
look
like
this,
maybe
all
nodes,
but
usually
nodes.
Those
like
this
and
they're,
the
only
ones
that
I
expect
to
set
the
label
for.
H
C
So,
in
the
case
where
you
didn't
expect
any
static
pods,
you
could
just
say
don't
allow
any
labels
like.
I
don't
expect
anything
and
you
could
be
confident
that
services
would
never
route
to
a
static
pod,
yeah.
H
And
in
the
case
where
you
had
a
static
pod
and
you
had
a
service
that
exposed
it,
for
I
don't
know,
metrics,
for
instance,
you
would
be
able
to
say
yep.
I
want
this
node
to
be
able
to
set
the
thing
or
the
indica
you
know
fly
that
indicates
yep.
I
am
part
of
this
service
for
metrics
gathering
purposes.
I
Yeah
I
mean
I
I
totally
get
that
like.
I
don't
want
to
just
say
because
we're
not
using
it.
No
one
else
should,
but
I
I
do
want
to
like.
I
guess
I
want
to
understand
too,
if
this
is
something
like
that
seems
sensible
to
put
in
tree
or
is
this
like?
A
just:
go
implement
your
own
web
hook,
and-
and
this
is
just
a
policy
issue.
A
But
that
said,
I'm
also
in
favor
of
kind
of
restricting
this
as
a
known
vulnerability.
But
I
guess
that
again
it's
like
running.
F
A
Mirror
pockets
are
required.
I
forget,
if
it's
an
annotation
or
a
label
on
it,
so
you
could
say
if
it's
a
mirror
pod,
then
you're
not
allowed
to
have
any
of
these
labels.
E
E
A
I
mean
there
is
this
cap,
that's
already
merged,
that
proposes
an
entry
version
of
this.
I
think
it
needs
to
be
revisited.
You
should
link
to
that.
I
did
it.
H
We
talked
about
it
long
ago,
tim
hawkins,
like
a
year
ago,
the
the
issue.
The
issue
was
around
like
there
are
use
cases
for
setting
these
labels
now
and
we
never
really
fleshed
out.
What
a
policy
would
be
like.
Would
it
be
around
sets
of
nodes
are
able
to
specify
certain
labels.
We
never
really
described
how
that
could
happen.
A
I
J
Yeah
yeah,
so
I
just
as
I
was
looking
into
this,
I
came
across
this
issue
looks
like
it's
been
discussed
before,
so
I
kind
of
just
wanted
to
understand
where
the
discussion
left
off,
with
with
some
sort
of
a
mechanism
to
allow
for
request
signing
in
clients
and
whether
the
the
community
was
opened.
I
didn't
see
any
caps
in
progress
or
anything
like
that
specifically
regarding
this,
but
I
might
have
missed
one.
J
J
J
Add
a
little
bit
of
detail
looks
like
mo
con
created
this
issue
and
I'll
just
quote
on
the
client
side.
We
do
not
have
a
good
story.
The
exact
credential
plug-in
mechanism
is
not
designed
for
this
purpose.
In
particular,
client
expects
to
catch
the
credential
until
it
expires
or
the
process
exits.
The
request
information
is
not
passed
to
the
exact
plug-in.
Calling
an
external
process
per
request
also
seems
like
a
bad
idea
in
general.
It
is
impossible
today
to
use
the
exact
plugin
mechanism
to
attempt
to
support
request
signing.
J
Whether
there
is,
would
it
be
worth
attempting
to
write
a
cap
that
proposes
an
external
process
executing
an
external
process
for
request,
signing
from
client
go
or
is
that
a
non-starter.
I
I
think
for
context
too.
This
came.
This
came
up
earlier
from
discussions.
I
was
having
with
mo
and
some
other
folks
about,
like
yeah,
adding
request
signing
to
kubernetes,
and
I
think,
from
my
recollection
like
this
was
around
the
same
time
as
the
there's
a
kept
to
add
like
what
was
it
like,
ub
key
or
something
for
every
request
in
the
in
the
client.
C
I'm
just
trying
to
remember,
I
think
the
two
sort
of
schools
of
thought
were
one
was
having
a
way
for
exec
plugins
to
like
do
request,
signing
and
the
other
was
making
control
talk
through
a
proxy
and
like
if
you,
whatever
you
want
to
do
with
requests
like
if
you
want
to
sign
them
or
like
whatever
you
want
to
do.
I
think
we
can
mostly
do
with
running
a
proxy
like
a
local
authentication
proxy
that
decorates
requests.
However,
we
want
I'm
sorry,
I'm
paging
this
back
in.
C
I
can't
remember
if
there
were
gaps
with
that
approach.
I
mean
it
certainly
seems
more
lightweight,
especially
now
that
we
have
proxy
url
support
in
cubeconfig.
So,
like
you,
can
point
cube,
config
or
cube
control
at
a
proxy
and
have
it
talk
to
that.
J
Mean
then
you
I
mean
if
you're,
if
you're
thinking
of
like
a
some
developer
on
their
laptop
to
me,
that
seems
slightly
more
onerous
than
the
exec
method.
But
I
guess
in
other
senses
other
clients
that
might.
I
I
I
think
it
would
be
worth
measuring.
I
think,
an
open
http
proxy
that
just
signs
requests
is
a
little
scary
like
on
the
on
the
client
side
like
if
you
just
had.
C
An
external
process
it
doesn't
have
to
be
open
right,
like
the
cube
control
can
still
like,
say,
talk
to
this
proxy
and
hear
the
credentials
to
talk
to
the
proxy
okay
and
then
so,
like
assuming.
You
know,
you
start
your
like
signing
proxy
and
it
like
decorates
your
cube,
config
and
like
put
configures
proxy
url
and
puts
in
the
short-lived
credentials.
C
So
you
say,
like
start
my
proxy
and
you
tap
your
yubikey
and
you
get
like
a
short
term
credential.
Now,
it's
not
an
open
proxy.
Like
only
cube.
Config
can
talk
to
that
proxy
and
then
the
proxy
does
whatever
signing
it.
Does
that's
what
I
was
envisioning,
but
I
wasn't
sure
the
gaps
there
that
I
was
missing.
I
C
J
I'll
yeah
I'll
take
a
look
at
the
the
short-lived
local
proxy
possibility,
but
other
than
that
I
mean.
Is
there
strong
resistance
to
the
general
idea
and
would
people
be
open
to
a
cap.
C
I
Not
a
there's,
not
a
real
standard
out
there.
At
this
point
for
request
signing
like
there's
some
dr
etf
drafts
out
there.
J
Yeah,
I
was
thinking
more
of
just
providing
the
ability
for
you
know.
In
our
case,
we
have
a
method
of
request
signing
we
can
you
know
we
don't
need
to
build
it
into
kubernetes
other
than
just
providing
a
mechanism
for
the
client
to
get
its
requests
signed.
J
C
I
think
the
question
is
just
about
like
how
do
we
communicate
all
the
all
the
relevant
attributes
of
the
request
to
the
exact
plugin,
and
how
does
it
like?
What
does
it
give
back
to
us
that
we
include
like?
Is
it
all
the
headers,
the
url
and
headers
method,
url
and
headers
body
content
like
yeah?
It's
just
a
much
bigger
service
area
than
what
we
have
today,
which
is
give
me
either
a
client
or
a
token
to
send
to
the
server.
C
So
we
it's
a
lot
less
clear
like
what
the
inputs
and
outputs
of
that
are
and
yeah.
I
aren't
super
standard
things
around
request,
signing
we'd
sort
of
be
making
it
up
or
trying
to
jump
onto
like
a
draft
thing
with
ietf,
whereas
if
you're
talking
to
a
proxy,
it's
like
what?
What
information
does
the
proxy
have
about
the
request?
C
J
Okay
yeah,
so
I
I
think
like
both
of
those
make
sense
and
in
the
in
the
case
of
exec,
I
would
think
we
would
do
the
entire
request
too,
but
yeah
the
proxy
method
seems
totally
reasonable.
C
At
least
starting
with
that
and
seeing
how
far
you
get
and
seeing
if
there
are
blockers
anytime,
we
can
make
progress
quickly
and
without
inventing
new
things
that
are
specific
to
kubernetes.
I
think
that's,
probably
a
win.
J
A
All
right:
do
you
have
a
clear
idea
of
next
steps
there
nick.
J
Yeah,
I
think,
explore
the
the
proxy
approach
I
can.
I
can
explore
both
of
the
approaches
in
a
cap,
and
but
it
sounds
like
proxy-
is
a
little
bit
favored,
because
there's
less
stuff
we'd
have
to
invent
so
see
if
that
makes
sense.
After
writing
it
down,
but
I'll
I'll,
spend
a
little
bit
of
time
on
the
alternative
as
well.
A
All
right,
thanks
all
right,
pod
security
policy
have
tabitha.
Do
you
have
a
status
update.
D
Yeah,
I
I
promise
not
to
take
up
the
entire
meeting
with
pod
security
policy.
This
time.
D
But
I
I
definitely
appreciated
the
way
that
we
all
had
a
lot
to
share
at
the
last
meeting,
because
I
mean
honestly,
it's
super,
informative
and
so
just
wanted
to
let
everybody
know,
in
light
of
the
the
discussion
that
we
had,
that
took
over
the
entire
last
meeting
that
you
know
we
are.
D
That
way
people
can
have
the
arguments
while
change
is
still
easier,
but
in
in
a
desire
to
come
with
something,
that's
specific
enough
to
agree
or
disagree
with
there's
there's
work
ongoing
before
it's
really
specific
enough
to
even
bring
around
for
wider
socialization.
So
I
just
wanted
to
make
sure
to
pop
in
and
say
yep.
This
is
a.
This
is
a
thing
that's
happening
and
there
there
will
be
more
to
talk
about
in
the
future.
C
I
think
the
one
of
the
things
towards
the
end
of
the
last
meeting,
I
think
we
realized
we
were
talking
past
each
other
a
little
bit
in
terms
of
like
wanting
to
preserve
a
way
to
have
controls
around
these
things
and
and
not
just
kicking
everything
out
of
tree
like
there's,
I
think,
there's
a
desire
to
have
something
that
can
serve
most
people's
use
cases,
and
so
that
sounds
like
what
you're
working
on
just
given
sort
of
the
baggage
of
api
compatibility.
D
Yeah
yeah.
I
think
that
it
must
absolutely
be
something
else
exactly
because
of
api
compatibility
yeah,
but
it's
conceptually
pod
security
policy.
C
Yeah
cloud
security
policy,
the
good
parts,
so
I
think
I'm
I'm
really
glad
to
see
attention
on
it.
I
don't
think
that
changes
the
trajectory
of
the
current
api,
but
having
a
thing
to
tell
people
like
this
is
we're
not
just
abandoning
this
concept.
There
is
work
happening.
Here's
where
that
work
is
happening.
I
think
that's
helpful
for
people,
given
that
we
don't
anticipate
graduating
the
current
api.
C
I
think
it's
still
useful
to
market
as
deprecated,
just
as
a
signal
to
like,
if
you're
not
already
using
it,
you
shouldn't
start
using
it
like.
Don't
don't
jump
on
this
bandwagon
like
wait
for
the
thing
we're
working
on
to
to
like
jump
into
this,
if
you're
new
to
kubernetes,
like
you
probably
don't,
want
to
start
investing
in
the
current
pod
security
policy
api,
and
so
I
think
the
sooner
we
can.
D
C
C
D
Yeah
yeah
and
actually
to
to
put
a
fine
point
on
those
concerns.
My
understanding
is
that
pod
security
policy
will
be
marked
deprecated
in
122.
H
C
Oh,
let
me
look
at
these
apis
there's
this
beta
api
cool
and
they
start
using
it,
and
we
know
like
in
three
months
or
four
months
in
122
they
were
going
to
start
getting
a
warning
about
no
deprecated.
I
think
it's
just
kind
to
communicate
as
far
in
advance
as
we
can
that
this
thing
is
not
going
to
graduate,
and
you
know
I
think,
yeah.
D
Yeah
yeah,
I
think
I
agree
with
that,
especially
if
we're
talking
about
121
since
121
is
a
ways
off
that
should
be
plenty
of
time
to
get
a
robust
public
discussion
going
about
what
the
replacement
is
going
to
look
like,
and
I
would
want
to
also
reserve
the
right
to
extend
out
the
end
date,
because
what
I
would
really
like
to
see
is
for
there
to
be
no
dead
zone
where
psp
has
been
removed,
but
there
isn't
a
good
alternative
for
people
to
migrate
on
to,
especially
since,
at
least
at
this
stage
in
the
discussion,
one
of
the
primary
goals
is
to
make
migrating
from
psp
as
painless
as
possible.
D
For
people
like
it
clearly
won't
be
the
exact
same
api
object,
but
but
to
make
the
migration
for
people
who
have
used
psp
relatively
painless.
I
would
want
there
to
be
a
good
overlap
between
the
ramp
up
of
whatever
you
know.
Psp
plus
plus
ends
up
being
called
just
to
make
sure
that
people
have
a
good
chance
to
move
on
to
it.
You
know
have
feedback
during
beta.
C
D
D
C
I
would
actually
like
to
keep
that
and
let
it
spur
urgency
and
involvement
in
making
progress
on
this,
that
that
would
I'd
like
to
keep
that
stake
in
the
ground
and
say
this
is
the
date.
That's
why
this
needs
attention
if
you're
interested
come,
participate
and
contribute
and
make
progress.
Now
on
this.
D
I'm
willing
I'm
willing
to
agree
with
that,
but
I
would
be
very
opposed
to
that
going
a
little
further
to
everybody
needs
to
panic,
rush
out
of
psp
now
like
if
that
like.
If
that
makes
sense,
I
agree
with.
I
agree
with
your
desire
to
have
it.
You
know
as
a
carrot
to
move
things
along,
but
but
I
think
that
the
messaging
around
it
is
is
important.
K
On
the
usage
of
psps.
I
D
K
Just
whether
they're
used
or
not
right,
because
I
think
one
of
the
challenges,
obviously
that
has
been
discussed-
has
been
that
they're
hard
to
use
in
production.
So
it
would
be
interesting
to
know
to
to
help
decide
if,
if
a
migration
or
path
needs
to
be
planned
or
if
it
can
be
a
clean
break
and
a
redesign.
K
A
I
Enable
it
for
all
our
clusters,
so
technically
all
all
eks
customers
are
using
it
like
they
might
not
be
aware,
because
they
have
a
permissive
policy,
but
ever
it's
used
everywhere.
So
I
think
I
think
to
the
point
that
yes,
a
lot
of
people
use
it
is
is
probably
sufficient
for
just
design
it
like
how
we
want
to
design
what
the
you
know.
Next
version
looks
like.
C
Speak
speaking
is
one
of
the
people
responsible
for
it.
I
feel
like
I
can
say
this
if
you're
using
it
and
you're,
not
aware
of
it,
you're,
probably
not
benefiting
from
it
at
all
like
if
your
policy
is
so
pervasive
that
you
don't
even
recognize
that
it's
restricting
you,
then
I
question
whether
it's
doing
you
much
good,
but.
D
D
C
A
Yep
as
we
kind
of
work
through
the
design
kind
of
tie
it
back
to
the
earlier
discussion
on
mirror
pods.
A
One
of
the
problems
that
we've
called
out
with
the
existing
cloud
security
policy
is
the
the
api
is
sort
of
unbounded.
It's
unclear
what
goes
in
there
or
where
we
stop
adding
things
to
it,
which
is
one
of
the
things
that
appeals
about
something
like
opa
or
gatekeeper,
where
it's.
You
know
the
entire
api
surface
and
write
arbitrary
policies
on
it.
A
K
D
A
And
maybe,
to
give
a
kind
of
a
concrete
example
there,
the
the
external
ip
issue
that
we
published
on
monday
is
an
example
of
something
where
I
don't.
I
wouldn't
necessarily
want
to
see
that
in
the
default
pod
security
policy,
first
of
all,
it's
on
pod
but
like
if
it
were
that's,
not
explicitly
a
privilege
escalation,
that's
more
a
like
traffic
interception
in
a
multi-tenant
environment,
so
kind
of
being
clear
about
like
where
we
draw
the
lines
on
things
like
that.
A
C
C
A
All
right,
I
think
we
should
call
it
there.
We
will
cancel
the
next
sig
off.
I
think
that
would
be
on
the
23rd,
so
our
next
meeting
will
be
on
january.
6Th,
so
see
you
all
next
year.