►
From YouTube: SIG-AUTH Bi-Weekly Meeting for 20220831
Description
SIG-AUTH Bi-Weekly Meeting for 20220831
A
All
right,
hey
everyone.
This
is
the
sig
off
meeting
for
august
31st
2022.
So
we're
going
to
be
talking
a
lot
about
our
126
plans
this
time
around
right,
I
guess
we'll
start
with
the
bugs,
because
I
think
jordan,
you
move
them
to
the
top,
which
is
probably
good.
A
A
Is
this
pr?
What
we
want.
B
I
did
a
review
pass
on
it.
It
looks
close
yeah,
mostly
just
wanting
to
make
sure
the
officer
is
able
to
actually
pick
it
back
up
early
in
the
release.
So
I.
B
Probably
so,
if
it's
it
shouldn't
be
user
facing
in
any
way
other
than
fixing
the
bug
like
there's
no
compatibility
issue
outside
of
this.
So
if
it's
a
minimal
enough
fix,
then
yeah,
I
would.
A
B
The
super
user
authorizer
got
set
up
in
a
weird
place.
The
direction
the
support
request
is
going
is
re-centralizing
it.
So,
I
think,
like
I,
don't
know
how
to
defend
against
someone
adding
code
in
a
new
area
and
that's
not
catching
it
in
review,
but
at
least
this
would
get
rid
of
the
split
initialization
pattern
that
we
have.
A
A
B
Is
important,
two,
the
first
part
merged
in
125,
which
made
the
controller
manager
tolerate
both
types
of
csr
requests,
and
so
this
is
the
cubelet
side,
where
cubelets
that
are
asking
for
certificates
for
elliptic
keys.
Don't
include
the
encirclement
key
usage,
so
I
think
this
is
ready.
I
just
needed
to
circle
back
and.
B
Controller,
so
cubelet
must
not
be
newer
than
the
api
server
it's
talking
to.
So
if
you
have
a
126
cubelet,
you
must
have
a
126
api
server.
B
Controller
manager
can
be
up
to
one
version
older,
so
it
either
matches
or
it's
one
version
older.
Like
you
get
a
leader
elected
cluster,
you
have
three,
you
know,
control
plane,
nodes,
one
might
upgrade
it's
api
server
to
126,
but
the
active
controller
manager
might
still
be
125.,
and
so
that's
why
we
put
the
change
into
controller
manager
and
125
to
accept
either
set
of
usages.
A
And
is
that
exception
just
permanent
we're
just
going
to
keep
it.
B
That
exception,
I
think,
from
the
controller
perspective,
we'll
probably
just
keep
it
like
the
yeah,
we'll
we'll
sign
usages
either
way
and
going
forward.
Our
cubelets
will
request
key
usages
that
make
sense.
A
Okay,
but
it's
okay,
so
this
is
not
anything.
We're
gonna
know
back
about,
because.
B
B
This
is
resolving
the
late
breaking
issue
that
we
found
around
exec
off.
B
Breaking
transport
caching
in
client
go
where,
if
you
use
the
exact
plug-in
every
time
you
tried
to
create
a
transport,
it
would
create
a
new
one,
and
so,
if
you
did
like
control
apply
on
a
big
manifest,
you
would
end
up
with
a
connection
to
the
api
server
for
every
item.
In
your
manifest,
so
mo
figured
out
a
clever,
minimal
way
to
fix
the
caching
safely,
so
we
can
backward
that
I
think
back
to
122,
which
is
great,
so
I
think
that's
about
ready
to
go
in.
B
For
the
bugs
that
already
have
prs
open
that
are
being
actively
worked
on,
we
don't
have
to
go
over
them
one
by
one.
Now
that
now
that
we've
already
done
that,
I
mostly
wanted
to
like
I
think
at
the
beginning
of
releases.
We
should
look
at
our
bug,
backlog
and
say
like.
Are
there
things
that
we
should
be
fixing
before
we
devote
time
to
new
features?
So
these
were
ones
that
I
pulled
out,
but
I
wanted
to
give
a
chance
for
other
people
to
do
the
same,
like
long-standing
issues
or
correctness
issues.
A
Yeah
so
let's
see,
I
think
the
grpc
thing,
I'm
just
waiting
for
vortech
to
take
another
look
address
tips
comments,
so
that'll
that'll
be
done
soon
too.
So
that
covers
the
stuff.
I
guess
I
would
ask
the
floor.
Are
there
any
anything
else
that
folks
are
aware
of
that?
We
have
not
captured
here
that
are
regressions
or
bugs,
or
anything
that
take
off
points
that
we
should
actually.
B
A
Okay,
I
didn't
know
that
so
yeah
someone
wants
to
take
a
look.
That'd
be
great.
B
A
A
I
think
it's
a
bit
much
but
waretech
made
a
good
comment
about
that.
We
probably
need
to
wait
until,
like
the
whole
server's
done
before
terminating
kms
stuff,
because
watches
can
still
be
going
and
you
still
need
to
decrypt
them.
B
B
Okay,
if
you,
if
some
occur
to
you,
it's
not
too
late,
you
can
put
them
here
or
like
shoot.
An
email
to
the
mailing
list
say
like.
I
think
this
is
important
and
we
should
do
it
126.
and
are
there
any
takers
or
I'm
willing
to
work
on
it?
If
you
want
to
volunteer
or
you're
looking
for
someone
to
pair
with.
A
Yeah
yeah,
I
think
the
only
thing
I
would
say
is
like
technically
we
knew
about
this
bug
for
like
months
and
then
we
just
we
just
didn't,
realize
the
the
cause
and
the
fact
that
we
shouldn't
remove
core
features
that
and
make
you
use
a
technically
non-functioning
feature
if
you
just
have
enough
data.
A
So
I'm
not
sure
if
there's
anything
we
can
do
about
that.
But
just
you
know,
if
you
notice
a
bug,
that's
not
being
addressed
sure
it
has
the
right
sig
labels
on
it.
So
that
way,
the
right
people
notice,
yeah.
B
I
think
there
was
one
aspect
of
the
exec
off
thing
that
was
reported
against
the
cube
control
repo,
as
well
so
like
places
where
we
are
tracking
issues
and
multiple
repos
make
kind
of
makes
things
harder
in
some
ways.
I
I
know
cube
adam
and
keep
control
have
different
repos
where
they
track
issues.
If
you
see
some
of
those
like
make
sure
people
get
tagged
in
or
maybe
even
spawn,
an
issue
in
kubernetes
kubernetes,
like
we
sig
off,
doesn't
really
watch
other
repos
for
issues.
So.
A
Yeah,
I
did
try
to
make
our
project
board
track
everything
that
looked
vaguely
reasonable
for
us
to
track.
Okay,
but
it's
still,
it's
still
kind
of
the
the
adding
of
items
is
still
semi-manual,
because
I
have
to
run
the
script
on
my
machine
to
go
harsh,
html,
okay.
So
it's
a
process,
maybe
not
a
good
process,
all
right
on
to
features
whom
I.
A
I
have
not
looked
at
this.
I
wanted
to
look
at
it,
but
I
don't
have
to
because
I
know
that.
B
This
one
was
so
close
to
making
it
into
125.
It
missed
code
freeze
by
like
three
days,
but
it
was
a
new
net
new
alpha
thing,
so
we
didn't
feel
like
pushing
for
an
exception
for
a
brand
new
alpha
thing.
So
it's
basically
done
both
david
and
I
had
looked
at
it
and
it
just
needed
to
reduce.
A
A
B
A
B
Yeah,
this
is
well
this.
This
one
is
it's
not
cleaning
stuff
up.
The
first
step
is
tracking
usage,
so
we
can
see
which
old
ones
are
even
being
used.
So
this
is
saying
whenever
you
use
a
secret
based,
auto
generated
token,
we'll
annotate
it
with
the
date
that
it
was
used
so
at
most
once
a
day,
it'll
be
updated,
so
we
have
day
level
granularity
on
use
and
so
that
that's
all
this
is
doing.
Oh
and
it'll
it'll
issue
a
warning.
B
If
you
are
still
using
like
auto-generated
tokens,
that'll
spit
back
a
warning
at
you
and
say
you're
using
an
auto-generated
token.
If
you
really
want
to
use
secret
base
tokens,
you
should
create
one
not
like
scrape
an
auto
generated
one,
and
so
that
gives
us
the
building
blocks
to
later
optionally
clean
up,
auto
generated
secret
tokens
that
haven't
been
used
in
a
certain
period
of
time.
I
think
the
proposal
in
the
cap
was
a
year
like
if
you
have
an
auto
generated
secret
base
token
that
hasn't
been
used
in
a
year.
B
A
B
I,
like
I
said
it's
already
been
through
a
few
cycles.
I
think
it's
pretty
close,
so
I
don't
think
we
need
more
people
on
it.
If.
B
Take
a
look
they're
welcome
to,
but
but
yeah
I
don't
think
we
need
more
folks.
B
A
A
A
But
we
can
start
so,
let's
see.
A
B
A
Okay,
let's
do
this,
let's
go
through
all
the
stuff
and
we
can
come
back
to
some
of
the
details.
If
we
have
time
cool
mostly
because
I
need,
I
need
some
feedback
from
folks
to
like
to
make
sure
I'm
going
in
the
right
place,
but
yeah.
So
I'm
working
on
kms
v2
is
working
on
it
and
this
is
working
on
it.
Rita
is
working
on
it.
A
So
I
think
we're
good
in
terms
of
coverage
for
people.
I
I
plan
on
keeping
it
alpha
in
126.,
mostly
because
I
want
more
tests.
A
Basically,
on
the
on
what
we
managed
to
accomplish
in
126,
we'll
determine
if
in
127
we
can
get
it
through
a
little
beta
state.
A
We'll
see
I'm
hopeful,
but
I
I
unlike
kms
v1.
I
will
not
try
to
push
for
a
veda
until
I
feel
like
it's
really
ready.
A
A
You
know,
I
don't
think
the
oidc
one
has
a
cup
at
all,
and
I
wanted
to
bring
these
two
up
because
structured
oidc
config
has
come
up
a
few
times
and
it
is
listed
as
one
of
the
kepts
that
someone
could
try
to
pick
up
and
then
the
same
thing
for
authorization.
A
A
A
That
that
would
work
consistently.
A
So
that's
an
open
question
there,
even
even
if
you
pull
those
bits
out,
it's
still
a
pretty
large
cap.
So
I
I
don't
know
if
anyone
is
even
signed
up
to
actually
do
the
work
on
this
one.
So.
A
B
Yeah,
I
guess
I
would
ask
if
there's
anyone
else
on
the
call
who
has
like
a
vested
interest
in
seeing
these
make
progress
to
jump
into
the
pr
as
well.
If
the
author
isn't
like
doesn't
have
bandwidth
like
other
people,
can
help
take
things
forward
and
make
progress
on
them.
So
that's
kind
of
an
open
call
as.
A
I
don't,
I
have
anything
else
on
those
let's
see,
I
have
not
reviewed
this,
but
I
know
nick
that
thanked
me
and
mike.
I
think
mike,
have
you
taken
a
look
at
all.
B
A
If
you
could
give
it
another
review,
maybe
we
could
get
on
slack
and
discuss
it
with
nick.
We
could
close
it
out.
Okay,
as
context
for
anyone
who
does
not
remember
this
enhancement
is
to
allow,
just
as
we
allow
a
client
or
credential
plug-in
today
to
dynamically
provide
client
certificates
or
tokens
to
for
for
authentication.
A
This
will
allow
you
to
dynamically
provide
a
proxy
that
would
then
allow
the
proxy
to
do
whatever
it
wants.
Basically,
so
that
proxy
would
have
full
control
over
routing
the
request
to
wherever
it
wants
to
route
it
to,
and
it
can
arbitrarily
modify
the
request
on
the
way
out
and
technically
could
modify
their
response
on
the
way,
and
maybe
you
shouldn't
do
that
one,
but
you
can
yeah
so
yeah,
that's
that's
what
this
cap
is
about.
I
think
nick
was
interested
in
it
for
eks
using
it
to
have,
like,
I
think,
hardware-based
identities
for
tubeless.
A
D
I
just
that's
the
I
don't
know
if,
if
this
is
the
right
sig
for
it,
it's
the
fine-grained,
kublet
api
authorization,
it's
split
between
node
and
auth.
I
would
presume.
D
Oh
yeah,
it's
issue,
2862.
I
put
a
link
in
the
chat.
D
Yeah
this
is,
this
is
different
than
the
cell
thing.
This
is
just
because
I
saw
the
caps
that
you
were
looking
at.
A
So
sorry,
I
got
confused
so
there's
this.
I
don't
think
this
has
a
kepler.
D
Right,
no,
this
one
doesn't
have
a
cap,
yet
I
just
thought
since
you're
listing
out
things
that
might
be
worked
on
in
the
next
cycle.
That
might
be
a
good
one
on
your
list.
Should
we
talk
about
some.
D
Great
yeah,
so
I
think
I
think
we
came
and
talked
briefly
about
so
like
a
month
or
month
and
a
half
ago,
but
I
think
we
more
focus
on
what
we've
been
doing
up
to
that
point,
and
I
wanted
to
give
a
brief
overview
of
what
we're
thinking
about
doing
in
126,
which
is
starting
to
integrate,
sell
into
admission
control,
and
is
it
okay,
five
percent.
D
Right
so,
while
we
wait
the
background
is
in
125,
we
we
had
added
cells
away
to
do
more
advanced
validation
of
crds
directly
into
the
schemas
in
125,
and
that
went
to
beta
okay,
cool
you're
good
to
present
awesome.
Thank
you.
A
Okay,
I
see
you're
seeing
your
commenting.
Do
you
mind,
I
think
that's
a
zoom.
B
Bug
so
if
you
were
using
zoom
lab,
you
have
to.
A
Share
the
whole
bundle
instead
of.
D
D
All
right
all
right,
my
audio
has
not
stopped
awesome,
so
we're
going
to
try
and
get
this
into
cap
form,
probably
by
the
end
of
the
week.
If
anybody
wants,
I
can
share
this
doc
around
we're.
Just
we're
just
collaborating
there's
a
bunch
of
people
working
on
this.
It's
mostly
in
sega
api
machinery,
tim
mulclair,
has
been
contributing
max
smith,
who
works
on
opa
gatekeeper.
A
lot
has
been
contributing.
D
Cc
has
been
contributing
who's
on
this
call,
so
the
idea
is
to
kind
of
extend
off
the
work
that
we
did
in
125
for
crd
validation
rules
and
take
that
idea
to
admission
control.
So,
instead
of
having
to
call
out
to
a
web
hook
to
extended
mission
control,
you
could
do
that
in
process
by
configuring,
the
api
server
to
know
how
to
do
an
evaluation,
some
kind
of
rule,
and
that
would
just
be
an
expression
and
cell.
I
won't
dig
too
much
into
what
excel
expression
looks
like,
but
you
can.
D
You
can
follow
some
of
the
other
links
in
here.
If
you
want
to
know
more
about
that,
so
I
mostly
wanted
to
make
sure
that
this
is
aware
of
what
we're
doing,
and
I
don't
want
to
take
up
too
much
time.
But
some
I
wanted
to
cover
some
of
the
motivate
motivations
and
some
kind
of
like
the
goals
and
see
if
people
have
thoughts
or
concerns
and
then
we'll
start
to
try
and
refine
this
into
a
real
cap
that
we
can
share
with
everybody.
D
But
the
the
very
high
level
idea
is
that
web
hooks
are
complex
to
develop
and
they're
complex
to
operate,
and
so
and
what
we've
found
is
we've
gone
and
we've
surveyed
a
fairly
large
number
of
different
systems
that
do
web
hooks
for
different
kinds
of
things.
D
We've
looked
a
lot
of
policy
engines
because
they
seem
to
kind
of
be
the
main
missing
use
case
that
we
need
to
support
and
most
of
their
rules
can
express
be
expressed
very,
very
with
very,
very
little
code
like
it's,
usually
just
like
an
expression
or
two
against
the
right
part
of
a
resource.
Again,
you
know,
like
you,
find
like
the
right
note
in
the
animal
that
you
want
to
check.
D
D
We've
we've
looked
at
different
kinds
of
use
cases,
but
really
policy
is
the
main
remaining
use
case.
That
we
think
is
the
focus.
Crd
validation
used
to
be
done
with
web
folks,
but
we've
already
handled
that
as
a
special
case.
So
now
we're
really
kind
of
focusing
on
policy,
which
kind
of
can
include
some
security
things.
D
So
that's
going
to
be
interesting.
I
I
think
that
might
apply
to
sigoth
in
in
a
couple
different
ways
like
you
might
actually
use
it
to
secure
something
or
you
know
how
how
we
integrate
with
information
that
needs
to
be
secured
might
also
come
into
play
some
ways
I'm
thinking
about
it
is
that.
D
We
want
to
what
we're
going
to
do
as
an
experiment
is
build,
a
prototype
that
is
actually
in
a
web
hook
to
do
what
we
would
eventually
do
in
tree
without
a
web
hook,
and
we
actually
want
to
keep
that
code
around.
The
idea
that
we've
had
is
to
actually
have
a
supported
polyfill.
So
if
you're
running
a
version
of
kubernetes
that
doesn't
support
this
feature
yet
or
you're
running
alpha,
but
you
can't
use
the
feature
because
it's
often
alpha
there
might
be.
D
We
also
think
it's
really
important
that
whatever
we
build
be
allowed
policies
to
be
reused
outside
of
this
one
enforcement
point
so
like
admission
is
a
major
enforcement
point,
but
a
lot
of
people
want
to
take
their
policies
and
apply
them
like
csed
time
to
make
sure
like
something's
saying
or
they
want
to
like
when
they
introduce
a
new
policy.
They
might
also
want
to
audit
all
the
existing
objects,
starting
the
system
to
see
if
they're,
all
adhering
or
if
there's
some
violations
to
that
policy.
D
So
there's
there's
kind
of
a
need
for
portability,
which
is
a
little
bit
more
challenging.
There
are
certain
rules
that
you
wouldn't
be
able
to
do
so
like
if
you
had
like
a
time-based
rule
like
maybe
you
had
a
moratorium
on
releasing
or
changing
stuff
in
a
cluster,
and
you
tried
to
enforce
that
with
the
policy
rule.
You
could
only
do
that
at
like
admission
enforcement
that
wouldn't
be
like
portable
to
those
other
cases.
D
So
we
have
to.
We
want
to
think
a
little
bit
about
some
of
those
kind
of
nuances
of
policy
when
we,
when
we
build
it,
the
things
that
we're
not
trying
to
do
we're
not
trying
to
build
a
whole
policy
framework
we're
trying
to
build
the
extension
point
at
admission
control
to
allow
you
to
build
policy
engines,
and
so
that's
that's
an
important
distinction
right
like
we're
not
trying
to
compete
with
policy
frameworks,
we're
not
trying
to
take
over
all
their
responsibilities
and
propose
one
way
of
doing
it.
D
We're
just
trying
to
provide
the
primitives
so
like
it
doesn't
matter
if
you're,
opa,
gatekeeper
or
cavano
or
you're
just
doing
your
home,
like
your
own
rule,
set
that's
small
enough
that
you
just
do
it
directly.
We
don't
want
to
get
super
involved
in
all
the
opinionated
things
that
those
systems
might
take
on.
I
think
that's
better
for
the
ecosystem.
Take
on
we're
not
going
to
do
admission
support
in
our
first
release.
We
think,
eventually
this
is
useful,
but
it's
probably
too
so
like
we
want
to
do.
D
We
want
to
do
the
equivalent
of
validating
admission
web
hooks,
but
not
mutating
admission
web
hooks
on
the
first
release,
but
we
want
to
make
sure
that
we
don't
paint
ourselves
into
any
obvious
corners
when
we
do
that.
So
we
have
to
kind
of
keep
in
mind
that
we
might
support
mutation
in
the
future,
but
we're
not
trying
to
build
that
as
the
first
release.
If
that
makes
sense,
we
do
want
pretty
full
feature.
D
So
you're
mostly
going
to
be
constrained,
the
object
that
you
can
see
in
the
admission
request,
and
maybe
some
extra
information
about
the
namespace
or
some
other
stuff.
That's
really
critical!
So
we're
trying
to
figure
out
how
to
balance
that
we
know
that
there's
a
bunch
of
use
cases
and
policy
where
people
need
the
labels
on
the
namespace
of
the
object.
You're
admitting
that's
really
common.
D
There
are
other
more
exotic
cases
where
people
need
to
like
load
up
a
bunch
of
other
objects
in
an
informer,
and
that's
probably
out
of
scope
of
this,
but
maybe
the
namespace
one's
in
so
that's
kind
of
like
how
we're
thinking
about
access
to
other
objects.
There
are
some
things
that
policy
engines
do
that
are
fairly
fairly
complex
compared
to
what
we
did
in
crd
validation.
D
One
is
that
oftentimes
a
policy
engine
will
separate
the
declaration
of
a
rule,
like
somebody
will
author,
like
some
kind
of
policy
rule
from
usually
that
will
be
separate
from
the
actual,
like
application
of
that
rule.
So,
like
somebody
might
say
well,
this
rule
applies
to
this
particular
namespace
and
I
want
to
configure
it.
So
it's
a
block
list
for
these
particular
strings
or
something
so
oftentimes.
There's
a
separation
between
the
declaration
of
policy
and
kind
of
the
application
of
it
to
a
cluster.
D
C
D
A
lot
of
use
cases,
we
have
a
lot
of
capabilities,
we
want
to
support,
I
think
that's
enough
to
introduce
it.
Does
anybody
have
any
questions.
A
I
was
going
to
ask:
have
you
all
considered
any
any
approach
where
so
the
context
is
providing
extra
data
to
your
to
your
functions
to
your
cell
functions?
We
all
considered
any
approach
where
you
could
have
some
like
dedicated
objects
that
contain
the
sort
of
opaque
data
that
basically
you
know
you
can
imagine
somebody
running
a
controller
that
builds
the
correct
state
for
their
functions
and
puts
it
somewhere
and
then
the
contract
is
well.
You
know
you
can
consume
it.
If
you
want
to.
D
Yeah,
I
I
think
this
is
exactly
what
what
a
lot
of
the
use
cases
call
for
so
there's
different
ideas,
we've
batted
around
and
I'm
like
not.
I
haven't
convinced
myself.
I
have
found
a
winner
yet
but
like
one
would
be
like
you
define
a
crd
for
like
your
configuration
information
and
then
like
there's,
either
one
cr
or
a
small
set
of
crs
that
are
this.
D
This
admission
capability
is
able
to
load
up
for
your
for
your
your
policy
and
then
it
uses
that
another
one
is
that,
like
literally
the
the
resource
that
configures
policy
has
a
schema
declaration
and
some
data
right
there
and,
like
a
controller,
has
to
go
like
figure
out
what
data
belongs
in
there
and
just
jam
it
into
that
that
resource
whenever
it
needs
it,
and
then
I
think
there
was
a
couple
other
variations
of
this.
D
A
Yeah,
I
think
I
think
the
most
common
use
I've
seen
around
policies
involves
at
least
a
slight
amount
of
external
state
yeah,
which
you
know,
which
can
be
internalized
by
copying
the
state
from
external
to
somewhere.
That
thing
can
get
to.
But
yeah
I
don't
know
if
just
the
object
and
like
name
space
stuff
would
be
enough
for
a
lot
of
various
policy
bases.
D
Yeah,
most
of
them
require,
like
a
nice
little
chunk
of
configuration,
in
fact,
most
of
them
organize
the
configuration
where
it's
like
you
like
the
the
policy,
the
abstract
policy
isn't
actually
like
kind
of
a
first-class
object
in
the
system
like
you
load
those
up
as
like
a
library
of
policies
and
then
like
when
you
actually
go
to
apply
one
somewhere,
that's
like
the
first
class
object,
and
so
it's
kind
of
inverted
in
that
sense,
it's
not
like
you
configure
the
first
class
object.
D
A
So
that
reminds
us,
I
saw
a
comment
about
psp,
so
so
psp
needs
authorization,
information
or
psp
did
when
they
existed
so
are.
Is
there
any
plans
to
expose
that
to
cell
functions,
the
ability
to
ask
the
authorizer
of
the
server
some
questions.
D
B
A
B
A
current
example
that
maybe
we
wouldn't
consider
horribly
unusable
is
the
the
certificate
the
csr
like
approving
and
signing
like.
If
you
go
to
approve
a
csr
in
addition
to
just
having,
you
know,
write
permissions
on
the
endpoint
like
the
csr
resource
in
general,
you
actually
need
a
specific,
like
approved
permission
on
the
signer
of
the
assigner
name
represented
in
the
csr,
so
that
that
lets
me
give
approved
permissions
to
you,
know,
alice,
but
not
to
approve
all
csrs
just
to
approve
csrs
from
a
specific
signer.
B
B
Yeah
now
we
can
okay.
So
I'm
not
sure
this
applies
to
the
csr
example,
but
I
think
it
could
apply
to
the
psp
example.
What
psp
was
doing,
there
really
was
getting
a
whole
bunch
of
policies
and
then,
and
the
way
it
was
internally
implemented,
was
get
all
of
the
policies
and
then
ask:
can
the
user
use
them?
One
of
the
things
we've
kind
of
talked
about
in
the
context
of
the
cell
admission
controller
is
how
like
how
dereferencing
to
other
objects
would
work.
B
So,
if,
like
I
want
to
get
a
related
object
to
write
a
rule
on
that
like
is
there
some
way
that
we
would
want
to
express
that,
and
that's
one
place
that
I
could
see
authorization
coming
into
play
where
it's
like,
if
maybe
you
use
the
authenticated
user
on
the
admission
request
to
fetch
those
additional
objects,
but
I'm
not
sure
that
we
want
to
actually
allow
you
to
fetch
additional
arbitrary
objects
in
the
first
place.
B
So
I
think,
there's
some
open
questions
there
yeah,
if
you're,
looking
for
just
all
kinds
of
cans
of
worms
to
open,
looking
at
the
admission
context
or
controller
context
or
whatever,
whatever
it's
called,
that
gets
passed
to
current
in
process
admission
plugins
like
that,
has
handles
to
the
things
that
entry
admission,
plugins
use
and
so
there's
a
handle
to
the
authorizer.
B
I
think,
most
of
the
things
in
that
are
probably
things
we
would
like
to
squint
at
and
say
I
don't
know
if
we
want
to
expose
like
all
of
that
through
this
api
service.
But
everything
in
there
is
there
for
a
reason
like
because
we
needed
it
to
do
a
thing,
and
so
it's
at
least
worth
asking
like.
Should
we
expose
some
limited
form
of
that?
Or
what
would
we
tell
people
who
wanted
to
write
admission
that
needed
this
sort
of
information.
B
B
That's
exposed
in
cell
that
checks
this
authorizer,
or
you
know,
thinking
about
other
models
that,
if
that's
too
heavy
weight,
potentially
to
allow
just
arbitrary
code
to
be
executing
right.
There's
like
a
availability
risk,
other
more
lockdown
ways
of
surfacing
that
functionality
yeah.
A
It
reminds
me
we
do
need
to
time
box
this
whole
discussion
because
there's
more
agenda.
That
does
remind
me,
though,
does
this
cap
propose
the
ability
to
filter
which
requests
get
routed
to
which
cell
function
based
on
cell
functions?
D
I
don't
think
we
committed
to
using
cell
functions
to
define
the
filtering,
although
I
think
that
came
up
in
one
of
the
in
one
of
the
straw.
Man
designs,
because
it
turns
out
that
like
knowing
knowing
what
knowing
which
objects
to
include
or
send
through
the
is,
is
a
little
bit
tricky
right.
A
Yeah,
it's
just
a
it's
just
a
thought.
It's
I
I
had
asked
for
similar
stuff
for
in
the
authorizer
config
stuff,
like
the
ability
to
use
cell
to
filter
which
requests
go
to
a
web
hook,
authorizer,
because
it's
so
expensive
because
it's
run
on
every
single
beat
and
right
yeah
and
you
know
if
you
want
to
have
a
fail,
closed
authorizer,
then
you
know
you're
you're
asking
for
trouble
because
it's
much
more
dangerous
than
admission,
because
if
the
your
reads
aren't
going
to
work
either
yeah.
D
Yeah,
I
don't
want
to.
I
want
to
take
too
much
time
from
the
meeting,
but
we
will
we'll
have
a
cap
open
for
this
and
I'll
try
and
I'll
try
and
circulate
it.
So
people
can
dive
in
more.
C
Yeah,
so
basically
I
wanted
to
say
that
it's
still
ongoing.
It's
not
that
because
it's,
the
second
attempt
to
give
cuba
proxy
turn
it
over
to
kubernetes.
So
I
talked
to
david
and
he
mentioned
it
would
be
wise
to
give
an
update
on
the
progress
like
every
quarter
or
something
like
that.
So
I
am
david,
as
I
mentioned
in
the
last
update,
did
the
review
so
we
are
working
ourselves
through
it.
C
There
were
some
nice
findings
that
he
had
and
there's
now
a
lot
of
reflection
around
the
code
because
partially
codebase
was
is
very
prototyping.
Very
clever.
Some
things
are
not
obvious.
Some
defaults
some
implicit
defaults.
This
was
not
not
obvious
this
if
it
is
secure
or
if
this
is
a
bug.
So
now
a
lot
more
things
are
explicit,
so
we
don't
rely
on
any
defaults
for
examiner.
C
Subject:
access
review
and
yeah
we
have
now
some
bigger
refactorings
that
are
pretty
big,
so
we're
taking
more
and
more
code
from
kubernetes
and
I
api
server
and
dropping
more
of
our
own
code,
which
has
small
implications
in
different
behavior,
where
we
kind
of
tend
to
create
a
big
v1
release
that
we
could
then
hand
over
to
kubernetes
like
a
small.
A
good
example
would
be,
for
example,
the
certificates
reloader.
C
You
could
customize,
for
example,
the
time
how
often
it
should
check
if
there
is
a
change
to
the
file
and
and
and
kubernetes
it's
it's
ready
for
one
minute
once
per
minute.
So
there
are
small
changes
also,
we
are
completely
removing
the
insecure,
listening
and
other
stuff
like
that,
so
yeah
we're
kind
of
preparing
for
a
kind
of
bigger
v1
release,
and
we
will
see
how
we
continue
from
that.
If
we
try
to
support
two
different
versions,
yeah
so
stuff
that
we
need
to
figure
out.
C
Oh
and
there's
one
big
thing
left
so
david
was
very
concerned
about
proxies
and
them
being
upgrade
aware.
So
he
referenced
me
to
a
big
cve.
So
there's
also
discussion
around
how
to
solve
that.
If
we
use
the
solution,
that's
in
kubernetes
or
if
we
use
something
specific,
but
I
think
mo
also
posted
a
test
suit
that
we
should
run
against
the
server
to
to
give
it
some
security
and
that's
basically,
it.
A
Yeah
so
that
proxy
cv
that
kubernetes
had
years
ago,
you
know
some
folks
had
written
tests
to
see
if
the
server
was
vulnerable
or
not.
So
certainly
we
can
run
those.
I
will
say
the
upgrade
aware
proxy
code
in
the
api
server
is
by
far
one
of
the
most
unbeatable
things
I've
ever
seen,
and
I
to
this
day
I
still
don't
fully
understand
exactly
what
it's
trying
to
do
so.
The
last
time
I
wrote
a
proxy
that
was
trying
to
proxy
things
like
this.
A
A
B
B
Yeah
when,
when
we
first
implemented
this,
the
standard
library
did
not
support
it
when
it
added
support.
I
have
vague
memories
of
aspects
of
what
we
were
doing,
that
still
we
couldn't
shoehorn
into
using
the
standard
library.
I
don't
know
if
that
gap
has
closed,
and
I
don't
honestly
even
remember
what
the
gaps
were.
B
It
might
have
been
around
some
of
the
stuff
like
how
we
handle
redirects
or
how
we
handle
like
pulling
enough
of
the
headers
and
status
code
out
from
the
back
end
to
see
if
there
was
an
error
and
then
if
there
was
instead
of
forwarding
the
error,
just
sort
of
intercepting
that
and
erroring
at
this
proxy
layer.
Like
I,
I
cannot
remember
all
the
weirdnesses
that
crept
into
our
proxy
implementation.
A
B
I
know
that's
a
crummy
like,
like,
I
don't
even
know
what
we're
recommending
like
we're
saying
we
we
have
an
upgrade
away
proxy.
We
don't
really
recommend
you
use
it,
but
we
also
don't
really
recommend
that
you
like
not
use
it
and
start
a
second
upgrade
aware
proxy.
Like
I
don't
even
know
what
we're
recommending
you
do.
Yeah.
A
So
I
mean
I,
I
had
told
kristoff
to
look
at
the
proxy.
I
wrote
that
didn't
use
this.
Basically,
I
think
there's
there's
three
choices
right:
they
they
do
whatever
they're
currently
doing
they
do.
What
kubernetes
does
with
the
upstream,
the
upgrade
aware
proxy
or
they
do
what
I
did.
I
don't
know
of
any
other
choices.
A
B
Like
if
I
were
to
make
a
recommendation,
it
would
probably
be
like
see
if
the
standard
library
proxy
will
do
what
you
need
and
like
pass
the
test
scenarios.
You
have
and
then,
like
as
a
sanity,
check,
sort
of
look
at
the
vulnerabilities
we
had
or
the
you
know,
terrible
bugs.
We
had
in
our
upgrade
aware
proxy
and
make
sure
that
the
standard
library
one
doesn't
have
the
same
vulnerability
like
there
are
some
things
in
the
standard
library
network
and
http
packages
where
it's
like,
oh
you're,
holding
it
wrong.
B
You
didn't
you
didn't
configure
this
timeout
or
you
didn't
like
handle
this.
Redirect
or
you
didn't
do
this
thing
or
that
thing
like
yo
and
so
yeah.
If
I
were
starting
a
new
project
or
like
bringing
in
a
new
thing,
I
would
probably
try
to
use
the
standard
library
one
and
see
if
it
was
not
vulnerable
to
the
things
we've
discovered
over
the
years
and
ours.
C
Yeah
thanks
a
lot
for
the
input.
I
will
definitely
try
it
in
the
order.
First,
I
will
go
through
the
standard
library
see
if
it
works
properly.
If
not,
I
will
go
through
the
code
that
mo
wrote-
and
more
mentioned
this
to
me,
but
I
wanted
to
be
diplomatic
and
then
know
if
it's
okay
to
say
the
code
is
hard
to
read
so.
C
Okay,
yeah
and
the
third
option
would
be
what
we
have
in
kubernetes,
but
I
will
really
focus
on
on
the
tests
if
they
pass
and
what
kind
of
leverage
they
take
to
to
have
the
exploitation
and
and
try
to
adapt
it.
If
all
the
circumstances
are
different.
A
Thank
you
christoph
for
continuing
the
effort,
so
we
only
got
like
two
minutes
left
so
there's.
I
will
basically
move
all
of
the
kms
stuff
to
next
time.
The
gist
I
want
to
get
across
is
so
rom
had
opened
up
these
two
issues.
A
I
would
like
folks
to
look
at
them
and
tell
me
if
those
are
things
that
we
consider
that
we
should
try
to
handle
basically
and
then
I
would
like
to
get
folks
opinion
on
if
we
should,
let
you
encrypt
all
of
that
cd
because
you
want
to
and
you
hate
yourself
or
love
yourself
depending
on
which
state
you
think
is
good.
A
I
know
what
jordan
thinks
about
this
already,
but
that's
it's
fine
on
hot
reloading
of
the
encryption
config
there
was,
I
think,
the
open
question
there
is
should
should
that
just
happen
on
its
own,
like
once
the
feature
exists,
should
it
just
do
that
or
should
you
have
to
opt
in
or
should
you
have
to
opt
out
or
sort
it
behind
a
feature
flag,
whatever
like
technically,
if
you're
not
putting
wrong
encryption
configs
on
your
disk?
A
It
shouldn't
matter,
but
you
know
today,
since
it
doesn't
matter
technically,
my
stuff
can
break
and
then
the
I
think
the
biggest
part
of
kms
is
so.
I
have
proposed
and
some
really
high
level
details.
A
An
api
server
managed
rest
api
that
exposes
enough
opaque
state
for
an
outside
controller,
to
do
rotation
or
to
help
you
with
storage
migration.
Basically,
so
I
wanted
to
get
folks
opinion
on.
A
A
B
A
B
This
is
just
a
general
thing,
so
everyone
who's
planning
on
doing
some
126
make
sure
the
tracking
issues
and
cups
get
updated.
Early
freeze
comes
early,
it's.