►
From YouTube: Kubernetes SIG Auth 20180404
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20180404
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
A
B
C
D
So
basically,
I've
been
doing
a
threat
model
review
internal
to
Red
Hat,
and
out
of
that,
we
identify
one
area
for
improvements
to
be
to
implement
the
kms
interface
that
landed
in
in
Cuba
was
yeah,
and
so,
but
one
of
the
things
that
we
realized
was
that
we
had
a
lot
of
systems
we
wanted
to
integrate
with.
That
did
not
have
easy
access
to
GRCC
for
a
variety
of
reasons,
and
we
also
identified
that
basically,
the
workflow
for
all
of
them
was
pretty
much
the
same.
D
What
was
that
we
needed
to
have
access
to
a
key
encryption
key
and
we
needed
to
do
perform
encryption
using
that
key
encryption
key
we
needed
to
cache
it,
and
then
we
needed
to
periodically
refetch
it.
So
so
what
we
came
up
with
was
this
app
called
sin,
though,
which
basically
does
the
GRE
see
bits
to
kubernetes
and
then
we'll
execute
a
command
that
the
administrator
can
specify
in
order
to
fetch
the
key
encryption
key,
and
then
it
does
all
of
the
encryption
stuff
internally
and
will
periodically
refresh
the
key
encryption
key.
D
One
particular
example
we
gave
there
is
with
the
Red
Hat
project
called
clevis,
which
is
a
project
for
doing
automated
decryption
policies
that
are
geographically
verified,
rather
than
being
a
special
process
which
which
can
make
decisions.
So
that's
one
particular
implementation,
but
you
can
plug
your
own
implementation
here.
There's
nothing
specific
to
the
clevis
project,
so
I
think
that's
pretty
much.
It
yeah.
C
So
idea
another
example
which
we
haven't
necessarily
add.
It
would
be
like
actually
corpse
Walt
the
ability
to
fetch
a
key
from
them
would
work
just
as
well.
Otherwise,
let's
see
if
I
you
guys
now
see
a
terminal
I'm
hoping
that
if
I
just
move-
and
we
do
okay,
so
so
I
have
a
little
cluster,
a
grenades
cluster
that
is
configured
to
use
the
chemists
interface
and
then
this
little
file
has
a
presume
secret
key,
which
is
obviously
not
secure,
so
as
just
a
little
demo.
C
C
C
Convert
these
secrets,
but
that
so
it
is
going
really
slow.
Okay,
there's
my
secrets,
so
we
have
some
secrets
in
a
TV
right,
so
one
of
the
fun
ways
that
you
can
see
that
this
is
actually
doing.
Something
is
if
I
come
back
over
here
and
kill
system
D
and
then
go
back
to
this
you'll
notice
that
it
can
only
like
decrypt
a
partial
list.
I'm
actually
surprised
it
can
decrypt
more
I
might
not
fully
catch
some
stuff.
C
C
If
we
create
a
secret,
while
we
had
a
watch
going,
we
will
see
that
we
can
see
the
envelope
prefix.
The
name
of
our
cam
adds
the
size
of
the
data
encryption
key,
a
prefix
that
so
they'll
add.
So
it
can
figure
out
what
it
did
with
your
stuff
and
then
the
data
encryption
key
and
the
actual
stuff
I
think
that's
it
yeah,
that's
pretty
much
it
thoughts.
Questions
concerns
comments,
looks
awesome.
D
We
haven't
measured
performance
yet,
which
is
one
thing
one
of
the
things
we
need
to
do.
We
want
to
understand
exactly
what
the
performance
hit
is
of
enabling
the
system.
So
one
of
the
things
we
did
is
we
had
a.
We
have
a
secret,
no
off
mode
where
it
will
just
pass
back
plaintext
to
kms
through
the
kms
interface,
so
that
we
can
just
measure
the
raw
impact
of
going
through
the
entire
KNX
interface.
I'll,
probably
put
some
debug
stuff
into.
A
But
the
the
reason
I
wanted
to
call
it
scheduling.
Policy
here
is
I
think
that's
kind
of
the
next,
the
next
policy
that
we're
going
to
be
adding
to
kubernetes
as
a
first-class
citizen,
and
so
this
is
becoming
a
bit
of
a
a
place
for
us
to
start
laying
out
what
shape
we
want
policies
in
communities
to
take
in
the
future.
A
A
A
B
A
lot
of
the
things
that
kubernetes
does
around
like
using
labels
and
letting
topology
be
arbitrary
and
letting
you
use
topology
for
different
things,
so
you
can
use
it
to
represent
like
availability
or
locality
or
security
boundaries
like
it's
really
flexible,
but
then
turning
it
around
and
saying,
oh
well.
We
obviously
want
to
manage
the
security
aspects
one
way
and
the
availability
aspects
another
way,
but
they're
both
kind
of
reusing
this,
this
common
mechanism,
so
the
flexibility
of
the
way
if
your
entities
does
some
of
this
is
wonderful,
but
also
gets
really
tough.
E
I
just
wanted
to
give
a
heads
up:
I
think
that
we
are
on
track
to
remove
external
ID
from
the
cloud
provider
interface
for
111
and
that's
the
PR
six
zero.
Six
nine
two
I
think
is
waiting
for
approval
and
package
cubelet
and
follow-up
PR,
which
is
six
one.
Eight
seven
seven
will
remove
it
from
the
API,
which
is
not
approved
and
still
needs
to
be
reviewed,
so
I
might
be
poking.
E
So
node
has
permission
to
delete
itself
right
now,
which
is
problematic
for
strong
excusing
taints
for
a
strong
exclusion.
For
example,
if
you
wanted
to
add
8
compromised
taint
to
a
node,
the
node
right
now
could
just
delete
its
node
object
and
recreate
itself,
and
it
would
no
longer
have
that
taint,
so
they're,
not
particularly
useful.
E
They're
worse,
where
would
happen,
but
six
zero?
Six
nine
two
removes
those
situations
they
would
happen
during
upgrades
of
the
controller
manager.
Basically
from
older
versions
like
1.2
to
1.3.
Changed
AWS
is
a
external
ID
which
required
their
notes
to
delete
themselves
and
yeah.
So
we're
happy
to
close
down
this
gap
that
we've
had
for
so
long
in
1.11.
A
E
So
basically,
it
the
semantics
weren't
completely
consistent,
there's
another
field
called
instanceid
which
for
I,
think
half
of
the
cloud
providers,
the
external
ID
method,
just
called
instanceid
for
a
couple
of
the
cloud
providers
that
they
called
the
external
entity
called
instanceid
added
a
slash
and
GC
in
AWS
we're
doing
something
a
little
weird,
but
the
the
first
PR
in
that
list
moves
all
callers
to
use
instance,
ID,
which
is
not
difficult.
If
I
understand
correctly.
Yes,.
B
E
B
The
immutability
of
the
field
was
the
big
issue
so
now,
if
node
comes
up
and
whatever
method
it's
using
to
determinants
and
since
ID
has
changed,
it
can
just
update
it.
There's
kind
of
ongoing
discussions
around
provider
ID
and
instance
ID
stuff,
and
whether
the
data
in
the
API
is
the
source
of
truth
or
whether
that's
just
an
optimization
to
let
you
easily
find
the
instance
ID
and
then
kind
of
verify
it
once
you've
found
it
in
the
cloud
provider
database,
but
those
are
sort
of
secondary
discussions.
H
The
supported
ways
right
now
are
either
a
manual
table,
so
no
creates
a
CSR,
and
then
operator
comes
in
many
other
fruits
or
I
using
a
Umberto
c'n,
which
just
the
session
of
a
bird
talking
grants
any
machine
the
ability
to
create
a
CSR
get
approved,
and
essentially
during
the
cluster.
That
is
not
perfect,
because
this
duggan
can
be
exfiltrated
and
it
doesn't
generally
expire,
even
though
you
can
make
expire.
H
So
the
proposal
is
adding
a
TPM
and
mix
which,
for
if
you
in
case
you're,
not
familiar
it's
a
hardware
firmer
or
software
device
that
essentially
keeps
all
the
crypto
secrets
of
private
keys
within
its
boundaries
and
expose
this
set
of
operations
like
sign
and
crept,
and
so
on.
It's
generally
slow
and
doesn't
have
a
lot
of
storage,
but
it's
good
to
protect
sensitive
data.
H
H
But
that
requires
implementing
a
crypto,
signer
interface
and
go
using
TPI
operations,
which
has
to
be
done
either
prickling
process
or
could
be
done
some
using
some
external
signing
interface.
But
that's
like
another
whole
thing:
that's
not
currently
implemented
in
people
it
yeah.
This
whole
design
is
not
salvageable
sumerians
or
any
questions.
Its
friends.
G
G
This
was
created
by
known
XYZ,
based
off
how
you
authenticate
that
the
issues
with
this
seem
to
be
so
that
that
strategy
seems
to
work
right
now,
except
for
the
fact
that
the
PRS
that
we
have
in
flight
for
adding
TLS
support
to
the
the
client
or
that
the
exact
plugins
require
you,
give
a
private
key
to
handover.
A
private
key
in
memory
to
client
go.
Have
you
considered
anything
alternative
like
having
that
private
key
signing
a
bearer
token
and
then
a
short-lived
bearer
token?
And
then
using
that,
instead
to
authenticate
against
the
APS
I.
H
So
I
think
that
still
has
the
same
problem.
I
agree
that
having
an
exact
alpha
game
that
uses
some
sort
of
cloud
specific
API
to
prove
identity,
there's
another
possibility
to
the
same
thing.
It
doesn't
work
outside
of
cloud
environments,
so
the
TPM
stuff
could
be
implemented
on
any
on
from
cluster.
B
H
E
Boring-Ass
is
also
also
supports
the
crypto
engine,
but
it
all
it
supports
something
called
a
split
handshake
where
handshake
messages
in
a
TLS
session
are
passed
to
a
external
server,
and
that
way
the
entire
handshake
is
offloaded
and
the
eventual
symmetric
encryption
channel
is
is
I,
guess
they're.
The
key
for
the
symmetric
encryption
general
was
eventually
handed
off
to
the
actual
process,
and
the
process
then
continues
to
the
TLS
session.
B
Eric
as
as
we're
looking
at
the
x.509
pieces
where
the
external
exec,
it
would
probably
be
worth
kind
of
surveying
the
the
methods
people
are
using,
that
don't
involve
handing
over
the
private
key
and
just
thinking
about
how
you
might
indicate
that
one
of
those
would
be
used
instead
in
the
future.
If
we
wanted
to
add
in
support
for
those
in
the
response
from
the
exact
plugin
yeah.
G
There
was
a
small
amount
of
conversation
on
one
of
the
PRS
of
this
I.
Don't
know,
I
think
it
would
require
something
like
basically
just
implementing
the
signer
interface
with
the
designer
interface
through
these
messages
that
are
being
passed.
So
everything
starts
looking
kind
of
it's
a
pretty
pretty
big
change
should
sort
of
the
flows
that
would
go
through
that
exact.
I
I
I'm
a
little
concerned
that
this
TPM
specific
bits
are
a
little
overly
specific
and
that
it
would
be
better
to
find
an
extension
mechanism
that
also
supported
other
kinds
of
attestation.
Like
Eric
mentioned,
like
the
cloud
provider
models
where
you
have
to
do,
some
funky
API
call
and
get
a
token
or
something
like
that.
In
the
end,
you
could
still
take
some
kind
of
assertion
document
and
bind
it
into
the
CSR,
and
then
this
TPM
thing
is
just
one
example
of
that.
We.
G
I
G
Having
them
this
for
its
really
some
of
the
AWS
stuff,
we
were
kind
of
skeptical
about
putting
any
data
like
that
into
the
CSR,
because
it's
often
not
it's
often
just
like
some
symmetric
document
that
you
you
have.
So
that's
not
data
you're
able
to
make
public,
which
is
why
we
were
stopped
going
on
the
route
saying
that
authentication
actually
works
or
doing
this
at
the
authentication
layer
with
some
credentials
works
really
well,
because
then
we
don't
have
to
publicly
make
available
like
the
true
signed
document
or
something.
H
Gross
another
issue
with
that
is
you
essentially
sign
the
public
key
in
the
certificates
in
order
to
actually
validate
that?
Whatever
thing
that
does
well,
they
shouldn't
have
to
read
the
tower
body
of
the
CSR,
which
I
believe
the
current
like
authentication
the
authentication
pieces
on
the
API
server.
Don't
generally,
they
only
look
at
the
headers
and
yeah
my
ex
correct,
it's
like
in
this
specific
design,
it's
extra
three
pen
blocks.
So
that's
a
lot
of
data.
E
G
And
just
while
we're
here,
so
we
should
definitely
talk
more
about.
You
know
ways
of
introducing
more
information
to
the
csr,
buy
it
while
we're
here
and
we
have
a
PR
with
who
looks
good
to
me
about
the
client
certs
is:
do
we
want
to
hold
off
on
that
PR
well,
we're
still
discussing
and
how
we're
going
to
deal
with
keys
that
we
don't
have
access
to
or
do
we
want
to
see
that
true
I
think.
B
Definitely
seen
requests
for
ways
to
protect.
Clients
hurts
so
they're,
not
just
plain
files
on
disk,
so
whether
that's
running
them
through
no
gbg
years,
like
some
some
encryption
layer.
That
requires,
like
an
initial
session
password
to
unlock
it
and
then
can
only
be
accessed
to
be
a
you
know,
a
script
that
goes
to
the
gbg
tool
or
some
some
agent
that
is
unlocked
and
so
adding
TLS
clients
or
support
for
the
exec
plugin.
It
helps
with
those
cases
a
lot
like
where
you're,
not
interacting
with
the
TPM.
B
E
E
So
what
that
means
is
it'll
look
and
act
a
lot
like
the
current
secret
volume
that
we
used
to
use
to
get
tokens
to
pods,
but
it'll
use
the
new
API.
So
the
only
I
think
the
weakest
part
of
the
proposal
is
probably
how
we
we
deliver
the
CA
certificate,
which
is
required
to
maintain
backwards
compatibility
to
that
old
secret
volume
right
now.
It
also
proposes
something
called
a
public
config
map
projection
where
we
look
for
config
map
in
the
cube
public
namespace,
which
we've
used
elsewhere
and
then
a
the
I
guess.
E
So
if
anybody
has
ideas
on
how
to
improve
that
without
going
down
the
path
of
figuring
out
cross
namespace
config
map
reference,
I
don't
want
to
block
on
that
discussion,
because
I
think
we've
talked
about
that.
For
a
couple
of
years
now,
definitely
please
help
weigh
in
on
the
design
of
this
I'm,
going
to
also
present
this
at
the
next
six
storage
meeting,
which
is
Thursday
after
tomorrow.
A
B
B
Somehow
I
think
what
we're
trying
to
do
is
remove
the
need
to
duplicate
the
see
a
bundle
in
10,000
places,
and
so
it
seems
like
the
trust
bundle
to
talk
to
the
API
is
something
that
the
cubelet
should
be
responsible
for
delivering
and
so
having
that
information
in
one
place
and
either
having
an
indication
in
the
API
that
that
should
be
injected
into
a
pod
or
having
that
be
implicit
along
with
the
service
account.
So
in
volume
is
kind
of
where
we're
where
we're
going.
E
B
E
A
A
The
main
thing
that
I
wanted
to
call
out
here
is
this.
Now,
since
each
CRI
implementation
is
now
serving
these
streaming
requests,
they
need
to
have
serving
certificates
for
the
API
server
to
talk
to
them
debatable
whether
there
should
also
be
a
client
certificate
flow.
The
URLs
that
are
returned
are
one-time,
use
randomly
generated
tokens,
so
that
should
be
sufficient.
I
think.
B
D
B
A
So
the
simplest
option
is
presented
here
as
require
or
option.
One
I
guess
is
to
basically
say
you
know
this
is
all
too
complicated.
Let's
forget
this
whole
redirect
flow
and
just
keep
the
cubelet
as
a
proxy
hop
and
the
CRI
streams
to
the
cubelet
over
a
UNIX
domain
socket
and
then
they
we
just
rely
on
the
couplet
two
API
server
mutual
TLS.
A
For
that
the
problem
here
is
you
do
have
that
extra
fought
through
the
cubelet
and
resources
get
attributed
there.
I,
don't
think
I
think
there
was
some
original.
Originally
some
concerns
about
this
I'd
like
to
see
some
benchmarking
on
what
the
actual
overhead
looks
like
or
I.
Guess
there
is
some
here
actually,
but
my
thinking
is
sort
of
like
this
is
a
debug
flow
and
shouldn't
be
used
for
high
volume
production
traffic.
I.
A
Option
to
is
basically
to
do
a
hybrid
approach.
I
forgot
to
mention
that
another
concern
about
this
is
the
cry.
Cuddle
tool
is
for
local
debugging
and
needs
to
be
able
to
connect
to
the
streaming
server
using
only
credential
or
using
a
flow.
That's
on
the
localhost.
Just
for
surely
for
like
debug
maintenance
of
the
cluster
option.
2
is
sort
of
a
hybrid
one,
I
I
think
it's
probably
more
complicated
than
we
want
and
then
option
three
is
about
keeping
this
redirect
flow
and
figuring
out
a
way
to
get
serving
credentials
for
the
CRI.
H
A
A
A
E
E
E
B
Yeah
I
think
the
trickiest
part
would
be
knowing
making
sure
that
the
API
server
had
visibility.
Network
visibility
to
the
endpoint
being
serviced
by
the
CRI
is
right.
Now
we've
got
one,
maybe
two.
If
you
care
about
both
of
the
cubelet
ports,
that
you
have
to
make
visible
and
so
yeah
becomes
the
new
ports
that
firewalls
and
network
rules
and
whatever
else
has
to
make
sure
they
have
yeah.
That.
A
E
B
I
I
mean
a
lot
of
the
ways
that
these
end
up
getting
run
like
you
end
up
having
something
in
between
in
the
network
that
keeps
this
from
turning
into
like
a
persistent
production
level
high-volume
tool
anyway,
and
so
it's
much
more
typical
for
it
to
be.
Let
me
jump
in
and
like
run
a
couple,
shell
commands
or
like
copy
a
file
out.
Not
this
is
what
I'm,
using
to
like
tar,
multi-gigabyte
backups
off
of
my
database
pod
like
it's
just
that's
just
not
what
people
are
using
it
for
yeah.
E
A
D
A
A
A
B
B
A
A
Yeah
and
so
then,
the
the
separate.
The
second
role
is
a
technical
lead,
and
this
is
kind
of
actually
providing
technical
leadership
for
the
sig,
and
so
things
like
establishing
new
sub
projects.
Decommissioning
existing
sub
projects
generally
things
that
are
sort
of
like
fall
within
the
sig
off
umbrella,
but
are
sort
of
maybe
cross-cutting
issues
that
don't
fall
neatly
into
a
specific
sub
project
area.
A
The
technical
leads
would
be
an
escalation
point
for
issues
and
help.
You
know
roadmap
and
think
about
some
of
the
broader
issues
within
the
sake,
and
also
the
contacts
for
cross
sig
issues
there
and
we
put
a
number
sort
of
arbitrarily
at
three
to
seven
for
technical,
leads
and
so
I
think,
historically,
we've
sort
of
had
the
the
chair
and
the
technical
lead
as
a
single
role
of
Sigma
the
lead,
and
we
are
so
now
we're
splitting
those
into
two
separate
ones
and
growing.
The
growing
the
space
for
technical
leadership.
B
Just
to
note
that
this
is
basically
a
tweaked
version
of
the
short
form
template
that
is
being
followed
by
most
of
the
SIG's.
So
if
you
are
interested,
there's
I
think
there's
a
link
to
that
in
the
poll,
so
you
can
kind
of
see
where
we
tweaked
language
or
kind
of
clarified
some
things
adapted
it,
but
in
general
this
is
following
that
pretty
closely.
A
You
know,
and
then
the
third
kind
of
leadership
role
is
the
sub-project
owners,
and
so
these
are
the
kind
of
more
narrowly
scoped
leads
of
the
specific
sub
projects.
We
haven't
really
defined
sub
projects.
Here
we
tend
to
follow
it
up
with
a
document
describing
more,
but
some
projects
are
how
they're
organized
and
how
they
should
be
run,
but
these
would
be
sort
of
the
like
domain-specific
experts
for
the
different
areas
within
sigilyph
and
a
lot
of
the
there's.
G
And
just
to
give
a
sense
of
what
a
sub
project
is
for
other
sakes.
This
might
be
something
that's
like
an
external
project
to
that
saying,
like
cluster
lifecycle,
has
a
lot
of
things
like
koobideh
and
we
saw
sub
projects
as
being
sort
of
a
lot
of
the
entry
implementations
like
the
authenticators
or
some
of
the
token
request,
work
or
something
like
that,
so
think
of
it
more
as
the
bits
that
we
own
already,
rather
than
new
projects
that
are
being
spun
out
of
Cooper
Deniz
yep.
A
We
have
a
list
I
can't
pull
it
up
right
now
of
kind
of
sub
projects
that
we're
thinking
about
at
the
moment.
So
this
includes
things
like
audit
logging,
the
policy
area,
authentication
authorization
authentication
may
be
broken
up
into
smaller
areas,
new
it
isolation,
but
we
will
we'll
follow
up
that
discussion
in
more
detail
at
a
later
date.
A
The
the
privileges
that
membership
comes
with
is
sort
of
a
voice
in
broad
SiC
direction.
If
we
ever
need
to
invoke
voting,
members
would
be
the
ones
to
vote
in
for
different
roles,
but
generally,
this
is
just
a
way
to
have
some
formal
recognition
of
sustained
and
valuable
contributions
to
the
project.
B
It's
also
helpful
to
know
like
how
many
people
are
there
that
are
able
to
help
in
this
area
so
for
planning
purposes.
You
know
if
there
are
one
person
who
is
interested
in
this
area
and
they
haven't
been
very
active
and
we
should
know
not
to
plan
on
lots
of
work
getting
done
in
that
area.
But
if
there's
20
people
that
are
responsive
than
it
helps
knowing
that.