►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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 - Margo Crawford, VMware & Mike Danese, Google
After a quick intro, this presentation will touch upon the current items 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 how to get involved with the SIG: https://docs.google.com/document/d/1sY8fRyRtk4eG9R439z5ao5i9bFuuxilS03XaNlqoni0
A
B
A
And
I'm
mike
I'm
a
software
engineer
at
google.
I've
been
working
on
gk
and
kubernetes
for
almost
seven
years.
Actually
over
seven
years
now-
and
I
am
a
co-chair
and
tl
of
sig
auth.
So
this
afternoon,
I'm
going
to
give
you
a
little
bit
of
an
intro
to
sigoth
walk
through
kind
of
review,
what
we
did
over
the
last
year
or
year
and
a
half
and
then
highlight
a
couple
enhancements
that
are
underway.
A
That
I
think,
are
interesting
and
then
I'm
going
to
hand
it
off
to
margot
she's,
going
to
walk
through
an
implementation
of
a
client
go
exec,
auth
plugin
to
get
you
give
you
kind
of
a
feel
of
how
to
extend
control,
client,
authentication
and
yeah,
and
then
we'll
wrap
it
up
and
go
to
questions
so
so
sig
auth.
What
we
do
this
is
our
patron
xqcd
comic.
A
The
kubernetes
community
is
very
inventive
they're
doing
a
lot
of
cool
things
all
the
time
I
can.
I
consider,
like
sig
os
responsibility
to
make
sure
that
you
know
operators
and
security
administrators
are,
you
know
able
to
you
know,
draw
I
I
guess
guard
rails
around
what
engineers
are
doing.
You
know
examples
of
maybe
auth
relevant
features
in
kubernetes.
Are
you
know
new
new
new
flags
in
the
security
context
of
a
pod
that
you
that
an
administrator
might
want
to
control?
A
A
So
this
is
like
on
paper
what
the
sigoth
mission
statement
is
over
the
last.
You
know
many
years
that
sigoth
has
existed
and
been
meeting
we've
kind
of
adopted
ownership
of
various
things
that
don't
really
fit
neatly
into
this
definition,
and
we
can
talk
about
those
later.
If
you
aren't
aware
already
there's
a
newly
established
as
of
in
the
last
year,
sig
called
the
six
security
who
you
know
might
take
over
various
things
that
have
fallen
on
the
sigoth
community
in
the
past.
A
So
this
is
a
full
list
of
sub-projects
on
the
left
side.
These
are
sub
projects
that
are
in
kubernetes
core
code
base,
so
github.com
kubernetes,
kubernetes
audit
logging
subsystem
all
authenticators
authorizers,
including
you
know,
our
back
abac,
node,
authorizer
certificates,
api
and
related
infrastructure,
so
any
entry,
signers
or
approvers
for
the
the
infrastructure
that
cubelet
uses
to
do
certificate,
rotation
for
voltage,
server
and
client
certificates
encryption
at
rest.
So
that
would
be
the
kms
plugin
for
encrypting
data
stored
in
ncd
at
rest,
node,
isolation
and
identity.
A
So
the
the
authorizer
and
admission
controller
responsible
for
preventing
cross
node
escalations
policy
management
such
as
you
know,
our
back
and
also
pod
security,
admission
and
anything
service.
Kubernetes
service
account
related.
So
out
of
tree.
We
have
kind
of
a
multi-tenancy
working
group
and
they
have
kind
of
incubator
project.
A
Out
of
that,
incubator
came
into
hierarchical,
namespace
controller,
which
is
a
project
that
is
focused
on
synchronizing
policy
across
a
hierarchy
of
name
spaces
and
the
secret
store
csi
driver,
which
is
a
csi
driver
that
integrates
with
various
secret
stores.
I
think
azure
gcp,
aws
and
vault
right
now
all
have
plugins
and
they
expose
kind
of
a
secrets
api,
but
rather
than
having
the
secrets
to
be
stored
in
scd,
they
are
stored.
A
You
know
in
your
secret
manager
of
choice
and
coming
soon.
So
this
is
a
recently
I
guess
currently
going
through
induction
subproject.
So
the
cube
rbac
proxy
is
a
pretty
widely
used
popular
project
and
we
have
recently
decided
to
make
it
an
official
sagasa
project,
not
sure
if
I
said
it,
but
at
any
point
just
raise
your
hand
if
you
have
questions.
A
So
what
have
we
done
in
the
last
year
and
a
half
so
pod
security
admission
is
ga
in
125,
which
is
the
upcoming
upcoming
release
of
kubernetes.
We
also
just
recently
merged
apr
to
delete
pod
security
policy
from
the
kubernetes
codebase.
So
that's
a
huge
accomplishment
certificates
api
went
to
ga
with
a
couple
new
features
specifically
like
signer
partitioning
the
exec
auth
plugin,
which
we
cube
control.
Credential
providers
are
now
ga
that's
what
margo
will
be
speaking
on
later
token
requests,
ga
and
secret
source
csi
drivers,
ga.
A
A
The
certificate
manager
need
to
have
a
need
common
need
to
distribute
certificate
bundles
to
all
pods
in
a
cluster
right
now.
The
state
of
the
art
to
do
that
is
a
config
map,
since
config
maps
can
only
be
referenced
by
pods
in
the
same
name
space
as
the
config
map.
You
end
up
synchronizing
config
maps
like
that
have
the
same
data
across
you
know.
Many
namespaces
has
presented
a
scalability
issues
in
clusters
with
many
namespaces.
A
A
It's
I.
If
you've
ever
written
like
a
dynamic
web
hook
configuration
you
also
have
to
embed.
You
know
a
certificate
for
qbps
server
to
establish
a
connection
to
the
web
hook,
so
these
should
will
also
be
referenceable,
and
you
won't
have
to
do
that.
I
know
that
you
know
in
the
current
mechanism
is
kind
of
gross
and
not
super
portable.
It's
hard
to
write,
helm,
charts
that
have
dynamic,
weft
configs.
For
that
reason,
the
next
one
is
kmsv2.
So
this
is
the
extension
point
that
is
used
for
encryption
at
rest.
A
The
current
kms
extension
point
has
been
alpha
for
a
very
long
time.
It
had
over
the
years
of
working
with
it.
A
couple
issues
have
come
up
the
it
is
hard
for
an
administrator
to
understand
what
the
storage
version
of
a
you
know.
Secret
that
might
be
encrypted
is
like
what
key
it
was
encrypted
at
the
health
check.
A
A
So
while
that
is
awesome,
those
secrets
are
still
those
old
service
gun.
Token
secrets
are
still
created,
which
is
not
a
great
thing,
but
we
can't
just
turn
off
the
token
controller,
because
you
know
we
expect
that
some
users
are
still
using
taking
those
tokens
and
maybe
putting
them
in
jenkins
or
like
a
github
action
toss
on
the
kit
to
their
cube
api
server.
B
B
B
So
then,
grays
makes
this
a
token
review
that
the
webhook
authenticator
is
then
waiting
to
see
and
it
it
sees
that
this
token
review
has
this
bearer
token
and
it's
able
to
interpret
the
token
so
that
the
kubernetes
api
server
can
use
it,
for
you
know
things
like
access
control.
You
know,
take
this
user
info
that
is
now
interpreted
to
tell
us
the
username
and
and
use
that
for
whatever
it
needs.
B
Typically,
the
way
this
is
set
up
is
your
user
has
a
cube
config
and
that
cube
config
has
the
exact
field,
and
within
that,
it's
it's
calling
some
command.
So
this
is,
you
know
some
a
path
to
some
binary
that
exists
on
the
machine.
It's
got
an
api
version.
It's
got
some
arguments
that
are
called
with
the
the
command
that
you're
calling
and
then
it's
got
some
information
about
whether
this
needs
to
be
interactive.
B
B
So
I'm
going
to
walk
through
the
simple
plug-in
now.
This
is
based
on
my
experience
with
pinpad
the
project
that
I
work
on,
but
it's
pretty
simplified.
So
this
one
is
written
in
go,
but
you
don't
necessarily
have
to
write
the
plugin
and
go
because
the
inputs
and
outputs
are
all
through
standard
out.
So
you
know
if
you
wanted
to
write
a
credential
plug-in
in
any
other
programming
language.
That's
also
totally
possible.
B
This
one
is
going
to
be
done
using
the
oidc
password
grant.
So
it's
going
to
take
the
users
a
username
and
password
from
the
cli,
and
then
it's
going
to
take
some
information
about
the
oidc
configuration
it's
going
to
get
an
id
token,
and
then
it's
going
to
package
it
in
an
exact
credential,
which
is
the
format
that
clanko
expects
to
see
this
credential
so
that
it
can
send
to
the
kubernetes
api
server.
B
B
Another
thing,
that's
typically
part
of
that
initialization
is
the
kubernetes
exec
info.
So
when
client
go
invokes
a
plugin,
it
passes
some
data
via
the
kubernetes
exact
info
environment
variable.
So
this
data
comes
directly
from
the
cubeconfig
and
it
contains
stuff
like
information
about
the
target
cluster.
So
this
should
be
useful.
For
example,
if
you
have
a
cluster-
or
you
know
some
authenticator
on
your
cluster,
that's
looking
for
a
specific
audience
and
that
information
is
based
on
which
cluster
it's
running
on
then
in
order
to
allow
your
credential
plugin
to
craft.
B
So
another
important
thing
to
think
about
when
you're
creating
one
of
these
credential
plugins
is
caching,
so
we
we
need
the
cache
credentials,
so
you
don't
have
to
fetch
the
same
token.
Every
single
time
you
make
like
a
cube,
ctl
request,
these
credential
plugins
are
invoked.
You
know
every
time
that
you
run
the
command
they're
short-lived.
So
maintaining
that
say
somehow,
so
you
don't
have
to
repeat
yourself.
It's
pretty
important.
B
This
is
going
to
be
stored
on
the
local
file
system,
so
just
like
within
the
user's
home
directory
they're
gonna
have
some
config
yummy
file
and
it's
gonna
be
keyed
off
of
the
arguments
sent
to
the
command.
So
you
know
in
this
case,
is
gonna,
be
the
issuer
and
the
client
id.
So
if
you
issue
the
same
command
with
the
exact
same
arguments,
you
should
get
the
same
token
back
from
your
file
system.
B
So
this
is
what
we're
going
to
do
to
get
the
file
from
the
cache.
So
we're
going
to
create
this.
This
cache
key
based
on
the
issuer,
the
client
id
and
the
scopes.
So
some
of
this
is
pretty
oidc
specific,
but
you
know
in
any
case
you
want
to
have
some
way
to
to
keep
track
of
of
how
it
was
called
it's
going
to
get
the
token,
and
this
cash.get
token
is,
is
just
a
helper
that
gets
it
from
the
local
file
system.
B
B
B
You
know
a
network
request
to
your
idc
at
any
provider,
or
you
know
in
case
of
a
different
identity
provider
than
that
out-of-band
authentication
either,
and
then
at
the
end,
if
you
did
have
to
get
a
new
token,
then
we'll
come
back
to
that.
But
at
the
end
you
can
put
the
token
back
at
the
cash
key
so
that
the
next
time
the
process
is
invoked.
B
B
B
C
C
C
A
B
So
this
getusername
and
password
function
is,
in
this
case
it's
for
odc
password
grant.
So
it's
going
to
take
these
values
and
then
it's
going
to
pass
them
to
an
oidc
identity
provider.
That's
going
to
give
us
a
token
back
with
some
information
about
the
user.
This
function
actually
works
both
in
interactive
and
non-interactive
environments.
So
it's
you
know,
there's
a
way
to
get
it
from
an
environment
variable.
B
You
know
calling
os.getnn
under
the
hood
and
then
it's
running
this
prompt
for
value
bear
with
me,
because
this
is
a
little
bit
indirect
for
testing
reasons.
So
we
can
do
a
dependency
injection,
but
the
actual
implementation
here
is
this.
Prompt
for
value
function
is
first
checking
whether
we
have
a
terminal,
it's
printing
out,
a
prompt
saying
like
enter
your
username
here,
basically,
and
then
it's
creating
a
channel
with
the
the
result
of
the
user
typing
in
their
username.
B
At
the
end
of
that,
you
know
it's
just
gonna
trim
spaces
and
return
the
value
once
it
gets
that
result.
There
is
a
little
bit
of
a
different
way
that
you
have
to
handle
passwords
from
usernames.
You
can
imagine
people
when
they're
typing
their
username.
They
want
to
see
it
as
they're
typing
it,
but
that's
not
what
you
want
for
passwords.
You.
B
You
want
that
to
be
hidden
as
you're
typing
it.
You
don't
want
to
just
see
your
password
in
plain
access,
you're,
writing
it
and
there's
actually
a
built-in
go
standard
library
function
called
read
password
that
hides
local
echo
so
that
you
don't
have
that
displayed
as
you're
typing
it
and
other
than
that.
It's
it's
kind
of
similar.
A
B
Yeah,
oh
and
then
the
yeah.
The
last
step
here
is
yeah
we're
gonna
package
the
token
into
an
exec
credential,
which
is
the
format
expected
by
clientgo.
It's
going
to
this
is
using
glycos
libraries,
because
it's
in
golang,
which
is
pretty
handy.
We
take
that
token
that
we
get
back,
which
I'm
you
know,
kind
of
gonna
hand
wave
over,
because
that's
pretty
specific
to
oidc
and
you'd
do
that
differently.
A
A
It
allows
for
richer
support
for
authentication
protocols
such
as
like
request
signing
protocols,
for
example,
awsv4
or
you
know,
kerberos,
and
I
kind
of
think
of
it
as
like
the
counterpart
of
authenticating
proxies,
which
is
a
model
for
extending
kubernetes
authentication
that
you
know
some
users
use,
and
that
concludes
our
content.
So
these
slides
will
be
posted
on
the
website
if
you
guys
want
to
click
through
to
on
any
of
the
links
that
you
saw,
but
so
we
have,
we
have
a
slack
channel.
A
A
D
A
Yeah,
I
I
think
I'd
recall
this
github
issue
so
that
the
idea
was
initially
to
on
401
to
re-exact
the
plug-in
and
that
had
keeping
track
of
you
know.
Multiple
clients
within
a
process
has
been
a
problem
but
yeah.
Basically,
we
try
to
fix
those
as
we
find
them,
like
people
creating
two
clients
with
two
authenticators,
but
sometimes
those
re-creep
in
and
we
don't
have
like.
We
haven't,
figured
out
a
holistic
solution
for
it.
Yet
so
just
file
github
issues
and
yeah
all.
E
E
F
A
Yes,
so
that's
a
great
question,
so
I
I
think
like
if
we
were
trying
to
accomplish
this,
for
just,
for
example,
like
cert
manager,
maybe
a
csi
driver
makes
sense
because
then
you
know
somebody
can
accomplish
that
auditory.
I
think
my
main
motivation
for
implementing
stuff
within
the
kubernetes
code
base
is
one
to
make
use
of
it
in
quark
kubernetes.
So
we
have
serp
bundles
that
we
are
distributing
to
every
single
name
space
and
that
does
present
a
scalability
issue
with
kubernetes
itself.
A
A
So
I
guess
at
a
high
level,
you
know
if
we
want
to
use
it
from
like
core
api
groups
or
for
a
core
functionality
of
kubernetes.
We
usually
try
to
implement
an
entry
and
then
otherwise
definitely
prototype
outside.
Until
you
know,
we
find
some
rationale
to
bring
it
in.
Maybe
the
other
motivation
might
be.
If,
like
everybody
in
the
world,
is
using
a
specific
out
of
tree
thing,
then
it
probably
makes
sense
to
bring
it
in
street
yeah.
F
Hey
thank
you
for
the
nice
presentation
in
the
demo.
I'm
very
excited
about
that,
because
I'm
working
on
something
similar
at
the
moment
for
for
2fa,
especially
because
that's
something
also
a
little
bit
finicky
topic
on
the
command
line.
Usually
do
you
have
a
repo
or
some
docs
available
somewhere
with
this
kind
of
sample
code
that
you
just
showed
like
also
the
whole
workflow
with
like
both
on
the
client
side
and
then
also
the
server
side?
Maybe
what
needs
to
be
done
there
and
what
needs
to
be
set
up.
C
B
So
a
lot
of
the
the
client
side
code
is
taken
from
the
project
that
I
work
on,
which
is
piped,
although
I
should
warn
you
there's
a
lot
of
other
like
complicated
stuff,
that's
hidden
away
there.
I
don't
know
if
you
have
a
better
answer
for
some
of
the
you
know,
the
sample
of
a
web
hook
authenticator
and
that
side
of
things.
A
So
that
link
on
the
bottom
is
the
kep:
it's
actually
fairly
thorough
documentation
on
the
design
of
these
plugins
and
how
like
we
expect
them
to
work.
I
think
we
should
probably
also
add
to
this
slide
a
link
to
your
the
code
that
you
walk
through,
which
is
on
github,
and
then
we
will
post
these
slides
on
the
schedule
after
this
so
yeah,
another
okay,
we're
out
of
time.
So
if
you
have
other
questions,
just
come
grab
me
I'll,
be
right
outside
awesome.
Thank
you
so
much
everyone.