►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Sig Auth Deep Dive - Rita Zhang & Mo Khan, Microsoft; Tim Allclair, Google
Speakers: Tim Allclair, Rita Zhang, Mo Khan
In this presentation, we will talk about all the major enhancements the SIG is working on. These include the ongoing Pod Security effort, KMS encryption at rest observability and performance enhancements, structured configuration for authentication and authorization, reduction of legacy service account token attack surface area, certificate signing request duration control, etc. We will also discuss ways you can get involved with the SIG: https://docs.google.com/document/d/1sY8fRyRtk4eG9R439z5ao5i9bFuuxilS03XaNlqoni0
A
A
So
for
our
topics
today,
we
are
just
going
to
go
through
a
bunch
of
the
work
that
sagoth
is
has
in
the
pipeline,
a
few
things
that
are
basically
finished.
So
we've
got
a
couple
things
that
recently
graduated
to
stable
that
we're
going
to
talk
about
a
bunch
of
things
that
are
kind
of
in
the
progress
of
being
implemented
and
then
a
few
provisional,
a
few
caps
that
were
still
working
through
the
design
of.
A
So
show
of
hands
who
here
is
familiar
with
pod
security,
admission,
all
right,
pretty
good
yeah,
so
pod
security
admission
graduated
to
stable
in
125,
which
is
the
same
release
that
pod
security
policy
was
removed
from
Trey
in
support
security
admission
we
designed
to
be
like
super
simple
security
out
of
the
box
for
kubernetes
enabled
by
default.
It's
not
exactly
well,
it's
not
at
all
a
feature,
complete
replacement
for
pod
security
policy,
and
so
this
was
kind
of
covering
the
like.
A
A
A
Oh
sorry,
yeah.
We
also
have
some
guides
published
on
how
to
do
that.
Migration
and
we
have
a
there's.
A
kubernetes
sigs
project
called
PSP
migrator,
which
automates
a
bunch
of
the
tasks
in
the
the
migration
workflow
like
identifying
mutating
PSPs,
which,
when
you
disable
that
can
potentially
cause
problems
with
things
that
no
longer
work.
C
So
if
you're
familiar
with
certificates
and
the
CSR
API
within
kubernetes,
traditionally
speaking
when
you
ask
for
a
certificate,
you
were
completely
on
the
whim
of
the
signer
to
decide
the
length
of
that
certificate
which,
for
all
intensive
purposes
meant
somewhere
between
one
and
five
years,
there's
a
cert
that
came
out
with
no
revocation
attached,
so
amazing
security,
but
we
fixed
that
not
too
long
ago.
So
now,
if
you
want,
you
can
request
the
duration
of
your
certificate
to
be
shortened
as
low
as
10
minutes
and
all
the
built-in
signers
to
the
controller
manager.
C
B
All
right
so
now
we're
going
to
talk
about
the
implementable
Caps
that
are
that
the
the
stake
is
currently
working
on
how
many
of
y'all
are
using
KMS
encryption
or
encryption
at
rest
at
all.
I
just
wanted
to
show
a
hand
cool.
Thank
you
great.
Thank
you
for
doing
that
for
your
companies,
so
yeah,
so
for
both
we
came
for
both
V1
and
V2.
B
There's
been
some
changes
that
that's
coming
along,
for
example,
default
crypto
algorithm
for
KMS
data.
Encryption
is
Now
default
to
GCM,
so
for
those
who
didn't
want
to
use
CBC.
Now
that
is
available
by
default
in
124,
you
can
still
use
CBC
and
both
CBC
and
GCM
are
in
read-only
format
and
we're
starting
in
125
right,
we'll
start
using
GCM
by
default,
but
read
can
still
support
GCM
and
CM
CBC
for
backward
compatibility
and
then
starting
from
KMS
V2.
B
The
default
will
only
be
GCM
and
for
those
who
may
be
following
the
state,
Gothic
PRS
we
just
merged
a
crd
encryption
yesterday.
So
really
excited
about
this.
What
this
means
for
you
is
in
starting
in
126.
You
can
now
encrypt
your
custom
resources
and
just
add
your
custom
resource
in
the
list
of
resources
in
in
your
encryption
configuration
and
your
pandas
are
happy
and
also
you
know,
as
we
kind
of
look
at
encryption
at
rest,
we're
also
wondering
do
the
community.
B
B
Please
plus
one
or
let
us
know
your
if
there's
an
interest
there,
and
if
so,
we
would
like
to
also
push
for
that
and
perhaps
make
that
a
default
Behavior
going
forward.
So
please
look
for
that
issue
and
we
also
have
hot
reload
for
encryption
configuration,
especially
for
folks
who
have
done
this
in
the
past.
You
all
know
how
hard
it
is
to
make
updates
there,
which
will
also
require
a
API
server,
restart,
which
is
very
problematic
and
could
put
your
cluster
at
risk,
and
so
with
hot
reload.
B
Again
for
those
of
you,
who've
used
KMS
encryption,
V1,
I'm,
sure
you've
known
this
gaps
for
a
while,
and
this
is
I-
think
we
introduced
KMS
V1
what
110
or
something
like
that.
So
this
is
years
ago
right
and
it's
still
in
V1
beta
1.,
and
we
would
like
to
change
that
right.
So
some
of
the
gaps
that
we
have
learned
along
the
way
are,
you
know
performance
right.
B
This
is
not
great
if
you're
trying
to
create
a
cluster
right
and
then
key
rotation
is
another
problem
problem
right
again,
if
you're
an
operator
you've
been
managing
your
kubernetes
cluster,
you
know
how
problematic
this
is.
Today
is
a
very
manual
process,
very
error
prone
and
hard
to
determine
which
key
is
actually
in
use
right.
B
So
we
would
like
to
also
change
that
and
here
we're
introducing
a
KMS,
V2
Alpha
One
again.
This
is
this
went
into
Alpha
in
v125.
So
if
you
want
to
check
it
out
these,
the
the
cap
is
there
as
well
as
some
usage
guidance
in
the
kubernetes
docs
website.
So,
to
use
this
feature,
you
would
enable
the
API
server
feature
gate
to
use
KMS
V2
and
again
this
comes
with
GCM
by
default,
and
it's
going
it's
Alpha
in
125
and
126
and
we're
hoping
to
Target
beta
in
127..
B
B
We
actually
have
a
reference
implementation
to
help
all
the
KMS
plugins
out
there
to
see
how
you
can
leverage
the
recommended
approach,
which
has
a
key
hierarchy,
design
such
that
you
will
have
a
local
key
encryption
key
so
that
you
reduce
the
number
of
remote
requests
that
you
have
to
make
to
the
remote
KMS
and
and
again
we
are
targeting
126
to
have
this
reference
implementation
and
for
key
rotation.
We
have
now
added
beta
metadata
to
track
the
actual
canvas
key
that
has
been
being
used
for
each
request
and
again.
B
B
Last
but
not
least,
we
also
added
a
new
uid
which
is
generated
for
each
envelope
operation
and
again.
This
helps
us
identify
which
requests
actually
went
through
the
the
entire
workflow,
and
we
also
have
a
new
Proto
format
for
the
data
that
is
stored
in
SCD
and
again,
this
is
to
give
operators
the
ability
to
use
a
you
know
a
protobuf
viewer
to
actually
see
the
data
that
is
stored
in
sdd
all
right.
B
B
So,
as
you
can
see,
imagine
you
have
an
encryption
request
coming
from
the
API
server.
What
we're
introducing
is
this
high
arc
key
hierarchy
concept
right
so
today,
with
existing
KMS
plugins,
the
request
comes
in
the
plugin,
sends
it
to
the
KMS,
the
remote
KMS
encrypts,
the
the
the
data
encryption
key
and
Returns
the
encrypted
key
back
to
the
API
server.
That's
how
it
works
today
with
this
new
key
hierarchy
design.
B
What
this
means
is
you,
the
plug-in
developer,
can
actually
add
a
local
Keck
cache
that
basically
says
Hey
for
all
the
request.
All
the
encryption
and
decryption
I'm
going
to
use
this
local
Tech,
which
is
going
to
be
encrypted
by
the
remote
key
right,
that's
stored
in
the
remote
KMS,
and
then
that
is
actually
the
key
that
is
going
to
be
encrypted,
and
that
will
also
be
the
key
that
is
cached
in
the
plugin
and
that
data
is
get
gets,
returned
to
the
encryption
response.
B
And
similarly
for
decryption
now
imagine
you
have
this
key
hierarchy.
Design
right
the
API
server
says:
hey,
looks
like
this.
This
request
actually
is
using
a
local
Tech,
so
I'm
going
to
ask
the
cash
the
the
the
key
cash
to
look
for
the
local
key
encryption
key
and
if
that's
found,
I'm
going
to
use
that
instead
of
making
a
remote
request
right-
and
that
will
also
be
the
key
that
is
used
for
decryption
and
then
and
then
that's
the
key
that
is
stored
in
KMS
in
SCD
as
well.
B
What
this
means
is
you're,
reducing
thousands
and
thousands
of
requests
to
the
remote
KMS
down
to
you
know:
n
number
of
requests
just
depending
on
how
you
set
up
the
the
configuration.
So
if
you
have
three
API
servers,
potentially
you
only
make
three
requests
to
your
remote
KMS,
which
is
beautiful.
You,
you
save
money
and
you
reduce
the
the
performance
impact.
B
So
what
does
that
Proto?
Buff
format
look
like
as
I
mentioned
earlier
here.
As
you
can
see,
the
data
that
is
actually
stored
on
SCD
there's,
a
prefix
looks
very
similar
to
V1,
it
will
say
KMS
V2
and
then
the
actual
object
is
actually
stored
in
this
beautiful,
structured,
Proto
format
and,
as
you
can
see,
there's
the
encrypted
data
and
then
there's
the
encrypted
data
encryption
key,
which
are
encrypted.
C
C
and
I
expect
basically
no
changes
to
this
API
because
there's
basically
no
inputs
and
I,
don't
really
know
what
else.
It
would
do
so
hope
to
see
that
one
soon,
so
anyone
here
familiar
with
client
go
credential
plugins.
Anyone
seeing
all
the
fun
warnings
coming
out
of
like
the
gke
UCLA
thing.
It's
going
to
get
deleted
soon
same
as
true
for
a
cast.
Don't
worry!
C
But
if
you're
familiar
with
the
interface
that
that
mechanism
has,
it
requires
that
the
credential
that
is
used
for
authentication
be
directly
passed
to
client
go
or
cube
CTO
as
an
example.
That
means
it
cannot
be
based
off
of
like
the
hardware-based
credential,
because
Hardware
doesn't
give
you
the
credential.
C
So
this
is
an
extension
to
that
existing
API.
That
will
allow
us
to
support
something
like
mtls
with
you
know,
keys
that
are
stored
in
the
KMS,
as
well
as
if
you
want
to
run
like
a
front
proxy
in
front
of
your
API
server,
and
you
want
to
have
signed
requests,
it'll
be
able
to
do
that
or
maybe
you
just
want
to
add
some
custom
headers
for
logging
or
audit
purposes.
C
As
a
first
small
step
in
that
direction,
we
are
working
on
adding
a
dedicated
API
called
the
cluster
trust
bundle
to
allow
you
to
specify
CA
bundles
that
can
be
reused
in
various
contexts
within
the
kubernetes
API.
So
the
initial
implementation
will
just
be
available
as
something
the
cubelet
can
mount
into
your
pots.
For
you
going
on
in
the
future,
there's
still
some
uncertainty.
Exactly
all
the
places
will
do
this.
C
One
sort
of
obvious
place
is
the
kubernetes
API
server,
so,
for
example,
if
you've
ever
had
to
configure
CA
bundles
for
admission
web
hooks
it'd
be
really
great.
If
you
could
configure
that
in
one
place
and
update
it
in
one
place
and
not
have
to
remember
every
other
place
that
you
had
to
update
that
one
of
the
open
questions
there,
that's
still
undecided,
is
the
API
server.
C
Unlike
most
clients
is
you
know,
High
memory,
High
CPU,
we
can
kind
of
hold
it
to
a
higher
bar,
and
traditionally
we
haven't
had
revocation
support
and
certificates
in
kubernetes,
but
this
is
one
place,
we're
exploring
being
able
to
add,
like
crl
support.
So
that
way,
if
you
wanted
to
revoke
a
cert
at
least
the
API
server
would
honor
it
for
you
and
I
suspect.
That's
a
client
that
many
people
care
about.
A
A
Had
a
bound
service
count,
tokens
which
are
generated
on
the
Fly
for
a
pod
running
with
those
service
counts
with
that
service
count
or
anything
that
wants
to
create
a
token
review
request.
Those
also
expire
they're
bound
to
they
have
a
expiration
time.
You
need
to
be
refreshed,
they're
also
bound
to
the
Pod
life
cycle,
but
we
still
in
kubernetes.
Have
these
Legacy
service
account
tokens
that
are
still
generated
for
each
well?
A
So,
as
of
124,
we're
no
longer
Auto
generating
those
and
then
in
126
we're
adding
an
alpha
to
make
it
easier
to
migrate
clusters
off
of
Legacy
service
count,
tokens,
and
so
there's,
if
this
feature
is
enabled
there's
a
couple
tracking
features
that
get
added
so
the
so.
If
you
do
use
the
Legacy
service
account
tokens,
it
gets
a
warning.
C
So
as
an
explanation
of
what
provisional
means
here,
the
things
we're
about
to
talk
about
are
completely
up
in
the
air.
At
this
exact
moment,
there
isn't
necessarily
agreement
among
the
Sig
or
the
community
that
this
is
where
we're
going,
but
there
are
kepts
open
for
this
and
also
if
you
want
to
get
involved.
This
is
a
great
place
because
we
haven't
written
any
code.
Yet
so
folks
are
familiar
with
the
existing
oidc
integration
that
the
kubernetes
API
server
supports.
It's
very
limited.
C
C
C
And
I
mean
I'm
looking
so
I
mean,
perhaps
we
could
use
this
for
dots.
You
know
that'd
be
cool,
I
haven't
convinced
Jordan,
yet
I
know,
but
the
another
thing
I
want
to
be
able
to
do
is
today.
Tokens
have
just
a
hard-coded
10
second
cache
just
to
like
completely
cause
to
prevent,
like
a
Dos
against
the
API
server,
but
otherwise
like.
If
you
have
a
web
hook,
it's
a
pure
hard-coded
cache
of
like
some
number
of
minutes.
C
Whatever
you
configure
in
the
case
of
jots,
you
know
we
we
can
have
a
claim
that
tells
us
the
expiration
time.
So
you
know
you
can
imagine
a
much
more
intelligent
cache,
the
caches
it
to
that
duration
or
until
like
a
key
rotation
occurs.
You
know,
whichever
one
happens
first,
so
just
all
around
better
semantics
sort
of
following
in
that
same
Trend.
C
Today
you
can
only
have
one
authorization
web
hook
configured
on
the
API
server,
so
we
want
to
be
able
to
support
as
many
as
people
would
want
in
whatever
order
they
want
to
run
them
in.
If
folks,
don't
know
today,
if
your
authorization
Web
book
is
down,
we
fail
open.
So
if
it
was
a
web
hook
that
could
have
denied
a
request,
we
won't
know
we'll
just
we'll
just
keep
going,
which
is
not
exactly
what
people
expect.
C
Another
thing
that
we
want
to
make
it
really
easy
to
do
is
unlike
admission,
that
only
runs
on
like
create
update
and
a
few
other
places.
Authorization
always
runs
on
every
request.
So
if
you
want
to
be
able
to
have
many
web
hooks,
but
not
have
any
single
one
of
them
being
down
completely
catastrophic
to
your
environment,
we
want
to
let
you
Scope,
whence
a
web
hook
would
be
invoked.
So
if
you
know
a
web
hook
only
interacts
with
like
users
from
a
particular
IDP
that
all
have
a
prefix.
You
know
we
want.
C
So
we're
considering
cell-based
filters
there
similar
to
KMS
and
various
other
features,
and
this
is
true
for
the
oidc
thing
earlier
as
well.
We
we
don't
want
any
API
server
restarts
unless,
like
absolutely
necessary.
So
even
though
these
things
are
CLI
Flags,
we
want
to
reload
the
config.
So
that
way,
if
you
can
change
the
file
on
disk,
you
don't
worry
about
anything
else.
C
B
And
last
but
not
least,
right.
We
also
want
to
talk
about
some
of
the
Cross
six
work.
That's
been
going
on
and
I
think
all
three
actually
are
part
of
API
machinery,
and
you
know,
as
we'll
mentioned
earlier
multiple
times.
So
this
is
the
cell
for
emission
control
cap.
That's
I,
think
recently
merged
in
one
for
126,
and
this
is
going
to
touch
on.
B
You
know:
policies
for
emission
validation,
mutation
as
well
as
authorization,
so
there's
a
lot
of
overlap
between
the
the
two
sticks
and
then
also
we
have
storage
version,
API
cap
and
the
aps.
Server
identity
cap
both
are
very
crucial
to
ensure
we
have
on
the
API
server,
which
is
the
foundation
to
ensure
we
can
actually
rotate
the
the
KMS
keys.
So
it's
actually
our
part
of
the
KMS
V2
future
as
well.
B
Anything
you
want
to
ask,
and
of
course
we
can
do
this
without
all
of
the
new
contributors
that
made
this
possible.
I
just
want
to
give
a
quick
shout
out
to
all
the
folks
who
really
really
helped
us
drive
a
lot
of
these
changes:
Anish
Kristoff,
Damien,
nilik,
Andrew
Tahari.
If
you're
listening.
Thank
you
for
all
your
contributions.
B
D
I
think
this
is
time
for
masking.
He
describes
some
changes
to
the
client
go
plugins
to
the
interface,
and
you
mentioned
that
you'll
have
more
control
over
say
having
headers
and
such
is
the,
and
he
said
there
was
some
concern
about
passing
the
data
back
through
the
the
client
go
Library.
So
it's
a
little
confusing.
How
does
the
request
make
it
out
containing
the
contributions
from
the
plugin.
C
So
we
we
went
through
a
few
designs
on
this,
like
we
I
think
the
initial
version
of
this
cap
was
open
like
almost
a
year
and
a
half
ago
now,
but
what
we
settled
on
was
it
would
be
really
hard
to
make
an
API
that
served
everyone's
use
case
and
also
we
were
tired
of
extending
this
part.
So
we
wanted
to
be
done
so
effectively.
C
What
we
do
or
what
we're
planning
to
do
is
basically
the
plug-in
can
give
us
a
proxy
and
we
will
just
connect
to
that
proxy
and
we
expect
you
to
basically
fully
terminate
the
request
and
then
you
can
do
whatever
you
want
with
it.
So
please
actually
send
it
to
the
API
server.
But
if
you
don't
that's
also
fine
I
guess
I
mean:
let's
use
it's
yeah,
it's
it's
yeah!
You
get
to
do
whatever
you
want,
because
you
make
the
request,
not
us.
C
So
it's
it's
meant
to
be
an
incredibly
powerful
extension
Point.
Hopefully
that
most
time
people
don't
need
it
but
Nick
from
AWS,
and
they
wanted
to
make
it
so
their
cubelets
could
do
request
signing
back
to
AWS
infra,
for
example.
It's
a
great
use
case,
totally
not
supported
by
the
existing
extension
point,
but
we're
hoping
that
you
know
others
can
use
it
too.
So.
E
C
E
C
B
The
to
get
involved-
you
know
coding
is
one
part,
but
the
other
part
is
also
give
us
your
feedback
right
and
like,
as
we
write
the
designs,
the
cap.
We
will
love
for
more
feedback
and
reviews
right
and
because
y'all
are
the
ones
that's
going
to
use
it
like,
for
example,
you
know
we
have
to
work
with
all
the
KMS
plugins
right
to
to
make
sure
the
migration
journey
is
not
going
to
be
too
terrible
right.
B
A
If
I
could
just
add,
I
think
those
are
good
answers
for
people
who
are
experienced
in
this
space,
but
you
know
maybe
not
kubernetes
but
understand
a
lot
of
the
nuances
of
say.
Goth
have
a
lot
to
add
on
the
design
aspects
for
like
more
kind
of
Junior
contributors
or
people
who
aren't
as
experienced
in
this
space
I
think.
Actually,
the
stable
features
are
a
really
good
place
to
jump
in
you
know:
I've
have
a
bunch
of
audit
cleanups
that
I'm
working
on
in
the
next
release.
A
C
E
C
That
so
that
reminds
me
on
the
oidc,
a
provisional
cap,
one
of
the
prereqs
for
that
cap
is
an
open
issue
right
now
with
I.
Don't
know
like
20
20
things
on
a
list
of
like
this
is
the
missing
test
coverage
for
oidc
so
like
and
I
have
I
have
blocked
new
changes
to
all
of
that
code
effectively
because
I,
don't
trust
it
did
not
break
if
you
touch
it
so
foreign.
F
Okay,
great
question:
thank
you
for
the
presentation.
Great
design
on
the
key
caching
I,
like
the
key
wrapping
part
I,
think
that's
really
really
cool
thing
and
we'll
solve
a
lot
of
latency
issues,
maybe
just
a
general
question:
what
is
the
scope
of
a
c?
Who
are
you
guys
focused
on
what
is
in
scope?
What
is
out
because
I
see
authentication
authorization
at
the
same
time.
C
C
A
E
G
Yeah
first,
thank
you
for
the
talk.
It's
very
nice
I
have
a
quick
question
about
the
upgrading.
It
looks
like
some
features
are
like
a
brick
broken
feature
without
backward
compatibility.
So
is
there
any
plan
we
put
some
automation
in
the
in
the
code
when
users
do
so
that
when
users
do
the
upgrading,
they
don't
break
their
cluster,
they
don't
cause
outage
in
the
production
environment.
C
C
So
we
we
staged
that
over
many
releases
and
we
have
retained
basically
Until
the
End
of
Time,
the
capability
of
reading
the
old
formatted
data,
so
like
KMS
V1
actually
has
like
I,
don't
know
like
two
Legacy
formats
that
are
still
supported
in
our
code
base.
Even
though
we
never
wrote,
we
never
write
them
out
and
we
haven't
written
them
out
in
like
10
releases.
We
just
assume
that
there
might
be
some
old
data.
That's
never
been
Rewritten,
so
we
are
very
careful.
I.
C
As
a
Web
book,
if
you
really
want
it,
so
that's
fair,
we
did
remove
a
beta
feature
without
graduating.
That's
fair
I,
don't
think
we'll
end
up
doing
something
similar
for
cam
sv1
beta
one,
mostly
because
it's
I
don't
know
if
you're
happy
with
it
I
guess
it
doesn't
really
hurt
us
I
guess,
keep
using
it,
whereas
pot
security
policy
did
cause
all
sorts
of
confusion
and
just
mistakes.
I.