►
From YouTube: Sig-AUTH Bi-Weekly Meeting for 20220511
Description
Sig-AUTH Bi-Weekly Meeting for 20220511
A
B
C
C
I
seem
to
remember,
like
seven
years
ago
mike
saying
that
he
had
concerns
about
allowing
someone
with
possession
of
a
token
to
determine
the
identity
that
both
that
that
token
represented,
and
I
wanted
to
make
sure
you
had
a
chance
to
say
whether
you
had
a
concern,
the
idea
being
that
you
would
be
able
to
take
a
token
and
say
or
just
connect
to
the
server
and
say
who
am
I
and
they'll,
come
back
and
say
you
have
connected
as
david
eads
you're
a
member
of
these
groups.
This
is
your
user
extra.
A
Right
so
I
I
think
the
thinking
back
about
the
concern,
the
what
I
was
probably
talking
about,
was
kind
of
in
like
in
oauth
scenario.
We
would
require
something
like
an
email
scope
to
allow
an
oitc
client
to
determine
what
the
email
address
associated
with.
That
token
is
so
I
I
don't
think
you
know
in,
like
speaking
specifically
about
google
oauth.
A
A
I
I
you
might
have
started
talking
before
I
raised
my
hand,
but
what
I
was
gonna
say
is
like
one
of
the
existing
integrations
that
we
have
today
in
kubernetes
is
the
oidc
authenticator,
which
uses
the
id
token
as
the
mechanism
for
authentication,
which
is
interesting
one
because
it
really
annoys
the
open
id
connect.
Folks,
they're,
not
a
fan
of
that
they're
like
you're
supposed
to
use
access
tokens
for
this,
not
id
tokens.
A
But
you
know,
as
an
aside
that
token
itself,
you
know,
tells
you
at
least
your
username
and
group
sort
of
just
directly.
It
doesn't
necessarily
tell
you
well,
I
might
also
tell
you
uid,
depending
on
how
the
system
is
configured,
but
so
that's
like
one
sort
of
I
wouldn't
say
it's
a
precedence,
but
it's
at
least
a
model
that
has
information
available
to
the
user.
A
The
the
other
thing
I
was
going
to
mention
is
you
know
if
you
were
asking
just
third-party
external
so,
like
the
tons
of
hot
stack,
has
mi
command,
basically,
which
today
is
implemented
using
an
aggregated
api
that
simply
echoes
back
what
the
aggregate
api
server
saw
about
you
so
like
it,
which
today
means
username
groups
and
extra.
It
doesn't
include
uid
because
of
a
bug
in
the
aggregation
layer,
but
otherwise
it's
the
full
information,
but
that
api
is
accessible
by
anyone.
That's
authenticated,
it's
not
a
it's
not
meant
to
be
secret
in
any
way.
B
C
Yeah,
I
guess
I'll
bring
up
one
more
example
and
it's
open
shift.
It's
different
than
the
tonsil
case.
Open
shift
runs
our
I
think
it's
different
openshift
runs
our
own
oauth
server
internally,
which
mints
tokens,
and
that
means
that
there
is
only
we
only
expose
the
information
that
openshift
has,
and
so
things
like
user
email,
that's
dropped
things
like
what
the
the
oidc
integration
you
may
have.
D
A
So
for
us,
the
information
that
is
exposed
is
the
information
that's
going
to
be
presented
to
the
kubernetes,
odd
stack,
so
basically,
the
exactly
what's
in
the
user
info
interface
is
what
we
expose
back
but
yeah.
If
there
was
some
other
metadata
that
the
odds
like
had
access
to
like
your
home
address
or
something
because
you
decided
to
include
that
in
the
scope
of
the
oydc
client
or
anything,
we
don't
include
that
in
the
tokens
that
are
being
sent
around
so
it's
not
exposed.
I
I
think
in
that
sense,
david
it
matches
openshift.
C
C
A
Yes,
exactly
so,
just
as
openshift
effectively
federates
some
external
idp,
which
may
or
may
not
have
tokens,
the
timezoa
stack
was
basically
the
same
thing
so
yeah.
You
are
right
in
the
in
the
google
case.
It's
it's
a
it's
different
in
the
sense
that
google
itself
is
an
idp
and
in
the
gke
case,
it's
like
directly
integrated
as
the
idp
within
the
platform.
So
like
those
those.
A
A
A
C
D
A
The
thought
I
had
was
a
an
ephemeral
arrest
api
like
token
review
and
subject
x3
all
of
those
in
the
off,
then
obviously
so.
Something
like
that,
but
one
that
just
basically
takes
in
so
at
that
layer
within
the
stack
you
you've
already
authenticated
the
system
already
knows
that
you've
already
also
authorized
everything,
so
it
would
be
basically
just
turning
around
and
sending
back
what
it
knew.
A
So
the
idea
would
is
is
that
it
would
be
compatible
with
like
any
front
proxy
or
anything
else
that
you
had
doing
odds
like
basically,
no
matter
what,
because
at
the
end
of
the
day,
they
have
to
tell
the
kubernetes
api
server
who
you
are,
and
this
api
is
basically
just
going
to
turn
around
and
say
after
whatever
magic
happened
in
front
of
me.
This
is
what
I
understood
to
be
the
user,
whether
it's
a
token
a
front
proxy
or
whatever.
I'm
just
going
to
send
that
back
to
you.
A
A
A
B
A
A
C
A
C
One
thing
I
would
like
us
to
clarify
here:
if
we
can,
I
don't
think
I
see
this
as
ever
being
required
for
conformance.
Do.
Do
we
see
a
state
differently
for
that
and
I
guess
a
capital
wanted
to
cover
that,
so
we
agreed
to
it
there
not
because
I
want
to
turn
it
on,
but
because
I
can
imagine
other
people
not
wanting
to
turn.
A
A
Yeah
I
mean
I
don't
I
don't
know
if
I,
if
I
care
one
way
or
the
other,
so
you
a
client
would
be
able
to
see
if
it's
present
in
discovery
right
if
it's
just
or
see
that
it's
not
present.
If
it's
disabled-
and
you
know,
if
you
had
like
a
cube
ctl
who
am
I
command,
it
could
say
that
this
api
is
disabled
on
the
server.
Please,
please
contact
your
admin
or
something.
C
B
D
D
A
E
All
right,
sorry,
okay,
anyway,
so
this
cap
is
pretty
long,
so
I'm
gonna
try
my
best
to
go
through
it
quickly.
But
as
many
of
y'all
already
aware
of,
there
are
a
bunch
of
improvements
I
for
for
kms,
as
is
today,
and
this
cap
actually
introduces
proposes
v2
of
the
kms
service
contract,
specifically
to
enable
fully
automated
key
rotation
for
the
latest
key
improved
canvas,
plug-in
health
check,
reliability
and
improve
observability
of
the
envelope
operations
between
api
server,
kms
plug-in
and
kms.
E
E
And
now,
as
you
can
see,
a
cipher
is
now
updated
to
ciphertext,
and
then
we
introduce
a
new
current
key
id,
which
I
will
discuss
in
later,
as
we
will
use
it
for
rotation,
but
specifically
metadata
here
is
introduced,
specifically,
is
something
that
we
could
or
any
plug-in
could
potentially
use
to
persist
this
encrypted
local
cache
to
scd,
and
when
it's,
when
key
hierarchy
is
not
used,
it
is
pretty
much
the
same
as
today.
As
you
can
see,
the
remote
cache
is
what
is
used
to
decrypt.
E
E
E
A
A
A
Yeah,
I
can
take
that
if
you
want
me
to
go
so
this
basically
is
meant
to
look
very
much
like
the
existing
protobus
dormant
storage
format.
We
have,
but
it
uses
a
different
magic
prefix
to
indicate
that
it's
being
used
and
instead
of
storing
a
runtime
dot
unknown,
you
know
as
a
way
of
figuring
out
what
it
is.
It
always
stores
the
exact
same
thing
right
now,
which
is
an
encrypted
object.
A
That's
meant
to
store
the
ciphertext
of
like
the
encrypted
data,
but
also
the
full
encrypt
response,
so
that
includes
the
full
metadata
and
everything
from
the
plugin
and
obviously,
we've
been
very
carefully
documented
to
plugin
authors,
but
that
part
is
stored,
unencrypted
in
the
sense
that
we
don't
store
it
in
any
encrypted
format.
We
store
exactly
what
you
gave
us
and
when
we
try
to
decrypt
something
we
send
it
all
back.
A
E
E
E
A
Is
a
technically
an
implementation
detail
of
the
kms
plugin?
What
we're
saying
is
that
we
will
provide
you
a
reference
implementation
that
can
do
a
key
hierarchy.
If
you
tell
it
to,
it
is
not
a
requirement
of
said
reference
implementation,
the
assumption
being
there
that
the
the
performance
hit
from
kms
comes
from
external
grpc
or
rest
api
calls
to
an
external
kms,
but
that
the
local
grpc
calls
over
the
unix
domain
socket
are
not
that
expensive.
A
We
have
done
some
limited
testing
to
see
that
this
doesn't
is
indeed
true,
but
I
think
it's
part
of
like
even
like
the
beta
criteria
for
this
cup
would
be
to
do
a
significantly
large
cluster,
with
at
least
you
know,
ten
thousand
hundred
thousand
secrets
and
prove
that
the
local
grpc
calls
are
not
the
ones
that
cause
the
system,
the
bottleneck,
because
if
they
are,
then
we
would
need
something
better.
We
would
need
something
within
the
api
server
to
help
break.
That
up.
A
Yeah,
so
I
guess
the
one
thing
on
the
storage
format
is.
We
should
evaluate
whether
we
want
to
continue
to
keep
it
opaque
to
cube
api
server
or
whether
we
need
kind
of
structured
metadata,
not
sure
which
one
is
preferable,
because,
like
one
option,
is
to
just
remove
that
limit
on
what
we've
passed
back
for
the
encrypted
key,
so
that
the
kms
plugin
can,
you
know,
define
their
own
format
for
the
envelope
or,
I
guess,
for
the
associated
key
data.
A
So
I
I
think,
and
we
don't
need
to
necessarily
rabbit
hole
on
this
is
so
the
the
api
that
is
being
sort
of
proposed
has
both
structured
bits
for
the
bits
that
we
want
to
have
opinions
on.
It
purposely
tries
to
leave
like,
like,
basically,
a
labels
map
map
of
string
to
string
as
available
storage
for
the
plugin,
basically
ask
us
to
hold
on
to
some
metadata
for
it
today.
That
metadata
is
just
a
string
to
string.
A
I
didn't
want
to
force
them
to
put
that
into
like
some
opaque
value
right.
I
want
to
at
least
give
them
a
structured
map
to
just
put
stuff
in
so
yeah
I
mean
yeah.
This
is
a
pretty
massive
capsule.
If
folks
want
to
like
very
carefully
read
it
and
think
about
things
and
make
suggestions,
I
don't
think
any
of
us
are
like
married
to
any
of
this.
It's
it's
more
of
like
this
is
the
closest
thing
you
could
come
up
with
for
a
good
athlete.
E
E
A
Okay,
so
what
this
tries
to
do
is
to,
in
addition
to
that
also
support
a
a
single
kms
instance
being
able
to
say
hey,
I
I
see
you
asked
me
to
decrypt
some
data
or
whatever
for
an
update,
call
that
used
this
key
id
at
some
point
in
the
past,
but
the
one
that
I
would
do
future
rights
with.
Is
this
other
one?
A
So
technically,
that's
still,
even
though
api
server
you,
you
can
decrypt
it
because
you
have
everything
cached,
you
still
need
to
mark
it
as
scale
for
the
purposes
of
storage
migration.
That's
basically
what
the
whole
current
key
id
thing
is
doing
is
basically
giving
away
for
the
kms
plugin,
while
it's
running
to
change
what
it
believes
to
be
its
current
write
key,
so
it
can
have
as
many
read
keys
as
it
wants.
A
A
I
mean
it
would
just
make
external
calls
and
go
ahead
and
fill
its
cache
and
do
the
decryption
anyway,
and
but
it
would
then
return
what
key
it
used
to
give
the
api
server
an
idea
of
like
oh,
I
see
that
that's
not
the
key
that
you
want
to
use.
So
that
means
it's
still
david.
I
saw
you
on
mute.
If
you
wanted
to
ask
me.
A
A
C
Yeah,
I
guess
I'm
used
to
the
implementation
of
key
rotation
in
openshift,
where
we
do
keep
track
of.
Who
can
read?
What
does
everyone?
Can
everyone
read
the
version
that
someone
else
is
writing
once
everyone
can
read
a
particular
version.
We
can
then
promote
something
to
the
right
key
yeah
right
right.
So
in
practical
usage,
you
would
want
to
know
everybody
can
read
this
new
key
first
yep
all
right
now
everybody
can
write
with
the
new
game.
A
A
A
Is
that
something
I
don't
know
what
that
gets
us
in
this
design,
because
the
the
way
it's
meant
to
work
is
like
say
you
have
two
api
servers
and
one
of
them
notices
like
one
of
the
kms
plugins
to
api
server,
a
notices,
the
right
key
change.
First,
if
it
immediately
starts
using
it,
if
api
server
b
then
tries
to
decrypt
some
of
that
data,
it'll
totally
work.
Fine,
like
it
works
fine
in
like
our
implementation
stuff.
Today,
because
what
it
does
is
it
basically
asks
the
external
kms
hey?
A
Can
you
can
you
help
me
do
this
decryption,
because
I
just
saw
a
key
id
that
I
don't
currently
know
about,
but
you
probably
do
because
you're,
the
external
kms,
but
basically
it
uses
the
external
kms
as
a
full
coordination
actor
right.
So,
like
you,
you
can't,
but
you
can't
go
to
a
key
that
the
external
kms
doesn't
understand.
A
A
D
A
That's
the
benefit
of
staging
the
new
keys
as
available
for
decryption
well
before
they
are
actually
used
for
encryption
right
right.
So,
what's
unclear
to
me,
and
if
we
try
to
do
it,
that
way
is
how
would
then
the
api
servers
coordinate
this
among
themselves
right?
We
don't
have
a
mechanism.
This
tries
to
avoid
building
such
a
mechanism
right.
I
think
you
just
don't
and
say
a
day
is
probably
enough
for
your
kms
api
to
become
consistent
or
like
if
you're
rotating
every
day.
E
A
E
B
E
A
But
I
think,
like
the
ideal
usage,
is
important
to
understand
when,
when
we
look
at
when
we
review
these
designs,
even
if
you
know,
I
think
that
you
are
right
and
that
this
is
out
of
the
purview
of
what
kubernetes
will
be
responsible
for
like
what
would
we
put
in
the
operator
docs
but
yeah.
I
think
we
have
pretty
reasonable
answers
for
that.
It
sounds
like
already
if
there
are
other
things
in
the
stock
that
you
wanted
to
get
to
rita.
E
B
A
C
A
C
A
C
A
A
Or
for
those
on
the
call
that
weren't
at
the
sig
api
meeting
recently,
I
had
wanted
to
use
the
storage
version
hash
from
discovery,
but
I
was
told
one
that
that
field
will
eventually
be
deleted,
so
don't
use
it
and
two.
There
was
important
and
significant
concerns
about
the
fact
that
discovery
is
accessible
by
most
actors
on
the
system.
So,
even
though
it's
technically
completely
opaque,
it
does
leak
information
about
the
system's
internal
state
to
basically
all
authenticated
users,
and
that
doesn't
seem
like
a
great
idea-
and
I
agree
with
that.
A
C
D
A
Do
we
have
guidance
like
like
for
the
like
of
the
overall
kubernetes
project
for
like,
if
you're,
if
you're,
building
a
feature
that
wants
to
rely
on
some
other
feature,
and
that
feature
is
not
done?
How
how
do
you
progress
like?
Would
we
try
to
block
on
it
or
do
we
try
to
have
partially
working
functionality
that
only
works
when
all
the
feature
gates
are
in
the
right
state.
C
C
C
A
E
A
I
don't
know
so
we
have
two
items
left
tim
and
mo,
so
I
will
give
you
five
minutes.
Awesome.
All
right,
gotta
talk
fast,
so
we,
I
realized,
you're,
not
sharing
a
screen
yet,
but
I'll
just
keep
going.
We
discussed
this
a
while
back
and
david
has
taken
at
least
an
initial
peak
at
a
very
rough
cap,
but
the
the
gist
of
what
the
cap
is
trying
to
propose
is
the
right.
Now.
It
just
proposes
a
code
level
change
that
basically
says
within
kubernetes
client
go.
A
We
will
be
able
to
assert
that
sorry,
not
a
cert
but
configure
tls
configuration
of
the
client,
so
not
the
server,
but
the
client
itself
in
particular,
being
able
to
fully
opt
into
tls
1.3
or
stay
at
tls
1.2
and
control
the
ciphers
therein
of
today.
Neither
of
those
things
is
configurable.
This
is
sort
of
hard-coded
in
client,
though,
and
david
has
rightly
pointed
out
that
if
the
kep
has
written
right
now,
basically
it
only
provides
valuable
to
maybe
like
a
library
author.
A
I
am
nervous
about
trying
to
con
get
expand
this
into
like
cube,
config
territory,
because
then
it
starts
showing
up
around
things
like
cube,
ctl
and
like
some
of
the
web
hook
configuration
and
maybe
ways
that
are
not
great
and
I'm
not
sure
how
to
do
feature
flags
for
any
of
that
stuff.
I
know
how
to
do
feature
flags
for
api
server
and
controller
manager.
A
C
A
Yeah,
that's
basically
it
like,
as
a
for
example,
like
the
default
tls
config
that
we
have
today
will
let
you
use
triple
des,
because
that's
when
you
don't
specify
any
cipher
suites
goes
fine
to
drop
all
the
way
down
to
triple
des,
which
is
man.
It
will
let
you,
but
it
will
never
actually
use
it
right.
So
what
I'm
saying
is
if
the
server
says
I
only
support
triple
des,
then
we
will
happily
connect
right
and
when
I'm
saying
that's
a
bug,
I
want
to
not
connect.
A
I
want
a
failure
because
you
don't
notice
right
so
there's
the
other
aspect
of
even
if
you
control
the
server,
you
might
have
infinite
numbers
of
proxies
between
you
and
it,
and
if
some
of
them
do
things
that
you
don't
like
you,
you
want
to
know
right,
so
it
does
give
you
a
way
of
affirming
on
both
sides
of
the
equation.
I
I
I
do
understand
the
point,
though
the
server
side
config,
is
significantly
more
critical,
but
we
already
have
it
today.
A
You
said
this
would
be
process
level
it.
It
is
both
you,
you
you'd,
be
able
to
override
the
process
level
configuration.
So
if
your
existing
code
isn't
setting
the
new
fields
and
rest
config
it'll
get
whatever
the
new
process
default.
Is
that
you've
changed
from
the
existing
default
and
if
you
set
the
fields
and
those
fields
would
be
honored
in
particular
right
now,
there's
no
provision
for
saying
I
have
this
process
default
and
it
cannot
be
overwritten.
That's
not
in
the
cap
right
now.
A
If,
if
we
wanted
to
have
that,
we
could
so
you
could,
you
could
get
extra
pedantic,
and
so
you
can
only
use
like
the
fifth
ciphers
and
I
don't
care
what
the
rest
of
the
code
does.
I
could
still
see
that
being
valuable.
If
you
have
a
piece
of
code
that
you
fork
and
you
you
want
to
contort
it
in
some
way
and
you
don't
necessarily
want
to
go
patch
every
client
in
there.
A
C
The
other
aspect
that
caught
my
eye
was
in
many
of
the
cases
where
we
make
connections
from
a
cubicle
server
out
the
only
piece
of
information
describing
how
to
make
that
connection
is
a
cube
config,
and
so
I
am
not
at
this
point,
convinced
that
moving
too
stable
without
a
way
to
to
use
it
in
those
areas
is
where
we
want
to
go,
and
so
those
are
two
areas.
When
people
review
the
cap,
I
encourage
them
to
read,
and
hopefully
mo
will
elaborate
as
to
well.
A
Yeah
a
quick
thing,
if
just
based
on
the
feedback,
I've
gotten
so
far
from
you
david,
I
think
I
would
I
would
expand
it
to
at
least
allow
like
api
server
and
controller
manager.
Config
of
this,
like
the
global
process
default
and
once
that's
there,
then
this
would
this
would
go
to
the
standard
alpha
beta,
ga
cycle
just
because
then
it's
exposed
in
a
way.
The
the
thing
I
was
saying
was
just
going
to
be
stable,
as
is
basically
just
the
code
level.
Change
of
client
go,
but.
C
B
Yeah,
so
this
is
just
a
follow-up
from
what
we
discussed
last
week
of
bringing
pod
security
to
ga.
I
wanted
to
get
this
pr
out
earlier,
but
apologies
for
the
last
minuteness
of
it.
The
one
thing
that
we
had
on
here
that
we
didn't
talk
about
last
week
was
conformance
test
plan
that
was
previously
an
unresolved
thing
for
ga.
B
I
basically
copied
what
we
had
from
the
conformance
future
extension
into
here,
saying
that
basically,
the
default
pod
security
mode
is
enforce
privileged,
which
is
a
no
op,
so
that
shouldn't
that
shouldn't
affect
conformance
of
any
clusters.
The
ete
framework
has
been
updated
already
to
explicitly
mark
namespaces
with
the
required
level.